Cassandra

1. 简介 Apache Cassandra是由 Facebook 创立的高度可扩大、高性能的分布式NoSQL数据库，能够灵便的在线扩容，满足业务水平扩大的需要。具备可能解决大量数据的分布式架构。 数据搁置在具备多个复本因子的不同机器上，以取得高可用性，而无需放心单点故障。           2. 个性分布式和去中心化 Cassandra 是分布式的，这意味着它能够运行在多台机器上，并出现给用户一个统一的整体。你能够释怀地将数据写到集群的任意一台机器上，Cassandra 都会收到数据。去中心化意味着 Cassandra 不会存在单点生效。Cassandra 集群中的所有节点的性能都齐全一样， 所以不存在一个非凡的主机作为主节点来承当协调工作。      弹性可扩大 节点间应用gossip协定通信，不须要重新启动过程，不用批改利用的查问，也无需本人手工从新平衡数据分布。在 Cassandra 里，你只有退出新的计算机，Cassandra 就会主动地发现它并让它开始工作。      可调节的一致性 CAP 定律表明，对于任意给定的零碎，只能在一致性（Consistency）、可用性（Availability）以及分区容错性（Partition Tolerance）之间抉择两个。所以 Cassandra 在设计的时候也不得不思考这些问题，因为分区容错性这个是每个分布式系统必须思考的，所以只能在一致性和可用性之间做抉择，而 Cassandra 的利用场景更多的是为了满足可用性，所以咱们只能就义一致性了。然而依据 BASE 实践，咱们其实能够通过就义强一致性取得可用性。 Cassandra 提供了可调节的一致性，容许咱们选定须要的一致性程度与可用性程度，在二者间找到平衡点。因为客户端能够管制在更新达到多少个正本之前，必须阻塞零碎。这是通过设置正本因子（replication factor）来调节与之绝对的一致性级别。 通过正本因子（replication factor），你能够决定筹备就义多少性能来换取一致性。正本因子是你要求更新在集群中流传到的节点数（留神，更新包含所有减少、删除和更新操作）。 客户端每次操作还必须设置一个一致性级别（consistency level）参数，这个参数决定了多少个正本写入胜利才能够认定写操作是胜利的，或者读取过程中读到多少个正本正确就能够认定是读胜利的。这里 Cassandra 把决定一致性水平的权力留给了客户本人。 所以，如果需要的话，你能够设定一致性级别和正本因子相等，从而达到一个较高的一致性程度，不过这样就必须付出同步阻塞操作的代价，只有所有节点都被更新实现能力胜利返回一次更新。而实际上，Cassandra 个别都不会这么来用，起因不言而喻（这样就丢失了可用性指标，影响性能，而且这不是你抉择 Cassandra 的初衷）。而如果一个客户端设置一致性级别低于正本因子的话，即便有节点宕机了，依然能够写胜利。 总体来说，Cassandra 更偏向于 CP，尽管它也能够通过调节一致性程度达到 AP；然而不举荐你这么设置。      高可用和容错 从个别架构的角度来看，零碎的可用性是由满足申请的能力来量度的。但计算机可能会有各种各样的故障，从硬件器件故障到网络中断都有可能。任何计算机都可能产生这些状况，所以它们个别都有硬件冗余，并在产生故障事件的状况下会主动响应并进行热切换。对一个须要高可用的零碎，它必须由多台联网的计算机形成，并且运行于其上的软件也必须可能在集群条件下工作，有设施可能辨认节点故障，并将产生故障的节点的性能在残余零碎上进行复原。 Cassandra 就是高可用的。你能够在不中断零碎的状况下替换故障节点，还能够把数据分布到多个数据中心里，从而提供更好的本地拜访性能，并且在某一数据中心产生火灾、洪水等不可抗劫难的时候避免零碎彻底瘫痪。      面向行 Cassandra 常常被看做是一种面向列（Column-Oriented）的数据库，这也并不算错。它的数据结构不是关系型的，而是一个多维稠密哈希表。稠密（Sparse）意味着任何一行都可能会有一列或者几列，但每行都不肯定（像关系模型那样）和其余行有一样的列。每行都有一个惟一的键值，用于进行数据拜访。所以，更确切地说，应该把 Cassandra 看做是一个有索引的、面向行的存储系统。 Cassandra 的数据存储构造根本能够看做是一个多维哈希表。这意味着你不用当时准确地决定你的具体数据结构或是你的记录应该蕴含哪些具体字段。这特地适宜处于草创阶段，还在一直减少或批改服务个性的利用。而且也特地适宜利用在麻利开发我的项目中，不用进行长达数月的事后剖析。对于应用 Cassandra 的利用，如果业务发生变化了，只须要在运行中减少或删除某些字段就行了，不会造成服务中断。 当然， 这不是说你不须要思考数据。相同，Cassandra 须要你换个角度看数据。在 RDBMS 里， 你得首先设计一个残缺的数据模型， 而后思考查问形式， 而在 Cassandra 里，你能够首先思考如何查问数据，而后提供这些数据就能够了。 ...

