Вопросы по MongoDB

Пишут, что лимит на коллекцию - 16MB

Лимит на размер документа, ЕМНИП.

Коллекция - это, грубо говоря, аналог таблицы из реляционных БД.

Пишут, что лимит на коллекцию - 16MB

Уже 32, ЕМНИП, и да, на размер документа а не коллекцию.

Точно, ошибся. Но, получается, это еще хуже, не?

Точно, ошибся. Но, получается, это еще хуже, не?

Почему, коллекция состоит из документов. 16 мб для одного документа - вполне достаточно.

т.е. если я храню коллекцию пользователей, то 1 документ == 1 пользователю?
если размер превышает 16МБ - значит, плохая структура?

1. Пишут, что лимит на коллекцию - 16MB. Много ли это? Пока что нет четкого понимания, что такое Коллекция.

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

Коллекция - это коллекция. Набор объектов («документов») возможно схожей структуры. Отличие от реляционных таблиц состоит в том, что когда в rdbms некий объект надо раскидывать по нескольким таблицам, в монге его целиком можно просто поместить в одну коллекцию.

3. Пишут, что сейчас блокировка там на уровне БД.

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

т.е. если я храню коллекцию пользователей, то 1 документ == 1 пользователю?

Да. Ты не можешь ввести информации об одном пользователе больше 16 мб.

если размер превышает 16МБ - значит, плохая структура?

Именно. Разработчики сказали, ЕМНИП: если вы не можете уложиться в 16 (уже 32) мб - это ваши проблемы, если мы увеличим максимальный объем документа, будет оверхед на IO.

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

Блокировки в Mongo были на уровне ноды (т.е. блокировались все базы на ноде) данных, с версии 2.2 сделали на уровне одной базы на ноде (разные ноды независимы). Обещали, что дальше можно будет запросто сделать блокировки на уровне коллекций и даже документов, но, насколько я понимаю, этого не сделали.

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

Оу...Ну ок, тогда спрошу про конкретную ситуацию:
Допустим, есть ЛОР. Мы хотим хранить его форум в монге.
db - lor
Какие будут коллекции?
Можно ли будет сделать такую структуру:

lor(db).talks(collection).[посты с комментами](document)

т.е. сообщения в толксах хранить:
[
    {
        "id": 123,
        "text": "blablabla",
        "user": 234234,
        "comments_count": 2000,
        "comments": [
            {
                "id": 1,
                "text": "test",
                "user": 444
            },
            ...
            {
                "id": 2000,
                "text": "test2000",
                "user": 444
            }
        ]
    }
]

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

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

Это я понял. Смотри мой пост выше.
Ясное дело, что 1 строка таблицы весом 16МБ - бред. Да и такое крайне редко встречается на практике - ведь все данные разбиваем по таблицам, а потом JOIN'ами и прочими выкрутасами объединяем. Так в этом и вопрос - если одна из фишек Монги - возможность хранить объекты целиком, не разбивая на кучу таблиц - то ограничение, имхо, жесткое.

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

Ссылайся в комментариях на родительский документ, драйвера DB это умеют. И да, почему 16Мб?

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

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

man GridFS

Ссылайся в комментариях на родительский документ, драйвера DB это умеют.

А можно подробнее? Или пример какой-нибудь?

И да, почему 16Мб?

ХЗ, на офф сайте так сказано.

ГридФС легко ставится? И прозрачна ли она? Или после прикрутки GridFS нужно будет сильно менять код?

А можно подробнее? Или пример какой-нибудь?

Можно: http://docs.mongodb.org/manual/applications/database-references/

ХЗ, на офф сайте так сказано.

Да, всё верно, я ошибся, лимит 16 Мб.

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

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

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

ГридФС не ставится, это возможность БД искаропки. Типа блобов в мускуле.

По поводу 16Мб

db.serverBuildInfo()

из консоли mongo даст ответ на вопрос. У меня «maxBsonObjectSize» : 16777216,

сложный индекс по полям игрок+дата на коллекции комментов и все будет ок

и да, map-reduce у монги отвратительный

ты неправильно понял дзен. монга хранит schemaless BSON и строит по ним индексы для быстрого поиска.

зы. покури redis - он по полной noSQL

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

640 кбайт хватит для всех.

