如果表将有数十亿行，则在设计数据库架构时的注意事项

Question

我即将开始从事电话词典类项目。它确认字典表中将有数十亿条记录，并且该字典表中的每个条目可能有参考字典表的进一步库存表。我之前没有使用过如此庞大的数据库。

InnoDB 有利于维护关系数据库。有类别和子类别引用，所以我将使用 InnoDB。会出现一种情况，我需要根据类别或子类别，甚至根据州和城市来显示总数。等等……它可以是任意组合。

我熟悉在大多数搜索列上创建索引。我听说过表分区也有助于加快查询速度。

我的问题是在创建此类将有数十亿行的数据库表时，在早期阶段我应该考虑哪些要点，以便以后当表变大时，我可以通过选择查询和 DML 查询将表性能保持在高水平（插入，更新）。

指导会给我很大帮助。

Answer 1

开始了解您面临的问题与您使用的数据库技术无关。它们是由物理引起的，物理不关心 oracle、microsoft 或开源。这是相同的。

通常 - 根据查询，您可能需要一个 HUGH 服务器（尽管“十亿行”对于电话词典来说听起来太多了）。或服务器集群。不是“我有 8GB 内存”。我这里有一个 48GB 内存的 sql 服务器，猜猜是什么 - 在谈论大数据时，它很小，不是说很小。

此外，临时可能不起作用。Oracle Exadata 是一款出色的硬件，可以通过纯粹的力量实现临时工作 - 但即便如此，也存在限制。

会出现一种情况，我需要根据类别或子类别，甚至根据州和城市来显示总数。

有一个称为数据仓库的概念，它具有与 oltp（事务）数据库完全不同的架构。我建议您阅读数据库概念以及 OLAP 和 OLTP 之间的区别，以及规范化和 - 另一方面 - 星型模式（用于报告。

通常，您可能会在这里遇到实时问题，因此可能需要定期更新预先计算的表格。数字可能会关闭，但谁在乎城市的数字是否晚了 5 分钟（或您使用的任何更新间隔）。

在很大程度上取决于确切的业务需求。关于什么是可接受的，某些查询发生的频率，是否可以卸载。数据集市/仓库可能是将报告/聚合查询与 OLTP 查询隔离以减轻服务器负担的好主意。有时你不能。但并非所有事情都可以/应该临时完成，尤其是当多个用户点击相同（大量）查询时。

通常 - 指导是“阅读一些书籍或聘请知道如何使用数据库的人”。重点是 - 你甚至不知道问正确的问题。而你专注于 Innodb 是完全错误的原因（“有利于维护关系数据库”——这就像说“巨无霸做出美味的食物，因为他们的汉堡包有肉”——在声明中根本没有任何意义。