Вышла MongoDB 2.0

> А как же подход, что можно все запихнуть в один документ? С одной стороны радуемся, что все можно загнать в одну сущность и не делать join, а с другой молимся, чтобы не перегрузить больше допустимого? В чем фишка?

Фишка в том, что пихать большие файлы внутрь документа не надо. а для маленьких строк и циферок места хватит с лихвой

> Так мы к реляционщине и вернёмся :)

Может и не надо от нее уходить? :)

Какой смысл менять а) все плюшки SQL + немасштабируемость транзакций + относительно скромный объем данных на б) отсутствие разнообразных фич в NoSQL базках типа MongoDB + адские тормоза их map/reduce + отсутствие транзакций вообще (даже если они нужны) + раздутое представление данных?

>> А как же подход, что можно все запихнуть в один документ? С одной стороны радуемся, что все можно загнать в одну сущность и не делать join, а с другой молимся, чтобы не перегрузить больше допустимого? В чем фишка?

Фишка в том, что пихать большие файлы внутрь документа не надо. а для маленьких строк и циферок места хватит с лихвой

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

>А как же подход, что можно все запихнуть в один документ? С одной стороны радуемся, что все можно загнать в одну сущность и не делать join, а с другой молимся, чтобы не перегрузить больше допустимого? В чем фишка?

Там ограничение в 16 мегабайт сейчас, если не ошибаюсь. Этого достаточно для почти всего, и если документы больше - то проблемы в архитектуре. Ну или монго не подходит.

>Держать рядом еще одно специализированное хранилище и молиться, что ссылки с первого на второе не протухнут и что они будут обновляться одновременно?

gridfs не протухает, это ещё один инструмент _внутри_ монго, а не отдельное хранилище.

Скорость же

>Тут — да. Но это достаточно частный случай.

это 99% случаев.

Объект статья, а в ней ссылки, рецензенты и автор.

Посмотри в твиттере объект твит. Там в него чего только не упаковано.

> Ну монго и не претендует на универсальность. но когда можно четко выделить документ - все ок

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

>Какой смысл менять

ключъ - локи и как следствие, масштабируемость.

твиттер.

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

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

>Что делать, если у документа более одного автора? Дублировать документы? :)

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

Или вкладывать ссылки на авторов. А еще лучше сделать коллекцию ссылок на документы с вложенными в них ссылками на авторов и наоборот, колллекцию ссылок на авторов с вложенным списком ссылок на документы.

Но ссылки только в том случае, если не стоит вопрос синхронизации изменений.

>Может и не надо от нее уходить? :)

У SQL баз есть свои недостатки. Например, невозможность делать объекты с динамическими свойствами, когда структуру БД невозможно заранее описать.

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

В таком случае на SQL делатся либо изменение таблиц на лету через ALTER TABLE, но это плохо, т.к. медленно. На таблице с миллионом записей может отрабатывать часами.

Либо делаем EAV, с отдельной таблицей, где каждое свойство занимает одну строку. Но тогда эта таблица может быть очень большой, особенно если у объекта десятки и сотни свойств. В этом случае сначала вроде как всё красиво, но потом оказывается, что для правильного поиска надо делать довольно сложные запросы, с кучей JOIN-ов. Производительность EAV-схемы иногда отличается от обычной на порядок.

Кроме того, размазывание свойств объекта таким образом отдаляет представление от предметной области, и заодно портит все красивые реляционные модели, т.к. каждая таблица уже не является отдельной сущностью.

Лучшим вариантом в таком случае является как раз nosql решение (не всегда монго, можно и XML-based).

> твиттер

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

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

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

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

>и что, все поклонники монгодб пишут свои твиттеры?

да. Это же сотни задачъ, которые хорошо себя ведут только в таком виде.

>а как же нормализация данных?

Нафига эти автомобили. А как же овес?

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

Редис - key-value, а в монге документы.

> Скорость же

Скорость (или точнее, отсутсвие ее) в map/reduce? Ну да, есть такое дело.

>>Какой смысл менять

ключъ - локи и как следствие, масштабируемость.

