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

Ответ 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, практически все можно сделать на стороне клиента, чтобы отобразить вашу страницу.