作者：杨文 DBA，负责客户我的项目的需要与保护，会点数据库，不限于MySQL、Redis、Cassandra、GreenPlum、ClickHouse、Elastic、TDSQL等等。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、前情提要：咱们晓得 cassandra 具备分区容错性和强一致性，然而当数据所在主机产生故障时，该主机对应的数据副本该何去何从呢？是否跟宿主机一样变得不可用呢？想晓得答案的话，就跟我一起往下看吧。 二、试验环境：集群模式下跨数据中心： 数据中心节点IP种子节点DC110.186.60.61、10.186.60.7、10.186.60.118、10.186.60.6710.186.60.61、10.186.60.7DC210.186.60.53、10.186.60.65、10.186.60.94、10.186.60.6810.186.60.53、10.186.60.65首先一起来瞅一瞅节点退出集群过程中的 owns 变动： [cassandra@data01 ~]$ nodetool statusDatacenter: dc1=================Status=Up/Down|/ State=Normal/Leaving/Joining/Moving-- Address Load Tokens Owns (effective) Host ID RackUN 10.186.60.7 88.29 KiB 16 46.0% 4702178e-9878-48dc-97e7-9211b7c9f2e7 rack1UN 10.186.60.118 69.07 KiB 16 37.7% c920c611-2e8b-472d-93a4-34f1abd5b207 rack1UN 10.186.60.61 88.25 KiB 16 34.2% af2e0c42-3a94-4647-9716-c484b690899i rack1Datacenter: dc2=================Status=Up/Down|/ State=Normal/Leaving/Joining/Moving-- Address Load Tokens Owns (effective) Host ID RackUN 10.186.60.65 69.04 KiB 16 41.4% 89683bf8-aff8-4fdc-9525-c14764cf2d4f rack2UN 10.186.60.53 83.18 KiB 16 41.7% 7c91c707-abac-44f2-811O-b18f03f03d13 rack2[cassandra@data01 ~]$ nodetool statusDatacenter: dc1=================Status=Up/Down|/ State=Normal/Leaving/Joining/Moving-- Address Load Tokens Owns (effective) Host ID RackUN 10.186.60.67 74.01 KiB 16 24.7% 9d6d759b-c00c-488b-938d-3e1ef9b92b02 rack1UN 10.186.60.7 88.29 KiB 16 27.5% 4702178e-9878-48dc-97e7-9211b7c9f2e7 rack1UN 10.186.60.118 83.16 KiB 16 28.9% c920c611-2e8b-472d-93a4-34f1abd5b207 rack1UN 10.186.60.61 88.25 KiB 16 30.3% af2e0c42-3a94-4647-9716-c484b690899i rack1Datacenter: dc2=================Status=Up/Down|/ State=Normal/Leaving/Joining/Moving-- Address Load Tokens Owns (effective) Host ID RackUN 10.186.60.65 83.17 KiB 16 27.7% 89683bf8-aff8-4fdc-9525-c14764cf2d4f rack2UN 10.186.60.53 83.18 KiB 16 29.8% 7c91c707-abac-44f2-811O-b18f03f03d13 rack2UN 10.186.60.94 69.05 KiB 16 31.1% c8fa86e4-ee9a-4c62-b00b-d15edc967b9f rack2[cassandra@data01 ~]$ nodetool statusDatacenter: dc1=================Status=Up/Down|/ State=Normal/Leaving/Joining/Moving-- Address Load Tokens Owns (effective) Host ID RackUN 10.186.60.67 74.01 KiB 16 21.4% 9d6d759b-c00c-488b-938d-3e1ef9b92b02 rack1UN 10.186.60.7 88.29 KiB 16 25.2% 4702178e-9878-48dc-97e7-9211b7c9f2e7 rack1UN 10.186.60.118 83.16 KiB 16 27.1% c920c611-2e8b-472d-93a4-34f1abd5b207 rack1UN 10.186.60.61 83.19 KiB 16 28.9% af2e0c42-3a94-4647-9716-c484b690899i rack1Datacenter: dc2=================Status=Up/Down|/ State=Normal/Leaving/Joining/Moving-- Address Load Tokens Owns (effective) Host ID RackUN 10.186.60.68 88.55 KiB 16 21.6% a7307228-62bb-4354-9853-990cac9614ab rack2UN 10.186.60.65 83.17 KiB 16 24.0% 89683bf8-aff8-4fdc-9525-c14764cf2d4f rack2UN 10.186.60.53 83.18 KiB 16 25.4% 7c91c707-abac-44f2-811O-b18f03f03d13 rack2UN 10.186.60.94 69.05 KiB 16 26.4% c8fa86e4-ee9a-4c62-b00b-d15edc967b9f rack2能够看到，刚建设的集群，owns 的总和时刻放弃在 200% ，但单个数据中心的 owns 不是 100% 。 ...

