Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

Вот попытка подключения базы данных Mongodb и Neo4j - https://neo4j.com/developer/mongodb/