И, потом, что делать с пермалинками на посты? Искать pid'ы в топиках? Или плодить очередную быдлокомментоподелку, с которой ничего серьёзного не сделать?

И, потом, что делать с пермалинками на посты? Искать pid'ы в топиках? Или плодить очередную быдлокомментоподелку, с которой ничего серьёзного не сделать?

Крон, я со своим сайтом на 7 страниц не очень понимаю, о чем ты тут говоришь :)

И совсем не догоняю, зачем у постов могут поменяться ID. Кроме того, если ты считаешь, что в 16М пост не поместиться, то... ну сделай модель, которая будет работать с несколькими записями и объединит их в одну.

быдлокомментоподелку

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

Крон, я со своим сайтом на 7 страниц не очень понимаю, о чем ты тут говоришь :)

А зачем для такого MongoDB? :)

И совсем не догоняю, зачем у постов могут поменяться ID

Вопрос не в их смене. А в выборке поста по ID. Перенос постов (и целых веток) между темами при сохранении пермалинков диктует прозраные ID для всей системы + быструю выборку по такому ID. Как это реализовать в схеме, когда комментарии находятся в контейнере?

ну сделай модель, которая будет работать с несколькими записями и объединит их в одну.

Зачем городить костыль на костыле, если сразу можно сделать правильно? :)

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

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

и подходит лишь для выражения эмоций

Именно для этого выражение и было выбрано.

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

Что с ними не так то? Не веду там дискуссий

Что с ними не так то?

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

Т.е. это именно простенькие комментарии к объекту. Но не нормальные дискуссии в контексте форумов (зная привычку ЛОРа менять контекст, напомню, что подветка пошла с обсуждения структуры форума).

Еще вопрос по уникальным ключам.
ensureIndex() - создаем уникальный индекс.

А что будет аналогом конструкции INSERT INTO test (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE b=5, c=7; ?

А зачем для такого MongoDB? :)

Ты такой предсказуемый :). Чтобы разобраться с Mongo... Про язык, на котором написан движок я промолчу.

Вопрос не в их смене. А в выборке поста по ID. Перенос постов (и целых веток) между темами при сохранении пермалинков диктует прозраные ID для всей системы + быструю выборку по такому ID. Как это реализовать в схеме, когда комментарии находятся в контейнере?

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

Если для твоего случая такая схема не подходит - ты делаешь другую.

И потому мы возвращаемся к моему первоначальному утверждению. Т.е. либо у нас полноценный форум, но тогда описанная архитектура малопригодна (всё правильно, нужна другая), либо у нас используется описанная архитектура, но тогда получится не нормальный форум, а очередная убогая (и далее по серии эпитетов) система примитивных комментариев :)

этим оно вообще создает индкес. конфигурировать индекс, как и _составные_ индексы городить - читай мануал.

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

http://blog.mongolab.com/2012/06/cardinal-ins/

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

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

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

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

А что будет аналогом конструкции INSERT INTO test (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE b=5, c=7; ?

Насколько я знаю, аналога для этого нет.

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

Потому что на конкретные вопросы нужно отвечать четко и по делу

Заметь, я это всё почти сразу говорил. Это именно система простеньких комментариев. Но не форум.

Обычно сначала ставят цель

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

http://rsmith.co/2012/11/05/mongodb-gotchas-and-how-to-avoid-them/

переносишь пост и оставляешь документ поста на старом месте с флагом редиректа на новый айди, problem officer ?

problem officer ?

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

Ага, это уже читал.

Возник еще вопрос, более конкретный: не создаются индексы (Perl, делаю как в мануале: http://search.cpan.org/~friedo/MongoDB-0.501.1/lib/MongoDB/Examples.pod):

$db->$users->ensure_index(Tie::IxHash->new(id => 1, unique => 1));

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

И еще: вот я буду сохранять сообшения (posts). Там будет поле комментариев (comments). Как мне туда запихнуть ссылку на другой документ, если я комментарии буду добавлять уже После того, как добавил пост ?

_id - это служебный уник йд который монга делает сама. из плюшек:

* по нему всегда есть индкес;

* из него можно извлечь timestamp.

Ну, ничего страшного, что я его сам задаю, да?

я б застремался

Почему? Пишут, что обычные id'шники (http://www.mongodb.org/display/DOCS/Object IDs).

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