[DB]Cassandra~宽列数据存储~与HBase的大数据对决

盘点九大热门开源大数据技术 &＃8211; IT经理网
http://www.ctocio.com/bigdata/7080.html

Apache Cassandra是Facebook开发的开源的分布式数据库管理系统，用来实现用户收件箱内搜索功能，Cassandra同时也是一个NoSQL数据库。2010年，Facebook放弃了Cassandra转而采用HBase。但是Cassandra依然被一些公司采用，例如Netflix使用Cassandra作为视频服务的后台数据库。Cassandra在Apache License2.0下开源。

国内哪些互联网公司使用了 Cassandra 数据库？ &＃8211; 数据库 &＃8211; 知乎
https://www.zhihu.com/question/19592244?utm_campaign=rss&utm_medium=rss&utm_source=rss&utm_cOntent=title

国内生产环境使用Cassandra比较多的大公司有360，从公开的资料看，应该有至少1500台服务器的集群。360选用cassandra的原因如下：团队人员少，需求紧，选择开源项目；无单点，无中心，适合在线业务；代码易懂，团队成员有代码基础；社区比较活跃。

另外一些中小型公司和创业公司也有在使用。

这里要解释几个对cassandra的误解：
1、Facebook弃用？
Facebook当初想用cassandra实现其消息系统，但后来发现不合适，原因不是cassandra不靠谱，而是Cassandra的最终一致性模型不适合Message System，HBase具有更简单的一致性模型。Cassandra强调AP ，Hbase强调CP。目前Facebook的inbox search系统在使用，8亿用户，200T数据；其移动应用开发平台也使用cassandra。
2、Twitter弃用？
本质是mysql和nosql之争。cassandra能进入twitter的视野，恰恰说明cassandra是nosql的代表性产品之一。为什么twitter在tweets系统中不使用cassandra？&＃8221;这是一次战略上的变化。我们将继续维护我们原本基于Mysql的存储。我们相信，现在还没有到大规模迁移数据到一个新技术的时候。”目前twitter也有使用cassandra——Using Cassandra in production for geolocation and analytics。
3、Cassandra不火？
国内对mongodb和hbase推崇备至，究其原因是因为mongodb这个公司进入了中国市场并建立了中文组，而hbase在阿里的大范围使用和推广下培养了一大批用户和公开材料。Cassandra最近两年在大数据公司Datastax的大力培育下获得长足发展，功能和性能均大幅提升，Datastax的估值也达数亿美元。从apache cassandra首页来看，大概有超过1500个公司在使用cassandra。其中除了facebook和twitter外还一些有代表性的公司列举如下：
Instagram：inbox、newsfeed、 audit、fraud detection，12 EC2 node，1.2T，2w+ wps，1.5w+ rps；
eBay：200+TB，400+M写，100+M读，应用场景：商品详情页上的Social Signals，如Like,Want,Own,Favorites等；用户和商品的hunch taste graph；时间序列如移动通知，反作弊，soa，监控，日志服务等；
Netflix：包含288+96+60个实例的大规模集群，每秒110万的写操作，3个AWS EC2 美国东部region的zone自动复制副本，总计330万写操作/秒；
Apple：75000+ nodes， 10s of PBs，Millions ops/s, largest cluster 1000+ nodes。

从技术实现上来讲，cassandra同时具备AWS Dynamo和Google Bigtable的设计理念，同时引入了P2P技术，具备大规模可分区行存储能力，强调AP，实现了最终一致性，具备多数据中心复制支持，具备市场上最具有竞争力的可扩展性，无中心节点，一致性和时延可调，无单点故障，每个节点只有一个进程等等大数据存储管理的先进特点，并支持spark、storm、hadoop的集成。但同时，Cassandra实现复杂性高，没有相应的中文社区，文档太少，国内应用和实践太少，Datastax也未进入中国市场，因此在中国的推广会比较困难。

最后，想说一点的是：技术人永远保持自己基于事实的独立判断。不要人云亦云，多看上下文，多亲自调查保持发言权；世事也绝不是非黑即白，看场景，分时势，适合的即是最好。

Cassandra与HBase的大数据对决 谁是胜者？
http://www.datatang.com/news/details_629.htm

