13 сентября 2011 в 00:53

MongoDB 2.0

Good news, everyone. Любите вы SQL, или не любите SQL (любите NoSQL?), но сегодня (ой, уже вчера) вышли как PostgreSQL 9.1 (про которую, пока я пишу этот пост, наверняка кто-нибудь тоже напишет), так и MongoDB 2.0!

В 1.4 появились двухмерные гео-индексы, в 1.6 — sharding, в 1.8, слегка запоздало — журналирование и частичные индексы… А что сносшибательного появилось в 2.0? Команда compact, которой можно сжать только одну коллекцию (а не как раньше — делать repair для всей базы) — не сногсшибательно, всяческие улучшения в плане параллелизации и в работе индексов (утверждается, что теперь они будут на 25% меньше и на 25% быстрее) — тоже скучно…

Пожалуй, самое интересное — что replica set-ам стало можно задавать приоритеты и тэги их местонахождения — ну, типа, «в какой стране/в каком датацентре/в какой стойке» —, а по этим тэгам создавать сложные правила, как сохранять данные (ну, вплоть до «у каждого экземпляра данных должно быть как минимум три копии как минимум на двух континентах»); это называется красивым термином Replica Set Data Center Awareness.

А ещё map/reduce научился выводить данные в sharded-коллекцию (а ещё был пооптимизирован и работает быстрее); в запросах появился оператор $and; регекспы научились, при желании программиста, матчить символом точки переносы строки; геоиндекс стало можно использовать в случае, если у одного документа задано сразу несколько местоположений, а также для поиска внутри многоугольников…

Что-то будет в 2.2?.. Если учесть, что небезызвестная Sequoia Capital только что инвестировала в 10gen 20 миллионов долларов (а ещё 10 миллионов у них уже было), похоже, скучно не будет.
+59
1316
25
Honeyman 134,9

Комментарии (31)

+3
remal, #
Правильно ли я понимаю, что map-reduce в mongo все еще не подходит для realtime выборок? Т.е. выполняется в один поток, да и скорость улучшилась не значительно?
+2
Honeyman, #
Так в один поток-то только на одном mongod. А скорость… ну, какие индексы, такая и скорость.

Или вы встречались с какими-то совсем специфическими проблемами?
0
vgoodvin, #
А разве скорость map/reduce в mongo сильно зависит от индексов? Как я помню, у меня была проблема с долгим маппингом, т.к. функция map проходила по каждому документу в выборке. Сейчас ситуация изменилась?
0
remal, #
У меня map-reduce по 700 относительно небольшим документам шел примерно 1.5 секунды. Для запросов в реальном времени это неадекватно долго.
0
Virtuality, #
Насклько я знаю, map/reduce в силу особенностей реализации или не использует индексы вообще, или очень-очень ограничено. На практике, даже не сильно сложные map/reduce отрабатывают неадекватно долго.
+3
Lisio, #
Сортировку кириллицы не поправили случаем?
+1
Honeyman, #
Нет, насколько я понял. Ждём SERVER-1920, судя по всему.
+3
megido, #
а что не так с кириллицей?
0
VolCh, #
Ключей для ограничения потребляемой оперативки не ввели? Или я упустил и их ввели раньше? Или монго вариант чисто для многосерверных конфигураций остаётся?
0
Honeyman, #
Эмм, а что, MongoDB есть много оперативки? По-моему, очень мало, там просто нечего ограничивать :)

+1
Honeyman, #
Ой, уже отослалось.

А если серьёзно, MongoDB использует memory-mapped files, а следовательно, всё выглядит так, как будто она съела всю доступную память, но на самом деле эту память съел файловый кэш. Который сам сбросится на диск и уменьшится в объёме, если другому приложению понадобится больше памяти.

