Комментарии 33
Так понимаю уже стабильная версия? Недавно была похожая новость, но с оговоркой от разработчиков, что в продакш лучше пока не использовать.
Кстати, добавили новый репозитарий для новой версии http://repo.mongodb.org/, старые версии остались на прежнем месте http://downloads-distro.mongodb.org/repo/
Кстати, добавили новый репозитарий для новой версии http://repo.mongodb.org/, старые версии остались на прежнем месте http://downloads-distro.mongodb.org/repo/
Напишу сразу про InMemory.
Его еще нет, но в вебинаре он упоминается. Планируется ввести его позже, скорее всего в последующем релизе.
Его еще нет, но в вебинаре он упоминается. Планируется ввести его позже, скорее всего в последующем релизе.
PostgreSQL догнал?
Все тролите?)
НЛО прилетело и опубликовало эту надпись здесь
По производительности в NoSQL части они были примерно одинаковы
Да разве? Насколько я помню MongoDB был раза в 3 медленнее.
На кластере из скольки узлов?
А причем тут кластер?
А при том, что тестирование (и расхваливание), насколько PostgreSQL эффективнее по сравнению с MongoDB при каких-нибудь простеньких key-value запросах (подозреваю, в тех бенчмарках даже агрегатные запросы не сравнивали) при работе на одном узле, настолько же глупо, бессмысленно и оторвано от практики, как и тестирование, насколько MySQL эффективнее по сравнению с PostgreSQL (или наоборот) при выполнении запроса «SELECT 1».
Но ждать качественного мультихостового нагрузочного бенчмарка от фанов PostgreSQL было бы бессмысленно, потому что, пока BDR только ожидается в upstream, в аспекте мульти-мастер репликации PostgreSQL находится примерно на уровне MongoDB 1.4 (а то и 1.2). То есть, PostgreSQL функционально отстаёт от MongoDB как минимум на 4 года.
Но ждать качественного мультихостового нагрузочного бенчмарка от фанов PostgreSQL было бы бессмысленно, потому что, пока BDR только ожидается в upstream, в аспекте мульти-мастер репликации PostgreSQL находится примерно на уровне MongoDB 1.4 (а то и 1.2). То есть, PostgreSQL функционально отстаёт от MongoDB как минимум на 4 года.
А при том, что тестирование (и расхваливание), насколько PostgreSQL эффективнее по сравнению с MongoDB при каких-нибудь
простеньких key-value запросах (подозреваю, в тех бенчмарках даже агрегатные запросы не сравнивали) при работе на одном узле, настолько же глупо, бессмысленно и оторвано от практики, как и тестирование, насколько MySQL эффективнее по сравнению с PostgreSQL (или наоборот) при выполнении запроса «SELECT 1».
NoSQL is WebScale ©. Вам никто не мешает поискать те самые бенчмарки. И да сравнивать на одном узле имеет смысл, так-как далеко не всегда требуется 100500 узлов для обеспечения необходимой производительности. Если MongoDB не умеет делать это на одном узле, то конечно очень эффективно делать это на куче узлов. Плюс я молчу просто про отсутствие ACID как класса в MongoDB.
Но ждать качественного мультихостового нагрузочного бенчмарка от фанов PostgreSQL было бы бессмысленно,
Доо конечно! Особенно если учесть что PostgreSQL обеспечивает ACID а MongoDB нет. В этом случае сделать мултимастер существенно проще. Если же в PostgreSQL смогут сделать milti-master то он явно будет с ACID. А где ACID в MongoDB? :)
То есть, PostgreSQL функционально отстаёт от MongoDB как минимум на 4 года.
Спасибо поржал. Для начала покажите в ACID в MongoDB.
> И да сравнивать на одном узле имеет смысл, так-как далеко не всегда требуется
> 100500 узлов для обеспечения необходимой производительности.
Для таких мелких случаев, возможно, не стоит и с MongoDB возиться? А это это как «писать на MPI для одного хоста, а потом удивляться, что оно работает медленнее, чем без него». Или Ceph на одной машине заводить, без каких-либо планов на рост.
> Для начала покажите в ACID в MongoDB.
(Пожимая плечами) Покажите BASE в PostgreSQL.
Что вы так к этому ACID прицепились? ACID — не самоцель, а просто всего лишь одна из возможных концепций баз данных. Понятно, что из-за простоты освоения и использования («всё само работает, всё само обеспечивает консистентность») она приятнее для новичков, настолько, что они начинают верить «любая серьёзная СУБД должна быть ACID-compatible». Ну что ж, про таких людей есть меткая пословица «когда в руках есть молоток, любая проблема кажется гвоздём».
> 100500 узлов для обеспечения необходимой производительности.
Для таких мелких случаев, возможно, не стоит и с MongoDB возиться? А это это как «писать на MPI для одного хоста, а потом удивляться, что оно работает медленнее, чем без него». Или Ceph на одной машине заводить, без каких-либо планов на рост.
> Для начала покажите в ACID в MongoDB.
(Пожимая плечами) Покажите BASE в PostgreSQL.
Что вы так к этому ACID прицепились? ACID — не самоцель, а просто всего лишь одна из возможных концепций баз данных. Понятно, что из-за простоты освоения и использования («всё само работает, всё само обеспечивает консистентность») она приятнее для новичков, настолько, что они начинают верить «любая серьёзная СУБД должна быть ACID-compatible». Ну что ж, про таких людей есть меткая пословица «когда в руках есть молоток, любая проблема кажется гвоздём».
Для таких мелких случаев, возможно, не стоит и с MongoDB возиться?
А как же NoSQL is WebScale?
Что вы так к этому ACID прицепились? ACID — не самоцель, а просто всего лишь одна из возможных концепций баз данных.
Эээ. Правда? Т.е. если банк случайно пролюбит пару транзакций одна из который ваша зарплата, а вторая выплата по кредиту, то ничего страшного? :)
Понятно, что из-за простоты освоения и использования («всё само работает, всё само обеспечивает консистентность») она приятнее для новичков
Ну давайте расскажите как вы обеспечиваете ACID сами без базы данных.
Для таких мелких случаев, возможно, не стоит и с MongoDB возиться?
А как же NoSQL is WebScale?
Мне это показалось, или вы приравниваете WebScale к «мелким случаям, для которых одного узла достаточно»?
Т.е. если банк случайно пролюбит пару транзакций одна из который ваша зарплата, а вторая выплата по кредиту, то ничего страшного? :)
А теперь внимание, сюрприз: банковская система (да-да, те самые «финансы», которые так любят упоминать любители ACID, AC of CAP «и прочих страшных слов» — за их важность, серьёзность, ынтырпрайзность и консистентность)… не удовлетворяет ACID и обеспечивает именно что eventual consistency :D highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-are-base-not-acid-availability.html
Ну давайте расскажите как вы обеспечиваете ACID сами без базы данных.
А я и не обеспечиваю. Если ACID даже мировой банковской системе не нужно, зачем оно сизому и убогому мне? Пусть ACID-ом студенты балуются, чтобы у них в голове хотя бы такой примитив, как реляционные базы данных, хоть как-то уложился. Благо что про использование ACID для приведения головы в порядок ещё Тимоти Лири писал.
Мне это показалось, или вы приравниваете WebScale к «мелким случаям, для которых одного узла достаточно»?
Нет. Это вы пытаетесь натянуть ежа на глобус. И первыми начали рассказывать про MongoDB на большом числе узлов.
А теперь внимание, сюрприз: банковская система (да-да, те самые «финансы», которые так любят упоминать любители ACID, AC of CAP «и прочих страшных слов» — за их важность, серьёзность, ынтырпрайзность и консистентность)… не удовлетворяет ACID и обеспечивает именно что eventual consistency :D
Угу приводить в пример что у банка есть банкомат и по этому система не ACID это мягко говоря не корректно. Это вообще говоря к ACID никаким боком.
А я и не обеспечиваю. Если ACID даже мировой банковской системе не нужно, зачем оно сизому и убогому мне? Пусть ACID-ом студенты балуются, чтобы у них в голове хотя бы такой примитив, как реляционные базы данных, хоть как-то уложился. Благо что про использование ACID для приведения головы в порядок ещё Тимоти Лири писал.
Ну не обеспечивайте. Главное финансовые системы не пишите. А то знаю я таких одних писателей. У них баланс в итоге не сходится в 10% случаях. Охрененно финансовая система. Про то что РСУБД примитив поржал. Особенно учитывая, что фактически MongoDB это еще больший примитив.
И первыми начали рассказывать про MongoDB на большом числе узлов.
Простите, вы серьёзно не в курсе, что MongoDB с начала и до конца — от типа данных для primary key и синтаксиса агрегатных запросов, и до механизма replica set tags — предназначен именно для эффективной масштабируемости? Или вам просто очень хочется вытянуть его в удобную и привычную для SQL-школоты нишу простеньких однохостовых бенчмарков?
Нет, пожалуйста, вытягивайте, если хотите. Просто каждый раз, когда обсуждаете такой бенчмарк, мысленно заменяйте MongoDB на Ceph, а PostgreSQL/MySQL — на ext4. И если вам вдруг будет смешно — то знайте, точно так же смешно для пользователей MongoDB выглядят и «бенчмарки PostgreSQL по сравнению с MongoDB на операциях с JSON».
Угу приводить в пример что у банка есть банкомат и по этому система не ACID это мягко говоря не корректно. Это вообще говоря к ACID никаким боком.
У меня возникает впечатление, что статью вы читали невнимательно. Помимо offline-банкоматов вспомните про offline-терминалы в магазинах — а в мире они очень даже сильно распространены! Перечитайте ещё раз рассказ про банки времён Ренессанса (16-ый век), про передачу банковских заявок курьерами на кораблях и лошадях и подумайте, что процессы, отлаженные тогда, прекрасно работают до сих пор. Письма от банка в 16-ом веке, чековые книжки в 19-ом веке, кредитки с затягивающимися на месяц платежами в 21-ом — это всё «звенья одной грёбанной цепи», в которой намного эффективнее откатить неконсистентную транзакцию, чем терять прибыли из-за потери availability.
ACID is overrated.
Особенно учитывая, что фактически MongoDB это еще больший примитив.
В постгре вон hot standby-ю пять лет скоро исполняется. Пять лет как read-only нагрузку можно сбрасывать на другие хосты. Ну, почти что масштабируемость, чо.
И первая официальная версия MongoDB вышла тоже почти пять лет назад. Кажется, репликация в ней уже была.
Так это, не подскажете, как в PostgreSQL сделать автоматический перевыбор мастера при пропадании текущего мастера?
А запретить ей при этом при перевыборе выбирать мастером вот этот вот хост — у него процессор слабее, чем у остальных?
Или как настроить репликацию, чтобы запись считалась успешно выполненной только тогда, когда она реплицируется как минимум на один — любой — хост из твоего датацентра и один — любой — хост из другого датацентра?
Простите, вы серьёзно не в курсе, что MongoDB с начала и до конца — от типа данных для primary key и синтаксиса агрегатных запросов, и до механизма replica set tags — предназначен именно для эффективной масштабируемости?
Я в курсе. Только вот если решение не может обеспечить на одном узле сравнимый уровень производительности, то приводить довод «оно же масштабируемое!» как минимум странно.
Или вам просто очень хочется вытянуть его в удобную и привычную для SQL-школоты нишу простеньких однохостовых бенчмарков?
А что MongoDB дает приемлемые результаты только если кластер? Стоимость владения нет не слышал?
то знайте, точно так же смешно для пользователей MongoDB выглядят и «бенчмарки PostgreSQL по сравнению с MongoDB на операциях с JSON».
MongoDB is WebScale!
Помимо offline-банкоматов вспомните про offline-терминалы в магазинах — а в мире они очень даже сильно распространены!
Вы еще про ручной эмбосинг карт вспомните. На данный момент практически все терминалы и банкоматы работают в онлайне. Дополнительно, я хотел бы заметить такие транзакции никакого отношения к ACID не имеют. По одной простой причине, для нее такие транзакции не существуют. И станут они существовать когда их добавят. И замечу такое есть в любой системе, так-как это внешние данные.
В постгре вон hot standby-ю пять лет скоро исполняется. Пять лет как read-only нагрузку можно сбрасывать на другие хосты. Ну, почти что масштабируемость, чо.
NoSQL is WebScale! Вот реально.
Так это, не подскажете, как в PostgreSQL сделать автоматический перевыбор мастера при пропадании текущего мастера?
А запретить ей при этом при перевыборе выбирать мастером вот этот вот хост — у него процессор слабее, чем у остальных?
Или как настроить репликацию, чтобы запись считалась успешно выполненной только тогда, когда она реплицируется как минимум на один — любой — хост из твоего датацентра и один — любой — хост из другого датацентра?
Расскажите как обеспечить ACID в MongoDB. Тогда и поговорим. Любой человек который начинает рассказывать что ACID ему не нужен, обязательно словит проблему с целостностью данных.
Только вот если решение не может обеспечить на одном узле сравнимый уровень производительности, то приводить довод «оно же масштабируемое!» как минимум странно.
(Терпеливо) Нет же. Нисколько не странно.
Параллелизуемые алгоритмы имеют полное право иметь оверхед по сравнению с непараллелизуемыми. Да в общем, скорее всего, для обеспечения паралеллизуемости они её и будут иметь, всегда. Если вы будете решать какую-то вычислительную задачу, то одно только добавление MPI или map/reduce уже снизит производительность на одном узле.
И что, по-вашему, это значит, что параллелизация не нужна?
Ну да, в случае требований «выжать максимум из одного узла, на второй у нас нет денег» — не нужна, наверное.
Но подобная задача — это, пожалуй, не то, чем стоит заниматься уважающему себя программисту.
А что MongoDB дает приемлемые результаты только если кластер? Стоимость владения нет не слышал?
Видите ли, «приемлемые результаты» для разных людей могут быть разными. Если для кого-то приемлемый результат — это 5 000 QPS, то для него это будет звучать как «с PostgreSQL/MySQL ниже стоимость владения системой, обеспечивающей приемлемые результаты, чем с MongoDB». Но если же «приемлемый результат» — это 500 000 QPS, то придётся переформулировать как «с MongoDB ниже стоимость владения системой, обеспечивающей приемлемый результат, чем с DynamoDB, а средствами PostgreSQL/MySQL такой результат вообще не достижим».
MongoDB is WebScale!
Вы так забавно повторяете эту мантру, как будто то ли MongoDB не применим ни для чего, кроме веба (хотя в success stories описывают не только его использование в Ebay, Yandex и Foursquare, но и для трейдерских данных, и для поддержки игроков в EA Sports, и для сбора данных с сенсоров), то ли будто эта мантра помогает вам опровергнуть мои слова.
MongoDB is scalable. PostgreSQL and MySQL are not. Вот как надо.
Дополнительно, я хотел бы заметить такие транзакции никакого отношения к ACID не имеют. По одной простой причине, для нее такие транзакции не существуют. И станут они существовать когда их добавят.
Говоря про ACID применительно к банку вы что, имеете в виду некую «базу данных внутри банка»? Да нет же. Думайте о банке в целом в целом. И о банковской финансовой транзакции в целом, а не о «транзакции записи в банковскую базу».
Вот вы взяли в Испании машину в Hertz, и тот залочил на карточке 500 евро — транзакция началась. Вы вернули машину, а через ещё две недели он списал с вас 750 евро (50 евро за прокат, а 700 евро — за то, что после вас в машине недосчитались запаски, зато нашли похищенного из зоопарка пеликана и дохлую проститутку в багажнике) — транзакция закончилась. Вы же не думаете, что всё это время клиент-банк в Hertz держал открытым sql-соединение, чтобы по итогу закоммитить?
И самое забавное — у вас на карточке было всего 600 евро. Поэтому, когда Hertz списал 750 евро, вы «ушли в минус». Ааа, constraint violation, ужас-ужас! У банка развалилась база! Криворукие программисты базы, весь баланс сломан, деньги потеряны, шеф, усё пропало! Ой ли?
Да нет же. Вы, как миленький, через неделю занесёте в банк недостающие 150 евро. И, может, ещё 5 евро за овердрафт. Узнаёте, на что это похоже? Прааавильно, это же eventual consistency!
Расскажите как обеспечить ACID в MongoDB. Тогда и поговорим. Любой человек который начинает рассказывать что ACID ему не нужен, обязательно словит проблему с целостностью данных.
Так вам «обеспечивать ACID» надо, или «обеспечивать консистентность»? Первое — это же всего лишь один из частных случаев, одна из возможных (и далеко не всегда удобных и эффективных) реализаций второго.
Вы прочитали про банк сверху? Да класть хотел тот банк на то, что, из-за «отсутствия ACID», у него бывают отрицательные суммы на балансе у пользователей и залоченные-но-ещё-не-списанные суммы. У него есть другие механизмы получения eventual consistency.
Так вот, про ваш вопрос, как «обеспечивать ACID без базы данных/в MongoDB». Ну, вот в случае банка, «как обеспечивать consistency без базы данных». Да просто же. У банка для этого есть Служба Безопасности и Коллекторы. Они приходят к тому, благодаря кому consistency нарушилось, и очень даже эффективно и дёшево для банка восстанавливают консистентность.
Нет же. Нисколько не странно.
Параллелизуемые алгоритмы имеют полное право иметь оверхед по сравнению с непараллелизуемыми.
Могут, но не в несколько раз.
Видите ли, «приемлемые результаты» для разных людей могут быть разными.
Конечно. Только вот момент. Вместо того чтобы говорить мне вот мы к примеру при помощи MongoDB получим больше производительности тогда-то тогда-то вы зачем-то начали аппелировать к кластерам. И да если при этом к примеру PostgreSQL либо другое что-то дает ту же производительность что на одной машине, что и MongoDB на двух трех, то начинают возникать сомнения а надо ли?
Вы так забавно повторяете эту мантру, как будто то ли MongoDB не применим ни для чего, кроме веба (хотя в success stories описывают не только его использование в Ebay, Yandex и Foursquare, но и для трейдерских данных, и для поддержки игроков в EA Sports, и для сбора данных с сенсоров), то ли будто эта мантра помогает вам опровергнуть мои слова.
Угу и тут вот в тред врывается статья Прощай, MongoDB, здравствуй, PostgreSQL Где внезапно все как-то не очень.
MongoDB is scalable. PostgreSQL and MySQL are not. Вот как надо.
Для MySQL есть Galera. Для PostgreSQL SkyTools от Skype. Так что не очень то это правда. Дополнительно еще есть SciDB.
Думайте о банке в целом в целом. И о банковской финансовой транзакции в целом, а не о «транзакции записи в банковскую базу».
Нельзя. Внешние события есть всегда. К примеру есть не автоматизированное снятие денег, через эмбосинг карты. Именно для этого на картах выдавлен номер карты.
Вы же не думаете, что всё это время клиент-банк в Hertz держал открытым sql-соединение, чтобы по итогу закоммитить?
Нет. Это не входит в ACID. Вы пытаетесь натянуть ежа на глобус. И в описанном вами случае будет три
транзакции. Первая помещение денег в hold. Вторая возврат денег. Третья реальное начисление.
Поэтому, когда Hertz списал 750 евро, вы «ушли в минус». Ааа, constraint violation, ужас-ужас!
Нет. Нету там constraint violation. ACID не обещает, что вам не дадут списать больше денег. Он обещает что операции будут в базе когда они проведены и обещает целостность. Т.е. что при списании с вас 750 евро и балансе в 600 евро у вас на счету будет -150 евро, а не -200 к примеру.
Так вам «обеспечивать ACID» надо, или «обеспечивать консистентность»? Первое — это же всего лишь один из частных случаев, одна из возможных (и далеко не всегда удобных и эффективных) реализаций второго.
Сначала разберитесь с тем что такое ACID. Судя по тому что вы пишите про банк вы слабо понимаете что это такое и не писали ни одной финансовой системы.
Да просто же. У банка для этого есть Служба Безопасности и Коллекторы.
Т.е. вашем случае если я внезапно в вашей системе обнаружу что у меня баланс -200 евро, а реально это ничем не подтверждается, то у вас будет специальный человек это искать? Ну-ну. Боюсь клиентам использующим вашу систему это сильно не понравится.
Сначала разберитесь с тем что такое ACID. Судя по тому что вы пишите про банк вы слабо понимаете что это такое и не писали ни одной финансовой системы.
(Тоскливо) Да перестаньте вы уже думать о «финансовой системе» как о «базе данных банка». Забудьте про базу. Про физический движок, на котором она крутится. Перестаньте мыслить как SQL code monkey, который гордо объявляет, что он «пишет финансовую систему», хотя он пишет всего лишь бэкенд и базу данных для неё.
Поднимитесь на уровень абстракции выше. На тот уровень, на котором финансовая система пишется не на SQL, а на бумаге, и вступает в силу не после коммита и деплоя, а после подписания её генеральным директором.
Вот там ACID-а — нет, там прямо чистый BASE. А что у какой-то мелкой подсистемы внутри банка есть ACID — да кто ж этих компьютерщиков разберёт.
Да перестаньте вы уже думать о «финансовой системе» как о «базе данных банка». Забудьте про базу. Про физический движок, на котором она крутится. Перестаньте мыслить как SQL code monkey, который гордо объявляет, что он «пишет финансовую систему», хотя он пишет всего лишь бэкенд и базу данных для неё.
Поднимитесь на уровень абстракции выше. На тот уровень, на котором финансовая система пишется не на SQL, а на бумаге, и вступает в силу не после коммита и деплоя, а после подписания её генеральным директором.
Вот там ACID-а — нет, там прямо чистый BASE. А что у какой-то мелкой подсистемы внутри банка есть ACID — да кто ж этих компьютерщиков разберёт.
Угу. А потом я буду искать два миллиона которые пропали не известно куда. И разбираться, а что это операции не прошли. Вы понимаете, что MongoDB просто не обеспечивает транзакции? А это фактически приводит к тому что нарушение целостности там словить легко и не принужденно. Ну нельзя складывать в MongoDB критичные данные.
Вы понимаете, что MongoDB просто не обеспечивает транзакции?
Ну да. Не обеспечивает. Их там нет.
Но не всегда и не для всех задач требуется консистентное изменение данных сразу в нескольких местах.
В реляционных базах данных без них хреново, конечно — там есть внешние ключи, и надо как минимум гарантировать целостность их, ведь так?
Но в MongoDB их нет, там же вовсю денормализованность!
Зато вот атомарные операции там есть. Помните, в статье про «в банках нет ACID» было то, что в основном операции там коммутативны? Добавить пять баксов, снять три. Так и тут. Любая операция над документом атомарна — а это уже много. Для значительного объёма практических задач этого весьма хватит. Ситуации в духе «уменьшить тут и увеличить на столько же там одновременно» возникают реже, но при этом, при желании, их можно симулировать — опа-опа! — благодаря тем самым атомарным операциям! Ещё в 2012-ом году была про это даже статья на хабре. В рамках одного документа MongoDB is ACID-compliant!
А теперь вопрос веселее. MongoDB изначально создавалась как распределённая база данных, и поэтому все гарантии, которые она может предоставлять — она должна предоставлять именно в рамках «multi-shard multi-replica-set deployment». Было бы странно и лживо иметь в ней, скажем, работающие транзакции на одном узле (или даже на одном реплика-сете), но неработающие в полноценном деплойменте?
Имеющиеся у нас реляционные базы данных, как правило, изначально создавались всё-таки для одного узла. Даже hot standby — это уже надстройки над ними, не говоря уже про BDR. Обеспечивать ACID на одном узле было чуть попроще.
А теперь посмотрите на актуальную современную ситуацию. PostgreSQL (как opensource RDBMS blessed child) с hot standby, 1 мастер и, скажем, 4 slave-а. Бэкенд, какой-нибудь pgbounce, распределяет нагрузку на чтение по slave-ам, а запись заставляет производить на master. Вопрос к вам: такая конфигурация в целом ещё ACID-compliant? Как перенесут такую параллелизацию нагрузки постгрешные transaction isolation levels?
Замечательно :)
А оно теперь будет работать с OpenVZ и Ubuntu просто-так, без напильника?
Или по-прежнему вопит про то что «это несувенир работает!!!»
А оно теперь будет работать с OpenVZ и Ubuntu просто-так, без напильника?
Или по-прежнему вопит про то что «это не
Будем ждать тестов и сравнений с предыдущими версиями.
Решил сам проверить 3.0 в действии, тест простой но близкий к моей задаче, пишем случайный ключ и читаем по случайному ключу.
Тесты делал на php-fpm + nginx, три отдельных сервера — на одном сразу три монги запущенно.
Возможно где то ошибся и тест сильно " синтетический ", результаты: в два раза быстрее и компактнее…
Подробности: gist.github.com/isublimity/4974919e38c66367804d
Тесты делал на php-fpm + nginx, три отдельных сервера — на одном сразу три монги запущенно.
Возможно где то ошибся и тест сильно " синтетический ", результаты: в два раза быстрее и компактнее…
Подробности: gist.github.com/isublimity/4974919e38c66367804d
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Вышла Mongodb 3.0 Production Release