Будет ли MongoDB хорошей идеей для сайта социальной сети (разработанного в Ruby on Rails)? - PullRequest
21 голосов
/ 21 февраля 2011

Мой проект (в Ruby on Rails 3) заключается в разработке сайта «социальной сети» со следующими функциями:

  • Пользователи могут быть друзьями.Это взаимная дружба;не асимметричный, как Twitter.
  • Пользователи могут публиковать ссылки, делиться ими.Друзья пользователя могут видеть, чем поделился этот пользователь.
  • Друзья могут комментировать эти общие ссылки.

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

Я думаю, что справлюсь с этим уровнем сложности с помощью SQL и RoR.

Мой вопрос: будет ли хорошей идеей использовать MongoDB (или CouchDB) для такого сайта?

Если честно, я думаю, что ответ - нет.MongoDB, похоже, не совсем подходит для отношений «многие ко многим».Я не могу придумать хороший способ MongoDB реализовать дружеские отношения.И я читал, что Диаспора начинала с MongoDB, но затем переключилась на классический SQL.

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

Кроме того, я слышал о графе DB, который, вероятно, великолепен, но мне он действительно кажется слишком молодым, и я не знаю,как они подходят к RoR (и не говоря уже о героку).

Итак, я что-то упускаю?

Спасибо,

Артур

Ответы [ 4 ]

10 голосов
/ 21 февраля 2011

Мне нравится MongoDB и я его часто использую, но я считаю, что если вы имеете дело с реляционными данными, вам следует использовать для этого подходящий инструмент.Для этого у нас есть реляционные базы данных.Mongo и Couch являются хранилищами документов.

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

Хорошая вещь о MongoDB в том, что он очень хорош в масштабировании.Вы можете осколок и создавать наборы реплик.Foursquare в настоящее время использует MongoDB, и он работает очень хорошо для них.MongoDB также выполняет сокращение карт и имеет достойную геопространственную интеграцию.Команда, которая разрабатывает MongoDB, превосходна, и я живу в Нью-Йорке, где они базируются и встречались с ними.У вас, вероятно, не будет проблем с масштабированием, хотя я бы подумал, что начинаю.

Что касается переключения диаспоры ... Я бы не хотел следить за тем, что они делают:)

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

В заключение, когда вы начинаете здесь, вы еще не сталкиваетесь с проблемами массового масштаба и, вероятно, ограниченывовремя и деньгами.Имейте в виду, что даже Facebook не использует только одну технологию, они в основном расширены до NoSQL для определенных функций (таких как обмен сообщениями Facebook).Ничто не помешает вам в будущем использовать скажем Mongo и gridFS для обработки загрузки изображений, геолокации и т. Д. Это хорошо для роста, когда ваши потребности меняются.Я думаю, что ваше интуитивное чувство, что у вас есть приложение SQL здесь, является правильным, и преимущества, полученные с MongoDB, не будут реализованы какое-то время.

8 голосов
/ 21 февраля 2011

Мой совет - использовать то, с чем вы наиболее знакомы, чтобы быстро приступить к работе. Из вашего вопроса звучит так, что это будет SQL, а не MongoDB.

4 голосов
/ 22 февраля 2011

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

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

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

0 голосов
/ 20 октября 2016

Извините, но вы должны начать изучать графики. Используйте базы данных графиков, которые выплевывают данные в формате JSON и записывают их в базу данных Mongodb. Вы имеете дело с сетью, а это означает, что должен быть какой-то график, который позволит вам создать эго (например, пользователя) или фокус или логический центр, который связан с другими узлами вокруг него. Узлы могут быть свойствами определенного пользователя, такими как имя, лайки, друзья, картинки и т. д. График эго будет напоминать концентратор и спицы, если вы будете его рисовать.

Для дальнейшего чтения, вы можете посмотреть, как Facebook реализовал свой Graph API - https://developers.facebook.com/docs/graph-api/overview/

Вот попытка соединить базу данных Mongodb и Neo4j - https://neo4j.com/developer/mongodb/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...