参考文章：https://www.cnblogs.com/dreamroute/p/8484457.html
原表：
| id | name | gender |
|---|---|---|
| 1 | alice | female |
| 2 | bob | male |
索引：
1:倒排索引
name表:
| term | posting list |
|---|---|
| alice | 1 |
| bob | 2 |
gender表：
| term | posting list |
|---|---|
| female | 1 |
| male | 2 |
2:term查询
1）排序
二分查询，复杂度log n
2）压缩term：FST
引用图片：（from:https://www.cnblogs.com/dreamroute/p/8484457.html）
3）term index
对term进行翻页处理，使之可以变得足够小，放进内存
3:posting list压缩——roaring bitmaps
假设原表：
| term | id |
|---|---|
| female | 1,3,4,6,9 |
传统bitmaps:
压缩后：
| term | id |
|---|---|
| female | 101101001 |
roaring bitmaps:
| term | id |
|---|---|
| female | [101],[101],[001] |
也就是分段压缩，让一个段能存进内存中使用。一般取65535个id为一段（一个int）
总结：
1、es更新数据应该会很吃IO吧？之前接过盖了es的系统，每次更新数据都无法做到同步，很多场景都需要外接一套缓存服务
2、es查询是真滴高效
网友评论