skyANAstopМонгу в 10+ раз и тд.
ну да, ну да... а где бенчмарки с участием различных движков MongoDB посмотреть, трёх-четырёх?

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

https://github.com/Bazist/DniproServer/blob/master/DniproDB/DniproDB/Test.h

На что способна ваша машинка с Днипро, можно узнать если в консоли запустить db.SelfTest()

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

Также если будете делать тесты, учитывайте пожалуйста, что Mongo не поддерживает ACID и Транзакции.
А также при добавлении документа, он не индексируется по всем полям ( кроме блоб ). Так что желательно это учесть в бенчмарках.

Со своей стороны скажу, что архитектура Монги неочень.
Эти bson-ы никуда не годятся.
У меня подходы совершенно другие и резульаты совершенно другие.

Такова специфика базы.
Наконец с пользователя снят головняк добавлять индексы.
Если индекс не нужен. Ну там картинка видео длинный текст - создавайте блоб.

По поводу размеров тут все специфично. Инвертация дает компрессию данных. На это можно найти много примеров. Но есть и оверхед в других примерах. Для разных данных он будет разный как и везде

Ну окей. Давайте начнем с азов.
Тут важно понять саму архитектуру.

Arm79Например, добавляется сложный иерархический и весьма объемный json.


Допустим у нас есть обьект, сложный, иерархический. Допустим это Джисон и занимает 1 мб.
В коллекции у вас таких джисонов допустим 100 тысяч.

Итак, берем формат

Arm79Кстати, в PostreeSql используется бинарный формат json. Вы анализировали?

И пытаемся понять, что у нас произойдет если мы захотим, допустим, вставить 1 млн атрибутов в середину ...
Один новый атрибут, для каждого документа. Очевидно что Монге или Постгресу прийдется идти и перезаписывать каждый такой бинарный джисон ! А сколько это займет времени ?
Не мало. Мегабайты прочитать и перезаписать. С некоторыми небольшими оптимизациями.

Вместе с тем Днипре достаточно просто вставить 1 млн ключей.
Днипра это сделает за считаные миллисекунды, разница буде в сотни раз с Монгой или Постгресом ...

Далее, тотже пример, с 100 млн джисонов нам нужно вычитать только по три аттрибута с каждого.
Что произойдет с бисонами и прочьим трешем ? Опять будем читать всё с небольшими оптимизациями ...

Днипре, вычитка нескольких ключей, опять шестизначные цифры в количестве запросов в секунду,
В Монге и Постгрю бинарный треш ...

Далее, компрессия. Днипра за счет инвертации будет хранить пути к атрибутам единожды, а Постгрес и Монга будет хранить дубли.
Документы однотипные все с дублями.

Короче Днипра ведет себя как поколоночное хранилище, хорошо оптимизироаное на вставки и апдейты документов,
(а что нам еще нужно?). Она предоставляет транзакции и ОРМ и имеет няшный синтаксис.
Вместе с тем Постгрес, Монго, Каучи и прочий западный треш спасет только выброс в море.

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

Сегодня в репо я добавил новый раздел. DniproExample там я буду собирать примеры работ на Днипре.

Перечитайте мой пост выше.
Также в книге моей есть архитектура. Самые первые страницы.

В целом, чтобы не разбираться в множестве этого треша, могу дать следующий ориентир.
Если база не индексирует по всем полям джисон (как полнотекстовый движок) значит
она не использует инвертацию раз, не работает эффективно два.

Кто тут неленивый, пишите бенчмарки. Но я бы не стал тратить на это время, если
вчитаться в то что я написал выше. Это глупо. Речь идет не о 10%, а о десятках и сотнях раз.
Именно во столько Днипра топчет всякие недолугие бисоны.

vadiminfostopНа открытом. В рамках импортозамещения у вас там как я понял свои правила игры.
Зато на в рамках импортозамещения нет опасных конкурентов. Там качество может быть ниже, а цена выше. Такая возможность не часто бывает.

А на открытом начнется: Флэшбэки, Секции (партиции), Резервные БД, Синхронная репликация, Аналитические запросы с оконными ф-ми и т.д. и т.п. Тут надо что-то эдакое, чтобы прорваться.

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

Если в импортозамещение уйдут базы тогоже Стоунберга, Пост Ингрес или Линтер то ИМХО, это будет шаг назад.
Нет никаких серьезных приимуществ у этих баз и собраны они по книжкам 20ти летней давности.

