Вышла MongoDB 2.0

Ура убийце MySQL!

Is it web scale?

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

Couch дико медленный

Отлично.

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

Пользовались, норм, не знаю

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

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

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

Югурт имеет ввиду слайсы по таким полям.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

…

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

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

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

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

нет не пьяный, удутый в хлам.

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

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

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

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

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

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

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

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

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

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

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

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

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

Нафейхуа? Там есть шарды и реплики.

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

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

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

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

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

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

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

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

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

Я прав?

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

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

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

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

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

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

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

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

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

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

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

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

{
  "_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.

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

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

Максимум, что есть - атомарные операции

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

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

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

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

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

на 2.1 что-то на эту тему запланировано https://jira.mongodb.org/browse/SERVER-828

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

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

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

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

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

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

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

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

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

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

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

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

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

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