Комментарии 33
Еще бы транзакции :)
+1
+1
Стоит знать про его особенности.
0
Кстати, транзакции присутствовали в списке для голосования за фичи для следующих версий.
0
Ну конечно! Где транзакции, там и уровни изоляции, а там и нормализация, и пошло-поехало…
+1
«И вот настал момент истины: MongoDB 2.8 будет иметь блокировки на уровне документов!» — ну наконец-то. Может дадим ей второй шанс.
-5
Я не совсем вас понял. Если не Mongo, то кто же оправдал ваше доверие?
+1
Кто-нибудь может пояснить, что это вообще означает? Спрашиваю, потому что я действительно не знаю.
+1
Никогда не работал с MongoDB и особо не вникал в суть NoSQL, но насколько я понимаю там доступ к данным имеет такую же структуру, как в Файловой системе. Примерно/вот/так/можно/хранить/данные. И блокировка на уровне документа наверное обозначает блокировку на уровне документа))
-14
Зовите санитаров. Пациент опять бредить начал.
+8
Прошу прощения? я говорю про Document Stores. Еще скажите что MongoDB не Документо-ориентированная БД. Вы что реально подумали что я говорю о файловой системе в прямом смысле?
Соглашусь что доля моей вины в этом есть, потому что по привычке использовал слеш обозначающий вложенность. А не json к которому вы привыкли…
Объяснял на пльцах(ближайшая аналогия вложенности у меня ассоциируется с ФС) новичку.
А карму слили пофи ВООТ С ТАКИМ ЭГОМ… Раз уж все такие профи, то почему не ответили ему? Отмалчиваетесь? Если уж до сих пор молчите, и так и ни поправили меня, ни объяснили что к чему, ни ссылку на мануал не дали, то какого черта портите мне карму?
Соглашусь что доля моей вины в этом есть, потому что по привычке использовал слеш обозначающий вложенность. А не json к которому вы привыкли…
Объяснял на пльцах(ближайшая аналогия вложенности у меня ассоциируется с ФС) новичку.
А карму слили пофи ВООТ С ТАКИМ ЭГОМ… Раз уж все такие профи, то почему не ответили ему? Отмалчиваетесь? Если уж до сих пор молчите, и так и ни поправили меня, ни объяснили что к чему, ни ссылку на мануал не дали, то какого черта портите мне карму?
0
Я ничего не подумал, просто прикалываюсь :)
Насколько я понял из курса по mongodb. Каждая коллекция представлена в виде отдельного файла, вернее файлов т.к. файл коллекции разбит на куски фиксированного размера (грубо говоря). Новые куски(новый файл) создаются по мере роста коллекции. В каждом куске лежит BSON, это почти JSON, тока оформленный так, чтобы можно было быстро обращаться к нужному куску JSON-документа, сконвертированного в BSON-форму. Также в этих файлах хранятся и индексы как-то.
Ну вот, видимо, ребята из MongoDB научились делать блокировку отдельных регионов этих файлов и не ставить lock сразу на все файлы коллекции, как раньше.
Если вы имели в виду, что на каждый документ коллекции создаётся отдельный файл, то — нет, это не так.
Насколько я понял из курса по mongodb. Каждая коллекция представлена в виде отдельного файла, вернее файлов т.к. файл коллекции разбит на куски фиксированного размера (грубо говоря). Новые куски(новый файл) создаются по мере роста коллекции. В каждом куске лежит BSON, это почти JSON, тока оформленный так, чтобы можно было быстро обращаться к нужному куску JSON-документа, сконвертированного в BSON-форму. Также в этих файлах хранятся и индексы как-то.
Ну вот, видимо, ребята из MongoDB научились делать блокировку отдельных регионов этих файлов и не ставить lock сразу на все файлы коллекции, как раньше.
Если вы имели в виду, что на каждый документ коллекции создаётся отдельный файл, то — нет, это не так.
0
Отдельным файлом(-ами) представлены отдельные БД, а не коллекции.
+1
Нет я не против шуток), но после вашей шутки каждый + в вашу шутку шел в минус моей карме)).
Нет, ни в коем случае я так не думал…
Знаком c BSON. Имел ввиду что документом называют json массив
document = { «json»:true }
Вложенный документ:
{ «docwment»: {«notdoc»:true}, «json»:true}
И вот во втором случае блокировка ставиться на вложенный массив document. То есть я спокойно могу менять ключ json, пока идет запись в document
>Если вы имели в виду, что на каждый документ коллекции создаётся отдельный файл, то — нет, это не так.
Я вообще в расчет реальные файлы БД не брал. Исходил из того что называют документами(листовые узлы) в документно-ориентированых СУБД.
Претендовать на то как технический реализована блокировка я и не смел. Сразу написал что я не использую MongoDB и не изучал ее технические особенности.
Нет, ни в коем случае я так не думал…
Знаком c BSON. Имел ввиду что документом называют json массив
document = { «json»:true }
Вложенный документ:
{ «docwment»: {«notdoc»:true}, «json»:true}
И вот во втором случае блокировка ставиться на вложенный массив document. То есть я спокойно могу менять ключ json, пока идет запись в document
>Если вы имели в виду, что на каждый документ коллекции создаётся отдельный файл, то — нет, это не так.
Я вообще в расчет реальные файлы БД не брал. Исходил из того что называют документами(листовые узлы) в документно-ориентированых СУБД.
Претендовать на то как технический реализована блокировка я и не смел. Сразу написал что я не использую MongoDB и не изучал ее технические особенности.
0
Я требую испытания Поединком!
0
Грубо говоря: у каждого инстанса монги может быть несколько баз данных; каждая база данных представляет собой список (массив) коллекций; каждая коллекция, в свою очередь, представляет собой массив JSON-документов произвольного формата. Вот в этой новой версии при обновлении какого-нибудь документа блокировка будет не на всю коллекцию, в которой он состоит, а только на сам документ.
0
Раньше при записи в коллекцию (таблицу), сама коллекция блокировалась на чтение, т.е. в момент записи невозможно было читать информацию из других документов коллекции пока не закончится запись. Это было недостатком Mongo, особенно в приложениях где часто что-то пишут в базу. Теперь блокируется лишь 1 документ из коллекции, в который что-то пишут.
0
Не очень пони про хранилище — они что, собираются забросить святой mmap? Неужели на восьмой год разработки дошло, что есть способы работать с диском эффективнее? :)
+5
Ребята молодцы и двигаются в правильном направлении. RocksDB в качестве бэкенда — это в первую очередь корпоративная поддержка Facebook, и это серьёзно. Занятно что архитектура с подключаемыми движками хранения становится стандартом для СУБД — сначала MySQL, затем Riak, Voldemort, теперь Mongo
+3
Лучше бы они подумали над тем, как сообщать приложению о возникающих ошибках. Каждая команда делает это своим уникальным способом. А для полного удобства, коды ошибок от mongo и mongos могут отличаться, причем сами коды не документированы.
+1
Кстати, про ошибки тоже упоминали на одном из докладов. Они их как-то доработали, добавили больше отладочной информации. Но конкретики пока дать не могу.
0
Спасибо. Действительно добавили. Было три разных способа возвращать ошибки, теперь их четыре основных и один устаревший. Модифицирующие операции теперь возвращают WriteResult или BulkWriteResult, в которых надо искать поля writeError или writeConcernError (writeErrors или writeConcernErrors).
Для операций чтения осталось поле $err, а для runCommand феерический double флажок ok. Старый добрый getLastError все еще можно использовать для высокоуровневых команд, если только не используются групповые операции.
Для операций чтения осталось поле $err, а для runCommand феерический double флажок ok. Старый добрый getLastError все еще можно использовать для высокоуровневых команд, если только не используются групповые операции.
0
Мы используем 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 снова будет с нами!
+2
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Три новинки в MongoDB 2.8