Отсутствие локов, и как следствие, отсуствие ряда фич?

Кстати, о масштабируемости какого рода идет речь? Что, каждый Василий Пупкин нынче пишет свой собственный Google Earth?

А чойта вы прицепились к map/reduce? Как будто это основной способ работать с монгой :))

>>Держать рядом еще одно специализированное хранилище и молиться, что ссылки с первого на второе не протухнут и что они будут обновляться одновременно?

gridfs не протухает, это ещё один инструмент _внутри_ монго, а не отдельное хранилище.

Да неужели..? Он вообще-то хранит данные хоть у внутри той же СУБД, но в отдельной коллекции. Сможешь атомарно изменить документик с ссылкой на файл и содержимое файла? Ой врядли... Транзакций-то у тебя нет. :)

ОК, можешь записать копию файла а потом обновить ссылку на него. Супер. А что, если процесс станет раком где-то в средине? Будет мусор в базе. Причем будет непросто его обраружить и вычистить. Ах да.. Зачем его вычищать, если у нас масштабируемость и куча железа? Конечно, «настоящего программиста» не парит, насколько прожорливым является его продукт и сколько стоит поддержка железа для него.

> А чойта вы прицепились к map/reduce? Как будто это основной способ работать с монгой :))

А с ней можно работать? :)

А если серьезно... Вот надо например хранить где-то транзакции. Транзакция выглядит как запись {сколько перевели денег, откуда, куда}. Само собой, должна быть возможность посмотреть в любой момент сколько и где денег. Предположим, что транзанкций этих порядка 100.000.000 и они продолжают бодренько лезть в базу.

Какой подход в хранении этого хозяйства в МонгоДБ предложите и как с ним работать? map/reduce посчитать суммы по счетам сможет. Но не быстро. А хочется быстро. :)

>Какой подход в хранении этого хозяйства в МонгоДБ предложите и как с ним работать? map/reduce посчитать суммы по счетам сможет. Но не быстро. А хочется быстро. :)

Если нужно такие вещи получать в режиме он-лайн (а нужно?), я бы пошёл на денормализацию и хранил бы сумму в отдельном документе. Пришла транзакция - инкрементнули

>>Какой подход в хранении этого хозяйства в МонгоДБ предложите и как с ним работать? map/reduce посчитать суммы по счетам сможет. Но не быстро. А хочется быстро. :)

Если нужно такие вещи получать в режиме он-лайн (а нужно?),

Допустим что нужно.

я бы пошёл на денормализацию и хранил бы сумму в отдельном документе. Пришла транзакция - инкрементнули

Хорошо. Значит имеем две коллекции документов: транзакции и суммы по счетам? Тогда как с этим работать в МонгоДБ? Я не вижу безопасного способа.

>Тогда как с этим работать в МонгоДБ? Я не вижу безопасного способа.

А в чём проблема и где небезопасно? $inc же атомарен.

> Хорошо. Значит имеем две коллекции документов: транзакции и суммы по счетам? Тогда как с этим работать в МонгоДБ? Я не вижу безопасного способа.

А я не вижу смысла работать с этим в монго. Монго не система аналитической отчетности и не предназначена для этого. И для говносайтов васи пупкина она тоже не предназначена.

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

>>Тогда как с этим работать в МонгоДБ? Я не вижу безопасного способа.

А в чём проблема и где небезопасно? $inc же атомарен.

Хм.. Мы говорим об одном и том же? Конечно он атомарен, но два инкремента вместе атомарными не являются. А так как добавлению одной записи в коллекцию «транзакций» соответствуют два инкременты в двух элементах коллекции «сумма на счете», то все это в целом является нисколечки не атомарным. Или может Вы имели в виду какую-то другую организацию данных?

>А так как добавлению одной записи в коллекцию «транзакций» соответствуют два инкременты в двух элементах коллекции «сумма на счете»

Да. Два атомарных инкремента по отдельности. Так в чём прикол? Какая опансая ситуация тут может возникнуть?

транзакция вставилась, коннекшен отвалился, общая сумма не увеличилась.

