LINUX.ORG.RU

Модуль для записи гигантского количества файлов на жесткий диск

 , , ,


0

3

Стоит задача сохранения небольших джейсонов (до 100б) на жесткий диск. Приблизительно 20000 джейсонов в секунду. Думал о двоичном дереве на жестком диске с хешированием (хеш формирует набор подкаталогов). Если кто-то сможет что-то посоветовать лучше или что-то почитать буду очень признателен.


освой базы данны

просто трясет с подобных идиотов «а вот ваша ФС не умеет/не может»-когда есть и уже 40 лет существуют инструменты под задачу

anonymous
()
Ответ на: комментарий от anonymous

Лорчую. А еще бы подумал сразу про распределение нагрузки на несколько машин. Х его З что может быть и куда его занесет.

deep-purple ★★★★★
()

Можешь попробовать на рамдиск писать, но боюсь, что и там всё в обновление метаданных упрётся.

Вангую архитектурные проблемы системы.

Radjah ★★★★★
()

жейсонов

Это формат для передачи данных. Тебе же нужны данные, а не джейсон? Вот. Я бы парсил и писал в БД.

anonymous
()

Писать велосипед - это всегда весело. Одобряю. Но ТС ничего не сказал о характере работы с этими данными. Будет иметь место постоянная запись и очень редкое чтение, или будут постоянные добавления/удаления джейсонов в случайных местах.

pathfinder ★★★★
()
Ответ на: комментарий от zolden

Мы не знаем что там за задача у ТС.

База данных потянет за собой ещё одну зависимость, которая потребует дополнительной нагрузки в развертывании, конфигурировании и сопровождении.

Иногда эта доп. нагрузка всех устраивает, иногда нет. А вдруг ТС нужно написать небольшую автономную утилиту которая просто делает свою работу не напрягая пользователя установкой всяких постгрессов.

pathfinder ★★★★
()

JSONы парсить и писать в базу данных, СУБД тебе нужна, а не файловая система.

Alve ★★★★★
()
Ответ на: комментарий от ECLIPSE

Осиль СУБД и заживешь. Если юзать классические реляционные бд — недостаточно по-хипсторски и ты хочешь хранить именно JSONы, открой для себя Mongo. Твои 20к/с — мелочь

mersinvald ★★★★★
()
Ответ на: комментарий от Alve

При такой нагрузке? СУБД не потянет такую сумасшедшую нагрузку это терабайты данных на рейд массивах. Я не собираюсь использовать СУБД для этой задачи.

ECLIPSE
() автор топика
Ответ на: комментарий от ECLIPSE

Сколько терабайт в секунду? В чём вообще проблема?

anonymous
()

PostgreSQL с JSONB, даже ничего парсить не придется

anonymous
()
Ответ на: комментарий от ECLIPSE

При такой нагрузке? СУБД не потянет такую сумасшедшую нагрузку это терабайты данных на рейд массивах.

Сразу видно профи, который изучил все возможность БД, коих тысячи.

А да. 20к жейсонов по 100 байт это вообще не нагрузка. та же монга даже не напряжется. А отстроенный постгрес тебе на порядок больше позволит писать.

ну если сильно охота велосипед - то B-tree и его варианты. походи по граблям, по которым уже до тебя походили :D

anonymous
()
Ответ на: комментарий от ECLIPSE

Ничего сумасшедшего не вижу. Правда, я почти уверен, что можно уменьшить твои данные, хорошо проанализировав задачу. Тебе весь тред говорит, чтобы брал субд, а ты не веришь.

Alve ★★★★★
()

с такой постановкой вопроса — /dev/null, быстрее ничего нет

anonymous
()
Ответ на: комментарий от ECLIPSE

Я если честно не понимаю как вы можете советовать мне базу данных при такой нагрузке.

Раз тебе не нужна база, то подойдёт запись всего в один файл

mashina ★★★★★
()
Ответ на: комментарий от mashina

Раз тебе не нужна база, то подойдёт запись всего в один файл

И этот файл /dev/null

Про MongoDB, Couchbase и др. уже упамянули.

beastie ★★★★★
()
Ответ на: комментарий от beastie

Не обязательно, так можно писать месяцами и потом что-то делать с данными за один проход по ним.

mashina ★★★★★
()

Модуль называется файл. Ведь у JSON вроде нет комментариев (плохо), то перед началом нового JSON добавляй строку ----- и станет ясно где разделяются файлы. И прям в файл откладывай. Один за другим. А другой файл - некую карту, по какому смещению тот или иной JSON в файле сидит. Так ты не перегрузишь файловую систему, но всё еще сможешь быстро читать.

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

