Три новинки в MongoDB 2.8

    На днях я посетил грандиозную тусовку любителей NoSQL — World MongoDB Conference.



    Eliot Horowitz, Co-Founder и CTO в MongoDB, рассказал о 3 новшествах, которые будут доступны уже в ближайшем релизе.
    Каждое из анонсированных нововведений нацелено на достижение следующих принципов в архитектуре MongoDB:
    • Продуктивность разработчика
    • Горизонтальная масштабируемость
    • Операционная масштабируемость
    • Администрирование одного вебсервера должно быть простым. То же самое касается кластеров

    Видео презентации можно посмотреть здесь.

    Согласованность данных


    MongoDB разрабатывается уже, ни много ни мало, 7 лет. И что же пользователи слышали о согласованности все эти годы? В основном они слышали о глобальных локах на уровне всей БД.

    Важно помнить о том, что блокировки в MongoDB очень похожи на латчи в реляционных СУБД — они очень простые и обычно занимают не более 10 миллисекунд. В MongoDB 2.2 была решена проблема блокировок на уровне всей БД, а также улучшен агоритм lock yielding. Это позволило существенно уменьшить количество проблем, возникавших у сообщества в связи с локами. Тем не менее, разработчики MongoDB продолжали трудиться в этом направлении.

    И вот настал момент истины: MongoDB 2.8 будет иметь блокировки на уровне документов! Это, безусловно, куда большее улучшение, чем долгожданная блокировка на уровне коллекций.

    Блокировка на уровне документов уже выложена на github (v.2.7.3), но ещё не готова для использования в продакшене. Для включения режима блокировки на уровне документов необходимо запустить mongod с ключём useExperimantalDocLocking=true. Продемонстрированный на презентации рост скорости апдейтов ошеломляет: он увеличился примерно в 10 раз с 30.000 per/sec по 340.000 per/sec!



    Произвольные хранилища данных


    Давайте попробуем ответить на один простой вопрос: какой движок для хранения данных является наилучшим для будущего MongoDB? Ориентированный на скорость чтения? Скорость записи? Безопасность? Ребята из MongoDB предпочли не заморачиваться с ответом. Они решили, что ни один из движков нельзя считать оптимальным сразу для всех нужд. И с этим действительно не поспоришь. В общем, они разработали заменяемое API для произвольного storage engine.

    Требований к данному API довольно немало, т.к. оно должно поддерживать все уже существующие фичи MongoDB, поддерживать операционную масштабируемость, добавление одной или нескольких нод в кластер и многое другое.

    В итоге, мы получим возможность подключения заменяемого хранилища, которое будет оптимизировано под конкретные нужды: производительность, сжатие данных и т.д.

    Предполагаемые типы хранилищ:
    — In-Memory
    — RocksDB (из Facebook, заточен под сжатие)
    — InnoDB (из MySQL)
    — TokuKV
    — FusionIO (работает в обход файловой системы, заточен под низкие задержки)

    In-Memory и RocksDB уже доступны в девелоперской ветке на github. Опять же, не торопитесь использовать это на боевых серверах.

    Автоматизация


    Как известно, MongoDB умеет из коробки реплицироваться и шардироваться. В результате мы получаем не один экземпляр БД, а сразу несколько. В по-настоящему больших проектах таких нод может быть очень много. И проблема заключается не только в развёртывании всех этих нод, но и в их дальнейшем обновлении, бэкапировании, мониторинге и многом другом.

    Всю эту рутину теперь за нас будет делать Mongo Management Service (MMS).



    MMS представляет собой дружелюбный веб интерфейс, который позволяет решать целый ряд задач буквально в пару кликов мышкой:
    • Развёртывание в один клик (coming soon)
    • Мгновенное обновление нод (coming soon)
    • Непрерывное (логирование) и инкрементальное создание резервных копий
    • Откат к любому состоянию
    • Мониторинг 100+ системных метрик
    • Настраиваемые уведомлния

    И на закуску: MMS научат интегрироваться с Amazon EC2.

    Что дальше?


    Мне очень нравится тот факт, что команда MongoDB уделяет много внимания тому, чтобы их продукт был удобен и полезен разработчикам. И делают это не в сферическом вакууме, а активно интересуясь мнением непосредственно у сообщества. Поэтому я уверен в том, что MongoDB и дальше будет сохранять отличный темп внедрения новых возможностей, совершенствовать безопасность, автоматизировать и делать ещё более незаметной всю рутину.
    Share post

    Comments 33

      +1
      Еще бы транзакции :)
        +1
          0
          Стоит знать про его особенности.
            0
            Странный там выбор методологии тестирования, на read only/write only версионник и должен сливать блокировщику. Такое надо тестировать oltp/crud-тестами.
          0
          Кстати, транзакции присутствовали в списке для голосования за фичи для следующих версий.
            +1
            Ну конечно! Где транзакции, там и уровни изоляции, а там и нормализация, и пошло-поехало…
            –5
            «И вот настал момент истины: MongoDB 2.8 будет иметь блокировки на уровне документов!» — ну наконец-то. Может дадим ей второй шанс.
              +1
              Я не совсем вас понял. Если не Mongo, то кто же оправдал ваше доверие?
                –2
                Ну, например, hstore в PostgreSQL?
                  –3
                  Вот именно ;)
                  –3
                  Старый добрый Postgres
                    0
                    В 9.4 заявлена поддержка json. При беглом взгляде на доку по 9.4 JSON Types не увидел поддержки даты и времени в JSON типах. Как хранить и осуществлять поиск по таким данным?
                  +1
                  Кто-нибудь может пояснить, что это вообще означает? Спрашиваю, потому что я действительно не знаю.
                    –14
                    Никогда не работал с MongoDB и особо не вникал в суть NoSQL, но насколько я понимаю там доступ к данным имеет такую же структуру, как в Файловой системе. Примерно/вот/так/можно/хранить/данные. И блокировка на уровне документа наверное обозначает блокировку на уровне документа))
                      +8
                      Зовите санитаров. Пациент опять бредить начал.
                        0
                        Прошу прощения? я говорю про Document Stores. Еще скажите что MongoDB не Документо-ориентированная БД. Вы что реально подумали что я говорю о файловой системе в прямом смысле?

                        Соглашусь что доля моей вины в этом есть, потому что по привычке использовал слеш обозначающий вложенность. А не json к которому вы привыкли…
                        Объяснял на пльцах(ближайшая аналогия вложенности у меня ассоциируется с ФС) новичку.
                        А карму слили пофи ВООТ С ТАКИМ ЭГОМ… Раз уж все такие профи, то почему не ответили ему? Отмалчиваетесь? Если уж до сих пор молчите, и так и ни поправили меня, ни объяснили что к чему, ни ссылку на мануал не дали, то какого черта портите мне карму?
                          0
                          Я ничего не подумал, просто прикалываюсь :)

                          Насколько я понял из курса по mongodb. Каждая коллекция представлена в виде отдельного файла, вернее файлов т.к. файл коллекции разбит на куски фиксированного размера (грубо говоря). Новые куски(новый файл) создаются по мере роста коллекции. В каждом куске лежит BSON, это почти JSON, тока оформленный так, чтобы можно было быстро обращаться к нужному куску JSON-документа, сконвертированного в BSON-форму. Также в этих файлах хранятся и индексы как-то.

                          Ну вот, видимо, ребята из MongoDB научились делать блокировку отдельных регионов этих файлов и не ставить lock сразу на все файлы коллекции, как раньше.

                          Если вы имели в виду, что на каждый документ коллекции создаётся отдельный файл, то — нет, это не так.
                            +1
                            Отдельным файлом(-ами) представлены отдельные БД, а не коллекции.
                              0
                              Да, точно :)
                                0
                                Вот оно, что получается… Кто то прослушавший курс говорит глупость с умным видом и его карма растет, не смотря на очевидные ошибки. А Кто то по простому, не используя неизвестных терминов, объясняет человеку суть дела и его тут же вгоняют в минус.

                                Не надо так.
                              0
                              Нет я не против шуток), но после вашей шутки каждый + в вашу шутку шел в минус моей карме)).

                              Нет, ни в коем случае я так не думал…

                              Знаком c BSON. Имел ввиду что документом называют json массив
                              document = { «json»:true }
                              Вложенный документ:
                              { «docwment»: {«notdoc»:true}, «json»:true}
                              И вот во втором случае блокировка ставиться на вложенный массив document. То есть я спокойно могу менять ключ json, пока идет запись в document

                              >Если вы имели в виду, что на каждый документ коллекции создаётся отдельный файл, то — нет, это не так.
                              Я вообще в расчет реальные файлы БД не брал. Исходил из того что называют документами(листовые узлы) в документно-ориентированых СУБД.

                              Претендовать на то как технический реализована блокировка я и не смел. Сразу написал что я не использую MongoDB и не изучал ее технические особенности.
                            0
                            Я требую испытания Поединком!
                          0
                          Грубо говоря: у каждого инстанса монги может быть несколько баз данных; каждая база данных представляет собой список (массив) коллекций; каждая коллекция, в свою очередь, представляет собой массив JSON-документов произвольного формата. Вот в этой новой версии при обновлении какого-нибудь документа блокировка будет не на всю коллекцию, в которой он состоит, а только на сам документ.
                            0
                            Уточнение: сейчас блокировка не на коллекцию, а на базу. Т.е. пока у вас идет запись в одну коллекцию у вас запись в другую коллекцию в этой же базе — блокирована.

                            На практике тот же PostgreSQL на многих задачах показывает лучшую производительность, чем монга.
                            0
                            Раньше при записи в коллекцию (таблицу), сама коллекция блокировалась на чтение, т.е. в момент записи невозможно было читать информацию из других документов коллекции пока не закончится запись. Это было недостатком Mongo, особенно в приложениях где часто что-то пишут в базу. Теперь блокируется лишь 1 документ из коллекции, в который что-то пишут.
                              0
                              Стоит заметить, что читать, теоритически можно. Если настроена replica set, можно читать с secondary нод.
                          +5
                          Не очень пони про хранилище — они что, собираются забросить святой mmap? Неужели на восьмой год разработки дошло, что есть способы работать с диском эффективнее? :)
                            +3
                            Ребята молодцы и двигаются в правильном направлении. RocksDB в качестве бэкенда — это в первую очередь корпоративная поддержка Facebook, и это серьёзно. Занятно что архитектура с подключаемыми движками хранения становится стандартом для СУБД — сначала MySQL, затем Riak, Voldemort, теперь Mongo
                              +1
                              Лучше бы они подумали над тем, как сообщать приложению о возникающих ошибках. Каждая команда делает это своим уникальным способом. А для полного удобства, коды ошибок от mongo и mongos могут отличаться, причем сами коды не документированы.
                                0
                                Кстати, про ошибки тоже упоминали на одном из докладов. Они их как-то доработали, добавили больше отладочной информации. Но конкретики пока дать не могу.
                                  0
                                  Спасибо. Действительно добавили. Было три разных способа возвращать ошибки, теперь их четыре основных и один устаревший. Модифицирующие операции теперь возвращают WriteResult или BulkWriteResult, в которых надо искать поля writeError или writeConcernError (writeErrors или writeConcernErrors).
                                  Для операций чтения осталось поле $err, а для runCommand феерический double флажок ok. Старый добрый getLastError все еще можно использовать для высокоуровневых команд, если только не используются групповые операции.
                                +2
                                Мы используем MongoDB во многих местах, в том числе кластером в 18 нод, и все бы ничего, быстро работает, true NoSQL, и Бог бы с глобальным локом — обходим ограничение несколькими RAID массивами… Меня удивляет сам факт того, что во времена автоматического шардинга и распределения реплик в том же Elastic Search мне приходится каждый раз читать свою же документацию о том, какие ноды что делают при необходимости обслуживания (читай — добавления нод). Приходится вчитываться в нее полностью, вспоминать зачем на одной машине на разных портах висит 3 mongod, а на другой это 6 mongod (в первом случае это 3 data ноды, во-втором это может быть комбинация дата нод, арбитров и конфиг серверов). Не поймите меня не правильно, проблем с чтением документации у меня нет, но есть частичные притязания к идеализму в архитектуре, а также относительно большой опыт работы с другими системами, в том числе Elastic Search, где для горизонтального масштабирования кластера мне всего лишь нужно у новой ноды указать имя кластера. Кстати, наши ребята Alex и Jeff были на Mongo World в качестве участников и рассказывали про кластер с текстовыми файлами (всего 8 нод в шарде/реплике) который заменил систему c веб сервером который раздавал те же файлы но с файловой системы, но они не упомянули о том кластере в 18 нод, который мы со свистом отправляем на пенсию. Стало невероятно сложно отслеживать баги, особенно бесит когда конфиг нода умирает, но никому ничего не говорит, даже процесс и демон висит как ничего не бывало :) В итоге одна из шардов у нас разбухла до 99% на диске, в то время как соседние были ~30%. Раз пять за 3 месяца перезапускал балансировщик, ресинхронизировал реплики, через некоторые время опять та же история. В итоге мы фиксим баги в архитектуре, а точнее с нуля пересоздаем всю систему, но уже в этот раз Монга там только как одна из систем хранения (+Elastic Search +Cassanda), а реал тайм обеспечивается Kaffka pub/sub. В общем что хочу сказать, Монго — это хорошо, но здесь магии нет и на поддержку более-менее сложной архитектуры придется потратиться. Надеюсь что нововведения решат эту проблему и магия Mongo снова будет с нами!
                                  +1
                                  Shards are the secret ingredient in the web scale sauce. They just work.

                                Only users with full accounts can post comments. Log in, please.