Альтернативы традиционным реляционным базам данных для потоков деятельности - PullRequest
16 голосов
/ 27 августа 2009

Мне интересно, подойдет ли какая-нибудь другая нереляционная база данных для потоков активности - вроде того, что вы видите на Facebook, Flickr (http://www.flickr.com/activity), и т. Д.) Сейчас я использую MySQL но это довольно обременительно (у меня десятки миллионов записей активности), и, поскольку они в основном доступны только для чтения после записи и всегда рассматриваются в хронологическом порядке, я подумал, что альтернативная БД может работать хорошо.

Действия такие вещи, как:

  • 6 вечера: Джон отдавал предпочтение Бэкону
  • 17:30: Джейн прокомментировала Snow Crash
  • 17:15: Джейн добавила фотографию Бэкона в свой альбом

Суть в том, что в отличие от Twitter и некоторых других систем, я не могу просто добавить действия в списки для каждого пользователя, который интересуется этим действием - если бы я мог, это выглядит как Redis будет подходящим вариантом (со списком операций).

Мне нужно сделать следующее:

  • Потяните действия для набора или подмножества людей, за которыми вы следуете ("Джон" и "Джейн"), в обратном порядке дат
  • Вытащить действия для вещи (например, "Бекон") в обратном порядке даты
  • Фильтр по виду деятельности («избранное», «комментарий»)
  • Храните не менее 30 миллионов мероприятий
  • В идеале, если вы добавили или удалили человека, на которого подписаны, ваш поток активности будет отражать это изменение.

Я делал это с MySQL. Моя таблица «действий» настолько компактна, насколько я могу сделать, ключи настолько малы, насколько это возможно, и соответствующим образом проиндексированы. Это работает, но кажется, что это не тот инструмент для этой работы.

Кто-нибудь делает что-то подобное за пределами традиционной РСУБД?

Обновление за ноябрь 2009 г. : Пока рано отвечать на мой вопрос, но мое текущее решение - придерживаться MySQL, но дополнить Redis для быстрого доступа к свежим данным потока активности. Больше информации в моем ответе здесь: Как реализовать поток активности в социальной сети ...

Обновление август 2014 : Спустя годы я все еще использую MySQL в качестве системы записи и использую Redis для очень быстрого доступа к самым последним действиям для каждого пользователя. Работа с изменениями схемы в массивной таблице MySQL стала не проблема благодаря pt-online-schema-change

Ответы [ 6 ]

5 голосов
/ 28 августа 2009

Я бы действительно предложил остаться с MySQL (или RDBMS), пока вы полностью не поймете ситуацию.

Я понятия не имею, какую производительность или объем данных вы планируете использовать, но 30M строк - это не очень много.

Если вам нужно оптимизировать сканирование определенных диапазонов, вы можете сделать это с (например) InnoDB, выбрав (неявно кластеризованный) первичный ключ и / или денормализуя при необходимости.

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


РЕДАКТИРОВАТЬ: Некоторые другие пункты:

  • база данных ключ / значение, такая как Cassandra, Voldermort и т. Д., Обычно не поддерживает вторичные индексы
  • Таким образом, вы не можете сделать CREATE INDEX
  • Большинство из них также не выполняют сканирование диапазона (даже по основному индексу), потому что они используют хеширование для реализации секционирования (что они в основном делают).
  • Поэтому они также не делают истечения диапазона (УДАЛИТЬ ИЗ ТАБЛ. ГДЕ ts <СЕЙЧАС () - ИНТЕРВАЛ 30 ДНЕЙ) </li>
  • Ваше приложение должно делать ВСЕ это самостоятельно или обходиться без него; вторичные индексы действительно убийцы
  • ALTER TABLE ... ADD INDEX занимает довольно много времени, например, MySQL с большой таблицей, но, по крайней мере, вам не нужно писать много кода для этого. В базе данных "nosql" это также займет много времени, НО вам также придется писать кучи и кучи кода, чтобы поддерживать новый вторичный индекс, правильно истечь его и изменять ваши запросы для его использования.

Короче ... вы не можете использовать базу данных ключ / значение в качестве ярлыка, чтобы избежать ALTER TABLE.

2 голосов
/ 07 сентября 2009

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

Я сомневаюсь, что вы найдете какое-либо другое хранилище данных, которое будет делать это, а также современную коммерческую СУБД (Oracle, SQLServer, DB2 и т. Д.) Или любой инструмент opn source, который мог бы выполнить это лучше, чем MySql.

Вы можете взглянуть на Googles BigTable, которая на самом деле является реляционной базой данных, но он может представить объектную личность вашей программе. Это исключительно хорошо для свободного формата текста поиски и сложные предикаты. Поскольку все это (по крайней мере, версия, которую вы можете загрузить) реализовано в Python, я сомневаюсь, что это победит MySql в марафоне запросов.

2 голосов
/ 27 августа 2009

Я также планирую отойти от SQL. Я смотрю на CouchDB , который выглядит многообещающе. Глядя на ваши требования, я думаю, что все можно сделать с помощью представлений CouchDB и списка API.

1 голос
/ 16 сентября 2009

CouchDB не содержит схем, и довольно просто быстро получить огромное количество данных, поскольку вы работаете только с индексами. Вы не «запрашиваете» базу данных каждый раз, вы извлекаете только совпадающие ключи (которые предварительно отсортированы, что делает его еще быстрее).

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

Я только начал исследовать создание решения «поток активности» с использованием CouchDB, и, поскольку парадигма отличается, мое мышление о процессе должно было измениться с мышления SQL.

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

Это идеально для потоков активности, и я могу изолировать все по дате, или вместе с изоляцией даты, я могу дополнительно отфильтровать результаты определенного подтипа и т. Д., Создавая представление по мере необходимости, а также потому, что само представление просто использует javascript и все данные в CouchDB - это JSON, практически все можно сделать на стороне клиента для отображения вашей страницы.

1 голос
/ 07 сентября 2009

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

1 голос
/ 27 августа 2009

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

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

Но для 99,999% случаев вам не нужно такое специальное решение. Проще обновить оборудование, перейти на Oracle, SQL Server или InterBase, использовать выделенный сервер базы данных, использовать более быстрые жесткие диски, установить больше памяти, перейти на 64-разрядную систему. Это более общие приемы, позволяющие улучшить производительность при минимальных усилиях.

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