ES（Elastic Stack）和redis建立检索数据库

需求

• 要建立一个千万级的数据库，来检索图片的特征并不断插入。（这段时间不断摸索踩了很多的坑，不过也算是最后终结了这个问题。简单记录下遇到的主要的问题）

方法

• 首先是es建立了一个生命周期30天的数据库，把数据的一些信息和id写进去，心里的数据查看有没有相似特征。如果有，就把指纹定位对方的指纹，如果没有就是自己的。

  • 特征是hash值。hash值可以分桶，因为大部分都不一样，用汉明距离卡了一个阈值，比如5或者10等等。那再检索的时候可以用这个阈值降低数据访问量的。具体是桶号设计为hash值中1有效的数目，也可以反过来用0的数目，效果是一样的。检索的时候先用桶号过滤一遍，桶号±阈值。在桶号阈值内的，肯定是符合汉明阈值的；反过来却不一定。所以这个分桶是充分不必要条件，多少可以减少一部分检索量。
  • es的时间差问题：es从插入到可被检索到，是有一个时间差的。在这段时间数据对检索来说就是不可见的。并发调用的情况下，这个时间差的峰值应该可以超过了10-20ms。

• 如何避免不可见问题。

  • 使用redis的高速反应来处理这个问题。
  • reids的不可见时间差要短的多，甚至redis锁是比python的锁靠谱不知道多少倍的。在分布式服务上更是少有的几个现成方案。
  • 可使用的方法有scan_iter(count=n)，scan(count=n)以及hset，hgetall。总起来说就是以redis做cache，这个任务里我选用了当前和上一秒共两秒的缓冲区。具体的：
    • 1.0. 以自定义id为key，特征（hash值）为value插入redis里，然后去scan redis的数据库。对可看到的数据做个结构化——相同的去排序进入下一步，不相同的直接进入下一步，也就是es数据库访问。
    • 1.1. 这种存储方式会占用整个DB。我也尝试过以hash为key，以指纹为value的方式。但是这种就要看id是否matters，是否有影响，因为不能排除后面有相同特征的情况出现，实际上我这里结构化的时候需要排序，时间戳对排序很重要。
    • 1.2. 另外，如果并发的插入，这种方式redis也会有不可见的时间差：插入redis后，随机time.sleep(n)，然后开始scan(count=n)。那如果有应该看到却看不到的情况，那通过调整n的值就可以发现这种情况下不可见的时间差峰值是多少。我测了一下，如果有300项并发进入，峰值有大概15ms的时间差。
    • 2.0 另外一种方式是hset和hgetall。这种情况是分桶，桶号是时间戳，key还是id，value是特征值和时间戳。这种情况基本上不会有看不见的情况，偶尔出现过一次，我把n延迟到了10ms，至今没再出现过，这儿没去深究，一位组里的redis大神说他从没见过这种情况。所以这儿的不可见是不是一定存在，我没有百分之百的把握。
    • 2.1. 另外一个小坑是id的问题，因为时间戳用来帮助结构化，我用了图片的url做md5做id，后来遇到了一个问题。后来的请求项有相同的url，直接写入了redis覆盖了前一个的时间戳。在这个空档，正好有一个相同特征的但是url却不一样的请求项，进行结构化，比较时间戳时引起了bug。所以接下来的md5，我都用的“文章url+图片url”的方式来做。
    • 3.0. 结构化，一直再提，具体是什么呢。总起来说就是相同的特征不要一下子都进去es去查询，redis对他们其他缓冲的效果。然后完整执行完es的再把结果广播给剩下排队的项。那些没有相同特征的，就正常进入es查询了。特征相同的时候，需要有个先来后到，不然就让一些请求项一直在等了，那这儿就有个时间戳的概念。

• es是组里另外一个专业的大神写的，但是中间也犯了几个错误，发现这些小bug用了些精力。也简单记录一下。

  • 分桶过滤时的标准需要检查好，特征是1*64维的，他只查了一半。
  • es单个查询时间、插入时间最好确认下，这儿踩了两次坑，时间太长引起的系统性问题。

• 目前基本上就这些问题了。