Комментарии 31
Правильно ли я понимаю, что map-reduce в mongo все еще не подходит для realtime выборок? Т.е. выполняется в один поток, да и скорость улучшилась не значительно?
+3
Так в один поток-то только на одном mongod. А скорость… ну, какие индексы, такая и скорость.
Или вы встречались с какими-то совсем специфическими проблемами?
Или вы встречались с какими-то совсем специфическими проблемами?
+2
А разве скорость map/reduce в mongo сильно зависит от индексов? Как я помню, у меня была проблема с долгим маппингом, т.к. функция map проходила по каждому документу в выборке. Сейчас ситуация изменилась?
0
У меня map-reduce по 700 относительно небольшим документам шел примерно 1.5 секунды. Для запросов в реальном времени это неадекватно долго.
0
Насклько я знаю, map/reduce в силу особенностей реализации или не использует индексы вообще, или очень-очень ограничено. На практике, даже не сильно сложные map/reduce отрабатывают неадекватно долго.
0
Сортировку кириллицы не поправили случаем?
+3
Нет, насколько я понял. Ждём SERVER-1920, судя по всему.
+1
а что не так с кириллицей?
+3
Ключей для ограничения потребляемой оперативки не ввели? Или я упустил и их ввели раньше? Или монго вариант чисто для многосерверных конфигураций остаётся?
0
Эмм, а что, MongoDB есть много оперативки? По-моему, очень мало, там просто нечего ограничивать :)
0
Ой, уже отослалось.
А если серьёзно, MongoDB использует memory-mapped files, а следовательно, всё выглядит так, как будто она съела всю доступную память, но на самом деле эту память съел файловый кэш. Который сам сбросится на диск и уменьшится в объёме, если другому приложению понадобится больше памяти.
Иначе говоря, потребление памяти MongoDB не надо ограничивать снаружи. Его надо ограничивать изнутри, шардингом.
А если серьёзно, MongoDB использует memory-mapped files, а следовательно, всё выглядит так, как будто она съела всю доступную память, но на самом деле эту память съел файловый кэш. Который сам сбросится на диск и уменьшится в объёме, если другому приложению понадобится больше памяти.
Иначе говоря, потребление памяти MongoDB не надо ограничивать снаружи. Его надо ограничивать изнутри, шардингом.
+1
Их мать, опять полнотекстовый поиск отложили.
+2
а зачем он там нужен?
0
Вариант, предложенный в доке, не устраивает по нескольким причинам. Разбив текст на слова и применив ключ на это поле, мы получим дубликат данных как на диске так и в памяти + 40 байт за каждое слово (таков оверхед у ключей на элемент, это осуждалось на конференции MongoDB Day Moskow в этом году). Ключи выгружаются в память монгой при старте. Таким образом никакой оперативы не хватит на большое количество текста. Так же нет морфологии. Сложно строить запросы на сложное вхождение словосочетаний и т.д. Я на той конфе разговаривал с Матиасом по поводу полнотекстового поиска, они хотели сделать хук для любого(любого ли?) полнотекстового движка, однако его ещё нет. Приходится выгружать в сфинкс, нагружается целостность данных. Изменились данные в одном месте — измени сам в другом. Не удобно, короче. (Извиняюсь за свой русский)
+1
Сорь, здесь
*осуждалось === обсуждалось
*осуждалось === обсуждалось
0
не надо все в одну кучу пихать: бд для данных, сфинкс (солр) для поиска. никто же не использует mysql для поиска в большом приложении, хотя там есть MATCH
0
> никто же не использует mysql для поиска в большом приложении, хотя там есть MATCH
Вы не представляете как меня это раздражало. Однако у сфинкса есть интеграция с mysql тем самым можно работать с полнотекстовым поиском в mysql. В монге этого не хватает.
> не надо все в одну кучу пихать
Я приверженец не раскидывать единые данные на разные кучи.
Вы не представляете как меня это раздражало. Однако у сфинкса есть интеграция с mysql тем самым можно работать с полнотекстовым поиском в mysql. В монге этого не хватает.
> не надо все в одну кучу пихать
Я приверженец не раскидывать единые данные на разные кучи.
0
Подскажите, транзакции есть в MongoDB?
0
Нет, транзакций нет. Есть update c атомарными операторами и атомарный же findAndModify.
+2
Который атомарен только на уровне ряда. То есть это тоже совсем не панацея
0
Продолжая про атомарные — а вы не знаете можно ли какой ключ на update указать что бы all or nothing было. А то у меня скажем три атомарные операции $inc, $pop, $push и вот допустим если pop`ить нечего то $inc и $push всё равно выполняться, а хотелось бы что бы нет :).
0
Короче вы хотите транзакции :-)
0
Не… это я хочу всего лишь в рамках одного апдейта, то есть я апдейчу один документ. Я многого хочу?
0
Аа, ну да, это не транзакции.
Если хотите посмотреть, насколько это будет «всего лишь» — предложите ваш синтаксис. Как, по вашему, должен выглядеть такой запрос? Потом заодно посмотрим, насколько сложнее стал язык запросов благодаря такому усложнению.
Если хотите посмотреть, насколько это будет «всего лишь» — предложите ваш синтаксис. Как, по вашему, должен выглядеть такой запрос? Потом заодно посмотрим, насколько сложнее стал язык запросов благодаря такому усложнению.
0
Насколько я знаю, никак. Для $push единственный вариант поведения с несуществующим или пустым полем — добавить это поле как массив с заданным значением. Для $inc аналогично.
0
лучше бы в конце-концов доделали row-wide locking. Ну или хоть collection-wide…
А то по-прежнему всю ДБ лочат
А то по-прежнему всю ДБ лочат
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
MongoDB 2.0