Solr 4.x：我应该使用二进制作为唯一键吗？

Question

我目前正在调查使用sha1散列，它将作为二进制文件存储在MS Sql Server中（20）。查看Solr 4.x中当前可用的数据类型，唯一看起来足够大的是二进制。但是，我不确定使用二进制作为唯一键是一个好主意。此外，在不久的将来，我们将从Solr 4.x独立转向Solr 6.x云。

Answer 1

根据最佳实践，唯一键应该是一个短的唯一String（例如，请参阅Java UUID）。 使用二进制作为唯一键不是一个好主意也不是推荐。 您可以在Solr文档的this page中找到解决问题的可行方案：

  

加密哈希

     

加密哈希算法可以被认为是非常创建N.   来自输入数据的随机位。 MD5算法创建128位。   这意味着2个输入数据集的概率为1 ^ 2 ^ 128   创建相同的MD5。这个标准表达为32   十六进制字符。 RFC-1321。几种MD5摘要算法   各种语言的包不符合此标准。 UUID   standard始终包括创建UUID的时间，即   排除了上述一些用例。你可以欺骗和忽视   时钟要求。最好使用UUID文本格式：   550e8400-e29b-41d4-a716-446655440000代替   550e8400e29b41d4a716446655440000。 （您将阅读其中许多键。）   使用加密生成的唯一密钥的一个优点是可以   通过通配符选择随机的文档子集。如果是UUID数据   保存为32个字符的RFC格式的字符串，   'd3adbe3fdeadb3e4deadbee4deadb3ef'，查询“id：a *”将选择一个   随机的1/16整个文档集。 “id：aa *”选择1/256   文档集，再次非常随机。统计分析和数据   提取项目可以使用它来选择小的子集而不是   走完整个指数。

同样的方法适用于任何版本的Solr。