Альтернативы традиционным реляционным базам данных для потоков активности

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

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

  • 6 вечера: Джон Благословенный Бэкон
  • 5:30 вечера: Джейн прокомментировала "Снег".
  • 5:15 вечера: Джейн добавила фотографию Бэкона в свой альбом

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

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

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

Я делаю это с MySQL. Таблица моих "действий" настолько компактна, насколько я могу это сделать, клавиши как можно меньше, и они индексируются соответствующим образом. Он работает, но он просто кажется неправильным инструментом для этой работы.

Кто-нибудь делает что-то подобное вне традиционной RDBMS?

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

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

ОТВЕТЫ

Ответ 1

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

Я не знаю, сколько производительности или много данных вы планируете использовать, но 30M строк не так уж много.

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

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

EDIT: некоторые другие моменты:

  • база данных ключей/значений, такая как Cassandra, Voldermort и т.д., обычно не поддерживает вторичные индексы
  • Следовательно, вы не можете делать CREATE INDEX
  • Большинство из них также не выполняют сканирование диапазонов (даже по основному индексу), потому что они используют хеширование для реализации разделения (что они в основном делают).
  • Поэтому они также не имеют срока действия (DELETE FROM tbl WHERE ts < NOW() - INTERVAL 30 DAYS)
  • Ваше приложение должно выполнять ВСЕ это самостоятельно или без него; вторичные индексы - действительно убийца.
  • ALTER TABLE... ADD INDEX занимает довольно много времени, например. MySQL с большой таблицей, но по крайней мере вам не нужно писать много кода для этого. В базе данных "nosql" это также займет много времени, но вы также должны написать кучи и кучи кода для поддержки нового вторичного индекса, исправить его правильно и изменить свои запросы, чтобы использовать его.

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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