https://www.opennet.ru/openforum/vsluhforumID3/108854.html Компания &#171;Перкона&#187; (Percona) объявила (https://www.percona.com/about-percona/newsroom/press-releases/percona-delivers-open-source-in-memory-storage-engine-for-percona-server-for-mongodb) о выпуске Percona Memory Engine (https://www.percona.com/software/mongo-database/percona-memory-engine-for-mongodb) для MongoDB, открытого in-memory хранилища для Percona Server для MongoDB. Хранилище в оперативной памяти на базе движка хранения WiredTiger (http://www.wiredtiger.com/) предусмотрено в MongoDB 3.2 Enterprise Edition, но отсутствует в MongoDB Community Edition. Percona Memory Engine для MongoDB предоставляет возможность без дополнительных затрат использовать аналогичное хранилище в Percona Server для MongoDB, бесплатной открытой альтернативе MongoDB Community Edition с расширенными возможностями. Исходные тексты продукта опубликованы (https://github.com/percona/percona-server-mongodb) на GitHub под лицензией AGPL.<br><br><br>Percona Memory Engine для MongoDB обеспечивает высокую производительность при операци https://www.opennet.ru/openforum/vsluhforumID3/108854.html#35 Mon, 22 Aug 2016 08:19:46 GMT "Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна mongo?"<br><br>на таблице с несчастными 100млн записей<br>select count(*) from data;<br>быстрый ПГ впал в кому на 15 минут, при этом заметно просадив скорость выборок.<br><br>В монге любой размер таблицы и ответ за пару сек. <br><br>Бэкап монга делает в десятки раз быстрее, чем ПГ и Оракле. При этом совершенно незаметно на скорости отдачи инфы.<br><br>Про alter table с 100-1000 млн записей у ПГ и Оракле я промолчу.<br><br>При этом задач где монго в разы медленнее ещё не встечал. На несколько десятков процентов - да.<br> https://www.opennet.ru/openforum/vsluhforumID3/108854.html#34 Mon, 22 Aug 2016 07:50:20 GMT "серверы бизнес-логики", в которых 80% занимает кривая, косая и забагованная реализация той функциональности (прежде всего связанная с транзакциями и целостностью), которая в СУБД уже есть."<br><br>Что за appserver-ы не умеющие JTA? Если есть, зачем их взяли, когда есть полностью бесплатные и опенсорсные? По количеству разнообразнейших либ промышленного качества никакому СУБД не угнаться за жабой.<br><br>На моих workload-ах жабовый аппсервер по скорости дерёт Оракла с его plsql в десятки раз. Скорость разработки на plsql чего-то более сложного чем полстранички кода тоже в разы дольше.<br>Так что ты всё правильно говоришь с точностью до наоборот.<br> https://www.opennet.ru/openforum/vsluhforumID3/108854.html#33 Mon, 22 Aug 2016 02:26:05 GMT &gt; Есть смысл в таком разделении? Ведь PG весьма быстр, на кой нужна <br>&gt; mongo?<br><br>PG быстрее Oracle и Mysql на десятки процентов в моих workload-ах. Монга быстрее по некоторым операциям в десяток раз ;)<br><br>p.s. сколько времени занимает добавить 5 новых столбцов в PG на табличке из 1млрд записей?<br>Как при этом проседает скорость select/update/insert?<br>Вспоминается анекдот "папа, покажи многозадачность", "щас, дискетку доформатирую!".<br> https://www.opennet.ru/openforum/vsluhforumID3/108854.html#32 Mon, 22 Aug 2016 02:22:20 GMT Профдеформация?! После 15 лет с SQL, считаю<br>db.persons.find().limit(1).sort({$natural:-1})<br>просто сказкой. Не буду напоминать, что у всех РДБМСов даже банальный .limit() делается у каждого по своему. У Оракле ещё и с приседаниями, т.к. rownum отсекает до сортировки. В сад такие "стандарты"!<br><br>С точки зрение прогера - JDBC многословен просто до одурения, то что в монге делается 5 словами, в JDBC полстраницы кода. Про гребублю с preparedStatements + select молчу, когда надо искать с переменным количеством критериев ты вынужден делать отдельные ps.<br> https://www.opennet.ru/openforum/vsluhforumID3/108854.html#31 Sun, 21 Aug 2016 10:20:47 GMT Конечный пользователь базы данных - администратор базы данных. А "логинишься ты на gmail" - это конечный пользователь сервиса gmail<br> https://www.opennet.ru/openforum/vsluhforumID3/108854.html#30 Sat, 20 Aug 2016 15:41:03 GMT логинишься ты на gmail, а там перед загрузкой мейлбокса вопрос "нужен вам ACID или нет". "конечный пользователь", ага<br> https://www.opennet.ru/openforum/vsluhforumID3/108854.html#29 Sat, 20 Aug 2016 07:43:52 GMT Это всё ограниченность мышления, такие вещи решать только конечному пользователю, нужен ACID или нет. База в первую очередь должна предоставить возможность выбора устройства хранения данных. А с новыми ssd, которые работают через интерфейс оперативной памяти, Postgresql, в отличие от теперь уже всех других баз, работать не будет.<br> https://www.opennet.ru/openforum/vsluhforumID3/108854.html#28 Fri, 19 Aug 2016 15:20:40 GMT ACID в inmemory вообще не нужен, в чем проблема?<br> https://www.opennet.ru/openforum/vsluhforumID3/108854.html#27 Fri, 19 Aug 2016 15:19:04 GMT В свое время только по этой причине и не перешли на постги, а с появлением tokudb смысл и вовсе отпал<br>