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 миллионов у них уже было), похоже, скучно не будет.
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

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

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

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

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

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

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

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

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

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