skyANAstopПеречитайте мой пост выше.
Зачем? Чтобы ещё раз задать свои вопросы?

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

Расскажите лучше когда современная Монга обзаведется транзакциями, а также научится блочить не весь документ а отдельные атрибуты ну и джоины запилит. И в каком из ваших перечисленных движков это реализовано.

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

Удачи в дальнейшем слепом освоении американских поделок )

skyANAstopЭтот разговор пуст. Поскольку нет понимания что же все-таки происходит внутри.
Вот это верная мысль, так как у Вас нет понимания того, что происходит внутри различных движков, доступных для монги.

Я вам уже ответил на вопрос.
Современные движки монги - муссор. Обьяснил на пальцах как работают бисоны.
Пояснил почему такие подходы работают в десятки раз медленее.
Намекнул почему такие ущербные архитектуры не увидят транзакции и АСИД. Индусы могут поднапрячься конечно,
но на бенчмарках всеравно всех выведут на чистую воду.
Обратного вы доказать не сможете, поскольку это разговор механика (меня) и водителя (вас).

Arm79Что за странная идея? Почему я что-то должен вставлять в какую то середину? Мне например, неочевидно.


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

Arm79Это совершенно неверное утверждение. Например, у меня есть сложный иерархический JSON, например, профиль клиента ЮЛ. Размер такого JSON может достигать нескольких мегабайт. Из всех реквизитов для поиска используется ну штук 50 реквизитов. Остальные несколько тысяч - идут в нагрузку. Вопрос - зачем мне тратить время на индексацию ВСЕХ реквизитов? Это бессмысленная трата времени.


А мне так удобней, можно искать по всем атрибутам. Строить разную аналитику.
Если работает быстрее, то почему бы и нет, почему меня должно заботить что чтото там не должно быть проиндексировано ?

stopВыложите тест, с загрузкой пользовательских JSON (а не то, что у вас 3 атрибута), чтобы каждый мог запустить у себя и рассказать о результатах.


Тестов у меня уже предостаточно. (из выложеных только уже под 20)
Если хотите свой сделать - пожалуйста делайте.

stopКроме того, осталась нераскрыта тема того, каким образом у вас обеспечивается транзакционность, если скорость вставки документов 1-3 млн/сек, а диск, собака такая, не поддерживает такую скорость, из чего следует, что эта толпа документов только у вас в оперативке.


Если в одной транзакции миллион вставок то позволяет делать. Поскольку коммит на диск происходит только на последней операции
db.Commit().

stopИ второй момент, который я хотел бы услышать - если я загружаю JSON с 2 тысячами атрибутов и размером 1 мегабайт, то какой оверхед по потребляемой памяти будет заниматься индексами?


Я вам уже отетил. От компрессии до оверхеда. Для сложных иерархических обьектов скорее всего будет компрессия.
Подробнее - изучать архитектуру и пробовать.

stopЗЫ Если речь о "импортозамещении", сравните ваше поделие с Tarantool

Не вижу смысла сравнивать базу с полноценными транзакциями, ОРМ и джисонами
с обычным ИнМемори Key\Value. Ф-сть не эквивалентна.

Arm79stopбазу с полноценными транзакциями, ОРМ и джисонами
с обычным ИнМемори Key\Value
Вы бы сначала почитали про них.


Про кого, про них ?

Arm79Они тоже дают транзакции.


Какие из трех стандартных видов поддерживают ? (ReadCommited, RepeatableRead, Snapshot)

Arm79В отличие от вас их разработка на продуктиве.
Когда ваши сервера будут обслуживать реальные миллионы обращений секунду, как у них, тогда вы можете так пренебрежительно относиться. Пока что у вас бета. И мы обсуждаем плюсы и минусы.


А вы уверены что у меня не также ?
Вообщето эта Днипра пришла к нам как форк из поисковика.
А в поисковике терабайты данных и при реиндексировании
нагрузка на ядро миллиарды запросов в час.

К томуже, нет у Меил ру никаких миллионов обращений в секунду.
У Гугла даже таких нагрузок нет. Если про реальные пользовательские обращения,
то всего около 3 миллиардов запросов в сутки.

Arm79Кстати, а где это у вас ОРМ?

А вы уверены что у них не Key\Value ?
У меня, как мы уже разобрались, можно записать в ламповом шарпе на няшном синтаксисе чтото вроде (ORM)




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