Комментарии 13
Прежде чем автор ответит на вопрос, скажу что нас, как заказчиков грантового исследования, интересовала прежде всего проверка реализуемости такого сценария: приложение работающее с Mongo переключается на Caché и продолжает прекрасно работать, не зная о том, что оно уже работает не с Mongo. Интересно нам это было как еще один факт подтверждения мультимодельности СУБД InterSystems Caché.
Автор может сказать и показать о производительности что-то конкретное с цифрами, но это некоторая субъективная история именно этого проекта и по большому счету ничего не значит и не было официальной задачей проекта. Очевидно, что в другом подобном проекте с производительностью может быть все иначе.
Т.е. это официальный дисклеймер, что все упомянутые цифры не носят никакого официального характера.
А немного связанный с предыдущим, но отдельный вопрос — базы данных это не только про соединение и сохранение объектов, но и про поиск. Очень важная часть Mongo API это работа с aggregation pipeline. Насколько хорошо это спроецировалось в вашей реализации? (Ну, т.е. я вижу упоминание операций, и делаю вывод, что скорее всего, это так или иначе работает, но есть вопросы) Подхватываются ли индексы при вычислении агрегатов на стороне Caché, как делается сортировка, вот это вот все? Есть замеры?
Очень важная часть Mongo API это работа с aggregation pipeline. Насколько хорошо это спроецировалось в вашей реализации?


Если вы имеете ввиду Aggregation
Pipeline
, то в данной реализации это не поддерживается.

Подхватываются ли индексы при вычислении агрегатов на стороне Caché, как делается сортировка, вот это вот все?


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

Есть замеры?


Замеры проводились но, как уже было сказано выше intersystems эти цифры носят частный характер. Могу провести отдельные замеры по интересующим вас сценариям.
Да, недостатки такой схемы понятны с самого начала, т.к. аналогичных механизмов хранения документов в иерархических массивах уже было много. На предыдущей итерации похожей дискуссии был приведен интересный XML документ, который бы хотелось попытаться сохранить в предлагаемой схеме трансляции JSON (мы ведь понимаем, что XML и JSON часто эквивалентные способы сериализации иерархии объектов?)
https://habrahabr.ru/company/intersystems/blog/264173/#comment_8533249

Подробно не расписывал и не подсчитывал, и думаю в предел subscript-ов не упремся, но было бы интересно посмотреть.
И именно по этой причине в проекте DocumentDB на базе движка Cache' (первый видимый результат этого проекта вы можете увидеть уже сейчас в 2016.1 — нативная поддержка JSON в языке, о чем недавно рассказал Штефан Витман на developer community портале), именно по этому схема хранения вложенных коллекций документов будет не простая проекция на иерархический массив, а специализированная структура данных «packed vectors array». О чем мы расскажем при случае.
А вы не думали оформить проект в виде storage engine? Тогда и интерфейс не нужно будет воспроизводить и сравнивать с остальными движками будет проще.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.