我的公司将拥有一个由大约2-3亿条logging组成的数据集。 源材料是csv，大约150GB未压缩。 我们需要执行数据的初始加载，然后每天更新约1％的logging。 我们也希望能够保持每条logging的历史。
我们目前使用MySQL，似乎有些人正在使用MySQL和PostgreSQL来处理这个大小的数据库，但是我并没有看到有关他们的经验的很多难以理解的信息。
我们肯定可以逃脱，而不会规范化数据，我可以设想分布在很多服务器上的信息。 那么MongoDB或其他一些非传统的数据存储呢？
有没有人对这种努力的可行性有任何想法？ 我感谢您能够给予的任何帮助。
我在这个大小的数据集中的经验仅限于MSSQL，但它可以最明确地处理这种大小的数据。
我首先关心的是数据的大小。 150Gb的300万条logging每行大约500Kb–这是一大步。 非常非常大的一排 如果你可以规范化到第三范式，那么这可能会有很大的帮助（假设有数据可以正常化）。 如果你不规范（只有一个单一的大表），那么支持ISAM的引擎将比RDBMS更快，所以在ISAM模式下的MySQL是MSSQL的明显select（对不起，我不喜欢对Postgre或Mongo没有任何经验）
也就是说，MSSQL可以处理这样大小的表格，不用担心。 它可以对数据进行分区，以便不同的部分位于不同的磁盘上，这样您就可以在快速磁盘上保持1％的更新数据，并在预算不足的情况下将剩余的数据保留在较慢的磁盘上。 如果你select的DBMS支持这个，那么这可能是一个明智的select。
仅供参考，我曾经pipe理过一个数据库，在一个表中有大约2亿行（但表中只有20Gb），而且一些智能的索引查询时间仍然在毫秒级。 这是正常化的第三范式，所以有很多LOJ来检索相关的数据。
大多数数据库可以轻松pipe理这么大数量的存储，这取决于您在加载数据后如何处理数据。 它是事务性的，所以会经常被查询和更新？ 还是仅仅从事务处理系统每天都有新的信息报道呢？