作者：杨文 DBA，负责客户我的项目的需要与保护，会点数据库，不限于MySQL、Redis、Cassandra、GreenPlum、ClickHouse、Elastic、TDSQL等等。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 一、背景：客户在集群中查看用户信息 list users 时，报错 Error from server:xxx 。其实是个简略的查看语句，但魔法失灵了？上面咱们将集群中用户角色等信息的查看形式做一个对立的剖析阐明。 二、cassandra 简略介绍：2.1、Cassandra集群组成：节点(Node)、机架(Rack)、数据中心(Data Center)；节点(Node)：运行Cassandra实例的服务器；机架(Rack)：一组互相凑近的Cassandra节点；数据中心(Data Center)：指逻辑机架的汇合。2.2、Cassandra通常跨多个数据中心存储数据正本，以确保高可用性，同时会将查问路由到同一数据中心的其余节点以实现最优性能，为了实现这一点，Cassandra应用两个外部协定来治理基于集群拓扑的数据路由：gossip和snitches。Cassandra应用Gossip协定实现了无核心架构。Cassandra应用Snitch机制实现了节点感知以进步性能。Cassandra应用环构造和令牌机制实现了集群的动静扩容和数据分区。2.3、环构造和令牌：Cassandra将一个集群治理的数据表示为环，会为环中的每个节点调配一个或多个数据区间或范畴，由一个令牌形容，确定数据在环中的地位。通过应用散列函数为分区键计算令牌，将数据调配给节点。将该分区密钥令牌与各个节点的令牌值进行比拟，以辨认领有该数据的范畴，从而辨认该节点。Cassandra将群集治理的数据表示为环。环中的每个节点被调配由令牌形容的一个或多个数据范畴，该令牌确定其在环中的地位，令牌是用于标识每个分区的64位整数ID。2.4、复制策略：节点用作不同数据范畴的正本。如果一个节点产生故障，其余正本能够响应对该数据范畴的查问。Cassandra以对用户通明的形式跨节点复制数据，复制因子是集群中接管雷同数据的正本的节点数。第一个正本将始终是申明令牌落入范畴的节点，但正本的其余部分依据复制策略搁置。三、本地环境测试：咱们将通过试验测试进行 cassandra 用户角色查看时的各种状况阐明。 试验环境：集群模式下跨数据中心。 数据中心节点IP种子节点DC110.186.60.61、10.186.60.7、10.186.60.118、10.186.60.6710.186.60.61、10.186.60.7DC210.186.60.53、10.186.60.65、10.186.60.94、10.186.60.6810.186.60.53、10.186.60.653.1、用户：应用默认用户名 cassandra 和默认明码 cassandra 登录： cqlsh 10.186.60.61 -u cassandra -p cassandra创立用户： cassandra@cqlsh> CREATE USER root WITH PASSWORD 'rootroot' SUPERUSER;cassandra@cqlsh> list users;name | super | datacenters----------+-------+-------------cassandra | True | ALL root | True | ALL(2 rows)阐明： 只有 SUPERUSER 能够创立用户，创立的用户默认为 NOSUPERUSER;只有 SUPERUSER 能够删除用户，任何用户不能删除本人。如果要删除默认帐号，须要用新创建的账号从新登录，才能够删除默认账号；删除后，将不能再应用cassandra用户登录数据库了。示例： cqlsh 10.186.60.61 -u root -p rootroot...root@cqlsh> drop user cassandra;和其它分布式数据库一样，此时能查看所有用户的几种形式： ...

