Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот попытка подключить Mongodb и графическую базу данных Neo4j — https://neo4j.com/developer/mongodb /