Существуют ли системы баз данных, более подходящие для социальных сетей? - PullRequest
2 голосов
/ 23 октября 2009

Этот вопрос вдохновлен статьей " Почему Facebook, Digg и Twitter так трудно масштабировать? " на highscalability.com

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

Ответы [ 3 ]

7 голосов
/ 23 октября 2009

Наличие системы базы данных, в которой модель данных адаптирована для структуры данных, которую вы пытаетесь представить, часто выгодно. Социальные сети очень хорошо подходят для баз данных Graph, таких как Allegro Graph , Neo4j и т. Д.

В блоге Neo4j есть хорошая статья о том, как представлять социальные сети в графовой базе данных, с примерами использования Neo4j.

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

Отказ от ответственности: я являюсь членом команды Neo4j.

3 голосов
/ 23 октября 2009

Проверьте отчет NOSQL , он содержит интересные ресурсы по нескольким распределенным нереляционным базам данных:

Презентационные слайды и видео
Вступительная сессия - Тодд Липкон, Cloudera (слайды, видео1, видео2)
Волдеморт - Джей Крепс, Linkedin (слайды в формате ppt, ppt, видео1, видео2)
Кассандра - Авинаш Лакшман, Facebook (слайды pdf ppt, видео)
Диномит - Клифф Мун, Powerset (слайды, видео)
HBase - Райан Роусон, Stumbleupon (слайды, видео)
Hypertable - Даг Джадд, Звенц (слайды pdf ppt, video1, video2)
CouchDB - Крис Андерсон, couch.io (слайды, видео1, видео2)

VPork - Джон Трэвис, Спрингсорс (слайды, видео)
MongoDb - Дуайт Мерриман, 10ген (слайды, видео)
Бесконечная масштабируемость - Jonas S Карлссон, Google (слайды, видео)

Некоторые видео Джона Куинна из Digg, отдых Мартин Диттус с Last.fm. Фотографии Russ Garrett с Last.fm.

Ссылки на слайды и видеоролики можно найти на исходной странице, их слишком много для вставки.

Возможно, вы захотите прочитать NoSQL: если бы это было так просто (и даже запись Nosql в Википедии).

1 голос
/ 23 октября 2009

В статье косвенно сообщается вам ответ, когда упоминается memcached. Это хранилище значений ключей, которое хранит все свои данные в оперативной памяти. Очевидно, у вас должны быть дополнительные хранилища данных, которые хранят данные на жестких дисках, но они, вероятно, также являются хранилищами ключей. Есть много таких как Hadoop , CouchDB , Tokyo Cabinet и Redis .

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

...