>Конечно он атомарен, но два инкремента вместе атомарными не являются.

Зато можно немного напрячься, и сделать вот так:

http://www.mongodb.org/display/DOCS/two-phase commit

>> Хорошо. Значит имеем две коллекции документов: транзакции и суммы по счетам? Тогда как с этим работать в МонгоДБ? Я не вижу безопасного способа.

А я не вижу смысла работать с этим в монго. Монго не система аналитической отчетности и не предназначена для этого. И для говносайтов васи пупкина она тоже не предназначена.

1. для чего же тогда предназначего Монго?

2. и что же надо использовать для отчетности (и вообще всех этих транзакций, что сваливаются в базу одна за другой)?

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

ОК. С миллионом записей все это решается даже на слонике. Я надеялся, что МонгоДБ сможет поднять большие объемы. Похоже он не может даже маленькие. :)

Это зависит от задач. Фотохоста на потенциальные на доли процента мусора - посрать. На легкую масштабируемость - нет.

> map/reduce посчитать суммы по счетам сможет. Но не быстро. А хочется быстро. :)

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

Для таких ситуаций анонимус уже подсказал http://www.mongodb.org/display/DOCS/two-phase commit

>>Конечно он атомарен, но два инкремента вместе атомарными не являются.

Зато можно немного напрячься, и сделать вот так:

http://www.mongodb.org/display/DOCS/two-phase commit

Вы это серьезно? :)

Конрольные вопросы:

1. что будет, если что-то подключится к базе и будет читать эту коллекцию, пока вы делаете этот игрушечный «two phase commit»?

2. как это будет (не)работать в случае, когда есть несколько приложений, одновременно обновляющих базу?

>> для чего же тогда предназначего Монго?

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

2. и что же надо использовать для отчетности (и вообще всех этих транзакций, что сваливаются в базу одна за другой)?

В случае, когда данные нужны не прямо здесь и сейчас, а например за данеь, то обычно используют OLAP по схеме 1. выгребание данных из транзакционных таблиц 2. представление данных в разных разрезах с жесткой денормализацей и дублированием. В идеале в виде близком к тому, что требуется показать в отчете. 3. ??? 4. PROFIT

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

>> map/reduce посчитать суммы по счетам сможет. Но не быстро. А хочется быстро. :)

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

Представляете себе, так делают и в SQL базках. Причем это несложно. А вот на МонгоДБ и подобных такого я не видел. А вы? Предложите на рассмотрение «историю успеха»?

> Представляете себе, так делают и в SQL базках. Причем это несложно. А вот на МонгоДБ и подобных такого я не видел. А вы? Предложите на рассмотрение «историю успеха»?

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

но на монге это было бы гораздо красивее и поддерживать было бы легче

Что-то я сомневаюсь. У вашего решения потенциал больше. Особенно по части администрирования.

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

Для веба, где клиент может 2 раза кнопку «отправить» нажать - достаточно к формам генерить случайный ID, и сделать временный лог post-запросов. Для исключения «двух постов подряд» хватит за глаза.

>> Представляете себе, так делают и в SQL базках. Причем это несложно. А вот на МонгоДБ и подобных такого я не видел. А вы? Предложите на рассмотрение «историю успеха»?

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

И много было данных, если не секрет? Что до структуры, полагаю она была не очень сложной, раз монго в конце-концов подошла.

только это было очень геморно и таблицы не отличались особой красотой и понятностью.

А подход как у монго, когда не налагается особых ограничений на структуру данных добавил (или хотя бы не забрал) понятности?

кроме того шардинг выполнялся на уровне приложения.

Некрасивно, но и фиг с ним.

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

Печально. Похоже на кривоту mysql.

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

Вы все-таки перевели все на Монго и возрадовались или просто фантазируете? Если бы в СССР построили коммунизм, то много чего было бы. Но мы ведь про «историю успеха» говорим, не так ли?

но что вам до этого, в ваших задачах надо посчитать суммы чего-то там,

Да, такая вот жизнь. Бывает надо и транзакции шустро принимать, и отчеты сходу отдавать. И если отчет формируется более чем за секунду, то я считают что это ненормально. :)

