Преимущества в производительности при хранении документов в формате JSON в MarkLogic 6

На диске MarkLogic хранит сильно сжатые структуры данных C ++, которые представляют иерархические деревья и соответствующие индексы. (Хорошо, это чрезмерное упрощение, но тем не менее иллюстративное.) Есть два места, где вы, как разработчик, обычно будете взаимодействовать с этими структурами данных: 1) создание запросов и логики приложения 2) десериализация / сериализация данных в этот внутренний модель данных. Сегодня MarkLogic использует модель данных XML (XDM) для последнего и, соответственно, XQuery, XPath и XSLT для первого. Мы выбрали этот стек по нескольким причинам: XML хорош для представления как текстовой разметки, так и структур данных, а инструменты для XML являются зрелыми и широко распространенными.

При этом JSON превратился в популярную сериализацию иерархических структур данных - «X» в AJAX. Хотя сегодня у нас нет такой же водонепроницаемой абстракции между JSON и внутренней моделью данных MarkLogic, мы предоставляем набор инструментов, которые позволяют вам эффективно и без потерь конвертировать между JSON и моделью данных XML. Кроме того, наши API-интерфейсы REST и Java позволяют хранить, извлекать и даже запрашивать древовидные структуры, созданные как JSON, не задумываясь об этом этапе преобразования; API обрабатывают это в сантехнике.

Что касается производительности, преобразование между JSON и XDM представлением будет связано с небольшими накладными расходами. Однако я ожидал, что для большинства приложений это будет незначительным. Настоящие преимущества XML заключаются в выразительности XQuery, XPath и XSLT при работе с данными. Сегодня в мире JSON нет широко распространенного эквивалента.

MarkLogic является родным для XML, и ему необходимо преобразовать JSON в XML, чтобы сохранить его в базе данных. Для выполнения преобразований существует высокоуровневая библиотека JSON. Основными функциями являются json:transform-to-json и json:transform-from-json, и при правильной настройке должны обеспечивать преобразование без потерь.

Я думаю, что основное отличие от вашего примера заключается в том, хотите ли вы преобразовать в XML с помощью собственного процесса или использовать инструментарий MarkLogic.

Для получения более подробной информации см. Документацию MarkLogic: http://docs.marklogic.com/guide/app-dev/json

Одно примечание: REST API (и, следовательно, оболочка Java API вокруг REST API) предоставляет фасад для преобразования JSON в XML, то есть API выполняет преобразование в XML за вас.

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

Если вам нужно поддерживать документы JSON в вашем клиенте, то фасад удобен.

С другой стороны, представление структуры в виде JSON не имеет преимуществ для операций с базой данных и некоторых ограничений. (Например, XML имеет основанные на стандартах запеченные атомарные типы данных, проверку схемы и серверную обработку с помощью XQuery или XSLT.) Итак, если у вас есть полный контроль над структурой данных, вы можете захотеть записать ее на сервер как XML.

Начиная с MarkLogic 8 (февраль 2015 г.), JSON теперь является собственным типом данных, как и XML. Это устраняет необходимость в слое перевода для приложений, которые хотят работать исключительно в JSON. Кроме того, мы добавили JavaScript в качестве первоклассного языка в самой базе данных (с использованием Google Двигатель V8). Это означает, что вы можете писать хранимые процедуры, триггеры и даже полные HTTP-приложения с помощью JavaScript, который выполняется в базе данных, рядом с данными.