Почему именно файлы на файловую систему, а не просто писать в СУБД?

Потому что производительность нужна.

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

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

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

Ты её явно не там ищешь.

Горшочек не вари.

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

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

жейсонов

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

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

Да, есть такой модуль в ядре Linux, называется PostgreSQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты придумал БД.

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

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

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

жырновато

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

до 100б

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

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

BerkleyDB -> BerkeleyDB

Самофикс

BerkleyDB

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

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

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

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

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

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

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

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

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

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

MUMPS бери

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

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

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

парсер 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.

в качестве реализации MUMPS можно взять GT.M

мануал по установке GT.M

саму VistA тебе ставить не нужно, только GT.M + пример повозиться с JSON

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

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

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

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

https://habrahabr.ru/company/mailru/blog/317274/