我们的一个业务问题的解决方案是将大约 5 亿条记录存储到数据库中。 每条记录大约有 40 到 50 列。
我有一个包含所有这些数据的文本文件，大约 150 GB。 （我硬盘的 3 个）
如果我要（以某种方式）将所有这些数据加载到数据库（ORACLE？）中，它的性能会如何？
我的一位同事坚持认为这绝对没问题。 我什至可以索引所有 40 到 50 列，然后写一些 sql 来获取数据。
他说得对吗？ 还是 5 亿条记录对于一个数据库来说太多了？
附言 只需在一些非常好的答案之后添加更多信息： 40 到 50 列将包含小字符串和/或数字。 对于小字符串，我打算使用小于 64 个字符的内容。
【问题讨论】：
标签： database performance
如果没有关于您正在使用的 RDBMS、它是如何托管的以及这是什么类型的数据（大文本、小数字等）的任何信息，一个可靠的答案并不容易。
纯粹的记录数量应该不是问题，几乎每个现代 RDBMS 都可以轻松应对 5 亿甚至更多的记录。
数据如何存储在您的 RDBMS 上会变得更有趣，p.e.它使用什么样的文件系统，有多少磁盘空间可用于表，表如何分布在硬盘上等等，所有这些都应该考虑在内。
一般来说，我建议只对应用程序真正需要的列和查询数据所用的列进行索引，否则它们只会减慢您的插入速度，占用宝贵的磁盘空间并且对您毫无帮助。
这里有一些 SO 链接可能会对您有所帮助：
【讨论】：
您的同事说的有点对 - 数据库中有 5 亿条记录很好，我使用过 2G 行的数据库，那是 10 年前的事了。为每一列建立索引是一个问题——索引会减慢每条新记录的插入速度，并且构建索引会花费很长时间。您需要确定要运行的查询类型，然后适当地编制索引。拥有如此多的记录，您可能会通过规范化数据而受益——扁平结构通常更快，但如果您有重复的长文本字段，那么用查找替换它们可能会带来存储和索引优势。没有看到数据，很难给出更准确的建议。
顺便说一句，如果您确实遇到了性能问题，您还可以将数据分区到物理上单独的表中，也许是按年？
我的下一步（在您选择数据库平台并找到服务器之后）是加载数据并查看其执行情况。我会看看 Bulk Loading your data - 我是一个 Sql Server 家伙，所以集成服务是要走的路。我会确保你有一个唯一的键，如果它不在数据中，请添加一个标识列。然后你就可以测试其中的一些了。 SqlExpress 是免费的，随 SSIS 一起提供，但它只能处理 10G 的数据库 - 但这足以熟悉这些问题。
我定期批量加载一个 4M 行的表，其中包含 50 多列，这大约需要 2 分钟。如果您需要进一步的一对一建议，我很乐意将此离线。
【讨论】：