每天，我们都会收到来自不同供应商的不同格式（CSV，XML，自定义）的巨大文件，需要将其上传到数据库中进行进一步处理。
问题在于这些供应商将发送其数据的完整转储，而不仅仅是更新。在某些应用程序中，我们仅需要发送更新（即，仅更改记录）。当前，我们要做的是将数据加载到临时表中，然后将其与以前的数据进行比较。由于数据集非常庞大，这非常痛苦，而且我们有时会缺少SLA。
是否有更快的方法来解决此问题？任何建议或帮助，不胜感激。我们的程序员用尽了所有想法。
答案 0 :(得分：5)
在完整的转储数据集中，有多种检测增量的模式，即更改的记录，新的记录和删除的记录。
我所见过的一种更有效的方法是为已经拥有的数据行创建哈希值，在数据库中创建导入的哈希值，然后将现有的哈希值与传入的哈希值进行比较。
主键匹配+哈希匹配=不变的行
主键匹配+哈希不匹配=更新了行
输入数据中的主键，但现有数据集中缺少主键=新行
主键不在传入数据中，而是在现有数据集中=已删除的行
如何对哈希进行哈希处理因数据库产品而异，但是所有主要的提供程序中都可以使用某种哈希。
优点在于仅需比较少量字段（主键列和哈希），而不需要通过字段分析来比较一个字段。即使是很长的哈希也可以很快地进行分析。
这将需要对导入处理进行一些返工，但是花费的时间将一次又一次地提高处理速度。
答案 1 :(得分：5)
对此的标准解决方案是哈希函数。您要做的就是能够获取每一行，并计算一个标识符+其内容的哈希值。现在比较哈希值，如果哈希值相同，则假定该行相同。这是不完美的-从理论上讲，不同的值可能会给出相同的哈希值。但是实际上，您比担心散列函数无法按预期工作那样担心宇宙射线会导致计算机中的随机位翻转。
rsync和git都是以这种方式使用哈希的广泛使用的软件的示例。
通常，在将哈希值放入数据库之前计算哈希值比在数据库内部执行一系列比较要快。此外，它还允许将处理分散在多台计算机上，而不会成为数据库的瓶颈。无论是在数据库中还是在数据库中进行比较，比较散列的工作都比比较许多字段的工作少。
您可以使用many hash functions。根据您的应用程序，尽管可能不一定需要使用加密哈希。多位多于少位，但是对于您描述的应用程序，64位散列应该很好。在处理了1万亿个增量之后，您在一千万个错误中仍然只有不到1次的机会。