我正在使用Delphi 2009.我有一个非常简单的数据结构,有2个字段:
困难在于我可能有几百万条记录,因此它们的总大小可能超过10 GB.显然,我正在寻找一种磁盘解决方案,而不是内存解决方案.
我的程序需要根据关键字段随机检索这些记录.这就是需要尽可能高效的部分.
我应该将数据库用于这样一个简单的结构吗？如果是这样,哪个数据库最好处理这个并且最简单的实现？
或者,是否有一个简单的磁盘上数据结构,不需要一个完整的数据库,也可以工作？
好吧,我所需要的只是让我回到现实的一个答案.我一直在寻找比简单数据库更简单的东西.但是,如果不使用数据库,那么我意识到我已经用自己对另一个问题的答案回答了这个问题:小应用程序和工具的最佳数据库.
我的回答是DISQLite3为我指定有原因.这就是我实施的可能性.
一些可能的更好的答案.那很棒.我将能够尝试一些不同的方法来看看什么效果最好.
更多的考虑,我不得不改变GpStructuredStorage解决方案的接受答案.
就我而言,总计几千兆字节的一百万条记录将对数据库结构造成压力.具体来说,用于在大多数数据库中存储索引的B*树速度很快,但对于某些操作(如重新索引一百万个值)会减慢.
对于索引,你唯一能找到比B*更快的东西就是哈希表.这正是gabr建议添加到GpStructuredStorage解决方案中所提供的内容.我认为它将哈希值分段为一个4级目录结构的方式非常优雅.
我可以使用哈希解决方案的关键原因是我只需要通过密钥随机访问.我不需要按键排序.如果需要排序,则哈希表的速度增益将会丢失,数据库系统将成为无脑的赢家.
当我开始实现这个时,我应该对这个技术与数据库进行比较.也许我会与Firebird和SQLite进行比较,这两者都是值得对手的.
另外一个跟进:
我刚刚发现了A. Bouchez的Synopse Big Table,它专为速度而设计,几乎可以准确地满足我的问题规格.当我在几个月内完成实施时,我会先尝试一下,然后在这里报告我的结果.
稍后的后续(2015年7月)
我从未尝试过Synopse Big Table.到目前为止,我一直坚持使用我的B*树.但现在我升级到Delphi XE8并计划使用FireDAC和SQLite来使用数据库解决方案.