Redis vs MySQL для финансовых данных?

Question

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

Я разрабатываю финансовую базу данных в реальном времени, которая захватывает котировки акций из сети несколько раз в минуту и ​​хранит ее в базе данных. В настоящее время я работаю с SQLAlchemy над MySQL, но я наткнулся на Redis, и это выглядит интересно. Он выглядит хорошо, особенно из-за его производительности, что имеет решающее значение в моем приложении. Я знаю, что MySQL тоже может быть быстрым, я просто чувствую, что реализация тяжелого кэширования будет больно.

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

С точки зрения размера данных, я хватаю около 10 000 символов несколько раз в минуту. Это составляет около 3 ТБ данных в год.

Меня также беспокоит ограничение количества ключей Редисом (2^32). Редис - хорошее решение здесь? Какие еще факторы могут помочь мне принять решение в отношении MySQL или Redis?

Спасибо!

Answer 1

Redis является магазин в памяти. Все данные должны вписываться в память. Так что, если у вас есть 3 ТБ ОЗУ в год данных, это неправильный вариант. Ограничение 2^32 на самом деле не является проблемой на практике, потому что вам, вероятно, придется очертить ваши данные в любом случае (т. Е. Использовать несколько экземпляров), а потому что ограничение на самом деле составляет 2^32 ключа с 2^32 элемента на ключ.

Если у вас достаточно памяти и по-прежнему хотите использовать (sharded) Redis, вот как вы можете сохранить пространство эффективных временные рядов: https://github.com/antirez/redis-timeseries

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

https://github.com/lsbardel/redis

http://lsbardel.github.com/python-stdnet/contrib/redis_timeseries.html

Redis отлично агрегированные статистические данные в режиме реального времени и сохранить результат этих caclulations (т.е. DIRT приложений). Однако хранить исторические данные в Redis гораздо менее интересно, поскольку он не предлагает языка запросов для выполнения автономных вычислений по этим данным. Btree-хранилища, поддерживающие sharding (MongoDB, например), вероятно, более удобны, чем Redis для хранения больших временных рядов.

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

Developing Time-Oriented Database Applications in SQL

Другой вариант вы можете рассмотреть использует bigdata решение:

storing massive ordered time series data in bigtable derivatives

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

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

Что касается использования MySQL, я бы определенно рассмотрел table partitioning из-за объема данных. В зависимости от шаблонов доступа я бы также рассмотрел ARCHIVE engine. Этот движок хранит данные в сжатых плоских файлах. Это пространство эффективно. Его можно использовать с разделением, поэтому, несмотря на то, что он не индексирует данные, он может быть эффективным при извлечении подмножества данных, если тщательно выбрать гранулярность разделов.

Answer 2

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

На самом деле, «Redis vs MySQL» обычно не правильный вопрос, так как это яблоки и груши. Если вы обновляете данные в своей базе данных (также регулярно удаляете), проверьте раздел MySQL. См. ответ я написал What is the best way to delete old rows from MySQL on a rolling basis?

>

Заканчивать MySQL Partitioning:

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

См., Например, этот пост, чтобы получить некоторые идеи о том, как применять его:

Using Partitioning and Event Scheduler to Prune Archive Tables

И это одна:

Partitioning by dates: the quick how-to

Answer 3

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

Ключевой момент по одному из ваших размеров запроса (обычно по тикеру), вы получаете доступ к диску (ssd или spinning), смежно. Вы не должны ударять индексы миллионы раз. Вы можете моделировать вещи в Mongo/SQL, чтобы получить схожую производительность, но это больше хлопот, и вы получаете ее «бесплатно» из коробки с помощью столбчатых парней, не требуя каких-либо шенинов на стороне клиента, чтобы объединить blobs вместе.

Мой опыт работы с Cassandra заключается в том, что он в 10 раз быстрее, чем MongoDB, который уже намного быстрее, чем большинство реляционных баз данных, для случая использования временных рядов, и по мере роста размера данных его преимущество над другими растет. Это верно даже на одной машине. Here - это то, где вы должны начать.

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

Меньше знакомы с Hbase, но он утверждает, что он более согласован (в другом случае будет цена - теорема CAP), но это гораздо более важно для установки стека Hbase.