4

我在 SQL Server（2008 R2 开发人员版）中也有一个非常大的表，它存在一些性能问题。

我想知道另一个 DBMS 是否更适合处理大表。我主要只考虑以下系统：SQL Server 2008、MySQL 和 PostgreSQL 9.0。

或者，正如上面提到的问题所暗示的那样，表大小和性能主要是索引和缓存的一个因素吗？

此外，更大的标准化会提高性能还是阻碍性能？

编辑：

下面的评论之一声称我含糊不清。我有超过 2000 万行（20 年的股票数据和 2 年的期权数据），我正在尝试找出如何将性能提高一个数量级。我只关心读取/计算性能；我不在乎写性能。唯一的写入是在数据刷新期间，并且是 BulkCopy。

我已经有一些索引，但希望我做错了什么，因为我需要加快速度。我也需要开始查看我的查询。

提供的评论和答案已经帮助我了解如何开始分析我的数据库。我是程序员，不是 DBA（因此Marco 的书推荐是完美的）。我没有那么多数据库经验，而且我以前从未分析过数据库。我会尝试这些建议并在必要时报告。谢谢！

4

6 回答 6

11

80M 行并不大。您只需要学习如何设计和查询该大小的数据。这可能包括规范化、非规范化、聚类、索引，但通常权衡比它们看起来更深。添加索引实际上会损害读取性能，例如，如果优化器不够好或决定了错误的统计信息。

我建议您阅读重构 SQL 应用程序，因为它不是从“数据库调谐器”而是从开发人员的角度来解决问题的。

这本书由 The Art of SQL 的作者撰写，在许多场景下比较了 Oracle、SQL Server 和 MySQL。它很实用，并带有一些有用的图表。

除非被迫，否则我会远离 MySQL。Postgres 9.0 根据“摇滚”的几个定义摇滚，但我仍会在生产中使用 8.4 几个月。

如果您希望人们帮助您处理此表，请提供尽可能多的详细信息：架构、索引、数据分布、使用模式等。

于 2010-07-13T21:37:01.507 回答
4

你离最大化 SQL Server 还很远。如果您不解决作为性能问题根源的设计和索引问题，您只会将它们移植到不同的平台。

不会有“使数据库快速”的灵丹妙药解决方案，否则很多 DBA 将失业。您只需要进行一些性能分析并微调您的数据库设计和索引策略，以使性能符合您的要求。

对不起，真的没有捷径。

如果您提供有关在性能和基础表结构/索引方面有问题的查询的更多详细信息，我敢打赌 SO 上的聪明人将能够提供一些指导。

于 2010-07-13T21:25:02.043 回答
4

切换 DBMS 不是解决方案。

大有多大？它有哪些指标？

如果它真的那么大，那么你可以分割它吗？

于 2010-07-13T21:16:05.573 回答
1

刚看到这个。您需要查看 infobright.org。对于数字计算，它很棒。它为 mysql 提供了一个数据库引擎，但它是为分析而不是事务更新而构建的。

您将遇到的唯一问题是您的数据集对于 infobright 来说有点小，但应该可以正常工作。

于 2010-10-12T18:16:06.933 回答
1

我认为 simpledb 是选择。考虑到亚马逊将它用于他们的平台。

于 2010-07-13T21:18:49.490 回答
0

大多数真正的大公司、银行、军队、政府委托大量数据的两个 DB 产品是Oracle和DB2。两者都带有适当的价格标签。这两种产品都经过了数十年的密集专业调整，但通常只有那些为高级顾问买单的人才能获得这些好处。我有一个朋友就是这样的 DB2 顾问；他为一条胳膊和一条腿充电，但通过其他人不会考虑的措施实现了一些惊人的性能提升。

这些都不在您的短名单中，因此您可能不会考虑它们。我怀疑任何其他产品也可以处理您的负载，尽管我对 Microsoft 产品有些不信任。所以...考虑到这只是为了信息的信息。

于 2010-07-13T21:26:53.630 回答