агрегацию)
Да все, монга славится своей скоростью, но если ты начинаешь использовать связи, она проседает. Блин в инете куча тестов производительности
Так погоди Связей нет, или они есть, но тормозят? Сравнение монги с рсубд не интересно, потому что лежит вне дискуссии. Нужно сравнение вариантов реализации на монге со связями, и без связей А ты кроме этих бд работал с чем-нибудь? Оракл там, эм эс сиквел
постгрес, mysql, mongodb, cassandra
вот смотри, есть mysql. у нее есть тип данных JSON, но возможности работать с ним как с json-ом нет, как бы ты это назвал? есть у нее тип данных json или его нет? тоже самое и связи. связи конечно же есть, но я бы не назвал их связями. они дают именно просадку, когда данных становится очень много. в конечном итоге скорость реляционной базы будет выше чем при работе с монгой. понимаешь? я просто к этому веду, у всех баз есть множество скажем так, проблемных мест. их нужно учитывать и на основе задачи подбирать базу. не разработчик выбирает базу, а по сути сам проект диктует определенные правила
Нет, не понимаю Можно посмотреть на тесты, которые показывают падение скорости (хз чего, видимо поиска) при использовании связей? И можно узнать критерии, по которым ты считаешь, что reference в монге нельзя называть связями?
ну естественно у меня не лежат тесты под все нужды, естественно я их проводил давно еще и было все очевидно. да нет критериев, видишь что появляется заторможенность на больших количествах данных, нежели чем использовать обычную вложенность
Ну а я ничего подобного не вижу, на больших объемах, причём Так как связи в монге это просто отдельный тип поля, примерно как число или строка, и нет поддержки ссылочной целостности, использование связей вообще никак не сказывается на производительности Если ты упоминаешь статьи, в которых показано, что она таки есть, можешь поделиться ссылками?
я б поделился с радостью, нету под рукой
Напомнить завтра? Я не доёбываюсь (ну или совсем немного), просто интересно, как это возможно физически. Поскольку я такой возможности не вижу, это все равно что считать, что использование boolean тормозит код. Может в статьях будет ответ
я чет тоже не нашел упоминаний что связи тормозят
я постараюсь, просто это было давно( правда. щас ввел mongo db relations bad и поехали вырезки в стиле The biggest issue with applying RDBMs structure to mongo is that relations in mongo are not as fundamental or optimized. So, if you think of collections as tables and documents as data in a table you are a bit off and will introduce a lot of extraneous querying of mongo data. таких примеров реально много, я не помню где читал. читал точно не в ру сегменте. и тестировал до 4 вложенности. лучше если Вы сами попробуете проверить, разница действительно есть
Ну тогда напоминаю У меня есть опыт работы с монгой, и я не встречал никаких просадок из-за наличия связей. Никогда о таких просадках не слышал, и не вижу оснований для них. Потому и прошу ссылки В цитате речь не о том, что использование связей замедляет работу, а о том, что их использование неоптимизировано - это совсем другое. Конечно же не надо использовать реляционную модель в монго (например, выделять под реляции отдельную коллекцию, по аналогии с тем, как это делают в рсубд). Но при этом наличие связей и попьюлейт это одна из базовых вещей в монго, которые были, кажется, с самого начала, и использование которых, насколько мне известно, не подвергалось сомнению
Занятный бенчмарк. Его критика со стороны монго https://www.mongodb.com/blog/post/benchmarking-do-it-right-or-dont-do-it-at-all И ответ авторов бенчмарка https://www.ongres.com/blog/benchmarking-do-it-with-transparency/
@x1dan думаю тебе тоже любопытно будет
Результаты в корне противоположные.
а там есть сравнение конкретно записи/модификации данных (без транзакций)? я думаю, что только в этом кейсе монга может быть быстрее (ну если не считать такие вещи, как скорость разработки, масштабирование)
Там есть то, что есть и больше нет
ну а ты читал? мне просто лень, итоги бенчмарков в сравнении монга/постгре мне кажутся очевидными
Да, там обычное io чуть быстрее, но с журналированием ± одинаково, но без fsync постгрес, часто обгоняет, можете руками проверить.
Мало того. Я читал ещё и другие вайтпеперы
Насколько я понял, задача была не сделать бенчмарки, а доказать несостоятельность предыдущего
мне не приходит голову проверять это, потому что инструменты разные, и их надо использовать для разных целей но раз кто-то проверяет, посмотреть можно
Самый сок сами монго пишут The OLTP benchmark was based on a teaching example for Python users written by a MongoDB developer advocate […] Ongres ported it to Java and then built benchmarking on top of that. This led to unnecessary uses of $lookup (JOIN) aggregation and other relational traits in MongoDB which are known to impact performance simply because MongoDB is not a relational database
Проблема в том, что стандарт хранения данных постфактум реляционный, почти всегда ты к нему придешь, и сейчас они говорят, что со своими агрегатными функциями хорошо справляются с этим, пусть и соревнуются тогда.
Обычно в таких холиварах, появляются "разрешители", они хотят разрешить дискуссии бенчмарка этих бд фразой: "Эти инструменты предназначены для разных целей". Можно сразу список таких несинтетических кейсов, где какая бд уместнее другой используется.
Не понял вторую часть
но это же не так в разных предметных областях используются разные модели в каком-нибудь машиностроении вообще нужны иерархические модели данных если кто-нибудь видел системы типа интермеха, может представить всю боль от необходимости натягивать такие модели на реляционные базы
Спасибо, погуглю.
Холивар был как раз на тему использовать связи в монге или нет
Это очевидно определяется запросом проекта, конечно, допустим список хобби пользователя это вложенный документ вполне, но список групп на которые он подписан это безусловно связь.
холивар был на тему того, что использование связей что-то там замедляет в приведённой тобой выше цитате речь идёт о лишних лукапах - т.е. тормоза взялись не из-за наличия ссылок, а из-за лишних операций а сами по себе связи в монге, как ты же сам выше и писал, вряд ли влияют на производительность
т.е. ты реально с человеком спорил, чтоб доказать, что хранить ничего незначащие в плане консистентности данные не имеют накладных расходов, главное чтоб ими не пользовались?)
что-то я не понял твоего вопроса я не спорил, а пытался выяснить информацию о тормозах, о которых он рассказывал я допускаю, что могу ошибаться, и потому хотел подробностей и всё ещё жду их
Скорей всего речь шла именно про тормоза запросов с лукапом, а не записи со связью
t.me/nodejs_ru/582357
Ты меня мне же?)
да потому что вроде ты сам реагировал на тормоза из-за связей, а не из-за лишних лукапов
Обсуждают сегодня