LINUX.ORG.RU

Вышла MongoDB 2.0

 , ,


0

1

Вышла очередная стабильная версия MongoDB. Из тех изменений, которые стоит отметить:

  • Журнал теперь включен по умолчанию, данные в нем сжимаются.
  • Индексы стали в среднем на 25% компактнее и быстрее.
  • Для сжатия одиночных коллекций/индексов появилась команда 'comрact' (раньше сжатие можно было делать только через 'repair' всей базы). В отличие от repair, compact не требует для работы удвоенного места на диске, и позволяет гибче работать с репликами.
  • Для реплик добавились теги и приоритеты. Плюс возможность гарантировать распространение критичных данных в группе серверов по окончании команды записи (например, это удобно при создании новых пользователей).
  • В документах теперь можно индексировать несколько гео-координат одновременно (раньше локейшены можно было положить в массив, но такие массивы не индексировались).
  • Oчень большие результаты map/reduce теперь можно складывать в шарды
  • К шардам добавили аутентификацию.
  • Уменьшен размер стека по умолчанию для новых соединений (имеет значение только в конфигурациях с большим количеством клиентов)
  • Начата работа по устранению блокировок при нехватке памяти (когда монга начинает работать с диском).

Разработчики отмечают, что версия 2.0 не означает революционных переделок. Это простое увеличение номера стабильной версии 1.8 на 0.2.

>>> Подробности

★★★★★

Проверено: Tima_ ()

Кто ее использует? Как впечатление? Особенно по сравнению CouchDB.

placement_new ★★ ()

Отлично.

А там уже можно запросить *элементы* поля-массива, содержащегося где-то в документе и удовлетворяющие определенному условию? А то мы в это в свое время уперлись.

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

Надо пример. Поля вложенных документов вполне индексируются. Нельзя сделать только композитный индекс, где больше 1 массива.

Vit ★★★★★ ()

>Это простое увеличение номера стабильной версии 1.8 на 0.2.

Капитан Очередность спешит заметить, что «простое увеличение номера версии» без «революционных переделок» это 1.10, а не 2.0

devnullopers ()

Очень не хватает автоматического инкрементального map/reduce, тогда couchdb будет просто не у дел.

baverman ★★★ ()

Как на нем сделать master<->master репликацию?

exst ★★★ ()

Минорщина. Сервера я конечно обновлю, может памяти меньше жрать станет. С нетерпением ждем инкрементарного map/reduce.

anonymous ()

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

splinter ★★★★★ ()
Ответ на: комментарий от placement_new

>Кто ее использует? Как впечатление? Особенно по сравнению CouchDB.

Вполне нормальная штука. Главное отличие от couch, имхо, это возможность динамически создавать запросы.

В монго запросы создаются прямо в коде, а в couch всё надо заранее написать в виде map/reduce views. На первый взгляд - разница небольшая, но по факту на couch сложно сделать расширяемую вещь с изменяемой на ходу структурой БД.

То есть даже программу типа инет-магазина с админкой, в которой на ходу создаются свойства и поисковые формы, сделать уже сложнее, так как генерить в процессе работы design-документы и грузить в базу - извращение. Впрочем, разработчики couch обещали какой-то свой язык запросов сделать.

Эта особенность couch возникает из-за принципа её работы - результаты views-ов создаются при первом вызове, а потом только обновляются частями при изменении данных. Эдакое постоянное кэширование в файл. Благодаря этому, couch иногда может быть быстрее.

Зато в couch версионность и она на вид БД более надёжная. Монго же раньше после падений требовала каких-то шаманств.

anonymous ()
Ответ на: комментарий от anonymous

Получается, что если у меня запросы «статические» мне лучше выбрать couch, которая не валится от каждого чиха.

placement_new ★★ ()
Ответ на: комментарий от splinter

> нафиг эти форки, уж лучше на firebird для веба переползать, правда грустно будет без автоинкремента и большой кучи ненужных типов данных.

Пьяный, что ли?

AnDoR ★★★★★ ()
Ответ на: комментарий от placement_new

>Получается, что если у меня запросы «статические» мне лучше выбрать couch, которая не валится от каждого чиха.

Монго уже не валится, так что выбирать можно и его:)

Там разный подход к написанию запросов. В монго они достаточно просты, а в couch только map/reduce, и всё. Это требует немного иного подхода, хотя ничего сложного там нет.

Ну и у баз немного разные подходы к репликации, но это уже мелочи.

