cassandra 表最大数据
- 作者: 李二狗他爹
- 来源: 51数据库
- 2020-09-28
众多基于Bigtable技术的开源项目正在通过不同的方式实现高扩展性、高灵活性、分布式及宽列数据存储等功能，Cassandra和HBase就是其中的代表。
在大数据[注]这一全新的领域里，Bigtable数据库技术非常值得我们关注，因为这一技术是由谷歌的工程发明的，而谷歌是一家公认的非常擅长管理海量数据的公司。
他们相同的地方：
1. 两者都被设计用于管理非常大的数据集。
2. 两者都是分布式数据库，不仅仅是在数据的存储方式上，在数据访问方式上亦是如此。
3. 两者都宣称拥有近似于线型的扩展能力。
4. 两者都是通过复制来防止集群节点故障而导致出现数据损失。
5. 两者都被称之为列式数据库
他们不同的地方：
1. ?尽管Cassandra和HBase中的节点都是对称的，这意味着客户端能够与集群中的任意节点相连，但是这种对称是不完全的。Cassandra需要用户将一些节点作为种子节点，让它们在集群间通信中扮演集流点的角色。在HBase中，用户必须让一些节点充当主节点，它们的功能是监控和协调地区服务器的行动。
2. Cassandra在节点间通信中使用的是Gossip协议。目前Gossip服务已经与Cassandra软件整合到了一起。HBase则依托完全独立的分布式应用Zookeeper来处理相应的任务。
3. 尽管Cassandra仍然支持Thrift API，但实际上Cassandra一直在推动让CQL成为数据库的主要编辑接口。Cassandra的文档列入了一些针对Java、C#和Python等使用CQL version 3的驱动。最终，Cassandra将可获得一个JDBC驱动。该驱动用CQL替代了SQL，将CQL作为数据定义与数据管理语言。
4. HBase也支持Thrift接口和RESTful Web服务接口，不过HBase原生的Java API向编程人员提供了丰富的功能（如附图所示）。虽然HBase的数据操作命令没有CQL丰富，但是HBase拥有一个“筛选”功能，该功能可以在会话的服务器端执行，大幅提升了扫描（搜索）的吞吐量。
5. HBase还引入了“协处理器”（coprocessors）这一概念，允许在HBase进程中执行用户代码。这基本上与关系型数据库中的触发和预存进程相同。目前，Cassandra还没有类似HBase协处理器的功能。
总结就是他们半斤八两，暂时还不知道谁最后能胜出。
cassandra与hbase都是nosql数据库。总体上看，这意味着用户无法使用sql数据库。不过，cassandra使用的是cql（cassandra 查询语言），其语法有明显模仿sql的痕迹。
两者都被设计用于管理非常大的数据集。hbase文件声称一个hbase数据库可以拥有数亿个，甚至是数十亿个行。此外，用户还被建议继续使用关系型数据库。
两者都是分布式数据库，不仅仅是在数据的存储方式上，在数据访问方式上亦是如此。客户端可以与集群中的任意节点相连，并访问任意的数据。
两者都宣称拥有近似于线型的扩展能力。想要管理两倍规模的数据吗？用户只需将集群中的节点扩展两倍即可。
两者都是通过复制来防止集群节点故障而导致出现数据损失。被写入数据库的行主要由单个集群节点负责（行至节点映射取决于用户所使用的分区模式）。数据会被镜像到称之为冗余节点的其他集群成员当中（用户可配置的复制因子会显示数量）。如果主要节点出现了故障，那么数据仍然可以从另外的冗余节点中被读取。
两者都被称之为列式数据库。由于它们的名字听起来像是关系型数据库，因此用户在接触中需要在思想上进行调整，这导致用户对它们的认知会出现混淆。最容易出现混淆的地方是，数据在表面上最初是由行进行排列的，表的主要键是行键。但是与关系型数据库不同，在列式数据库中，没两个行需要相同的列。正如上面所说的那样，在表被创建后，用户能够快速在行中加入列。实际上，你能够向一行中增加许多列。虽然最高上限值难以被准确地计算出来，但是用户几乎不可能达到这样的上限，即便他们加入大量列的情况下也是如此。
在大数据[注]这一全新的领域里，Bigtable数据库技术非常值得我们关注，因为这一技术是由谷歌的工程发明的，而谷歌是一家公认的非常擅长管理海量数据的公司。
他们相同的地方：
1. 两者都被设计用于管理非常大的数据集。
2. 两者都是分布式数据库，不仅仅是在数据的存储方式上，在数据访问方式上亦是如此。
3. 两者都宣称拥有近似于线型的扩展能力。
4. 两者都是通过复制来防止集群节点故障而导致出现数据损失。
5. 两者都被称之为列式数据库
他们不同的地方：
1. ?尽管Cassandra和HBase中的节点都是对称的，这意味着客户端能够与集群中的任意节点相连，但是这种对称是不完全的。Cassandra需要用户将一些节点作为种子节点，让它们在集群间通信中扮演集流点的角色。在HBase中，用户必须让一些节点充当主节点，它们的功能是监控和协调地区服务器的行动。
2. Cassandra在节点间通信中使用的是Gossip协议。目前Gossip服务已经与Cassandra软件整合到了一起。HBase则依托完全独立的分布式应用Zookeeper来处理相应的任务。
3. 尽管Cassandra仍然支持Thrift API，但实际上Cassandra一直在推动让CQL成为数据库的主要编辑接口。Cassandra的文档列入了一些针对Java、C#和Python等使用CQL version 3的驱动。最终，Cassandra将可获得一个JDBC驱动。该驱动用CQL替代了SQL，将CQL作为数据定义与数据管理语言。
4. HBase也支持Thrift接口和RESTful Web服务接口，不过HBase原生的Java API向编程人员提供了丰富的功能（如附图所示）。虽然HBase的数据操作命令没有CQL丰富，但是HBase拥有一个“筛选”功能，该功能可以在会话的服务器端执行，大幅提升了扫描（搜索）的吞吐量。
5. HBase还引入了“协处理器”（coprocessors）这一概念，允许在HBase进程中执行用户代码。这基本上与关系型数据库中的触发和预存进程相同。目前，Cassandra还没有类似HBase协处理器的功能。
总结就是他们半斤八两，暂时还不知道谁最后能胜出。
cassandra与hbase都是nosql数据库。总体上看，这意味着用户无法使用sql数据库。不过，cassandra使用的是cql（cassandra 查询语言），其语法有明显模仿sql的痕迹。
两者都被设计用于管理非常大的数据集。hbase文件声称一个hbase数据库可以拥有数亿个，甚至是数十亿个行。此外，用户还被建议继续使用关系型数据库。
两者都是分布式数据库，不仅仅是在数据的存储方式上，在数据访问方式上亦是如此。客户端可以与集群中的任意节点相连，并访问任意的数据。
两者都宣称拥有近似于线型的扩展能力。想要管理两倍规模的数据吗？用户只需将集群中的节点扩展两倍即可。
两者都是通过复制来防止集群节点故障而导致出现数据损失。被写入数据库的行主要由单个集群节点负责（行至节点映射取决于用户所使用的分区模式）。数据会被镜像到称之为冗余节点的其他集群成员当中（用户可配置的复制因子会显示数量）。如果主要节点出现了故障，那么数据仍然可以从另外的冗余节点中被读取。
两者都被称之为列式数据库。由于它们的名字听起来像是关系型数据库，因此用户在接触中需要在思想上进行调整，这导致用户对它们的认知会出现混淆。最容易出现混淆的地方是，数据在表面上最初是由行进行排列的，表的主要键是行键。但是与关系型数据库不同，在列式数据库中，没两个行需要相同的列。正如上面所说的那样，在表被创建后，用户能够快速在行中加入列。实际上，你能够向一行中增加许多列。虽然最高上限值难以被准确地计算出来，但是用户几乎不可能达到这样的上限，即便他们加入大量列的情况下也是如此。
推荐阅读
