关于ElasticSearch的几个疑惑?

kazaff
  • 987

最近在调研ElasticSearch(简称ES),从官方文档中了解到了一些ES的设计原理,不过也产生了几个疑问,和大家讨论讨论~


默认为每一个字段创建索引
该做法是否会影响数据的插入、删除、更新的速度?


会存储文档的所有字段,直接从ES中返回查询结果,而不需要去关联查询db
该做法增加了磁盘资源的使用(如果你还不得不在db中存储一份数据的话),当然,可以只在ES中存储那些需要检索的数据字段,但这就会和其他搜索引擎一样(速度上),并且同样会造成数据一致性问题,大家平时都是怎么权衡的?


文档相对少,核心开发人员只有一个,没有经历过时间上的洗礼(太年轻)
关于这个观点,大家又是如何理解?


其实是因为ELK才认识到ES的存在的,在处理日志数据的时候,感觉ES的设计理念还是很贴近场景的,但是如果使用在整个项目的搜索场景,我个人是有些犹豫的。大家又是怎么看的呢?

最后附上一个对比链接:this

回复
阅读 7.9k
2 个回答

默认为每一个字段创建索引

其实是没有必要的,哪个字段创建索引根据业务来定。例如像直接靠数据库的索引能解决了的就没必要,但是像中文名,文本类的模糊匹配这类在mysql检索速度很慢的字段,就可以将这种字段与他的主键id一起在es创建索引。

会存储文档的所有字段,直接从ES中返回查询结果,而不需要去关联查询db

这个问题属于第一个的引申,应用将文本查询的检索执行后,得到该条记录在数据库的主键id,再用id去数据库里查相关信息。如果涉及到A表x字段和B表y字段的联合模糊检索,那么创建索引的时候将这两个表的x与y字段在es中同一个Type里创建索引。检索后可以得到结果在A表和B表各自的主键id,再根据自身业务去数据库里取相应记录即可。

关于数据的一致性问题,大概有三个方案
1,应用上自己控制,增删改的时候相应的去维护索引信息。一致性的维护就靠程序实现,比较麻烦,但是比较灵活。

2,通过bin-log去自动创建索引,https://github.com/siddontang/go-mysql-elasticsearch github上有这个项目,自己配置好数据源就自动创建索引了。靠binlog同步一致性能做到最好,但是不太灵活,完全根据数据库表结构创建所有字段的索引,并且联表查询也比较麻烦。

3,通过river去自定义创建索引,https://github.com/jprante/elasticsearch-jdbc github上也有这个项目,是es的一个插件,通过jdbc将自定义好的sql语句从mysql中同步过来。通过sql可自定义需要索引的字段,另外表结构里需要有一个update_time的字段供sql去查找新增或者更新的数据,以保证索引的一致性,删除数据的一致性需要在程序里控制。这个方法虽然也不完美,但是也算结合了1和2方式的优缺点把。

文档相对少,核心开发人员只有一个,没有经历过时间上的洗礼(太年轻)

看看官网上的USE CASES就可以不用担心这个问题了

如果使用在整个项目的搜索场景,我个人是有些犹豫的。大家又是怎么看的呢?

搜索还是看场景,能够通过数据库搜索的就靠数据库,预期数据库解决不了的再切换到es上。
全放在es上,效率和数据的安全性肯定不如db与es结合的高。

lacusRinz
  • 1
新手上路,请多包涵
撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