数据库可扩展性 - 性能与数据库大小答案

【问题标题】：Database scalability - performance vs. database size数据库可扩展性 - 性能与数据库大小
【发布时间】：2010-09-18 01:36:56
【问题描述】：

我正在创建一个应用程序，它必须将最多 32 GB 的数据放入我的数据库中。我正在使用 B-tree 索引，因为读取将具有范围查询（例如 from 0

在开始时（数据库大小 = 0GB），我将获得每毫秒 60 和 70 次写入。在说 5GB 之后，我测试过的三个数据库（H2、berkeley DB、Sybase SQL Anywhere）真的减慢到每毫秒不到 5 次写入。

问题：

这是典型的吗？
如果我删除了索引，我还会看到这个可扩展性问题吗？
此问题的原因是什么？

注意事项：

每条记录由几个整数组成

【问题讨论】：

顺便说一句，我要尝试提高性能的第一件事是将数据分区到单个列/属性的数据域上。这应该给我 24 张桌子而不是一张。

标签： database scalability

【解决方案1】：

我认为他们在 BDB 文档的某处提到页面大小极大地影响了 btree 中的这种行为。假设你没有在并发方面做太多事情并且你有固定的记录大小，你应该尝试增加你的页面大小

【讨论】：

【解决方案2】：

是的，索引通常会减慢插入速度，同时显着加快选择（查询）速度。

请记住，并非所有对 B 树的插入都是相等的。这是一棵树；如果你所做的只是插入它，它必须不断增长。数据结构允许进行一些填充，但如果您继续向其中插入按顺序增长的数字，则它必须不断添加新页面和/或随机播放以保持平衡。确保您的测试插入分布良好的数字（假设它们在现实生活中会如此），并看看您是否可以做任何事情来告诉 B-tree 从一开始就期望有多少项目。

【讨论】：

好点。通常，出于这个原因，我更喜欢加载一个表，然后构建索引。我什至有时会卸载并重新加载一个表，以帮助在插入新数据（并且在某些情况下更新）的服务中使用大量时间后重新平衡。
Richard，您不需要走那么远，删除并重新创建索引就足够了。虽然你可能会从重新加载中得到一些碎片整理，这可能是一件好事。但一般来说，我会说只是重建索引。
是的，Dmitriy，但一些 RDBMS 具有“固有”表结构，并且不只是索引堆。也就是说，基表本身就是一个结构，就像一个索引——一个内置索引——这种情况可以从不时重新加载中受益。

【解决方案3】：

索引通常会牺牲插入速度来换取访问速度。您可以从为每一列建立索引的数据库表中找到这一点（我已经在野外看到过这些）。如果更新的数量与查询的数量相比，它本身并没有什么问题。

但是，鉴于：

1/ 您似乎担心写入速度会降低到 5/ms（仍然是 5000/秒），

2/ 每条记录只写几个整数；和

3/您的查询仅基于时间查询，

您可能需要考虑绕过常规数据库并滚动您自己的数据库（我的想法是您正在收集实时数据，例如设备读数）。

如果您只写入顺序定时数据，您可以只使用平面文件并定期单独写入“索引”信息（例如在每分钟开始时）。

这将大大加快您的写入速度，但仍允许相对高效的读取过程 - 最坏的情况是您必须找到相关周期的开始并从那里进行扫描。

这当然取决于我对您的存储是否正确的假设：

1/ 您正在按时间顺序写入记录。

2/ 你只需要查询时间范围。

【讨论】：

您的提案中的假设比您列出的还要多！ - 其中最重要的一点是，这个人可能出于充分的理由使用 RDBMS（其中有很多可能）。例如，如果想要进行 JOIN，则需要 RDBMS。
在某些情况下，这实际上是个好主意。诀窍是知道何时使用它。您不知道提出问题的人是否需要加入。

【解决方案4】：

完全同意@Richard-t - 在离线/批量场景中，在批量更新语料库之前完全删除索引是很常见的，只有在更新完成时才重新应用它们。

应用的索引类型也会影响插入性能 - 例如，使用 SQL Server 聚集索引更新 I/O 用于数据分发和索引更新，其中非聚集索引是单独更新的（因此更昂贵）我/O 操作。

与任何工程项目一样 - 最好的建议是使用真实数据集进行测量（页面分布倾斜、撕裂等）

【讨论】：

【解决方案5】：

是的；索引以插入时间为代价提高了获取时间。你的数字听起来很合理 - 不知道更多。

您可以对其进行基准测试。您需要存储合理数量的数据。考虑是否根据查询进行索引 - 重获取和轻插入？索引 where 子句可能使用它的任何地方。轻取，重插入？可能避免索引。混合工作量；对其进行基准测试！

在进行基准测试时，您需要尽可能真实或真实的数据，无论是在数量上还是在数据域上（例如，数据的分布，不仅仅是“henry smith”，而是各种名称）。

【讨论】：