Mais conteúdo relacionado
Semelhante a Cassandra架构与应用 (20)
Cassandra架构与应用
- 3. NoSql背景 随着互联网大规模的Web2.0应用的兴起,随着云计算需要的大规模分布式服务和分布式存储的发展,传统的关系数据库面临着诸多全新的挑战,特别是在那些超大规模和高并发的SNS类型的应用场景下,使用关系数据库来存储和查询用户动态数据已经显得力不从心,暴露了很多难以克服的问题,例如需要很高的实时插入性能;需要海量的数据存储能力同时还需要非常快的查询检索速度;需要将数据存储无缝扩展到整个群集环境下,并且能够在线扩展等等。在这样的背景下,NoSQL数据库就应运而生了。
- 4. NOSQL is simply Not Only SQL!
- 7. ACID/BASE ACID 原子性(Atomicity). 事务中的所有操作,要么全部成功,要么全部不做. 一致性(Consistency) 在事务开始与结束时,数据库处于一致状态. 隔离性(Isolation). 事务如同只有这一个操作在被数据库所执行一样. 持久性(Durability). 在事务结束时,此操作将不可逆转.(也就是只要事务提交,系统将保证数据不会丢失,即使出现系统Crash,译者补充). BASE Basically Available(基本可用) Soft state(柔性状态) 状态可以有一段时间不同步,异步 Eventually consistent(最终一致) 最终数据是一致的就可以了,而不是时时一致
- 8. 最终一致性 场景介绍 (1)存储系统 存储系统可以理解为一个黑盒子,它为我们提供了可用性和持久性的保证。 (2)Process A ProcessA主要实现从存储系统write和read操作 (3)Process B 和ProcessC ProcessB和C是独立于A,并且B和C也相互独立的,它们同时也实现对存储系统的write和read操作。 强一致性 强一致性(即时一致性) 假如A先写入了一个值到存储系统,存储系统保证后续A,B,C的读取操作都将返回最新值 弱一致性 假如A先写入了一个值到存储系统,存储系统不能保证后续A,B,C的读取操作能读取到最新值。此种情况下有一个“不一致性窗口”的概念,它特指从A写入值,到后续操作A,B,C读取到最新值这一段时间。 最终一致性 最终一致性是弱一致性的一种特例。假如A首先write了一个值到存储系统,存储系统保证如果在A,B,C后续读取之前没有其它写操作更新同样的值的话,最终所有的读取操作都会读取到最A写入的最新值。此种情况下,如果没有失败发生的话,“不一致性窗口”的大小依赖于以下的几个因素:交互延迟,系统的负载,以及复制技术中replica的个数(这个可以理解为master/salve模式中,salve的个数)。
- 10. Cassandra有什么特点? 列表数据结构 在混合模式可以将超级列添加到5维的分布式Key-Value存储系统。 模式灵活 使用Cassandra,你不必提前解决记录中的字段。你可以在系统运行时随意的添加或移除字段。 真正的可扩展性 Cassandra是纯粹意义上的水平扩展。为给集群添加更多容量,可以增加动态添加节点即可。你不必重启任何进程,改变应用查询,或手动迁移任何数据。 多数据中心识别 你可以调整你的节点布局来避免某一个数据中心起火,一个备用的数据中心将至少有每条记录的完全复制。 范围查询 如果你不喜欢全部的键值查询,则可以设置键的范围来查询。 分布式写操作 有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。
- 12. 数据模型 Column SuperColumn ColumnFamily Keyspaces Row
- 19. 数据定位 第一层索引所用的 key 为 (row-key, cf-name), 即用一个 row-key 和 column-family-name 可以定位一个 column family。column family 是 column 的集合。 第二层索引所用的 key 为 column-name, 即通过一个 column-name 可以在一个 column family 中定位一个 column。
- 21. 数据分布策略 Distributed hash table Partitioner类型 RandomPartitioner OrderPreservingPartitioner ByteOrderedPartitioner CollatingOrderPreservingPartitioner 副本策略 LocalStrategy RackUnawareStrategy RackAwareStrategy DatacenterShardStategy
- 23. Partitioner类型 RandomPartitioner 随机分区是一种hash分区策略,使用的Token是大整数型(BigInteger),范围为0~2^127,因此极端情况下,一个采用随机分区策略的Cassandra集群的节点可以达到2^127+1个节点。 为什么是2^127? Cassandra采用了MD5作为hash函数,其结果是128位的整数值(其中一位是符号位,Token取绝对值为结果)。
- 34. 副本策略 Cassandra-rack.properties # Cassandra Node IP=Data Center:Rack 192.168.1.200=DC1:RAC1 192.168.2.300=DC2:RAC2 10.0.0.10=DC1:RAC1 10.0.0.11=DC1:RAC1 10.0.0.12=DC1:RAC2 10.20.114.10=DC2:RAC1 10.20.114.11=DC2:RAC1 10.21.119.13=DC3:RAC1 10.21.119.10=DC3:RAC1 10.0.0.13=DC1:RAC2 10.21.119.14=DC3:RAC2 10.20.114.15=DC2:RAC2 # default for unknown nodes default=DC1:r1
- 40. Memtable/SSTable SSTable包含对应的三种文件 Datafile 按照Key排序顺序保存的数据文件 文件名称格式如下:ColumnFamilyName-序号-Data.db Indexfile 保存每个Key在Datafile中的位置偏移 文件名称格式如下: ColumnFamilyName-序号-Filter.db Filterfile 保存BloomFilter的Key查找树 文件名称格式如下: ColumnFamilyName-序号-index.db
- 41. Commitlog Commitlog是server级别的,不是Column Family级别的,每一个节点上的Commitlog都是统一管理。 每个Commitlog文件的大小是固定的,称之为一个CommitlogSegment,目前版本(0.7.0)中,这个大小是128MB,硬编码在代码中。 当一个Commitlog文件写满以后,会新建一个的文件。 SSTable持久后不可变更,故Commitlog只用于Memtable的恢复,相当于Oracle的Instance Recovery。Cassandra不需要做Media Recover 当节点异常重启后,将根据SSTable和Commitlog进行实例恢复,在内存中重新恢复出宕机前的Memtable。 当一个Commitlog文件对应的所有CF的Memtable都刷新到磁盘后,该Commitlog就不再需要,系统会自动清除。
- 49. Quorum NRW N: 复制的节点数量 R: 成功读操作的最小节点数 W: 成功写操作的最小节点数
- 55. Delete 分布式删除存在的问题? 一个删除操作不可能一下子就将被删除的数据立即删除掉:如果客户端执行一个删除操作,并且有一个副本还没有收到这个删除操作,这个时候这个副本依然是可用的,此外,该节点还认为那些已经执行删除操作的节点丢失了一个更新操作,它还要去修复这些节点。
- 57. Delete 什么时候才真正被删除掉呢? 我们在使用客户端从Cassandra中读取数据的时候,节点在返回数据之前都会主动检查是否该数据被设置了删除标志,并且该删除标志的添加时长已经大于GCGraceSeconds,则要先删除该节点的数据再返回。
- 60. Hinted Handoff Key A按照规则首要写入节点为N1,复制到N2 假如N1宕机,如果写入N2能满足ConsistencyLevel要求,则Key A对应的RowMutation将封装一个带hint信息的头部(包含了目标为N1的信息),然后随机写入一个节点N3,此副本不可读。同时正常复制一份数据到N2,此副本可以提供读。如果写N2不满足写一致性要求,则写会失败。 N1恢复后,原本应该写入N1的带hint头的信息将重新写回N1。 HintedHandoff是实现最终一致性的一个优化措施,可以减少最终一致的时间窗口。
- 61. Read Repair 读取Key A的数据时,系统会读取Key A的所有数据副本,如果发现有不一致,则进行一致性修复。 如果读一致性要求为ONE,会立即返回离客户端最近的一份数据副本。然后会在后台执行Read Repair。这意味着第一次读取到的数据可能不是最新的数据。 如果读一致性要求为QUORUM,则会在读取超过半数的一致性的副本后返回一份副本给客户端,剩余节点的一致性检查和修复则在后台执行。 如果读一致性要求高(ALL),则只有Read Repair完成后才能返回一致性的一份数据副本给客户端。 该机制有利于减少最终一致的时间窗口。
- 67. Gossip消息如何如何发送 如果没有这个判断,考虑这样一种场景,有4台机器,{A, B, C, D},并且配置了它们都是seed,如果它们同时启动,可能会出现这样的情形: 1、A节点起来,发现没有活着的节点,走到第三步,和任意一个种子同步,假设选择了B 2、B节点和A完成同步,则认为A活着,它将和A同步,由于A是种子,B将不再和其他种子同步 3、C节点起来,发现没有活着的节点,同样走到第三步,和任意一个种子同步,假设这次选择了D 4、C节点和D完成同步,认为D活着,则它将和D同步,由于D也是种子,所以C也不再和其他种子同步 这时就形成了两个孤岛,A和B互相同步,C和D之间互相同步,但是{A,B}和{C,D}之间将不再互相同步,它们也就不知道对方的存在了。 加入第二个判断后,A和B同步完,发现只有一个节点活着,但是seed有4个,这时会再和任意一个seed通信,从而打破这个孤岛。
- 68. Gossip数据结构 gossip通信的状态信息主要有3种: 1、EndPointState 2、HeartBeatState 3、ApplicationState HeartBeatState由generation和version组成,generation每次启动都会变化,用于区分机器重启前后的状态 ApplicationState用于表示系统的状态,每个对象表示一种状态,比如表示当前load的状态大概是这样:(1.2, 20),含义为版本号为20时该节点的load是1.2 EndPointState封装了一个节点的ApplicationState和HeartBeatState 一个节点自身的状态只能由自己修改,其他节点的状态只能通过同步更新。
- 73. Flowdock转向MongoDB 稳定性问题 所有的节点都陷入无限循环(infinite loop),运行垃圾回收工作(GC, Garbage Collection)并尝试压缩数据文件——并偶尔导致集群瘫痪。除了对集群进行重启并经常性的手工对节点做压缩工作以让其稳定一会外,无计可施。其他人也报告过类似的问题。在前面几周的时间里,我们的Cassandra节点总是会吃掉给他分配的所有资源,而导致Flowdock运行缓慢。 运维问题 从Cassandra 0.4升级到0.5的时候,我们被迫关闭了整个集群,仅仅是为了将所有的数据刷新到磁盘上(虽然,我们已经按照文档进行了手工刷新的操作)。这个操作导致我们丢失了几分钟的讨论内容,以及我们手工创建的索引出现严重的不一致,以致于需要做完全的重建。