数据库选择大数据量？

我即将开始一个应该有一个相当大的数据库的新项目.

表的数量不会很大(<15),大多数数据(99%)将包含在一个大表中,这几乎只是插入/读取(没有更新).

该表中的估计数据量将以每天500,000条记录的速度增长,我们应该保留至少1年的时间来进行各种报告.

需要(只读)复制数据库作为备份/故障转移,并且可能用于在高峰时间卸载报告.

我没有那些大型数据库的第一手经验,所以我问的是那些DB在这种情况下最好的选择.我知道Oracle是安全的赌注,但如果有人有类似设置的Postgresql或Mysql的经验,我会更感兴趣.

我在一个我们每天看到100K-2M新行的环境中使用过PostgreSQL,大多数都添加到一个表中.但是,这些行往往会缩减为样本,然后在几天内删除,因此我不能谈论超过~100M行的长期性能.

我发现插入性能非常合理,特别是如果你使用批量COPY.查询性能很好,虽然计划员的选择有时会让我困惑; 特别是在做JOINs/EXISTS时.我们的数据库需要非常定期的维护(VACUUM/ANALYZE)才能保持平稳运行.我可以通过更仔细地优化autovacuum和其他设置来避免这种情况,如果你没有做很多DELETE,那就不是问题了.总的来说,在某些方面我觉得配置和维护比应该更加困难.

我没有使用Oracle,而MySQL只用于小型数据集,所以我无法比较性能.但PostgreSQL确实适用于大型数据集.

你有" 数据仓库工具包 " 的副本吗？

建议有以下几点.

从符合或组织这些事实的维度中分离事实(可测量的,数字的)值.一张大桌子并不是最好的主意.它是一个支配设计的事实表,加上一些小尺寸表,可以"切割和切割"事实.

将事实保存在简单的平面文件中,直到您想要进行SQL样式的报告.不要创建和备份数据库.创建和备份文件; 仅为您必须从SQL执行的报告加载数据库.

尽可能创建摘要或额外数据集以供分析.在某些情况下,您可能需要将整个内容加载到数据库中.如果您的文件反映了您的表设计,则所有数据库都有批量加载器工具,可以从文件中填充和索引SQL表.

Google的BigTable数据库和Hadoop是两个可以处理大量数据的数据库引擎.

关于Google BigTable的一些有趣观点有......

Bigtable与DBMS

快速查询率

没有联接,没有SQL支持,面向列的数据库

使用一个Bigtable而不是使用许多规范化表

在传统观点中甚至不是1NF

旨在支持历史查询timestamp field =>昨天这个网页看起来像什么？

数据压缩更容易 - 稀疏

我强调了你所提到的需要运行一系列报告的联接和无SQL支持.我不知道有多少(如果有的话)如果你在哪里使用这个,那么你可以在运行报告时做到这一点.

数据量(每年200万条记录)并不是很大,应该与任何标准数据库引擎一起使用.

如果您不需要实时报告,情况会更容易.我在例如每日批处理中镜像并预聚合其他服务器上的数据.像S.Lott建议的那样,您可能希望阅读数据仓库.

我们使用Firebird作为一个非常庞大的数据库(现在保存数据超过30年)并且它可以很好地扩展.

最好的是你有配置的属性,但不像你安装它的Oracle,它可以很好地工作,无需开始配置,然后才能使用它.