【工作思考】几个检索条件的设计

定向安装和定向未安装

这个问题一度也非常棘手，不过经过数天的讨论，我还是通过集合的技巧将其拆解为几个简单条件的运算。

首先，为定向生成三个检索条件：T#INS（定向安装）, T#UNINS（定向未安装），T#REST（为定向）

然后，为所有关联某个APPID的广告生成 A#APPID1, A#APPID2…的索引

检索条件只能获取用户的安装列表L={L1,L2,…,Ln}

然后，定向安装的广告 = T#INS ∩ (A#L1 ∪ A#L2 ∪ ... A#Ln)
           定向未安装的广告 = T#UNINS ∩   ~(A#L1 ∪ A#L2 ∪ ... A#Ln)
           其他广告 = T#REST

所有广告 = 定向安装的广告 ∪  定向未安装的广告 ∪  其他广告
               = (T#INS ∩ (A#L1 ∪ A#L2 ∪ ... A#Ln)) ∪
                  (T#UNINS ∩   ~(A#L1 ∪ A#L2 ∪ ... A#Ln)) ∪
                  T#REST

这里实际上使用了一个技巧，即未安装列表 = 已安装列表的补集，通过取反运算即可获取。

小于等于某个值得检索

我们拥有一批视频广告，假定时长是t。每个广告位都有一个最大广告时长限制，设置h。
需要检索出所有 t<=h的广告。

我们最初的想法是，基于t不会太大的考虑，按秒枚举所有的时间，以5分钟为最长限制，可能的时间为0~300s，因此共需要301个检索条件。
生成索引时，只需要生成C#t即可（C为检索条件前缀，用于和其他检索条件区分）。

但是，这带来一个问题，当h很大时，比如h=60(1分钟）时，需要使用61个检索条件(0~60)才能检索出所有广告，这个过程中既有RPC传递长列表的消耗，也由检索次数过多的消耗。

后来，我想了一个方案，本质上是通过预处理时间来换取检索时间，将比较次数缩减到只需要2个检索条件（对应2次检索）。

首先，生成索引时，重新赋予C#t的含义为所有<=t的广告，这样，检索时只需要传入 C#h和C#0即可（C#0之所以要特殊处理是因为存在大量的非视频广告）。

如何生成索引达到这种目的呢？答案就是预处理过程中，对于时长为t的广告，显然t<=t, t<=t+1, t<=t+2, …, t<=MAX
因此，我们需要为该广告生成 C#t, C#(t+1), C#(t+2), …, C#MAX的所有索引。显然，这里预处理的时间增长了，将之前等于个值得信息聚集到了一起，所以提升了检索效率。