https://www.opennet.ru/openforum/vsluhforumID3/114724.html Доступен (https://www.mongodb.com/blog/post/mongodb-multi-document-acid-transactions-general-availability) стабильный выпуск документо-ориентированной СУБД MongoDB 4.0 (https://www.mongodb.com/mongodb-4.0), которая занимает нишу между быстрыми и масштабируемыми системами, оперирующими данными в формате ключ/значение, и реляционными СУБД, функциональными и удобными в формировании запросов. Код MongoDB написан на языке C++ и распространяется (https://github.com/mongodb/mongo/) в рамках лицензии AGPLv3. Сборки MongoDB 4.0 сформированы (https://www.mongodb.org/downloads#community) для Linux, Windows и macOS.<br><br><br><br><br>MongoDB поддерживает хранение документов в JSON-подобном формате, имеет достаточно гибкий язык для формирования запросов, может создавать индексы для различных хранимых атрибутов, эффективно обеспечивает хранение больших бинарных объектов, поддерживает журналирование операций по изменению и добавлению данных в БД, может работать в соответствии с парадигмой Map/Reduce, поддерживает репликацию и построен https://www.opennet.ru/openforum/vsluhforumID3/114724.html#85 Thu, 05 Jul 2018 10:59:40 GMT Postgres очень дорого и хрупко горизонтально масштабируется. И при этом вообще не эластичный (когда нужно без downtime с минимальным ручным вмешательством добавить или убавить несколько штук или десятков узлов) нифига.<br><br><br><br>Такие системы как Mongo, Ignite, Cassandra предназначены для ситуаций, где нужно быстро и дешево горизонтально масштабироваться в высоконагруженной OLTP-системе, при необходимости оперативно доставлять и убирать узлы, обеспечивая эластичное масштабирование.<br><br>Так, например, Netflix в свое время тестировал Cassandra на кластерах до 288 узлов: https://medium.com/netflix-techblog/benchmarking-cassandra-scalability-on-aws-over-a-million-writes-per-second-39f45f066c9e<br><br>И даже делал утилиту для автоматического масштабирования:<br>https://medium.com/netflix-techblog/scryer-netflixs-predictive-auto-scaling-engine-a3f8fc922270<br>https://medium.com/netflix-techblog/scryer-netflixs-predictive-auto-scaling-engine-part-2-bb9c4f9b9385<br><br>Ignite имеет кластеры на 2 000 узлов: https://www.gridgain.com/r https://www.opennet.ru/openforum/vsluhforumID3/114724.html#84 Thu, 05 Jul 2018 08:42:54 GMT &gt; Накладно при откате ?<br>&gt; Мы говорим про нормальную работу БД, где коммиты происходят значительно чаще чем <br>&gt; откаты. Зачем PG нужен этот мусор? Если бы их все устраивало, <br>&gt; они бы на каждой конфе не говорили, что хотят переписать движок <br>&gt; и сделать его таким же как у Oracle <br><br>О каком мусоре речь? Это, батенька, не мусор, а многоверсионность. В её самой напрашивающейся реализации -- хранить исторические данные о данных в виде самих этих... данных. В Оракле подход другой, в Оракле хранят довольно сложно устроенный код, как собрать состояние блока на любой момент в прошлом (в пределах объёма сегмента отката). Какой подход лучше -- бесполезный спор(т).<br>Обслуживание же MVCC в Слоне тема давно уже не болезненная. Просто нужно делать автовакуум очень часто. Вот и всё. Очень-очень часто. Да и не ясно к чему о ней тут.<br> https://www.opennet.ru/openforum/vsluhforumID3/114724.html#83 Thu, 05 Jul 2018 08:28:38 GMT Зависит от орм-а. Если вы о реализациях JPA, то версионность часть стандарта, так что такая ситуация менеджером обрабатывается. Тут важнее понимать, что происходит.<br> https://www.opennet.ru/openforum/vsluhforumID3/114724.html#82 Thu, 05 Jul 2018 02:29:58 GMT &gt;В Монге длительная операция может упорно что-то там изменять, а другая, начавшаяся после, но короткая, видит такие "сырые" изменения и без проблем фигачит прямо по ним<br><br>Если это недопустимо и тем не менее происходит, то вывод ровно один: прогер ленивый олень.<br>Тут один уже отписался, что "ну $set же никто не использует, все олени за replace"<br><br>Открою страшную тайну: с труЪ СУБД + ORM фреймворк у того же самого оленя будут те же самые проблемы, он делает entity managed, чего-то там с ним долго делает, если кто-то другой дернет глобальный update, то persist() на эту entity перезапишет результаты глобального апдейта.<br><br>ОКей, без ORM фреймворк эта проблема тоже никуда не делась. Если у тебя разные процессы живут своей жизнью и один делает глобальный UPDATE, то выполнятся они по очереди, но проблема перезаписи данных никуда не ушла.<br> https://www.opennet.ru/openforum/vsluhforumID3/114724.html#81 Wed, 04 Jul 2018 20:28:53 GMT Великолепный ответ!<br> https://www.opennet.ru/openforum/vsluhforumID3/114724.html#80 Wed, 04 Jul 2018 17:51:54 GMT &gt;&gt; Для сравнения в Монго этого делать не надо никогда. Профит...<br>&gt; Всерьёз считаете, что в монге изобрели новые способы хранения индексов? И о <br>&gt; страничной организации они ничего не слышали?<br>&gt; Шли бы в Кнута, для начала....<br><br>Почитайте, для чего нужен ваакуум для начала и поймите лучше, что вам хотят сказать<br> https://www.opennet.ru/openforum/vsluhforumID3/114724.html#79 Wed, 04 Jul 2018 17:40:06 GMT Ну что ты несешь? Сидели бы по углам и не вылазили<br> https://www.opennet.ru/openforum/vsluhforumID3/114724.html#78 Wed, 04 Jul 2018 11:36:45 GMT Ну это вааще роскомнадзор какой-то<br> https://www.opennet.ru/openforum/vsluhforumID3/114724.html#77 Wed, 04 Jul 2018 11:28:59 GMT По-моему, некорретно называть Монго СУБД. Монго, всё же, это мета-файловая система. Функционально она ничем не лучше сочетания, скажем, работающего по верх zfs grep-а. Ну в сочетании с какой-нибудь технологией блочной репликации.<br>