Лучше прочитать couchdb guide и монговскую документацию, можно даже особо не вчитываться. Сразу станет ясно.

anonymous ()
Ответ на: комментарий от SteveBallmer

>Ура убийце MySQL!

Трактора — убийцы «Газелей»?

Они ж из разных областей :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от placement_new

>Кто ее использует? Как впечатление?

Пока всё на уровне тестов. Для новых сторонних проектов пока не оправдано, так как задач нет, а на старых, где есть задачи, там mysql-legacy :)

Но в тестах — нравится. Так, пока на перспективу без практической надобности попиливаю бэкенд, может для набора опыта и запущу что-нибудь мелкое…

KRoN73 ★★★★★ ()
Ответ на: комментарий от exst

>Как на нем сделать master<->master репликацию?

Погугли, видел рецепты, вроде.

Кстати, это самый привлекательный для меня вариант. Хочется иметь резервный сервер на случай отказа основного, но не реплику, а полноценный. Чтобы мог работать дальше, пополняя данные, и после поднятия основного, тот бы автоматом забрал данные с резервного.

Кажется, именно master-master такому способствует :)

KRoN73 ★★★★★ ()

Кстати, никто не хочет довести до вменяемого состояния nginx-gridfs? Я б чего-нибудь пожертвовал на это.

Vit ★★★★★ ()
Ответ на: комментарий от KRoN73

>Они ж из разных областей :)

Однако ж там, где сейчас по-привычке городят EAV на mysql, монго очень даже подходит. Причем монго является менее костыльным решением, которое ближе к предметной области, чем mysql с костыльными таблицами свойств.

Хотя соглашусь, области всё-таки разные.

anonymous ()
Ответ на: комментарий от KRoN73

Это не master-master, а master-slave с failover'ом. master-master это когда запись может параллельно идти на нескольких репликах

maxcom ★★★★★ ()
Ответ на: комментарий от placement_new

На простых запросах в монге можно спокойно обойтись без мапредьюса, нафигачив индексов. Это удобно. Она вообще довольно понятна после реляционок. Мозг надо всего лишь повернуть под углом, а не выворачивать наизнанку.

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

Vit ★★★★★ ()
Ответ на: комментарий от anonymous

>Однако ж там, где сейчас по-привычке городят EAV на mysql, монго очень даже подходит

Ну, это да. Но это достаточно узкая (хотя и массовая :D) специфика.

Причем монго является менее костыльным решением, которое ближе к предметной области

Когда оно в бэкенде спрятано, то пофиг становится. Собственно, это главная причина, по которой слезать с MySQL на legacy не тянет и по которой в новых проектах то же самое делается :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от maxcom

>master-master это когда запись может параллельно идти на нескольких репликах

Именно про это я и говорю. В идеале не должно быть разницы между тем, на каком сервере делается вставка.

В принципе, на MySQL такое тоже делается, и даже без всяких репликаций, на голом SQL, но это уже велосипед и костыли :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

такую схему умеет, например, Apache Cassandra. Но там много ограничений из-за этого и eventual consistency

maxcom ★★★★★ ()
Ответ на: комментарий от devnullopers

>Капитан Очередность спешит заметить, что «простое увеличение номера версии» без «революционных переделок» это 1.10, а не 2.0

Проверь в калькуляторе. Удивишься

anonymous ()
Ответ на: комментарий от KRoN73

> Погугли, видел рецепты, вроде.

Целый день потратил. Не нашел решения.

exst ★★★ ()
Ответ на: комментарий от placement_new

> Разве это не просто replica set(прошлый replica pair)?

Нет. replica set - это некий master->slave.

exst ★★★ ()
Ответ на: комментарий от exst

>Нет. replica set - это некий master->slave.

Значит, с ним путаю. Насколько я помню, там одна машина, действительно, назначается центральной (но не master в контексте данных) и занимается распределением данных между вторичными. Но в плане модификаций данных все равноценны. Т.е. можешь вносить изменения в любые — и они разойдутся по другим.

Я прав?

Тогда это то, что я называю master-master в контексте данных :)

Вроде, master-slave принято называть, когда slave просто дублирует все изменения с master'а, но не наоборот.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Вы, наверное, имеете ввиду шардинг.

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

exst ★★★ ()
Ответ на: комментарий от exst

>В моем случае две копии одних и тех же данных.

