扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
这篇文章将为大家详细讲解有关索引表和ES的使用心得是什么,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。
创新互联的客户来自各行各业,为了共同目标,我们在工作上密切配合,从创业型小企业到企事业单位,感谢他们对我们的要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。专业领域包括成都网站建设、成都做网站、电商网站开发、微信营销、系统平台开发。
在电商项目中,物理库存系统是个极其重要的系统,订单支付后,就会开始来占用物理库存。一般情况下,库存系统都是要分库的,因为主要的操作是写操作,例如占用/释放/取消等写操作。使用分库可以降低数据库写的压力。尽管写操作为主,但是读操作也是有的。比如说,库存占用的时候,得先查询是否有库存,而这个查询操作并不都会带上分库因子(用于路由到具体的某个数据库),而是一些比较宽松的查询条件,这些查询条件对应的数据可能分布在不同的数据库上。这个时候为了查询的方便,会构建一个索引表。这个索引表是存在另外的单独的一个数据库中,不会再分库了的。
比如说一个查询商品的操作,只是按照价格去搜索的时候,如下图:
这个时候就得从几个DB里面去获取数据,需要遍历DB,相当的麻烦。当然也可以为价格建立索引,加快查询速度,但是要知道,查询的时候,可能还根据其他条件来查询,像上下架状态,商品类别等,不可能都为这些查询条件建立索引,代价太大了,也不合理。引入索引表之后,则不同了。
根据查询条件从索引表中找出主键ID,再根据主键ID从多个数据库中查找数据。这样无论查询条件有哪些,通通只需要根据主键ID查找数据即可。当然索引表的设计不只是像上图那样设计,大概分三种。
把查询字段放到索引表,还需要把对应的数据库主键ID也放置进去。当查询请求到来时,根据查询条件找出对应的数据主键,再根据数据主键路由到对应的存有完整业务数据的数据分库上。这种方案呢。索引表占用空间小,可以支撑很久。但是要找出业务数据,还是需要路由到分库上。另外,如果要把索引表的数据存储到ES搜索引擎上的话,这种方式就不行了。因为索引表中没有外部系统要的业务数据。所以当时的库存系统没有使用这种索引表设计方案。
这种方案呢。当请求到来的时候,直接查询索引表即可。无需根据主键路由到分库了。同时如果要结合ES的话。可以直接把索引表的数据弄到ES上即可。后续直接让ES暴露查询接口即可。目前我在唯品会参与的物理库存项目中,是使用这种方式的。但是这个方案也有个缺点。就是索引表的体积比较大,后续数据量一大的话,也是个问题。能不能优化一下呢?
上面说到的第二种方案,索引表的膨胀可能很快,可以考虑将索引表拆分。比如说:索引表只是保存查询条件和主键,而需要展示给外部系统的数据,另外存储在单独的表上。比如叫index_detail表。这个表拥有索引表的主键。这样的话,当查询请求到来的时候,先从索引表查询到主键,再根据主键从index_detail表中查询出数据。当然这样做的话。ES的数据来源就变成多张表了,不过这是可以接受的。
一般来说,构建索引数据是使用单独一个应用来做的。比如叫data-index域。这个域会从消息队列中读取消息,用于构建索引数据。当业务数据发生变化后,生产者发送MQ消息到队列上。
这里的消息设计也分两种情况。一种是消息只是带有数据主键和操作类型(ADD/Update/DELETE),消费者拿到主键后再去DB获取完整的数据并插入到索引表中。另一种方案呢,是消息包含了大部分需要的字段,消费者拿到消息后直接把数据插入到索引表中。这两种消息设计,我在实际项目中都有用过。
这种方案呢就比较粗暴,直接配置一个索引表库的数据源,当业务数据发生变化时,使用Mybatis或者JDBC把数据更新到索引表中。一般不建议这么做,一来构建索引数据的逻辑跟数据的CRUD操作融合在一起了。二来,操作其他数据库的数据,要么通过接口的方式,要么由单独的域来做。建议还是使用MQ的方式来构建索引数据。
像在唯品会这边,自研了一个叫VDP的组件,使用storm job去监听索引表数据的变化,一旦有变化,就把数据同步到队列中,ES直接从队列中获取数据,并存储到ES上。
这种方案的好处是,我们无需写任何代码,数据自动可以同步到ES上。
如果公司内部没有开发VDP这样的组件,可以通过发送MQ消息的方式来将索引表的数据同步数据到ES上。
另外一种方案是,让ES暴露CUD接口,用于同步索引表数据。但是这样就跟ES耦合在一块了。不太推荐这么做。
当索引表结合ES后,交互流程就变成如下的形式了。
在数据库分库的情况下,如果要分页展示数据的话,并且数据库数据的数量又特别庞大,可以借助ES,从ES获取分页数据。如果没有ES,只有索引表的话,那就直接在索引表中获取分页数据对应的ID,再从数据库中获取。
1、ES不支持Group By后再分页
这样的操作,所以在构建索引表的时候,可以事先计算好Group By的一些统计数据,并存储到索引表中;
2、一些后台应用中,如果数据库表的数量已经很大,好几个亿了,并且查询的SQL还非常变态,用数据库已经无法支持了,那么可以使用ES,查询速度快,也支持一些统计操作;
3、使用ES输出数据时,也有个坑。经常会拿到脏数据的。例如当数据发送变化后,构建索引数据并把索引数据同步到ES上是需要时间的,但是我们后台通常有将数据下架的操作,下架的操作操作完后,再次点击查询按钮,可能还是看到脏数据,因为数据同步到ES上没那么快。现在我还没想到很好的办法来解决这个问题。
关于索引表和ES的使用心得是什么就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流