Иначе говоря, потребление памяти MongoDB не надо ограничивать снаружи. Его надо ограничивать изнутри, шардингом.
0
VolCh, #
В Q&A господствует другое мнение, да и, по-моему, приложение, использующее 500Мб дискового кэша на уровне ОС должно отличаться в htop от приложения, запросившего себе 500 Мб через *alloc/new/… Mongo, имхо, ведёт себя как второе.
+2
Aco, #
Их мать, опять полнотекстовый поиск отложили.
0
quard, #
а зачем он там нужен?
+1
Aco, #
Вариант, предложенный в доке, не устраивает по нескольким причинам. Разбив текст на слова и применив ключ на это поле, мы получим дубликат данных как на диске так и в памяти + 40 байт за каждое слово (таков оверхед у ключей на элемент, это осуждалось на конференции MongoDB Day Moskow в этом году). Ключи выгружаются в память монгой при старте. Таким образом никакой оперативы не хватит на большое количество текста. Так же нет морфологии. Сложно строить запросы на сложное вхождение словосочетаний и т.д. Я на той конфе разговаривал с Матиасом по поводу полнотекстового поиска, они хотели сделать хук для любого(любого ли?) полнотекстового движка, однако его ещё нет. Приходится выгружать в сфинкс, нагружается целостность данных. Изменились данные в одном месте — измени сам в другом. Не удобно, короче. (Извиняюсь за свой русский)
+1
Aco, #
0
Aco, #
Сорь, здесь
*осуждалось === обсуждалось
0
quard, #
не надо все в одну кучу пихать: бд для данных, сфинкс (солр) для поиска. никто же не использует mysql для поиска в большом приложении, хотя там есть MATCH
0
Aco, #
> никто же не использует mysql для поиска в большом приложении, хотя там есть MATCH

Вы не представляете как меня это раздражало. Однако у сфинкса есть интеграция с mysql тем самым можно работать с полнотекстовым поиском в mysql. В монге этого не хватает.

> не надо все в одну кучу пихать
Я приверженец не раскидывать единые данные на разные кучи.
0
AlexNomad, #
Подскажите, транзакции есть в MongoDB?
+2
vden, #
Нет, транзакций нет. Есть update c атомарными операторами и атомарный же findAndModify.
0
XEK, #
Который атомарен только на уровне ряда. То есть это тоже совсем не панацея
0
Rusan, #
Продолжая про атомарные — а вы не знаете можно ли какой ключ на update указать что бы all or nothing было. А то у меня скажем три атомарные операции $inc, $pop, $push и вот допустим если pop`ить нечего то $inc и $push всё равно выполняться, а хотелось бы что бы нет :).
0
kost_bebix, #
Короче вы хотите транзакции :-)
0
Rusan, #
Не… это я хочу всего лишь в рамках одного апдейта, то есть я апдейчу один документ. Я многого хочу?
0
kost_bebix, #
Аа, ну да, это не транзакции.

Если хотите посмотреть, насколько это будет «всего лишь» — предложите ваш синтаксис. Как, по вашему, должен выглядеть такой запрос? Потом заодно посмотрим, насколько сложнее стал язык запросов благодаря такому усложнению.
0
Rusan, #
Подождите… Не торопитесь. Ведь если сравнивать с SQL где если я у меня не получилось обновить поле хотя бы одно (ну там прав не хватило), весь запрос не выполнится? Я всего лишь хочу (не требую, а хочу), что бы можно было и в монге так делать. По моему тикет там на all or nothing висит.
0
vden, #
Насколько я знаю, никак. Для $push единственный вариант поведения с несуществующим или пустым полем — добавить это поле как массив с заданным значением. Для $inc аналогично.
0
Rusan, #
ну то есть в criteria добавить. Ну так примерно и сделали.
0
vak, #
лучше бы в конце-концов доделали row-wide locking. Ну или хоть collection-wide…
А то по-прежнему всю ДБ лочат

Только зарегистрированные пользователи могут оставлять комментарии.
Войдите, пожалуйста.