面向文档型数据库,一条数据就是一个文档,用json把文档序列化。
关系数据库=elasticsearch
数据库=索引
表=类型
行=文档
列=字段
交互可以用java api或http的restful api,插入一条记录就是对一个uri执行put
PUT /megacorp/employee/1
{
"name" : "John",
"sex" : "Male",
"age" : 25,
"about" : "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
es的设计宗旨:检索性能
为了提高检索性能,要牺牲插入、更新的性能。
插入时,会为每个字段建立倒排索引。
倒排索引
Term:阳光
posting list:12,23,45
这样搜索“阳光”,就可以马上找到有“阳光”的文档
Term dictionary:
把“阳光”“雨水”等term排序,二分法查找term,logn的查找效率。
Term index:
通过磁盘性能差,所以es通过内存查找term,term太多,term dictionary就会很大。term index是基于前缀的树状索引,可以找到term的offset从而定位到term。
再结合fst压缩技术,term index就可以缓存到内存里了。
压缩技巧
1.posting list有序
step1 真实值存储变增量存储,step 2 分区,step 3 以字节形式存储
Roaring bitmaps
将posting list按照65535为界限分块,用<商,余数>的组合表示每一组id,
65535是一个经典值,因为它=2^16-1,正好是用2个字节能表示的最大数,一个short的存储单位。
最后的block,如果超过4096个元素,用bitset存,否则用short[]存。
65536个元素用bitmap存恒定8192bytes,用short[]存是2*nbytes。
联合索引
多个field索引联合查询
用跳表做快速与运算,或者用bitset按位与
跳表查询很快,所以对最短的posting list每个元素判断其他两个posting list里是否存在就行。
用bitset就直观的按位与就行了。
总结和思考
es的思路:1.能搬进内存的尽量搬进内存,减少磁盘读取次数。2.能压缩的尽量压缩,严苛地使用内存。
注意点
不需要索引的字段一定要标出来,默认是建索引的
不需要anayasis的string也要标出来,默认是analysis的
选有规律的id很重要,提升压缩效率和寻道效率
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。