大数据量的数据库select？
我即将开始一个应该有一个相当大的数据库的新项目。
表的数量不会很大（<15），大多数数据（99％）将被包含在一个大表中，这几乎是插入/只读（没有更新）。
这张表中的估计数据量每天将增长到50万条 ，我们至less要保留1年才能做好各种报表。
需要将（只读） 复制数据库作为备份/故障转移，并且可能在高峰时间卸载报告。
我对这个大型数据库没有第一手的经验，所以我问在哪种情况下哪个数据库是最好的select。 我知道Oracle是安全的，但如果有人对Postgresql或Mysql有类似的设置经验，那么我更感兴趣。
我在一个每天看到100K-2M新行的环境中使用PostgreSQL，大多数情况下添加到一个表中。 然而，这些行往往会减less到样本，然后在几天内删除，所以我不能说超过1亿行的长期performance。
我发现插入性能是相当合理的，尤其是如果你使用大容量的COPY。 查询性能很好，虽然计划者的select有时让我困惑; 特别是在JOIN / EXISTS时。 我们的数据库需要相当常规的维护（VACUUM / ANALYZE）来保持它的平稳运行。 我可以通过更仔细地优化autovacuum和其他设置来避免这些问题，如果你没有做很多DELETE，那么这不是一个大问题。 总的来说，有一些地方觉得configuration和维护比应该的要困难。
我没有使用Oracle和MySQL，只用于小数据集，所以我无法比较性能。 但是PostgreSQL对大数据集工作正常。
你有“ 数据仓库工具包 ”的副本吗？
build议有以下几点。
-
从符合或组织这些事实的维度中分离事实（可衡量的，数字的）值。 一张大桌子不是最好的主意。 这是一个支配devise的事实表，加上一些小尺寸的表格可以“切分”事实。
-
将事实保持在简单的平面文件中，直到你想要做SQL风格的报告。 不要创build和备份数据库。 创build和备份文件; 仅为您必须从SQL执行的报告加载数据库。
-
在可能的情况下，创build摘要或额外的数据集以供分析。 在某些情况下，你可能需要把整个东西加载到数据库中。 如果你的文件反映你的表格devise，所有的数据库都有批量加载工具，可以从文件中填充和索引SQL表格。
数据量（每年2亿条logging）不是很大，应该使用任何标准的数据库引擎。
如果你不需要现场报道的话，情况就更简单了。 我会镜像和预集合其他服务器上的数据，例如每日批次。 就像S.Lottbuild议的那样，您可能想要阅读数据仓库。
有关谷歌BigTable在那里有一些有趣的点…
Bigtable与DBMS
- 快速查询率
- 没有联接，没有SQL支持 ，列式数据库
- 使用一个Bigtable，而不是有许多标准化表
- 传统观点甚至不在1NF
- 旨在支持历史查询时间戳字段=>这个网页是什么样子昨天？
- 数据压缩比较容易 – 导向是稀疏的
我强调了连接和无SQL支持，因为您提到您需要运行一系列报告。 我不知道有多less（如果有的话）没有能力做到这一点将在你运行报告，如果你在哪里使用这个。
Google的BigTable数据库和Hadoop是两个可以处理大量数据的数据库引擎。
我们使用Firebird作为一个真正庞大的数据库（保存数据超过30年），并且它的规模非常好。
最好的方面是你有configuration的属性，但不像甲骨文，你安装它，它工作得很好，而不需要开始configuration之前，你可以使用它。
