到底什么是“大数据库”？

好的，我知道这个愚蠢的问题，但是我看到模糊的注释“大型数据库”以及中小型，我想知道这是什么意思。有人可以为我们的SQL新手定义一个小型，中型和大型数据库吗？

小型数据库成为中型数据库或大型数据库成为中型数据库没有门槛。通常，当我听到这些术语时，就存储的总记录而言，我想到的是特定数量级。

• 小：10 ^5个或更少的记录。
• 中：10 ⁵至10 ⁷条记录。
• 大：10 ⁷至10 ⁹条记录。
• 非常大：10 ^9个或更多记录。

正如海报dkretz所建议的那样，您还可以根据每种数据库具有的属性来考虑它。以这种方式进行分类，我会说：

• 小：性能不是问题。您的查询运行良好，无需进行任何特殊的优化。使用诸如索引之类的前线增强功能时，您只会看到微不足道的性能差异。

• 中：数据库可能有一名或多名兼职维护和保养人员。这些人关注数据库的健康状况。他们的主要管理职责是防止不可接受的性能问题并最大程度地减少停机时间。

• 大型：可能有专门的工作人员，他们的工作是在数据库上工作并提高性能，并确保应用程序更改不会在数据库的整个生命周期内造成架构损坏。密切监视有关数据库的运行状况和状态的指标。需要大量的专业知识来理解和执行优化。

• 非常大：数据库存储大量必须易于访问的信息。绝对需要性能优化才能使每个查询的速度达到最后一盎司，如果没有它，数据库的可用性将大大降低甚至无法使用。数据库可能正在使用复杂的或创新的复制或群集技术，从而突破了当前技术的界限。

请注意，这些完全是主观的，并且某个人很可能具有完全合法的“大”替代定义。

解决它的一种方法是观察测试查询。

小型数据库是索引无关紧要的数据库。

如果没有适当的索引，则中型数据库是查询所花时间超过一秒的数据库。

大型数据库是查询设计，索引修改和许多测试周期的组合，查询通常需要数小时来优化的数据库。

大型数据库迫使您不得不停止使用关系数据库。

换句话说，由于大量的JOIN，世界上所有索引都无法帮助您满足响应时间要求的规范化的关系数据库。

如果您曾经不得不放弃关系数据库以解决其他问题，那么您要么是一个贫穷的数据库开发人员，要么没有专业的DBA，要么拥有非常庞大的数据库。

“大型数据库”确实是一个模糊的概念。该问题的答案中已经有非常不同的答案和意见。定义“小型”，“中型”和“大型”数据库的某些方法可能比其他方法更有意义，但在某些时候，我认为每种定义都是正确，正确和有效的。

一些定义比其他定义更有意义，因为它们侧重于对数据库的设计，编程，使用，维护和管理的重要性的不同方面，而这些不同方面对于可用的数据库确实至关重要。碰巧所有这些方面都受到“数据库大小”的模糊概念的影响。

因此，这是否意味着您能够定义特定的数据库是否很大并不重要？

当然不是。这意味着您在评估数据库的不同设计/运营/管理方面时，将采用不同的概念。这也意味着每次这个概念都是模糊的。

例如：数据库索引策略（数据库设计的一个方面）受到每个表的记录计数（度量“大小”），记录大小乘以记录计数（度量另一个大小）以及查询Vs的影响。 。创建/更新/删除操作比率（数据库使用情况的一个方面）。

如果索引用于具有大量记录的表，则查询响应时间会更好。根据WHERE，ORDER BY和record-aggregation子句的性质，某些表可能需要多个索引。

创建，更新和删除操作会随着受影响表上索引数量的增加而受到负面影响。受影响的表的更多索引意味着RDBMS必须执行更多更改，花费更多时间和更多资源来应用这些更改。

另外，如果您的RDBMS花更多时间来应用这些更改，那么锁也将维护更长的时间，从而影响到其他查询同时发送到系统的响应时间。

那么，如何平衡索引的数量和设计呢？您如何知道是否需要其他索引，以及是否通过添加该索引不会对查询响应时间造成较大的负面影响？答：您可以根据负载/性能要求针对目标负载测试和分析数据库，并分析性能分析数据，以发现是否需要进一步的优化/重新设计/索引。

不同的查询V需要不同的索引策略。创建/更新/删除操作比率。如果您的数据库承受着沉重的查询负载，但很少更新，那么，如果您添加每个改善查询响应时间的索引，则整个应用程序的性能将会更好。另一方面，如果您的数据库正在不断更新，但是查询操作不多，那么使用较少的索引会提高性能。

当然还有其他方面：数据库架构设计，存储策略，网络设计，备份策略，存储过程/触发器/等等。编程，应用程序编程（针对数据库）等所有这些方面都受到不同的“大小”概念（记录大小，记录计数，索引大小，索引计数，模式设计，存储大小等）的不同影响。

我希望有更多时间，因为这个话题很有趣。我希望这小小的贡献可以为您在这个迷人的SQL世界中提供一个起点。

您必须考虑此定义的硬件进步：

1. 小型数据库：工作集适合单个商品服务器的物理RAM（现在约16GB）

2. 中型数据库：可在一台计算机上装入单个或多个（通过RAID）商用硬盘驱动器（现在最多可达到TB）

3. 大型数据库：数据需要分布在多个商用服务器上才能适应（现在最多可以容纳几个PB。）

根据Wikipedia关于超大型数据库的文章

很大的数据库或VLDB是包含非常多的元组（数据库行）或占用非常大的物理文件系统存储空间的数据库。VLDB的最常见定义是占用1 TB以上或包含数十亿行的数据库，尽管此定义自然会随时间而变化。

如果您的数据库足够大，不能仅将其“备份”到开发或测试箱中，则可能有一个“大型数据库”。

我认为诸如Wikipedia或美国人口普查数据之类的数据库都是“大”数据库。我的个人地址列表或待办事项是一个小型数据库。中型数据库介于两者之间。

您可以尝试根据所需的服务器数量来定义大小。小型数据库是您在桌面上运行的应用程序的组成部分，中型数据库将是某个地方的单个mysql（无论如何）服务器，而大型数据库将需要具有某种复制/故障转移支持的多个服务器。