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

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (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 в этом году). Ключи выгружаются в память монгой при старте. Таким образом никакой оперативы не хватит на большое количество текста. Так же нет морфологии. Сложно строить запросы на сложное вхождение словосочетаний и т.д. Я на той конфе разговаривал с Матиасом по поводу полнотекстового поиска, они хотели сделать хук для любого(любого ли?) полнотекстового движка, однако его ещё нет. Приходится выгружать в сфинкс, нагружается целостность данных. Изменились данные в одном месте — измени сам в другом. Не удобно, короче. (Извиняюсь за свой русский)
        • +1
        • 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…
    А то по-прежнему всю ДБ лочат

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