Redis против MySQL для финансовых данных?

Question

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

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

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

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

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

Спасибо!

Answer 1

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

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

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

https://github.com/lsbardel/redis

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

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

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

Разработка ориентированных на время приложений баз данных в SQL

Другой вариант, который вы можете рассмотреть, - использовать решение для больших данных:

хранение массивных данных упорядоченных временных рядов в больших производных

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

На самом деле, «Redis vs MySQL» обычно не правильный вопрос, так как это яблоки и груши.Если вы обновляете данные в своей базе данных (также регулярно удаляете), проверьте разделение MySQL.См., Например, ответ, который я написал Каков наилучший способ удаления старых строк из MySQL по мере поступления?

>

Извлечение Разделение MySQL :

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

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

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

А вот это:

Разделение по датам: краткое руководство