JSON как формат экспорта БД

Question

Проблема. Мы записываем вещи в базу данных. Чтобы ограничить использование дискового пространства, мы экспортируем из базы данных в файлы, которые можно скопировать или просто удалить. Некоторая сила над мной хочет видеть это как JSON.

Я вижу отдельные файлы JSON как один объект. Так что в этом случае мы бы создали объект со списком сообщений журнала. Проблема в том, что в этом файле может быть несколько миллионов элементов журнала, что, я думаю, душит большинство анализаторов. Так что я думаю, что единственный способ сделать это для каждого элемента журнала - иметь свой собственный объект JSON.

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

Это звучит правильно?

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

Спасибо.

Answer 1

Вся идея JSON не может сосуществовать с хранением нескольких миллионов записей в файле ...

Весь смысл JSON состоял в том, чтобы устранить издержки, вызванные XML. Если вы записываете каждую запись как объект JSON, вы возвращаетесь к хранению служебных битов, которые не имеют смысла. Следующий логический шаг - написать обычный файл CSV с записью заголовка, которую все на планете понимают, как импортировать.

Если по какой-то причине у вас есть дочерние записи, вам следует посмотреть, как работает регулярный EDI.

Answer 2

Это верно, мне не удалось найти парсер json, который не требует, чтобы все это было сразу в памяти, по крайней мере, во время некоторой части процесса (у меня был дамп базы данных в формате json, который мне нужен разбор ... это был кошмар).

Обычный способ сделать это в настоящее время - стиль объекта или стиль csv

Стиль объекта:

{"name":"bob","position":"ceo","start_date":"2007-08-10"}
{"name":"tom","position":"cfo","start_date":"2007-08-11"}

и др.

CSV стиль:

["name","position","start_date"]
["bob","ceo","2007-08-10"]
["tom","cfo","2007-08-11"]

Вы теряете много места на диске со стилем объекта, но каждая строка самодостаточна.

Вы экономите место на диске в стиле csv, но ваши данные более тесно связаны с форматом, если вам не нужны вложенные структуры данных, такие как:

["bill","cto","2007-08-12",{"projects":["foo","bar","baz"]}]

Вы также можете использовать формат CSV.

Answer 3

Ваша стратегия звучит правильно: иметь отдельные объекты в JSON и генерировать / анализировать их с помощью стандартных инструментов JSON, а также самостоятельно решать проблему группировки вне JSON.

Помимо сброса всех данных в один файл, вы можете рассмотреть другие стратегии. Например, вы можете хранить каждый объект в отдельном файле или (если это чрезмерно, поскольку вы говорите, что у вас есть миллионы объектов) объединять их в файлы в разумных группах и именовать файлы в соответствии с некоторым идентификатором, который у вас есть для этих объектов либо просто первичный ключ (так что вы получите «0-10000», «10001-20000» и т. д.), либо что-то еще. Например, для записей в журнале будет подходящей дата / время. Таким образом, если какой-то бедной душе понадобится когда-нибудь использовать или изучить эти данные в любой форме, это немного более управляемо. А чтобы перевести эти файлы в архивный формат, просто сожмите их в один файл, JSON, поскольку текстовые данные должны сжиматься достаточно хорошо.

Answer 4

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

Это звучит правильно?

Это звучит разумно ... так что вы получите большой массив строк, разделенных переносами строк, каждая строка состоит из одного объекта JSON.