Именно про них и говорю. Я же выше контекст указывал — падает основной сервер — работаем (и читаем, и пишем) на запасном. Поднялся основном — продолжаем работать там (данные, введённые на запасном, уже там, втягиваются).

На второй запись возможна, если положить первый.

Мне казалось, что я видел рецепт именно многосторонней модификации (а иначе бы внимания не обратил). Но на практике так и не собрался попробовать, поломало несколько машин настраивать :)

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

Сейчас порылся в закладках — да, это не replicaSet. Последнее — просто передача данных на слейвы в одну сторону. По интересующей информации ссылку не нашёл. Видно, не откладывал. Нужно было сразу в Scrapbook сбрасывать :)

KRoN73 ★★★★★ ()
Ответ на: комментарий от Vit

Пример я сейчас придумал синтетический, оригинальные условия помню смутно и доступа к той базе сейчас нет.

В общем есть коллекция элементов вот такого типа:

{
  "_id" : "dshjskgjslkfjdk"
  "name" : "Vasily",
  "surname" : "Pupkin",
  "items" : [
    {"id" : 1, "type" : "coffee", "price" : 33},
    {"id" : 33, "type" : "beer", "price" : 70},
    {"id" : 35, "type" : "knife", "price" : 100} 
  ]
}

Надо, зная _id всей записи и id предмета, получить соответствующий элемент из items.

Монговская матчилка, насколько я помню, позволяла накладывать условия на элементы полей, но матчила при этом сами документы и фетчила всё поддерево, включая туда поле-массив полностью.

yoghurt ★★★★★ ()

вопрос ко всем тестировавшим или занимавшимся разработкой с применением mongo. В mongodb есть что-то похожее на транзакции в реляционных бд?

anonymous ()
Ответ на: комментарий от anonymous

>вопрос ко всем тестировавшим или занимавшимся разработкой с применением mongo. В mongodb есть что-то похожее на транзакции в реляционных бд?

Не очень. Изменения одного документа - atomiс, нескольких - нет.

Суть в том, что в случае с монго не нужно разносить данные по нескольким документам, поэтому хватает одного. В отличие от SQL-решений, где в рамках одной транзакции необходимо изменять несколько таблиц одновременно. В монго содержимое нескольких таблиц можно (и нужно) делать как один документ, ведь там можно хранить массивы и прочее прямо внутри, причем структура не фиксирована. Потому проблема транзакций встречается гораздо реже.

Однако бывают случаи, что надо всё же изменить несколько разных документов в рамках одной транзакции. В документации монгодб это предлагают делать частично вручную, там есть рецепт.

anonymous ()
Ответ на: комментарий от anonymous

спасибо за пояснение, еще почитаю документацию.

anonymous ()

Nosql это фантом. Никакой математики, одно шаманство.

AVL2 ★★★★★ ()
Ответ на: комментарий от SteveBallmer

> Ура убийце MySQL!

Точно. MySQL сдохнет от смеха.

rtvd ★★★★★ ()

> Разработчики отмечают, что версия 2.0 не означает революционных переделок. Это простое увеличение номера стабильной версии 1.8 на 0.2.

Эта школота не осилила общепринятые правила нумерации версий. Даже страшно после этого смотреть в их код. Вдруг потом кошмары сниться будут?

rtvd ★★★★★ ()
Ответ на: комментарий от yoghurt

>Надо, зная _id всей записи и id предмета, получить соответствующий элемент из items.

Монговская матчилка, насколько я помню, позволяла накладывать условия на элементы полей, но матчила при этом сами документы и фетчила всё поддерево, включая туда поле-массив полностью.

Ну так в любом случае монга лочит весь документ. Или он настолько большой, что от передачи всего документа клиент валится?

AVL2 ★★★★★ ()
Ответ на: комментарий от anonymous

>>Капитан Очередность спешит заметить, что «простое увеличение номера версии» без «революционных переделок» это 1.10, а не 2.0

Проверь в калькуляторе. Удивишься

Марш назад на уроки информатики. Удивишься.

rtvd ★★★★★ ()
Ответ на: комментарий от AVL2

Массив элементов, который будет прислан в поддереве, может быть довольно большим, и каждый элемент в нём - куда больше, чем в моём примере. На высоких нагрузках оно становилось неприятно :)

yoghurt ★★★★★ ()

Опять повылазили веб-макаки со своими хэш-табличками.

anonymous ()
Ответ на: комментарий от rtvd

А с каких это пор на уроках информатики дают рекомендации(!!!) по оформлению номеров релизов? Школоло?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.