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

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

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

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

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

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

Спасибо!

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

<Р →

Отъезд Разделение MySQL:

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

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

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

И этот:

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