cassandra装置部署1.装置 cassandra本文采纳tar包的形式装置 # 确保本地装置java 8以上版本java -version# 下载tar包curl -OL http://archive.apache.org/dist/cassandra/3.11.9/apache-cassandra-3.11.9-bin.tar.gztar xzvf apache-cassandra-3.11.9-bin.tar.gzcd apache-cassandra-3.11.9/2.配置 cassandracassandra配置文件是 conf/cassandra.yaml，测试环境是214、215集群部署，配置具体如下： 环境1(ip假如为 192.192.192.1)配置文件 cassandra.yaml cluster_name: 'CLUSTER-NAME'seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "192.192.192.1,192.192.192.2"listen_address: 192.192.192.1rpc_address: 192.192.192.1环境2(ip假如为 192.192.192.2)配置文件 cassandra.yaml cluster_name: 'CLUSTER-NAME'seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "192.192.192.1,192.192.192.2"listen_address: 192.192.192.2rpc_address: 192.192.192.23.启动 cassandra本文采纳tar包的形式装置 ## 启动cassandracd apache-cassandra-3.11.9/bin/cassandra## 查看日志tail -f logs/system.log## 查看节点状态bin/nodetool status## 尝试连贯数据bin/cqlsh

简介容器是一种风行的技术，用于减速当今的利用程序开发。多亏了Docker这样的容器平台，与虚拟机相比，您能够无效地打包应用程序。应用容器，应用程序及其所有依赖项一起打包到一个最小的可部署镜像中。作为开发人员，您能够应用容器在环境之间挪动应用程序，并确保您的应用程序按预期运行。这些指标导致了容器编排平台的创立。这个畛域的领导者是Kubernetes。 其劣势如下： Kubernetes承受服务定义，并解决容器到服务器的调配并将它们连贯在一起。Kubernetes动静跟踪正在运行的容器的运行状况。如果某个容器呈现故障，Kubernetes会解决重启它的问题，并能够安顿在其余硬件上更换其容器。通过应用Kubernetes编排容器，您能够疾速构建基于微服务的应用程序，并确保它们在任何Kubernetes平台上都能按设计运行。Cass Operator是 DataStax 开源的，主动在Kubernetes集群中部署和治理开源ApacheCassandra®。 Cass Operator将用户提供的信息精简为节点数和集群名称，以治理各个Kubernetes资源的生命周期。能够应用其余选项，然而对于初学者来说，基本上就是您须要指定的全副。当初，治理分布式Cassandra的过程变得容易得多，这意味着您的团队能够自在地专一于应用程序层及其性能。 Cass Operator能够应用以下任何通过认证的Kubernetes平台： 开源 KubernetesAmazon Elastic Kubernetes Service (EKS)Google Kubernetes Engine (GKE)Microsoft Azure Kubernetes Service (AKS)Pivotal Container Service (PKS)部署1：部署Cass Operator 装置Cass Operator自身很简略。官网提供了从1.13到1.17的每个Kubernetes版本的清单。如下将相干清单利用于您的集群： K8S_VER=v1.16kubectl apply -f https://raw.githubusercontent.com/datastax/cass-operator/v1.4.1/docs/user/cass-operator-manifests-$K8S_VER.yaml本次部署的集群为aws的eks1.17版本。所以具体部署命令如下： K8S_VER=v1.17kubectl apply -f https://raw.githubusercontent.com/datastax/cass-operator/v1.4.1/docs/user/cass-operator-manifests-$K8S_VER.yamlnamespace/cass-operator createdserviceaccount/cass-operator createdsecret/cass-operator-webhook-config createdcustomresourcedefinition.apiextensions.k8s.io/cassandradatacenters.cassandra.datastax.com createdclusterrole.rbac.authorization.k8s.io/cass-operator-webhook createdclusterrolebinding.rbac.authorization.k8s.io/cass-operator-webhook createdrole.rbac.authorization.k8s.io/cass-operator createdrolebinding.rbac.authorization.k8s.io/cass-operator createdservice/cassandradatacenter-webhook-service createddeployment.apps/cass-operator createdvalidatingwebhookconfiguration.admissionregistration.k8s.io/cassandradatacenter-webhook-registration created查看operator运行状态： kubectl -n cass-operator get pods --selector name=cass-operatorNAME READY STATUS RESTARTS AGEcass-operator-7cc94f547-cctd4 1/1 Running 0 3m44s咱们能够看到status 为runing。 Operator定义了一个名称为CassandraDatacenter的CRD，该CRD蕴含了Cassandra集群的所有根本结构块，例如机架，节点，镜像以及其余方面。 ...

