Правильный дизайн БД для хранения огромного количества данных криптовалюты в БД

Question

Я хочу хранить большое количество данных криптовалют в db. Тогда я хочу показать хорошие графики цен JavaScript с историческими ценами на веб-странице. Проблема в том, что я не уверен, какой дизайн базы данных лучше всего подходит для этой проблемы, я думал о Mysql DB, но, возможно, NOSQL db лучше в этом случае, я не знаю.

Что мне нужно:

• Мне нужно отслеживать как минимум 100 криптовалют с историческими и текущие цены и другая информация о запасах, таких как объем и т. д. *
• Я собираюсь вставлять новые данные каждые 10 минут для каждого шифрования ((6 записей / час * 24 часа * 365 дней) * 100 для каждого шифрования = 5 256 000 новые рекорды в год)
• Мне нужно запросить различные временные диапазоны для каждой монеты, чтобы нарисовать график на веб-странице.

Моя идея:

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

Пример структуры моей таблицы:

tbl_coin_detail:

id.   |Tick_name    | Name      |Algorithm   |Icon  

1     | BTC         |Bitcoin    |SHA256      |path/to/img   
2     | ETH         |Ethereum   |Ethash      |path/to/img
.
.
.

tbl_prices:

id  | price_USD     | price_EUR | datetime              | Volume_Day_BTC        | FK_coin       

1   | 6537.2        | 5 632,28  | 2018-07-01 15:00:00   | 62121.7348556964      | 1

2   | 466.89        | 401.51    | 2018-07-01 15:01:00   | 156373.79481106618    | 2
.
.
.

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

Можете ли вы указать мне правильное направление, как это решить? БД SQL или NOSQL, что лучше? Заранее спасибо.

Answer 1

Если честно, это далеко не «огромный». Мы не говорим здесь о миллиардах записей, поэтому любая правильно проиндексированная БД подойдет.

Answer 2

MySQL рекомендации ...

У вас есть Volume_Day_BTC, но вы говорите «6 записей / час» - это ежедневная запись или более мелкозернистая.

Объем данных не так велик, но будет полезно сократить типы данных, прежде чем вы начнете.

id не требуется; используйте PRIMARY KEY(coin, datetime) вместо.

Тщательно продумайте тип данных для цен и объемов. На одном полюсе находится пространство (следовательно, в некоторой степени скорость); с другой, точность.

DOUBLE -- 8 bytes, about 16 significant digits, large range
DECIMAL(17, 11) -- 8 bytes, limited to $1M and 11 decimal places (not enough?)
DECIMAL(26, 13) -- 12 bytes, maybe big enough?
etc.

Можно ли обобщать данные, скажем, за один месяц, чтобы сэкономить место? Почасовая или дневная средняя / высокая / низкая и т. Д. Это было бы очень полезно для ускорения выборки данных для построения графиков.

В частности, я рекомендую хранить сводную таблицу по монетам + день с объемом, ценой и т. Д. Рассмотрите возможность использования FLOAT (4 байта, 7 значащих цифр, достаточный диапазон) как более чем достаточно для построения графика.

Итак, я рекомендую 3 таблицы:

Coins -- 100 rows with meta info about the currencies.
Prices -- 5M rows/year of details -- unless trimmed  (400MB/year)
Summary -- 36500 rows/year for graphing range more than, say, a week. (4MB/yr)

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

Использовать InnoDB.

Сводные таблицы