平台|StarRocks VS ClickHouse，携程大住宿智能数据平台的应用( 二 )_缓存|访问|场景|应用|智能|消息

现在的主动缓存+被动缓存取代了原本需要从ClickHouse上很大一部分的查询量，这样可以避免我们无限的扩容服务器。同时也可以把因为集中并发的查询拉起来的峰刺打平。

文章图片

现阶段痛点
在节假日期间，实时数据是关注的重点，以今年劳动节为例，实时看板的访问量要比平时高10倍左右。

文章图片

工作日期间， CPU使用率一般不会超过30% 。

文章图片

节假日期间， CPU使用率一度超过70% ，这对服务器的稳定性造成了很大隐患。

文章图片

面对这种情况，一方面我们在前端做了节流来防止用户高频查询，同时在后端也做了缓存，但是实时数据的缓存时间不能太久，一般1~2分钟已经是用户可接受的极限。通过下图可以发现，离线数据的缓存命中率一般都会比较高，基本能达到50%以上甚至更高，但对于实时数据，命中率则只有10%左右：

文章图片

另一方面，我们在服务端启用了分流机制：实际应用场景中有一些业务的权限比较小，对应需要查询的数据量也会比较小，我们通过分析定义出了一个阈值，比如权限数小于5000的用户从MySQL请求数据，这部分用户即使通过MySQL查询速度也很快。让权限大的用户通过ClickHouse请求数据，这样可以引流很大一部分用户。

文章图片

这样做虽然暂时解决了眼下的问题，不过新的问题又接踵而至：
·数据需要双写到ClickHouse和MySQL ，无法保证两边数据的一致性
·同时存在两套数据，导致硬件成本增加
·ClickHouse不支持标准SQL语法，所以代码也需要维护两套，开发成本增加
针对上述问题的挑战，我们的目标是寻求一个新的OLAP引擎来减少开发和运维成本，同时还要兼顾查询性能，并在高并发和高吞吐的场景下有较好的适用性。
为此我们尝试了一些市面上其他引擎，如Ingite、CrateDB、Kylin等，每种引擎从硬件成本或性能上都有自己特有的优势，不过综合到使用场景，最终我们选择了StarRocks 。
StarRocks介绍
·StarRocks是一个高性能分布式关系型列式数据库，通过MPP执行框架，单节点每秒可处理多达100亿行数据，同时支持星型模型和雪花模型。

平台|StarRocks VS ClickHouse，携程大住宿智能数据平台的应用( 二 )

推荐阅读

如何找寻自我

缝纫机调线器怎么安装平车方法如何

强组词强字组词

火笋鸡翅的做法（增肥食谱）

闺女生日快乐祝福语朋友圈

LV请来潮牌设计师做艺术总监，看中的是啥

老虎豆怎么做好吃老虎豆图片怎样弄来吃

暖气有流水声是什么原因

皮球是什么体

手机怎样开通QQ空间

男生发mua说明 mua是什么意思

手指盖凹陷怎么回事

对自己的生活失去掌控咋调整

小米10s怎么没有月亮模式

我想找个偏僻的地方搞养殖！有没有推荐的地方？

南京养老金认证上门服务怎么申请南京市养老金认证

如何评价猪场阉割猪？

最后一个字是豹的成语

泰山散酒怎么样

猫发情的声音(猫发情的叫声)