В какой БД лучше хранить ежеминутные значения криптовалют (+1500 записей в минуту)?

Question

[Ted7021]

Система собирает данные из CoinMarketCap API для дальнейшего анализа. Пока просто собор данных и отображение графиков.
Что выбрать в качестве хранилища, если каждую минуту добавляется 1500 записей, то есть за сутки больше 2 млн.?
Планируем хранить в MySQL, но я уверен что есть решение более подходящее под эти задачи.
Так что мне нужен совет опытного в БД и в BigData человека.
Спасибо!

Comments

[sim3x]

1500/60 = 25rps

Почитайте, что такое bigdata

[Евгений]

sim3x, что такое rps?

[sim3x]

Евгений, requests per second

Answer 1

[Barhis]

Например, influxDB. Или любая другая time series DB. Она чаще для всяких метрик и мониторинга, но если для вашей задачи требуется привязка к timestamp (например для визуализации графиков) - идеально ляжет.

Answer 2

[Everything_is_not_so_bad]

ClickHouse, InfluxDB.

Comments

[Dimonchik]

Clickhouse

Answer 3

[Максим Тимофеев]

Все зависит от структуры, типов данных. Операций, которые планируете проводить. Их частоты.
1500 записей в минуту, это не страшная цифра для mysql. Вопрос каких записей. Если ключ bigInt
то в базу теоретически влезет 4,294,967,295 записей. А это данные за 5,5 лет при вашей частоте. Но опять таки - количество строк мало что говорит.
Я думаю что Вы раньше упретесь в объем хардрайва, чем в ресурсы БД.

Comments

[Ted7021]

В таблице около 10-ти decimal полей разной длины, максимум 30 (decimal(30, 25)).
Пара полей INT и пара TIMESTAMP.
Операции - в основной поиск/группировка по дате. Никаких сложных операций не предвидеться.
Для таких объемов потребуется кластеризация?
Спасибо!

[Максим Тимофеев]

Ted7021, Я думаю стоит попробовать и не гадать на кофейной гуще. Тестовых данных накидайте и вперед. Замеряйте скорость, определите предельный показатели. От железа же тоже многое зависит. Вам никто не расскажет ничего из того что Вы ожидаете. Данных нет, что бы рассказать. Да и сколько факторов должно совпасть. Глухая затея, делайте тест. это это же не так долго делать.

[Ted7021]

Максим Тимофеев, Спасибо! Так и сделаю.

[Dmitry Bay]

Ted7021, зависит от использования. Если у вас будет сервис для людей, то возмонжо понадобится. если эти данные нужны будут вам - то думаю что нет необходимости.

[Crash]

не поленился ведь, посчитал)

[Максим Тимофеев]

Crash, Хотел ответить. что в уме, но кого я обманываю)))

[Сергей Пуговкин]

Если ключ bigInt то в базу теоретически влезет 4,294,967,295 записей.

https://mariadb.com/kb/en/library/bigint/
9,223,372,036,854,775,807 как минимум

Answer 4

[little-brother]

1500 строк/минуту можно без проблем получить на любой базе, если вставку выполнять не отдельной транзакцией, а пачками по несколько штук, откладывая запись в базу. Даже на SQLite можно получить 100К строк в секунду на запись.

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

Если сильно не загоняться, то достаточно просто разместить таблицу в индексе см. Clustered Index (в PostgreSQL и MySQL) или Index-Organized Tables (в Oracle).

Также можно провести микро-оптимизацию: если известно, что данные поступают с минутным интервалом, то хранить не время (date = 7байт) или unix-epoh (4байта), а номер измерения.

Answer 5

[vanyamba-electronics]

Создаёте диск в ОЗУ, и размещаете базу на нём. Чтобы к жёсткому диску не обращаться.

Answer 6

[asd111]

Clickhouse. Он как раз создан для подобного рода данных и их анализа. Яндекс метрика на нем работает.
Clickhouse оптимизирован для больших транзакций по 400-500 тыс. строк в секунду.
Он хорошо сжимает большие объемы данных так что база будет занимать меньше места на диске чем в других СУБД и хорошо ищет по миллионам строк - в разы быстрее чем MySQL и т.п. РСУБД.
Ещё он хорошо шардится.
И также одно из главных преимуществ - язык запросов похож на SQL с минимальными изменениями.
https://youtu.be/Ac2C2G2g8Cg

Answer 7

[Артемий]

cassandra.apache.org