И да, раз чтение редкое, даже во втором файле индексов будет прилично. Ну можешь там уже что-то посерьезнее придумать, например уже БД или иное, что позволит дерево хэшей быстро просматривать. Файловая система не рассчитана на это, так что пара файлов - основной + БД. Смотри как тормозит подобной в кэше браузеров, быстрее тупо картинку из сети дернуть чем из кэша порой.

I-Love-Microsoft ★★★★★
()
Последнее исправление: I-Love-Microsoft (всего исправлений: 1)
Ответ на: комментарий от I-Love-Microsoft

перед началом нового JSON добавляй строку ----- и станет ясно где разделяются файлы.

Это очень тупой и плохой совет. Писать, очевидно, нужно в бинарном виде длину записи, а не ставить маркер.

mashina ★★★★★
()
Ответ на: комментарий от mashina

Ну я обычно такие данные в бинарном виде и кладу - длина блок + блок. Согласен, однако я предлагал индексный файл - вот там уже не важно есть ли что-то текстовое вдобавок, но для просмотра вручную удобнее.

I-Love-Microsoft ★★★★★
()

Попробуй, определив статистику размеров файлов, сделать размер блоков ФС чуть больший среднему размеру файла.

anonymous
()

У мну идея! А что если на лету парсить эти JSON и класть в БД лишь значения. Ну какие там могут быть значения в этих крошечных JSON, однако обязательно ли их в таком же виде и хранить?

I-Love-Microsoft ★★★★★
()

BerkleyDB уже предлагали? Простая как топор и ты не осилишь сделать запись/чтение быстрее и надежность выше, я гарантирую это

anonymous
()
Ответ на: комментарий от anonymous

BerkleyDB

б-гмерская оракловщина.

20к по 100 байт даже SQLite осилит и не обосрется.

anonymous
()

Простой тест на питоне:

plain files - 1M files, time 254 sec, dir size 3,9G

couchbase - 1M files, time 125 sec, dir size 140 Mb

Базу никак не тюнинговал, поставил докер контейнер с ней. Без докера думаю будет еще быстрей.

Deleted
()
Последнее исправление: moon (всего исправлений: 1)
Ответ на: комментарий от ECLIPSE

Будет постоянная запись 20000 файлов в секунду. Чтение будет происходить очень редко.

ИМХО тут можно просто завести два файла. Один будет содержать индексы, хранящие смещение и размер (можно указатель на начало и указатель на конец) отдельного джейсона. Второй файл будет хранить сами джейсоны один за одним. Каждый новый джейсон можно дописывать в конец. Все должно работать очень быстро. А с массивом индексов можно сделать разное. Например, хранить их в нескольких файлах, группируя по критериям (например по дню или месяцу того момента, когда была сделана запись).

pathfinder ★★★★
()

Отдельные файлы ты со скоростью 20000 в секунду не создашь - после каждого close() ФС обязана сделать некоторые операции, которые трудно соптимизировать планировщиком io. Раз данные не нужно часто читать и лень парсить json и класть в нормальную базу - пиши в один файл, например сразу в tar. Каждую полночь будешь открывать новый.

PS 20000 файлов * 100 байт = 2мб/с - семечки.

legolegs ★★★★★
()

MUMPS бери

«кешируюший сервер глобалов и рутин»

«глобалы хранятся страницами в B-tree, страницы подкачиваются по требованию»

anonymous
()

Пиши в один файл, а не в 20000, и лучше бинарные данные, чем текстовые. Тогда будет быстро.

Deleted
()
Ответ на: комментарий от anonymous

парсер JSON для MUMPS

On Wednesday, March 25, 2015 at 1:03:53 PM UTC-4, Sid wrote:

Does anybody have a MUMPS Routine that parses JSON strings into an array or global?
Thanks

The most robust parser we found is part of the VPR codebase. See https://github.com/OSEHRA-Sandbox/Health-Management-Platform/tree/master/hmp/...

  JSONVPR>n VAR, JSON, ERR
  JSONVPR 1S1>s JSON="{""afield"":""avalue"", ""array"":[{""morefields"":""morevalues""}]}"
  JSONVPR 1S1>d DECODE^VPRJSON("JSON","VAR","ERR")
  JSONVPR 1S1>zw VAR
  VAR("afield")="avalue"
  VAR("array",1,"morefields")="morevalues"

Documentation is in VPRJSON.int.

anonymous
()
Ответ на: комментарий от ECLIPSE

Тотже mongodb делает 30000 инсертов / апдейтов в сукунду без рейдов на стареньком SATA винте на моем рабочем калькуляторе в один поток (Pentium G860). Cоздание файла на диске - дорогостоящая операция, СУБД будет явно быстрее ...

zaz ★★★★
()

В /dev/null пишите, вы эти данные всё равно не читаете.

P.S. Меняйте архитектуру системы. В тему.

anonymous
()
Ответ на: комментарий от ECLIPSE

2Мб/сек - сумасшедшая нагрузка? И где док-ва, что не потянет?

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.