广告索引 简述

这里主要说的是显示广告的广告索引，分为正排索引或者倒排索引

一：正排索引

正排索引是通过一个广告的id，找到对应的广告具体对象的信息，一般使用一个hashmap存储，如map<uint64_t, AdGroupInfo>，通过广告id可以快速找到广告的具体设置信息。

二：倒排索引

我们先看下如下两种场景

a：再早期的广告引擎中，广告定向比较古老的方式就是循环遍历各个定向条件，看是否满足定向条件。（这种方式只能在原始的广告投放引擎中适应，因为有广告位的概念，且每个广告位下的投放也不会很多，一旦很多投放，则这种方式会导致效率直线下降。）

b：广告索引的思路则完全不一样（主要是从dsp兴起之后才开始出现这种方式，因为dsp没有广告位的概念，每个dsp有成千上万，甚至几百万，上千万的广告，如果每个广告都去遍历，肯定达不到想要的效率）：

那怎么怎么样能避免每个定向都去做遍历操作呢，答案就是倒排索引。

一般是使用map嵌套set的结构，如map<int, set<uint64_t>> / map<int, set<uint64_t>> , 每一个定向的结果是一个set，多个定向执行的结果就是多个set求交接

当然在dsp出现之前，像搜索引擎/广告、推荐系统，其实已经都是使用索引的方式去做了。

问题描述：

以地域定向为列子，比如进来一个广告请求且用户是上海的，dsp有100000个投放，其中有1000个是定向上海的，另外有1000个是定向到北京和深圳的，剩下的都是没有做地域定向的(注意未做定向的都是默认能定向成功的)。（地域定向需将ip转换为地域信息，有的公司用字符串，如

CNSH*，有的公司用int的地域编码，如1156110000）

具体实现大概为：

程序初始化的时候需要加载所有的地域信息和对应的投放/广告表，组合成一张hash表（map），最终组织为key为地域编码，value为hash set，比如来了一个上海的ip（转换为编码之后），则可以直接从表中找到哪些投放/广告（hash set）满足上海的投放。

每次做完第二个定向之后可以将两个set进行合并，最后合并完的数据则是定向成功的投放。

其实广告索引的方式也被用在传统的搜索引擎中。

二：倒排索引优化

上面说到倒排的map结构为map<int, set<uint64_t>> / map<int, set<uint64_t>>，当广告有上百万/上千万的时候，要为每个定向分配多个set，会占用大量内存，有没有优化办法呢？答案是肯定的。

可以将map中的值set替换为RoaringBitmap，这种bitmap可以节省内存，也可以方便快速的做merge操作。更多RoaringBitmap资料可以自行google/百度。

如下为某gbt对RoaringBitmap的描述：

(Roaring Bitmap是一种高效的位图数据结构，它在处理大量整数集合时特别有效。Roaring Bitmap通过将整数分为高16位和低16位来优化存储和操作。这种分割允许Roaring Bitmap在不同的密度下提供高效的存储和查询性能。

在Roaring Bitmap中，整数被分为两部分：

1. **高16位**：用于确定整数所在的容器（container）。每个容器对应于一个2^16大小的整数范围，即65536个可能的整数值。容器可以是位图（bitmap），数组（array），或者是压缩的位图（run-length encoding bitmap），具体取决于该范围内整数的分布情况。

2. **低16位**：在确定了容器之后，低16位用于在该容器内表示具体的整数值。

Roaring Bitmap使用一个键值对映射来关联高16位和对应的容器。键是整数的高16位，值是一个指向容器的指针。这样，当你想要检查一个整数是否存在于位图中时，你可以：

1. 将整数分为高16位和低16位。
2. 使用高16位在映射中查找对应的容器。
3. 在找到的容器中使用低16位来确定该整数是否存在。

这种方法允许Roaring Bitmap在保持高性能的同时，有效地处理稀疏和密集的整数集合。例如，如果一个特定的高16位值对应的整数分布很稀疏，Roaring Bitmap可能会使用数组容器来存储这些整数的低16位。如果整数分布很密集，它可能会使用位图容器。如果整数以连续的范围出现，它可能会使用压缩的位图容器。

总之，Roaring Bitmap通过将整数分为高16位和低16位，并使用不同类型的容器来存储这些低16位的值，从而实现了一种空间和时间上都高效的位图表示方法。)

原文写于2015年，最初写于网易博客