Cassandra和HBase都在很大程度上借鉴了早期Bigtable的定义。实际上，Cassandra起源于Bigtable和亚马逊的Dynamo技术，HBase将自身定位为“开源Bigtable工具”。就其本身而论，这两个项目既有许多相同的特点，同时又有许多重大区别。

//
同为大数据而生

Cassandra与HBase都是NoSQL数据库。总体上看，这意味着用户无法使用SQL数据库。不过，Cassandra使用的是CQL（Cassandra 查询语言），其语法有明显模仿SQL的痕迹。
两者都被设计用于管理非常大的数据集。HBase文件声称一个HBase数据库可以拥有数亿个，甚至是数十亿个行。此外，用户还被建议继续使用关系型数据库。
两者都是分布式数据库，不仅仅是在数据的存储方式上，在数据访问方式上亦是如此。客户端可以与集群中的任意节点相连，并访问任意的数据。
两者都宣称拥有近似于线型的扩展能力。想要管理两倍规模的数据吗？用户只需将集群中的节点扩展两倍即可。
两者都是通过复制来防止集群节点故障而导致出现数据损失。被写入数据库的行主要由单个集群节点负责（行至节点映射取决于用户所使用的分区模式）。数据会被镜像到称之为冗余节点的其他集群成员当中（用户可配置的复制因子会显示数量）。如果主要节点出现了故障，那么数据仍然可以从另外的冗余节点中被读取。
两者都被称之为列式数据库。由于它们的名字听起来像是关系型数据库，因此用户在接触中需要在思想上进行调整，这导致用户对它们的认知会出现混淆。最容易出现混淆的地方是，数据在表面上最初是由行进行排列的，表的主要键是行键。但是与关系型数据库不同，在列式数据库中，没两个行需要相同的列。正如上面所说的那样，在表被创建后，用户能够快速在行中加入列。实际上，你能够向一行中增加许多列。虽然最高上限值难以被准确地计算出来，但是用户几乎不可能达到这样的上限，即便他们加入大量列的情况下也是如此。
除了这些源于Bigtable定义的特点外，Cassandra和HBase还有一些其他的相似之处。
首先，两者都使用相似的写入路径，即首先将写入操作记录在日志文件中以确保持久性。即便出现写入失败的提示，保存在日志当中的操作记录可以被重新开始。随后，数据被写入内存缓存中。最后，数据被通过大量的一系列写入操作写入到磁盘中（实际上是将内存缓存的副本拷贝至磁盘中）。Cassandra和HBase所使用的内存和磁盘数据结构在某种程度上都是日志结构的合并树。Cassandra的磁盘组件是SSTable，HBase中磁盘组件的是HFile。
两者提供JRuby语言的命令行外壳。两者都通过Java语言被大量写入，这是访问它们的主要编程语言，尽管在许多其他的编程语言中都有适合两者的客户端包。
当然，Cassandra 和 HBase都是Apache软件基金会管理的开源项目，两者都可以通过Apache License version 2.0许可证免费获取。
相似与差别
尽管两者有着众多相似之处，但是它们之间还是存在着许多重大的区别。
尽管Cassandra和HBase中的节点都是对称的，这意味着客户端能够与集群中的任意节点相连，但是这种对称是不完全的。Cassandra需要用户将一些节点作为种子节点，让它们在集群间通信中扮演集流点的角色。在HBase中，用户必须让一些节点充当主节点，它们的功能是监控和协调地区服务器的行动。为了确保高可用性，Cassandra采取方式是允许在集群中设置多个种子节点；HBase则是利用备用主节点，如果当前的主节点发生故障，那么备份主节点将成为新的主节点。
Cassandra在节点间通信中使用的是Gossip协议。目前Gossip服务已经与Cassandra软件整合到了一起。HBase则依托完全独立的分布式应用Zookeeper来处理相应的任务。尽管HBase与Zookeeper一同出货，但是用户常常会使用预置在HBase数据库中的Zookeeper。
虽然Cassandra和HBase都不支持实时交易控制，但是两者都提供了一定程度的一致性控制。HBase向用户提供记录级（也就是行级）的一致性。实际上，HBase在每行都支持ACID级语义。用户可以在HBase中锁定一行，但是这种行为并不被鼓励，因为这不仅影响到并发性，同时行锁定还会导致无法进行区域分割操作。此外，HBase还可以执行“检查与写入”操作，该操作在单个数据元上提供了“读取-修改-写入”的语义。
Cassandra免费的DataStax社区版包含有一个DataStax 操作中心。该中心提供了集群监控与管理功能，它可以检测数据库模式，提示键空间是否能够被编辑，以及是否可以增加或删除列族。
尽管Cassandra被描述为拥有“终极”一致性，但是读取和写入一致性可以在级别和区间方面进行调整。也就是说，你不仅可以配置必须成功完成操作的冗余节点数量，还可以设置参与的冗余节点是否跨数据中心。
此外，Cassandra还在其计算机指令系统中增加了一些轻量级的交易。Cassandra的轻量级交易采用的是“比较与集合”机制，相当于HBase的“检查与写入”功能。不过，对于HBase的“读取-修改-写入”操作功能，Cassandra则缺乏相对应的功能。最终，Cassandra的2.0版本增加了单独的行级写入功能。如果一个客户端在一行中更新了多个列，那么其他的客户端将会看到所有未更新的部分，或所有更新的部分。
在Cassandra和HBase当中，主索引是行键，但是数据被存储在磁盘中，这导致列族成员相互间非常接近。因此仔细规划列族组织非常重要。为了保持高查询性能，有着相同访问模式的列应该被放在在相同的列族当中。Cassandra允许用户创建关于列值的额外次索引。这一举措提升了对那些值具有高重复性的列（例如存储客户电子邮件地址中国家地区的列）的数据访问。HBase虽然缺乏对次索引的内置支持，但是它们有一些能够提供次索引功能的机制。这些都在HBase的在线参考指南和HBase社区博客中被提及。
如前所述，两个数据库都有发布数据操作命令的命令行外壳。由于HBase和Cassandra的壳都是以JRuby壳为基础，因此用户可以编写一些脚本，让这些脚本能够调用JRuby壳的所有资源与数据库所提供的特定API进行交互。此外，Cassandra还定义了模仿自SQL的CQL。与HBase所使用的查询语言相比，CQL的功能更加丰富，并且可以在Cassandra的壳内直接执行。
尽管Cassandra仍然支持Thrift API，但实际上Cassandra一直在推动让CQL成为数据库的主要编辑接口。Cassandra的文档列入了一些针对Java、C#和Python等使用CQL version 3的驱动。最终，Cassandra将可获得一个JDBC驱动。该驱动用CQL替代了SQL，将CQL作为数据定义与数据管理语言。
HBase也支持Thrift接口和RESTful Web服务接口，不过HBase原生的Java API向编程人员提供了丰富的功能。虽然HBase的数据操作命令没有CQL丰富，但是HBase拥有一个“筛选”功能，该功能可以在会话的服务器端执行，大幅提升了扫描（搜索）的吞吐量。
HBase还引入了“协处理器”（coprocessors）这一概念，允许在HBase进程中执行用户代码。这基本上与关系型数据库中的触发和预存进程相同。目前，Cassandra还没有类似HBase协处理器的功能。
Cassandra的文档较HBase的更加醒目，并且拥有更加扁平化的学习曲线。设置一个开发用的Cassandra集群比设置HBase集群要更加简单。当然，这仅对于开发与测试目的来说非常重要。
棘手之处
在必须为特定应用调整集群时，用户需要做一些工作。在指定数据集大小、创建与管理多节点集群（通常会跨多个数据中心）的复杂度后，调整工作将变得非常棘手。用户需要深刻理解集群的内存缓存、磁盘存储和节点间通信之间相互影响，仔细监控集群的活动。
HBase对Zookeeper的依赖会带来一些额外的故障点。虽然Cassandra避开了这一问题，但这并不意味着Cassandra集群的调整难度会大幅下降。我们对两个数据库的集群调整难点进行了对比（如附表所示）。


Cassandra和HBase.jpg

需要说明的是，这里并没有确定谁是胜出者，谁是失败者。每个数据库的支持者都会找到一些证据来证明他们的系统优于对方。通常用户需要对两个数据库进行测试，然后才能确定它们执行目标应用的情况。那么从技术角度出发是否会有更好的办法呢？