数据库可伸缩性 - 性能与数据库大小

Question

我正在创建一个必须将最多32 GB的数据放入我的数据库的应用程序。我正在使用B树索引，因为读取将具有范围查询（例如从0＆lt; time＆lt; 1hr）。

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

问题：

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

备注：

每条记录都包含几个整数

Answer 1

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

你可以对它进行基准测试您需要存储合理数量的数据。考虑是否根据查询进行索引 - 重读取和轻插入？索引到处都是where子句可能会使用它。轻装，重型插件？可能会避免索引。混合工作量;基准吧！

在进行基准测试时，您希望在数据域和数据域上尽可能地获得真实或真实的数据（数据分布，不仅仅是所有“亨利史密斯”，而是所有名称，例如）。

Answer 2

索引通常会牺牲访问速度的插入速度。您可以从数据库表中找到它（我已经在野外看到过），它们为每一列编制索引。如果更新次数与查询次数相比较小则没有任何内在错误。

然而，鉴于：

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

2 /你每个记录只写几个整数;和

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

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

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

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

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

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

2 /您只需查询时间范围。

Answer 3

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

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

Answer 4

完全同意@ Richard-t - 在批量更新语料库之前完全删除索引在离线/批处理方案中非常常见，只有在更新完成后重新应用它们。

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

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

Answer 5

我认为在BDB文档的某处，他们提到页面大小会极大地影响btree中的这种行为。假设您在并发方面做得不多，而且您有固定的记录大小，那么您应该尝试增加页面大小