Требуется: БД для быстрого чтения, доступ к которой осуществляется из приложений ruby

Question

По сути, это финансовая база данных с дневными и внутридневными данными (дата, символ, открытый, высокий, низкий, закрытый, объем, открытый интерес) - очень простая структура. Обновления только один раз в день. Типичным запросом будет: дата и цена закрытия MSFT для всех дат в БД. Я думал, что должно быть что-то, что было бы оптимизировано для большого числа операций чтения, а не большого количества записей, в отличие от СУБД общего назначения, таких как MySQL. Я искал rubyforge.org и не увидел ничего, что конкретно касалось этого (насколько я мог судить).

Answer 1

MS SQL Server можно оптимизировать следующим образом:

ALTER DATABASE myDatabase
SET READ_COMMITTED_SNAPSHOT ON

SQL Server автоматически кэширует ваши данные в памяти, если они интенсивно используются для чтения.

Answer 2

Вы всегда можете использовать RAMdisk для вашей установки MySQL, если ваша база данных достаточно мала. Один из способов сделать ваши таблицы достаточно маленькими, чтобы соответствовать их, - создать их как таблицы MyISAM ARCHIVE. Хотя они очень компактны, сжаты, их можно только добавлять или считывать, но не обновлять. (http://dev.mysql.com/tech-resources/articles/storage-engine.html)

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

Например, при наличии кортежа stock_id, date, price сортировка и получение будут выполняться довольно медленно. Если вместо этого у вас есть stock_id и столбец с некоторыми сериализованными данными, время поиска будет очень коротким.

Другое решение, которое, вероятно, быстрее, - это поместить все данные в альтернативную СУБД, такую ​​как Toyko Cabinet или что-то подобное, особенно если ваши данные аккуратно помещаются в хранилище ключ / значение.

Answer 3

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

Answer 4

Самая известная (по крайней мере, мне!) база данных временных рядов - это Fame , но это дорого, и я сильно сомневаюсь, что есть что-то вроде, скажем, реализации ActiveRecord для нее , Если за последние 10 лет с момента моего последнего прикосновения он сильно не изменился, он вообще не совместим с SQL.

С достаточно узко сфокусированным приложением вы можете более гибко просматривать ваши данные. Например, подумайте, какую информацию вы действительно хотите сохранить? Это атомная цена / hi / lo / close / vol / что угодно, или это более подходящий временной ряд таких значений? Если вы всегда хотите просмотреть серию, сохраняйте серию в строке, а не значение.

Бросаю несколько идей сюда ...

Как это могло бы выглядеть, если бы вы хранили год или месяц одного значения для одной акции в одной строке? Может быть, в виде строки XML, или JSON, или чего-то более краткого из ваших собственных разработок. Сжатый CSV, возможно? Это должно соответствовать значениям месяца в столбце из 255 символов. (Используйте что-то вроде кодирование Хаффмана для кодирования, возможно - один словарь должен работать для всех экземпляров таких похожих данных).

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

Есть очевидный недостаток: у вас будет куча дополнительной работы.

У меня нет личного опыта, но MogoDB утверждает, что предлагает гибкость в реляционном стиле и производительность ключ-значение.

Как уже упоминалось в другом месте, базу данных значений ключей, возможно, стоит посмотреть: Tokyo Cabinet , CouchDB или один из других еще раз, возможно, с объединенным значением для временного ряда.