Является ли mongodb пригодным для таких сайтов, как stackoverflow?

Ответ 1

Проще говоря: да, это может быть.

Позвольте разбить различные страницы/функции и посмотреть, как они могут быть сохранены/воспроизведены в MongoDB.

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

Изменить:, как @beagleguy, вы можете быстро достичь этого ограничения размера документа 4 МБ таким образом, чтобы он было бы лучше хранить ответы в отдельных документах и ​​связывать их с вопросом, сохраняя ObjectID в массиве.

votes может храниться в отдельной коллекции с простыми ссылками на вопрос и на user, которые проголосовали. A db.eval() вызов может быть выполнен, чтобы увеличивать/уменьшать подсчет голосов непосредственно в документе при добавлении голоса (хотя он блокирует так, что 't be very performant), или MapReduce вызов может быть сделан регулярно, компенсируя эту работу. Он может работать одинаково для favourites.

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

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

Страница "Вопросы" и ее фильтры могут обрабатываться с помощью закрытых коллекций, а не для непосредственного запроса этих данных.

В конечном счете, YMMV. Как и во всех инструментах, есть преимущества и затраты. Есть некоторые функции SO, которые потребуют большой работы в СУБД, но могут быть обработаны довольно просто в Mongo и наоборот.

Я думаю, что основным преимуществом Mongo над RDBMSs является безрезультатный подход и репликация. Частое изменение схемы в "реальном" приложении на основе RDMBS может быть болезненным, даже невозможным, если оно сильно используется с большими объемами данных - эти типы операционных систем могут блокировать таблицы слишком долго. В Mongo добавление новых полей тривиально, так как вам может не понадобиться добавлять их в каждый документ. Если вы выполняете свою относительно быструю операцию для запуска карты/сокращения для обновления документов.

Что касается репликации, Mongo имеет то преимущество, что БД не нужно приостанавливать, чтобы сделать снимок для ведомых. Многие РСУБД не могут настроить репликацию без такого подхода, который на больших БД может занять мастер в течение длительного времени (я смотрю на вас, MySQL!). Это может быть благом для сайтов типа StackOverflow, где вам нужно масштабироваться в течение долгого времени - не отнимать мастер каждый раз, когда вам нужно добавить node.

Ответ 2

Я думаю, что это так.

Вы можете сохранить сам вопрос, ответы и комментарии по вопросу + ответы как один mongo-документ. Максимальный размер документа составляет 4 мб, поэтому ни один документ в stackoverflow не будет слишком большим для монго. Я загрузил содержимое stackoverflow (дамп данных) с помощью bittorrent, и я смог импортировать этот контент в монго.

Импорт этих данных в mongo не является тривиальным, потому что дамп stackoverflow состоит из нескольких xml файлов, и каждый xml файл соответствует одной реляционной таблице, поэтому приходится рекомбинировать эти данные в формате документа.

Я также добавил отображаемое имя + репутацию комментаторов OP + + комментаторов к этому документу. Это означает, что если пользователь меняет свое имя, вы должны обновить все документы с помощью своего идентификатора пользователя. Если вы денормализуете свои данные, стоит заплатить цену. То же самое, если изменится репутация пользователя.

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

Здесь вы можете загрузить дамп данных stackoverflow: http://blog.stackoverflow.com/category/cc-wiki-dump/

Ответ 3

Я бы сказал "нет", это не очень удобно, тем сложнее, что ваши объекты получают более объектную/документальную базу данных. Но если вы посмотрите на SO, большинство из них не являются сложными отношениями с объектами.

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

Есть запросы, выполняемые в фоновом режиме для значков и т.д., вам нужно быстро проверить, не попадаете ли вы за репутацию за голоса... много реляционных запросов, которые проще в РСУБД, учитывая сложность объектной модели.

Это, конечно, мое мнение, возможно, структура SO намного сложнее, чем кажется

Ответ 4

С RDBMS для OLTP-стороны вашего приложения и правильного кэширования - он должен работать изящно.

Фактически - существует клон с открытым исходным кодом stackoverflow, который использует RoR и MongoDB.:)

Ответ 5

Вы также можете использовать $inc/$dec для отслеживания треков, поэтому нет необходимости использовать db.eval

Ответ 6

Я думаю, это было бы хорошо. Существует множество причин использовать базы данных Nonrel, такие как MongoDB, на сайтах, которые работают аналогично StackOverflow. Подумайте о том, как RDBM хранят данные на диске и принимают во внимание размер блока блока и аналогичные атрибуты диска при планировании макета. Мне нравится пользоваться документами, которые охватывают несколько блоков файловой системы и хранят в себе множество связанной информации в себе красивую и сглаженную. Я обнаружил, что хранилище менее распространено, и можно записать один блок, содержащий много информации, в которой несколько блоков будут записаны с использованием других решений.

Ответ 7

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