对表进行分片或分区之前的限制

Question

我是数据库系统设计的新手。阅读了很多文章后，我真的很困惑我们应该有 1 个表而不进行分片或分区的限制是多少。我知道提供通用答案确实很困难，事情取决于诸如

之类的因素

• 行的大小
• 数据类型（字符串、blob 等）
• 活跃查询数量
• 什么样的查询
• 索引
• 重读/重写
• 预期延迟

但是当有人问这个问题

• 如果每天有 10 亿条数据和数百万行添加，您会怎么做？对于如此大的数据库，4 次读取、1 次写入和 2 次更新查询的延迟需要低于 5 毫秒。
• 如果您只有 1000 万行，但更新和读取量很高，您会选择什么？添加的新行数并不重要。高一致性、低延迟是要求。

如果行数少于一百万，并且行大小增加数千，那么选择很简单。但当选择涉及数百万或数十亿行时，事情就会变得更加棘手。

注意：我在问题中没有提到延迟数。请 根据您可以接受的延迟数回答。另外，我们正在讨论结构化数据。

我不确定，但我可以添加 3 个具体问题：

• 假设您为亚马逊或任何电子商务订单管理系统选择 SQL 数据库。订单数量每天都在以百万计的速度增长。已经有10亿条记录了。现在，假设没有数据存档。每秒有超过一千个查询的高读取查询。并且也有写入。读：写比例为100：1
• 让我们举一个现在较小的数字的例子。假设您为 abc 或任何电子商务订单管理系统选择 SQL 数据库。订单数量每天都在增加数千。已经有1000万条记录。现在，假设没有数据存档。每秒有超过一万个查询的高读取查询。并且也有写入。读写比例为10:1
• 第三个示例：免费赠品分发。我们有1000万件好东西要分发。每个用户 1 件好东西。高一致性、低延迟是目标。假设已经有 2000 万用户在等待免费分发，一旦时间开始，他们所有人都会尝试获得免费的好东西。

注意：在整个问题中，假设我们将选择 SQL 解决方案。另外，如果提供的用例在逻辑上没有意义，请忽略。目的是获取数字方面的知识。

有人可以帮忙了解一下基准是什么吗？您当前正在从事的项目中的任何实际数字都可以表明，对于具有如此多查询的大型数据库，这就是观察到的延迟。任何可以帮助我证明针对特定延迟的一定数量的查询选择表数量的合理性的任何东西。

Answer 1

MySQL 的一些答案。由于所有数据库都受到磁盘空间、网络延迟等限制，其他引擎可能类似。

• 无论行数有多少，“点查询”（使用合适的索引获取一行）都需要几毫秒。
• 编写一个需要数小时甚至数天才能运行的SELECT是可能的。所以你需要了解查询是否是这样病态的。 （我认为这是高“延迟”的一个例子。）
• 当您无法维持单个服务器上所需的写入数量时，就需要“分片”。
• 通过使用复制并将读取发送到副本，可以“无限”扩展大量读取。
• PARTITIONing（尤其是在 MySQL 中）的用途很少。更多详细信息：分区
• INDEX 对于性能非常重要。
• 对于数据仓库应用，构建和维护“汇总表”对于大规模性能至关重要。 （其他一些引擎有一些内置的工具。）
• 每天插入一百万行不是问题。 （当然，有些模式设计可能会导致这个问题。）经验法则：100/秒可能不是问题； 1000/秒可能是可能的；之后就变得更难了。更多关于高速摄取
• 网络延迟主要取决于客户端和服务器的距离。到达地球的另一边需要超过200毫秒。另一方面，如果客户端和服务器位于同一栋楼内，则延迟会低于 1 毫秒。另一方面，如果您指的是运行查询需要多长时间，那么这里有一些经验法则： 对于需要命中 HDD 磁盘的简单查询，需要 10 毫秒； SSD 为 1 毫秒。
• 如果数据太大而无法缓存在 RAM 中，UUID 和哈希值对性能非常不利。
• 我没有提及读/写比，因为我更喜欢独立判断读和写。
• “每秒万读”很难实现；我认为很少有应用程序真正需要这样的。或者他们可以找到更好的方法来实现相同的目标。一个用户发出查询的速度有多快？也许每秒一个？有多少用户可以同时连接和活动？数百个。
• （我的观点）大多数基准测试都是无用的。一些基准测试可以表明一个系统的速度是另一个系统的两倍。所以呢？一些基准测试表明，当您有超过数百个活动连接时，吞吐量就会停滞，并且延迟会趋于无穷大。所以呢。当应用程序运行一段时间后，捕获实际查询可能是最好的基准。但它的用途仍然有限。
• 几乎总是单个表比拆分表（多个表；分区；分片）更好。如果您有具体的例子，我们可以讨论一下表格设计的优缺点。
• 行的大小和数据类型——大列（TEXT/BLOB/JSON）被“不记录”存储，从而[可能]导致额外的磁盘命中。磁盘命中是任何查询中成本最高的部分。
• 活跃查询——几十次之后，查询就会相互冲突。 （想象一下杂货店里有很多推着购物车的购物者——“太多”的购物者，每个人都需要很长时间才能完成。）

当您进入大型数据库时，它们分为几种不同的类型；每个都有一些不同的特征。

• 数据仓库（传感器、日志等）——附加到表的“末尾”；高效“报告”的汇总表；巨大的“事实”表（可选择分块存档）；某些“维度表”。
• 搜索（产品、网页等）——EAV 有问题；全文通常很有用。
• 银行业务、订单处理 - 这对 ACID 功能和处理交易的需求非常重要。
• 媒体（图像和视频）--如何存储庞大的对象，同时使搜索（等）相当快。
• '查找最近的' - 需要一个 2D 索引，SPATIAL 或一些技术 此处