我想要创建的是一个更大的数据集合的巨大索引。数据是一个巨大的图像集合（我的意思是数百万张照片！）我想在所有独特的图像上建立一个索引。 因此，我计算每个图像的哈希值，并将其与图像的宽度，高度和文件大小相加。这将为每个图像生成一个非常独特的密钥。这将与图像的位置相结合，或者在重复的情况下与位置结合使用。
从技术上讲，这完全适合单个数据库表。文件名上的唯一索引以及hash-width-height-size上的附加非唯一索引就足够了。但是，我可以使用现有的数据库系统来解决这个问题，或者只编写我自己的优化版本。无论如何它将是一个单用户应用程序，主要目的是检测何时我将一个重复的图像添加到集合中，这样它就会警告我已经在我的集合中有它并显示其他副本所在的位置。然后，我可以决定仍然添加副本或丢弃它。
我以前编写过哈希表实现，一旦你知道你需要注意什么就不那么困难了。所以我可以为这些数据实现我自己的文件格式。我不太可能需要为这些图像添加更多信息，我对类似的图像不感兴趣，只是确切的图像。我不会将原始图像存储在此文件中，只是哈希，大小和位置。 根据经验，我知道这可能会非常快。我以前做过这件事并且近三十年来一直做类似的事情所以我很可能会选择这个解决方案。
但我确实想知道......对现有的数据库系统（如SQL Server，Oracle，Interbase或MySQL）执行相同的操作，性能是否仍然足够高？在这个数据库中索引的图像大约有750 TB，大致相当于一个小表中的大约3000万条记录。是否值得考虑使用常规数据库？
我怀疑这个项目的数据库的可用性。数据量巨大，但结构非常简单。我不需要多用户支持或大多数数据库提供的大多数其他功能。所以我认为不需要数据库。但我对其他程序员的意见感兴趣。 （虽然我希望大多数人会同意我的意见。）
项目本身，在我脑海中仍然只是一个想法，应该是探险家或其他什么的工具或附件。基本上，它为我附加到系统的任何外部硬盘构建索引，当我将图像复制到某个地方的磁盘时，它应该告诉我该磁盘上是否已存在该图像。这将允许我避免填充重复的备份磁盘，虽然我有时想添加重复项。 （例如，因为它们是系列的一部分。）因为我喜欢创建自己的渲染图稿，所以我有很多图像。另外，自1996年以来，我一直用数码相机拍摄数码照片，所以我也有很多照片。添加一些其他大型集合，你很快就会意识到数据量将是巨大的。 （是的，我的收藏中已经有很多重复......）
答案 0 :(得分：3)
由于它是您正在考虑的单用户应用程序，我可能会看一下SQLite。我会说，它应该很适合你的其他要求。
答案 1 :(得分：3)
交易一致性并非易事。
我建议以这样的方式设计你的代码，以后可以很容易地替换后端，然后以理智的方式运行（SQLite是一个很好的起始选择），以最合理的方式开发它，然后尝试插入在备用后备存储中。
然后分析差异，并对其进行回归测试，以确保您的数据库不比SQLite差。
现有的数据库解决方案往往会赢得胜利，因为他们已经有多年的改进和微调以获得他们的好处，一个天真的尝试可能会更慢，更轻松，并且做得更少，一直增加您的开发负载为纯 MONUMENTAL 比例。
http://fetter.org/optimization.html
- 优化的第一条规则是，您不要谈论优化。
- 优化的第二条规则是，你不要谈论优化。
- 如果您的应用运行速度比基础传输协议快，则优化已结束。
- 一次一个因素。
- 没有marketroids，没有marketroid时间表。
- 只要必要，测试就会继续进行。
- 如果这是您在优化俱乐部的第一个晚上，您必须编写测试用例。
此外，对于数据库，有一件事你完全必须根深蒂固。
速度不重要
您的数据在那里， 非常重要。
如果您确信您的数据始终存在，那么您可能会担心速度等微不足道的问题。
您还哀叹您将使用图像SHA / MD5等对图像进行重复数据删除。这是一个自己的错误概念，文件的哈希只能判断文件是否不同，而不是它们是否相同。
逻辑类似于要求30个人掷硬币，你看到第一个人得到了头，因此决定删除所有其他人，因为他们显然是同一个人。
虽然您可能认为不太可能有2个不同的文件具有相同的哈希值，但您的赔率几乎与赢得乐透区一样好。你赢得乐透的机会很低，但每天都有人赢得乐透。不要让它成为你。
答案 2 :(得分：3)
我刚刚在笔记本电脑上测试了PostgreSQL的性能（Core 2 Duo T5800 2.0 GHz 3.0 GiB RAM）。我有一个表略超过100M的记录，5列和一些索引。我在一个索引列（不是主键）上执行了范围查询，并返回了所有列。平均查询返回75行并在750毫秒内执行。你必须决定这是否足够快。