поэтому монго говно.

С этим утверждением сложно спорить.

>Представляете себе, так делают и в SQL базках. Причем это несложно. А вот на МонгоДБ и подобных такого я не видел. А вы? Предложите на рассмотрение «историю успеха»?

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

> Что-то я сомневаюсь. У вашего решения потенциал больше. Особенно по части администрирования.

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

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

> В поиск. Была еще одна тема, где это обсуждалось, с примерами. У меня нет задач, требующих на каждом шаге атомарности и контроля целостности. Скорость, простые выборки и легкое масштабирование мне важнее.

Как я уже говорил, мало кто пишет свой Google Earth. А если это что-то другое, то обычно

а) скорость у монго не выше чем у всяких там mysql и postgres

б) простые выборки он умеет, а что-нибудь слегка сложнее - нет

в) масштабирование можно и на mysql и postgres сделать

Так что плюсы спорны, а минусы - бесспорны.

Для веба, где клиент может 2 раза кнопку «отправить» нажать - достаточно к формам генерить случайный ID, и сделать временный лог post-запросов. Для исключения «двух постов подряд» хватит за глаза.

И много вы создали (знаете) проектов для веба, где понадобилось масштабирование монго, и пришлось жертвовать всем ради этого? Сколько формочек там было отправлено? :)

>Отсутствие локов, и как следствие, отсуствие ряда фич?

не без этого. Меняется парадигма, меняются слабые и сильные стороны.

Кстати, о масштабируемости какого рода идет речь? Что, каждый Василий Пупкин нынче пишет свой собственный Google Earth?

Будете смеятся, но всякие говнолор-эффекты не просто так плодятся. Так что каждый Вася Пупкин имеет реальный шанс пострадать от болезней sql.

> И много было данных, если не секрет? Что до структуры, полагаю она была не очень сложной, раз монго в конце-концов подошла.

данных дохрена, но они все мелкие и структура у них больше для монги подходит.

А подход как у монго, когда не налагается особых ограничений на структуру данных добавил (или хотя бы не забрал) понятности?

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

Некрасивно, но и фиг с ним.

А варианты?

Печально. Похоже на кривоту mysql.

Ага, кривоту в плане отсутствия горизонтальной мастшабируемости из-за того самого замечательного sql :)

Вы все-таки перевели все на Монго и возрадовались или просто фантазируете? Если бы в СССР построили коммунизм, то много чего было бы. Но мы ведь про «историю успеха» говорим, не так ли?

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

>> И много было данных, если не секрет? Что до структуры, полагаю она была не очень сложной, раз монго в конце-концов подошла.

данных дохрена, но они все мелкие и структура у них больше для монги подходит.

Терабайты?

У меня данных много пока не бывало. Скажем так.. Десяток-сто гигабайт всяких мелких записей слоник поднимает на недорогом железе и неплохо в этом копошится с сотнями активных подключений.

Печально. Похоже на кривоту mysql.

Ага, кривоту в плане отсутствия горизонтальной мастшабируемости из-за того самого замечательного sql :)

Не вижу связи. sql как язык сам по себе не является проблемой. И при нормальной реализации масштабирование должно быть чудесным.

Вы все-таки перевели все на Монго и возрадовались или просто фантазируете? Если бы в СССР построили коммунизм, то много чего было бы. Но мы ведь про «историю успеха» говорим, не так ли?

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

1. Цыплят по осени считают. Кстати, интересно было бы сравнить объем хранимых данных в обоих решениях. Впрочем, раз это _новый_ проект, то честного сравнения сделать не получится.

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

> Будете смеятся, но всякие говнолор-эффекты не просто так плодятся. Так что каждый Вася Пупкин имеет реальный шанс пострадать от болезней sql.

Я просто гляну в глаза фактам. Там где для решения на слонике нужен старенький серверок, для аналогичного решения на монго нужен современный кластер (т.к. монго - жалкий тормоз). Меня не сильно удивляет, что задосить старую машинку сложнее чем компашку новых. :)