Cassandra 的过去、现在、未来(三)

阅读数:1 2020 年 1 月 7 日 09:54

Cassandra 的过去、现在、未来(三)

5. 解决的问题 & 价值

Cassandra 的过去、现在、未来(三)

① 随时在线

Cassandra 的过去、现在、未来(三)

  • 没有 master,多副本,具有可调一致性。比如挂了一台或者删掉一个副本,在一般的强制读模型下,是没有影响的。节点副本越多,冗余度越高,可接受的挂更多的节点。

  • 无主从切换带来的抖动

② 线性扩展,易于运维

Cassandra 的过去、现在、未来(三)
Cassandra 的过去、现在、未来(三)
由于节点对等,可以进行线性扩展,因此非常易于运维。当集群扩展时,直接加一台机器就好了,绝大多数步骤都可以自动完成。因此很多公司都把商标做成一个环了,代表是可线性扩展的。

③ 多 DC,两地三中心

Cassandra 的过去、现在、未来(三)

就近读写,大大降低延时。比如有个国际化的业务,在中国和国外皆有分布,比如 FB 的图片社交业务,国内和国外的用户都会发图片动态,我会关注国外朋友的图片动态,通过多 DC 可以就近读写,读的延时是很低的。

实现业务的多地容灾。比如某个地域发生地震,整个机房宕掉了,可以把业务的就近起一个 DC。

④ Cql + 丰富数据结构 + 类 jdbc driver

Cassandra 的过去、现在、未来(三)

⑤ 完备的多语言客户端

Cassandra 的过去、现在、未来(三)

有非常完备的多语言客户端,主流的语言都在里面,包括我们常用的 python、C++、Go、node JS、php 等日常使用比较多的语言。

6. 性能表现

Cassandra 的过去、现在、未来(三)
这是外部的一些权威的性能披露。左侧图对比了 Cassandra、HBase、MongoDB 和 Conchbase 的性能表现,右侧是比较有名的一篇论文,对比了 Cassandra、HBase 和 Voldemort 在延时、吞吐化方面的表现,Cassandra 的延时表现是优于 HBase 的。

7. 使用场景

Cassandra 的过去、现在、未来(三)

下面我们讲一下 Cassandra 的使用场景,这里我分享一下自己的看法,以及自己论文的一些最佳实践。

① 不适合用的场景:

Cassandra 是一种 NoSql 的解决方案,很多 TP 的场景是不适合使用的。
不适用于先读后写的操作。
和其他数据库不太一样的地方,Cassandra 是一种无主的,反言之即 Cassandra 是一种多主的。多主的意思就是多个节点都可以操作,并不是都转发到一个节点上。在一个节点上很容易加锁,只要对某一行加锁,对所有的请求保持串行就可以了。所以对于独立行写其实是有冲突的,在 Cassandra 里面解决冲突的办法是很暴力的,就是 last write win ( 最后写入者获胜 ),因此导致 Cassandra 不适合做先读后写的操作。对于这种场景,Cassandra 建议使用 cas 的语法,但 cas 的性能比较差,因此使用 cassandra 时要避免冲突很多的场景。什么是冲突很多呢?比如多个手机用户同时更新一条数据,就是强冲突的。

② 使用场景

  • 风控领域:用户画像库、爬虫、发欺诈系统、订单数据

  • 个性推荐领域:用户行为分析、用户画像、推荐引擎和海量实时数据处理

大数据

社交 Feeds

Cassandra 的过去、现在、未来(三)

Instagram 的 Feeds 应用场景,与微博类似,大 V 会发图片和动态,同时一般也有很多的粉丝。当大 V 发图片或者动态,首先会有一个异步的推送 ( delivery ),把大 V 发布内容推到数据库里,然后粉丝读取大 V 动态的时候,再去拉取数据库的对应信息。比如川普有几千万的粉丝,对于每个粉丝都会去更新消息的 id,然后把信息写进来。对于每个粉丝,通过自己 id 查到对应的消息 id,再关联别的表查一下就可以获取到大 V 的动态。

这个例子充分利用了 Cassandra 的弹性扩展,一般传统的 sqlserver 只有单边节点,存储无论容量还是 ES 都是有限的。还使用了 Cassandra 的其他特性,比如 count 在 cassandra 里面都是分片计算的,效率非常高,因此点赞、计数这种场景做起来是没有压力的。

时空时序

Cassandra 的过去、现在、未来(三)

现阶段 IOT ( 物联网 ) 是比较热门的,有各种可穿戴设备,比如手表电话之类,还有像滴滴这样的公司,都会把数据实时上传到在线的数据库里。一般可能会做一些初期的 ETL 转换,在这个例子中使用 kafka、消息队列,然后有可能发的是比较快的,慢慢地把并发起到 Cassandra 里面,基于 Spark,或者基于某些数据,数据不断上传,对旧数据进行定期归档,存到备用。这种场景的特点是客户端非常多,像滴滴有上万台车同时在线地写入非常多的数据,数据量并发非常大。Cassandra 有个特点,是一个 LSM 的存储模型,写入性能非常高,扩展能力是很强的,整体集群扩展能力很高,通过加节点就能作线性扩展。

本文转载自 DataFunTalk 公众平台。

原文链接: https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247496333&idx=2&sn=2f36fb5991c6e963f247abc36f6d71a6&chksm=fbd740e1cca0c9f75644a4d9bd201d818b204727c4f425fdbb338ea43221e93c9cce71bf38d5&scene=27#wechat_redirect

评论

发布