Как стать автором
Обновить

Комментарии 33

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

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

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

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

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

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

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

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

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

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

На практике тот же PostgreSQL на многих задачах показывает лучшую производительность, чем монга.
Раньше при записи в коллекцию (таблицу), сама коллекция блокировалась на чтение, т.е. в момент записи невозможно было читать информацию из других документов коллекции пока не закончится запись. Это было недостатком Mongo, особенно в приложениях где часто что-то пишут в базу. Теперь блокируется лишь 1 документ из коллекции, в который что-то пишут.
Стоит заметить, что читать, теоритически можно. Если настроена replica set, можно читать с secondary нод.
Не очень пони про хранилище — они что, собираются забросить святой mmap? Неужели на восьмой год разработки дошло, что есть способы работать с диском эффективнее? :)
Ребята молодцы и двигаются в правильном направлении. RocksDB в качестве бэкенда — это в первую очередь корпоративная поддержка Facebook, и это серьёзно. Занятно что архитектура с подключаемыми движками хранения становится стандартом для СУБД — сначала MySQL, затем Riak, Voldemort, теперь Mongo
Лучше бы они подумали над тем, как сообщать приложению о возникающих ошибках. Каждая команда делает это своим уникальным способом. А для полного удобства, коды ошибок от mongo и mongos могут отличаться, причем сами коды не документированы.
Кстати, про ошибки тоже упоминали на одном из докладов. Они их как-то доработали, добавили больше отладочной информации. Но конкретики пока дать не могу.
Спасибо. Действительно добавили. Было три разных способа возвращать ошибки, теперь их четыре основных и один устаревший. Модифицирующие операции теперь возвращают WriteResult или BulkWriteResult, в которых надо искать поля writeError или writeConcernError (writeErrors или writeConcernErrors).
Для операций чтения осталось поле $err, а для runCommand феерический double флажок ok. Старый добрый getLastError все еще можно использовать для высокоуровневых команд, если только не используются групповые операции.
Мы используем 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 снова будет с нами!
Shards are the secret ingredient in the web scale sauce. They just work.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории