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

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

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

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

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

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

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

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

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

For a project I once needed a simple database that was fast at doing lookups and which would do lots of lookups and just an occasional write. I just ended up writing my own file format.

While you could do this too, it is pretty complex, especially if you need to support it from a web server. With a web server, you would at least need to protect every write to the file and make sure it can be read from multiple threads. The design of this file format is something you should work out as good as possible with plenty of testing and experiments. One minor bug could prove fatal for a web project in this style, but if you get it working, it can work real well and extremely fast.

But for 99.999% of all situations, you don't want such a custom solution. It's easier to just upgrade the hardware, move to Oracle, SQL Server or InterBase, use a dedicated database server, use faster hard disks, install more memory, upgrade to a 64-bit system. Those are the more generic tricks to improve performance with the least effort.

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

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

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

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

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

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

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

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