简介Apache Cassandra是一个高度可扩大的高性能分布式数据库，旨在解决许多商用服务器上的大量数据，提供高可用性而没有单点故障。它是NoSQL数据库的一种。首先让咱们理解一下NoSQL数据库的作用。 NoSQL 数据库 NoSQL数据库（有时称为“Not Only SQL”）是一种数据库，它提供了一种存储和检索关系数据库中应用的表格关系以外的数据的机制。这些数据库是无模式的，反对简略的复制，具备简略的API，最终是统一的，并且能够解决大量数据。 NoSQL数据库的次要指标是： 设计简略程度缩放更好地管制可用性与关系数据库相比，NoSql数据库应用不同的数据结构。它使NoSQL中的某些操作更快。给定NoSQL数据库的适用性取决于它必须解决的问题。 NoSQL vs 关系型数据库 下表列出了将关系数据库与NoSQL数据库辨别开的要点。 关系数据库 NoSql 数据库 反对弱小的查询语言 反对非常简单的查询语言 schema固定 schema不固定 遵循ACID 最终一致性 反对事务 不反对事务 除了Cassandra，咱们还有以下十分风行的NoSQL数据库- Apache HBase-HBase是一种以Google的BigTable建模的开源，非关系，分布式数据库，并应用Java编写。它是Apache Hadoop我的项目的一部分，在HDFS之上运行，为Hadoop提供相似BigTable的性能。MongoDB-MongoDB是一个跨平台的面向文档的数据库系统，它防止应用传统的基于表的关系数据库构造，而是应用具备动静模式的相似JSON的文档，从而使数据在某些类型的应用程序中的集成更加容易和快捷。什么是Apache Cassandra？Apache Cassandra是一个开源，分布式和扩散/分布式存储系统（数据库），用于治理散布在世界各地的大量结构化数据。它提供高可用性服务，没有单点故障。 以下列出了Apache Cassandra的一些值得注意的中央- 它具备可伸缩性，容错性和一致性。它是一个面向列的数据库。其散发设计基于亚马逊的Dynamo及其在Google的Bigtable上的数据模型。它创立于Facebook，与关系数据库管理系统截然不同。Cassandra实现了Dynamo格调的复制模型，没有单点故障，然而增加了更弱小的“column family”数据模型。一些大型公司（例如Facebook，Twitter，Cisco，Rackspace，ebay，Twitter，Netflix等）正在应用Cassandra。Cassandra特点 Cassandra因为其杰出的技术个性而变得如此受欢迎。以下是Cassandra的一些性能： 弹性可扩展性– Cassandra具备高度可扩展性；它容许增加更多硬件，以依据需要包容更多客户和更多数据。始终在线-Cassandra没有单点故障，并且能够间断用于无奈接受故障的要害业务应用程序。疾速的线性规模性能-Cassandra具备线性可扩展性，即，随着集群中节点数量的减少，它能够进步吞吐量。因而，它放弃了疾速的响应工夫。灵便的数据存储-Cassandra可包容所有可能的数据格式，包含：结构化，半结构化和非结构化。它能够依据须要动静适应对数据结构的更改。轻松进行数据散发-Cassandra通过在多个数据中心之间复制数据，提供了在所需地位散发数据的灵活性。事务反对-Cassandra反对原子性，一致性，隔离性和持久性（ACID）等属性。疾速写入-Cassandra旨在在便宜的商品硬件上运行。它执行疾速的写入，并且能够存储数百TB的数据，而不会就义读取效率。架构Cassandra的设计指标是在多个节点上解决大数据工作负载而不会呈现任何单点故障。 Cassandra在其节点之间具备对等分布式系统，并且数据分布在集群中的所有节点之间。 集群中的所有节点都表演雷同的角色。每个节点都是独立的，并同时互连到其余节点。集群中的每个节点都能够承受读写申请，而不论数据理论位于集群中的何处。当某个节点产生故障时，能够从网络中的其余节点解决读/写申请。Cassandra中的数据复制 在Cassandra中，集群中的一个或多个节点充当给定数据段的正本。如果检测到某些节点响应的值过期，则Cassandra会将最新值返回给客户端。返回最新值后，Cassandra在后盾执行读取修复以更新过期的值。下图显示了Cassandra如何在集群中的节点之间应用数据复制以确保没有单点故障的示意图。 Cassandra应用Gossip协定，以容许节点彼此通信并检测集群中的任何故障节点。Cassandra 组件 组成部分如下- Node − 它是存储数据的中央。Data center − 它是相干节点的汇合。Cluster − 是蕴含一个或多个数据中心的组件。Commit log − 是Cassandra中的解体复原机制。每个写操作都会写入commit log。Mem-table − 内存表是驻留内存的数据结构。commit log后，数据将被写入内存表。有时，对于single-column family，将有多个内存表。SSTable − 它是一个磁盘文件，当其内容达到阈值时，会将数据从内存表中刷新到该磁盘文件中。Bloom filter − 这些仅是用于测试元素是否为汇合成员的疾速，不确定性算法。这是一种非凡的缓存。每次查问后都会拜访Bloom筛选器。Cassandra 查询语言 ...