Honeyman Sep 13 2011 at 00:53

MongoDB 2.0

1 min

3.2K

MongoDB*

+59

Comments 31

remal Sep 13 2011 at 01:31

Правильно ли я понимаю, что map-reduce в mongo все еще не подходит для realtime выборок? Т.е. выполняется в один поток, да и скорость улучшилась не значительно?

Honeyman Sep 13 2011 at 03:00

Так в один поток-то только на одном mongod. А скорость… ну, какие индексы, такая и скорость.

Или вы встречались с какими-то совсем специфическими проблемами?

vgoodvin Sep 13 2011 at 08:36

А разве скорость map/reduce в mongo сильно зависит от индексов? Как я помню, у меня была проблема с долгим маппингом, т.к. функция map проходила по каждому документу в выборке. Сейчас ситуация изменилась?

remal Sep 13 2011 at 12:54

У меня map-reduce по 700 относительно небольшим документам шел примерно 1.5 секунды. Для запросов в реальном времени это неадекватно долго.

Virtuality Sep 13 2011 at 13:51

Насклько я знаю, map/reduce в силу особенностей реализации или не использует индексы вообще, или очень-очень ограничено. На практике, даже не сильно сложные map/reduce отрабатывают неадекватно долго.

Lisio Sep 13 2011 at 03:44

Сортировку кириллицы не поправили случаем?

Honeyman Sep 13 2011 at 04:02

Нет, насколько я понял. Ждём SERVER-1920, судя по всему.

megido Sep 13 2011 at 10:15

а что не так с кириллицей?

Lisio Sep 20 2011 at 06:09

Currently, sort() on a string uses strcmp: sort order will be reasonable but not fully international correct. Future versions of MongoDB may support full UTF-8 sort ordering.

VolCh Sep 13 2011 at 07:43

Ключей для ограничения потребляемой оперативки не ввели? Или я упустил и их ввели раньше? Или монго вариант чисто для многосерверных конфигураций остаётся?

Honeyman Sep 13 2011 at 08:03

Эмм, а что, MongoDB есть много оперативки? По-моему, очень мало, там просто нечего ограничивать :)

Honeyman Sep 13 2011 at 08:09

Ой, уже отослалось.

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

Иначе говоря, потребление памяти MongoDB не надо ограничивать снаружи. Его надо ограничивать изнутри, шардингом.

VolCh Sep 13 2011 at 08:21

В Q&A господствует другое мнение, да и, по-моему, приложение, использующее 500Мб дискового кэша на уровне ОС должно отличаться в htop от приложения, запросившего себе 500 Мб через *alloc/new/… Mongo, имхо, ведёт себя как второе.

Aco Sep 13 2011 at 09:36

Их мать, опять полнотекстовый поиск отложили.

quard Sep 13 2011 at 11:15

а зачем он там нужен?

Aco Sep 13 2011 at 11:27

Вариант, предложенный в доке, не устраивает по нескольким причинам. Разбив текст на слова и применив ключ на это поле, мы получим дубликат данных как на диске так и в памяти + 40 байт за каждое слово (таков оверхед у ключей на элемент, это осуждалось на конференции MongoDB Day Moskow в этом году). Ключи выгружаются в память монгой при старте. Таким образом никакой оперативы не хватит на большое количество текста. Так же нет морфологии. Сложно строить запросы на сложное вхождение словосочетаний и т.д. Я на той конфе разговаривал с Матиасом по поводу полнотекстового поиска, они хотели сделать хук для любого(любого ли?) полнотекстового движка, однако его ещё нет. Приходится выгружать в сфинкс, нагружается целостность данных. Изменились данные в одном месте — измени сам в другом. Не удобно, короче. (Извиняюсь за свой русский)

Aco Sep 13 2011 at 11:28

Вариант, предложенный в доке

Aco Sep 13 2011 at 11:29

Сорь, здесь
*осуждалось === обсуждалось

quard Sep 13 2011 at 11:29

не надо все в одну кучу пихать: бд для данных, сфинкс (солр) для поиска. никто же не использует mysql для поиска в большом приложении, хотя там есть MATCH

Aco Sep 13 2011 at 11:37

> никто же не использует mysql для поиска в большом приложении, хотя там есть MATCH

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

> не надо все в одну кучу пихать
Я приверженец не раскидывать единые данные на разные кучи.

AlexNomad Sep 13 2011 at 12:42

Подскажите, транзакции есть в MongoDB?

vden Sep 13 2011 at 12:49

Нет, транзакций нет. Есть update c атомарными операторами и атомарный же findAndModify.

XEK Sep 13 2011 at 15:24

Который атомарен только на уровне ряда. То есть это тоже совсем не панацея

Rusan Sep 13 2011 at 15:32

Продолжая про атомарные — а вы не знаете можно ли какой ключ на update указать что бы all or nothing было. А то у меня скажем три атомарные операции $inc, $pop, $push и вот допустим если pop`ить нечего то $inc и $push всё равно выполняться, а хотелось бы что бы нет :).

kost_bebix Sep 13 2011 at 16:32

Короче вы хотите транзакции :-)

Rusan Sep 13 2011 at 16:46

Не… это я хочу всего лишь в рамках одного апдейта, то есть я апдейчу один документ. Я многого хочу?

kost_bebix Sep 13 2011 at 16:52

Аа, ну да, это не транзакции.

Если хотите посмотреть, насколько это будет «всего лишь» — предложите ваш синтаксис. Как, по вашему, должен выглядеть такой запрос? Потом заодно посмотрим, насколько сложнее стал язык запросов благодаря такому усложнению.

Rusan Sep 13 2011 at 16:54

Подождите… Не торопитесь. Ведь если сравнивать с SQL где если я у меня не получилось обновить поле хотя бы одно (ну там прав не хватило), весь запрос не выполнится? Я всего лишь хочу (не требую, а хочу), что бы можно было и в монге так делать. По моему тикет там на all or nothing висит.

vden Sep 13 2011 at 16:44

Насколько я знаю, никак. Для $push единственный вариант поведения с несуществующим или пустым полем — добавить это поле как массив с заданным значением. Для $inc аналогично.

Rusan Sep 13 2011 at 16:52

ну то есть в criteria добавить. Ну так примерно и сделали.

vak Sep 13 2011 at 20:20

лучше бы в конце-концов доделали row-wide locking. Ну или хоть collection-wide…
А то по-прежнему всю ДБ лочат

Show the best of all time