正确的数据库设计以在数据库中存储大量库存加密货币数据答案

【问题标题】：Correct DB design to store huge amount of stock cryptocurrencies data in DB正确的数据库设计以在数据库中存储大量库存加密货币数据
【发布时间】：2018-12-15 03:28:16
【问题描述】：

我想在数据库中存储大量加密货币数据。然后我想在网页上显示带有历史价格的漂亮 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 DB 或 NOSQL 哪个更好？提前谢谢你。

【问题讨论】：

一般规则：你不能在不知道需要优化的查询的情况下选择优化策略。
您可能想查看 PostgreSQL 时间刻度扩展。

标签： mysql sql database-design nosql bigdata

【解决方案1】：

说实话，这远非“巨大”。我们在这里讨论的不是数十亿条记录，因此任何正确索引的数据库都可以。

【讨论】：

【解决方案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。

Summary tables

【讨论】：

嗨瑞克，感谢您提供宝贵的信息。我不知道汇总表。我整天都在阅读这个问题，每个人都指向聚合时间序列。我知道我是否有 10 分钟。数据库中的数据，以 3 个月的缩放在图表中获取它们是愚蠢的，例如发送 1 天的数据更好。我看到 coinmarketcap.com 以某种方式解决了这个问题，全部缩放以显示 3 天图表，1 天缩放显示 5 分钟图表。如何处理这个缩放数据。我需要 10 分钟、小时、天、3 天数据的汇总表吗。我需要使用 mysql 查询聚合数据，比如按小时、天分组。或其他技术
基本表有10分钟的数据。 3 数据数据可以轻松有效地从当日数据中获取。他们通过创建一个新的SELECT 并从头开始绘制来“放大”。
嗨瑞克，我还有一个问题。在您的回答中，您建议删除 id（主键）并使用 PRIMARY KEY（硬币，日期时间）。如果我理解得很好，这叫复合主键？这个解决方案带来什么优势？对不起，我不是数据库专家。非常感谢您的时间和回答:)
使用 InnoDB，表是根据 PK 排序的。辅助键向下钻取“BTree”以在底部找到 PK。然后通过向下钻取另一个 BTree 来查找该行，即一个在叶子节点中具有 PK 和数据的 BTree。我不知道（没有更多信息）PK(coin, dt) 或 PK(dt, coin) 是否更好。是的“复合”。搜索这些术语；阅读更多我的博客；浏览一下这个论坛。