Your SlideShare is downloading. ×
Cassandra简介.ppt
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Cassandra简介.ppt

10,246
views

Published on


1 Comment
47 Likes
Statistics
Notes
  • Tags cassandra
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
10,246
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
649
Comments
1
Likes
47
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • http://highscalability.com/blog/2009/10/26/facebooks-memcached-multiget-hole-more-machines-more-capacit.html http://highscalability.com/strategy-facebook-tweaks-handle-6-time-many-memcached-requests http://www.facebook.com/note.php?note_id=39391378919
  • 上面来自 Vogel 的定义应该更多说明的是好的 Scalability 是怎么样的 http://www.dbthink.com/?p=357 性能与可伸缩性 http://www.dbthink.com/?p=352 简述伸缩性 A review of Forecasting Oracle Performance by Craig Shallahamer By Baron Schwartz
  • http://www.slideshare.net/guestdfd1ec/design-patterns-for-distributed-nonrelational-databases (slides 22/23/24)
  • 对 CAP 公理的详细描述 . http://www.julianbrowne.com/article/viewer/brewers-cap-theorem Brewer 的最初描述 http://www.cs.berkeley.edu/%7Ebrewer/cs262b-2004/PODC-keynote.pdf 两位教授对 CAP 公理的证明 . http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.20.1495&rep=rep1&type=pdf Daniel Abadi 对 CAP Theorem 的质疑 ,C 并不是始终为 A 做牺牲 , 因为 P 是一个很少发生的事实 , 大部分情况下 ,C 可能更多的是为 L(Latency) 做牺牲 . http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html
  • About ACID http://en.wikipedia.org/wiki/ACID About BASE http://queue.acm.org/detail.cfm?id=1394128 Eventual Consistency http://www.allthingsdistributed.com/2008/12/eventually_consistent.html
  • http://blog.nahurst.com/visual-guide-to-nosql-systems
  • http://www.slideshare.net/egpeters/nosql-cassandra-talk-for-seattle-tech-startups-31010-3399002(slides 3)
  • http://n2.nabble.com/Cassandra-users-survey-td4040068.html http://www.dbthink.com/?p=183
  • http://www.slideshare.net/benjaminblack/introduction-to-cassandra-replication-and-consistency(slide 2)
  • http://www.slideshare.net/benjaminblack/introduction-to-cassandra-replication-and-consistency(slide 3,4)
  • http://en.wikipedia.org/wiki/Consistency_model
  • 因果一致性 。如果进程 A 通知进程 B 它已更新了一个数据项,那么进程 B 的后续访问将返回更新后的值,且一次写入 将保证取代前一次写入。与进程 A 无因果关系的进程 C 的访问遵守一般的最终一致性规则。 “ 读己之所写( read-your-writes )”一致性 。当进程 A 自己更新一个数据项之后,它总是访问到 更新过的值,绝不会看到旧值。这是因果一致性模型的一个特例。 会话( Session )一致性 。这是上一个模型的实用版本,它把访问存储系统的进程放到会话的上下文中。只要 会话还存在,系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止,就要建立新的会话,而且系统的保证不会延续到新的会话。 单调( Monotonic )读一致性 。如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回在那 个值之前的值。 单调写一致性 。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性,就非常难以编程 了。 具体可参考 http://www.allthingsdistributed.com/2008/12/eventually_consistent.html http://www.ningoo.net/html/2010/cap_theorem_and_eventually_consistent.html
  • http://wiki.apache.org/cassandra/ReadRepair
  • http://wiki.apache.org/cassandra/HintedHandoff
  • http://tech.idv2.com/2008/07/24/memcached-004/
  • http://www.slideshare.net/gdusbabek/cassandra-presentation-for-san-antonio-jug http://arin.me/blog/wtf-is-a-supercolumn-cassandra-data-model http://wiki.apache.org/cassandra/DataModel
  • http://www.slideshare.net/jhammerb/data-presentations-cassandra-sigmod(slide 5)
  • http://www.slideshare.net/jhammerb/data-presentations-cassandra-sigmod(slide 7)
  • http://www.slideshare.net/jhammerb/data-presentations-cassandra-sigmod(slide 8)
  • http://spyced.blogspot.com/2009/05/consistent-hashing-vs-order-preserving.html http://ria101.wordpress.com/2010/02/22/cassandra-randompartitioner-vs-orderpreservingpartitioner/ http://www.slideshare.net/jhammerb/data-presentations-cassandra-sigmod (slide 6)
  • http://www.slideshare.net/jhammerb/data-presentations-cassandra-sigmod ( slide 9) http://www.slideshare.net/jbellis/cassandra-open-source-bigtable-dynamo( slide 22) 或许是 Cassandra 在后期做了调整 , 在上面第一个 ppt 以及原始的 Paper 中 , 都是基于 Key 的原子性 , 但是 ,Jonathan Ellis(Cassandra 的项目负责人 ) 在后面一个 ppt 中改成了基于 ColumnFamily 的原子性 , 本 ppt 采纳后者 .
  • http://www.slideshare.net/jbellis/cassandra-open-source-bigtable-dynamo (slide 23/24)
  • http://www.slideshare.net/jhammerb/data-presentations-cassandra-sigmod ( slide 12)
  • http://www.slideshare.net/guestdfd1ec/design-patterns-for-distributed-nonrelational-databases (slide 35-39), 本页以及后续 4 页 .
  • http://www.slideshare.net/jhammerb/data-presentations-cassandra-sigmod (slide 13) http://www.dbthink.com/?p=372 ( 5.3.1 一节 ) 给定部分阈值 Φ, 并假定当 Φ=1 时我们就决定怀疑一个节点 A, 我们犯错误 ( 例如 , 这个决定在将来可能由于心跳接收延迟而被证明是错误的 ) 的概率为 10%.Φ=2 时出错的概率大约为 1%,Φ=3 大约为 0.1%, 等等 .
  • Transcript

    • 1. Cassandra 简介 [email_address] 童家旺 http://www.dbthink.com
    • 2. A highly scalable, eventually consistent, distributed, structured key-value store.
    • 3. 议题介绍
      • 背景
      • 基本前提
        • Scalability
        • 基本的 Storage Model
        • CAP 公理简介
      • Cassandra 使用案例
      • Cassandra 设计
        • 它山之石
        • Consistency Models(Eventual Consistency)
        • Consistent Hashing
        • Data Models
        • Storage Model (SSTable & MemTable)
        • 故障检测 & Gossip 通讯
    • 4. Cassandra 的设计背景
      • Scale Up 不可接受
      • 满足海量数据存储需求
        • 海量数据 , 主要是用户的信息与用户消息 ( 类似于我们的反馈 )
        • 大量随机的读写
        • 没有现成的解决方案 , 或者说现成的解决方案无法解决 (4000 个节点的 Memcached)
      • 很多应用并不是很依赖于关系模型了
    • 5. Cassandra 的设计目标
      • 高可用性
      • 最终一致性
        • 经过权衡 , 在强一致性与高可用性之间选择了高可用性
      • 动态可伸缩
      • 乐观复制
      • 可以动态调整一致性 / 持久性与延时
      • 节点管理要保持低开销
      • 最小化管理开销
    • 6. Scalability
      • 当我们增加一个系统中的资源,并能获取与增加的资源保持适当的比例关系的性能提升,我们就认为这个服务具备了伸缩性。
        • 资源投入与输出保持线性关系
        • 为促进冗余投入的资源不会带来性能损失
        • 能够处理异构资源
        • 能做到运维高效
        • 具备自修复能力
      • scalability is a function that represents the relationship between workload and throughput
    • 7. Scalability[2]
      • Scale Out Vs Scale Up
        • Scale Up- 在同一个逻辑单元内增加资源 , 例如增加 CPU/ 内存 / 网卡数量等 .
        • Scale Out- 增加多个逻辑单元的资源 , 并使它们如同一个集中的资源那样提供服务 ( 集群 / 分布式 / 负载均衡等 )
        • Scale Up 较为简单 , 但是规模有限 , 代价越来越大
        • Scale Out 需要从架构层面设计 , 规模没有限制 , 代价由架构决定 .
    • 8. 基本的存储模型
      • 行存储 Vs 列存储 Vs 混合存储
        • 行存储适合查找整行的存储 , 不过需要配合索引
        • 列存储适合查找少量列 , 适合做基于列的统计 / 查询
        • 混合列存储 .
          • 将需要经常组合查询的列组合在一起 .
          • 将其他列 ( 列的组合 ) 单独存储 .
    • 9. 基本的存储模型 [2]
    • 10. CAP Theorem
      • Consistency
        • the system provides a view of the distributed state which is consistent between observers
        • 所有的用户都可以看到一致的系统状态
      • Availability
        • The system as a whole should continue functioning , even if servers should fail or be unreachable due to network failures
        • 无论何时 , 哪怕出现硬件故障 , 数据中心故障 , 系统也可提供服务 , 哪怕是降级的服务
      • Partition Tolerance
        • The system as a whole should continue to function, potentially with degradations in service, even if the network can fail in arbitrary ways.
        • 哪怕在网络出现分割的情况下 , 各个独立的子系统都可以继续提供服务
      • Can Only Choose Two From Above Three
    • 11. CAP Theorem[2]
      • BASE
        • Basic Availability
        • Soft state
        • Eventual Consistency
      • ACID
        • Atomic
        • Consistency
        • Isolation
        • Durability
    • 12. CAP Theorem[3] http://blog.nahurst.com/visual-guide-to-nosql-systems
    • 13. Cassandra 使用案例
    • 14. Cassandra 使用案例 [2] user site application others evaluated Jonathan Ellis-3 Rackspace stats collection (testing, almost production),Mail & Apps division (early testing) HBase, Hypertable, dynomite,and Voldemort Ryan King Twitter storage for all tweets a custom mysql impl, voldemort, hbase, mongodb, memcachdb, hypertable, and others Edmond Lau Ooyala store and serve our near real-time video analytics data HBase, Cassandra, Voldemort, and some others Joe Stump SimpleGeo real-time location infrastructure scott w Onespot a subset of our data store Tokyo, Voldemort and Riak and Cassandra Vitaly Kushner Astrails a project for one of our clients(early development stage)   Dan Di Spaltro Cloudkick store monitoring statistics and running analytics over the data   Eric Lubow ShermansTravel mailing system,social network usage Cassandra and Tokyo Cabinet/Tokyo Tyrant Richard grossman bee.tv smart TV and movies recommendations , index each day all the TV shows in every states + all the new VOD sources   matthew hawthorne Comcast tons of data that we are migrating into non-relational storage cassandra, riak, voldemort, and hdfs Santal Li Cisco Webex store User Feed & User Activity data Voldemort, MemcacheDB, Dynomite
    • 15. Cassandra 设计
      • 它山之石
      • Consistency Models(Eventual Consistency)
      • Consistent Hashing
      • Data Model
      • Storage Model (SSTable & MemTable)
      • Gossip 通讯
      • 故障检测
    • 16. 它山之石
    • 17. 它山之石 [2]
      • Dynamo-like features
        • Symmetric,P2P architecture
          • No Special nodes, No SPOF(Single Point Of Failure)
        • Gossip Based cluster management
        • Distributed hash table for data placement
          • Pluggable partitioning
          • Pluggable topology discovery
          • Pluggable placement strategies
        • Tunable, Eventual Consistency
      • BigTable-like Features
        • Sparse , ”columnar” data model
          • Optional,2-level maps Called Super-Column Families
        • SSTable Disk Storage
          • Append-only Commit Log
          • MemTable (Buffer & Sort)
          • Immutable SSTable Files
        • Hadoop Integration
    • 18. Consistency Models
      • 一致性模型是程序员与系统之间交互的一个协议 , 如果程序员遵循特定的规则 , 系统就可以保证结果的一致性以及结果的可预测性
      • 一致性模型决定了数据可见与显示更新顺序的规则
      • 一致性是一个连续的平衡的过程
    • 19. 客户端一致性
        • 强一致性
          • 所有用户都可以同时看到同一份一致的数据 (ACID 标准 )
        • 弱一致性
      • 最终一致性 ( 弱一致性的变种 )
        • 如果系统确保一定的时间不做任何变更,最终所有的查询都会返回相同的最新值
          • 因果一致性
          • " 读己之所写 (read-your-writes)" 一致性
          • 会话 (Session) 一致性
          • 单调 (Monotonic) 读一致性
          • 单调写一致性
    • 20. 服务端一致性
      • N — 数据复制的份数
      • W — 更新数据是需要保证写完成的节点数
      • R — 读取数据的时候需要读取的节点数
        • 如果 W+R>N ,写的节点和读的节点重叠,则是强一致性
        • 如果 W+R<=N ,则是弱一致性
    • 21. Cassandra 支持的一致性
      • 一致性模型取决于副本( Replicas )的数量( N ) , 一般为 3
      • 在 Cassandra 中一般选择 Quorum 数量的读节点数( R, 一般为 2 )以及 Quorum 数量的写节点数 (W, 一般为 2)
      Write Read Level Description Level Description ZERO Cross fingers ANY 1 st Response (Including HH) One 1 st Response One 1 st Response QUORUM N/2 + 1 Replicas QUORUM N/2 + 1 Replicas ALL All Replicas ALL All Replicas
    • 22. Read Repair
      • 每次读取时都读取所有的副本
        • 只返回一个副本的数据
        • 对所有副本应用 Checksum 或 Timestamp 校验
      • 如果存在不一致
        • 取出所有的数据并做合并
        • 将最新的数据写回到不同步( out of sync) 的节点
    • 23. Hinted handoff
      • Hinted handoff 主要解决节点 Down 掉以后的复制问题 .
      • Cassandra 会往一个活动节点记录信息 , 此节点需要重新 Apply 此变更 .
      • 如果节点 Down 掉时间较长 , 可能会导致出现较大的 Hinted handoff 日志 .
      • Hinted handoff 解决的主要问题
        • 降低一个临时 Down 掉的节点恢复的速度
        • 在一致性 (Consistency) 允许的情况下 , 提供尽可能好的写可用性 (always writable)
    • 24. Consistent Hashing
      • 为所有的 Key 计算一个 Hash 值 ( 一般为 Md5 计算的 128 位 Hash 值 )
      • 这些 Hash 值都分布在一个环 (Ring) 上 .
      • 最大的 Hash 值的位置与最小的 Hash 值相邻
      • 每个可提供服务的节点负责环上的一段区间
      • 每个节点都有一个环上的令牌 (Token)
      • 每个节点负责它的令牌到顺时针方向的下一个令牌之间的区域
    • 25. Consistent Hashing[2]
    • 26. Data Model
      • Keyspace 包含 Column Family
      • Column Family
        • 标准 Column Family 或 Super Column Family
        • 两级索引 (Key 以及 Column Name)
      • Column 以及 SubColumn 的排列顺序
      • Column 总是有序的 ,Column 通过其 ColumnName 进行排序
      • 指定你使用的 Comparator
        • TimeUUID
        • LexicalUUID
        • UTF8
        • Long
        • Bytes
        • CreateYourOwn
    • 27. Data Model KEY ColumnFamily1 Name : MailList Type : Simple Sort : Name Name : tid1 Value : <Binary> TimeStamp : t1 Name : tid2 Value : <Binary> TimeStamp : t2 Name : tid3 Value : <Binary> TimeStamp : t3 Name : tid4 Value : <Binary> TimeStamp : t4 ColumnFamily2 Name : WordList Type : Super Sort : Time Name : aloha ColumnFamily3 Name : System Type : Super Sort : Name Name : hint1 <Column List> Name : hint2 <Column List> Name : hint3 <Column List> Name : hint4 <Column List> Name : dude C2 V2 T2 C6 V6 T6 Column Families are declared upfront Columns are added and modified dynamically SuperColumns are added and modified dynamically Columns are added and modified dynamically C1 V1 T1 C2 V2 T2 C3 V3 T3 C4 V4 T4
    • 28. Storage Model Key (CF1 , CF2 , CF3) Commit Log Binary serialized Key ( CF1 , CF2 , CF3 ) Memtable ( CF1) Memtable ( CF2) Memtable ( CF2) FLUSH
      • Data size
      • Number of Objects
      • Lifetime
      Dedicated Disk <Key name><Size of key Data><Index of columns/supercolumns>< Serialized column family> --- --- --- --- <Key name><Size of key Data><Index of columns/supercolumns>< Serialized column family> BLOCK Index <Key Name> Offset, <Key Name> Offset K 128 Offset K 256 Offset K 384 Offset Bloom Filter (Index in memory) Data file on disk
    • 29. Storage Model-Compactions K1 < Serialized data > K2 < Serialized data > K3 < Serialized data > -- -- -- Sorted K2 < Serialized data > K10 < Serialized data > K30 < Serialized data > -- -- -- Sorted K4 < Serialized data > K5 < Serialized data > K10 < Serialized data > -- -- -- Sorted MERGE SORT K1 < Serialized data > K2 < Serialized data > K3 < Serialized data > K4 < Serialized data > K5 < Serialized data > K10 < Serialized data > K30 < Serialized data > Sorted K1 Offset K5 Offset K30 Offset Bloom Filter Loaded in memory Index File Data File D E L E T E D
    • 30. Storage Model- 写操作
      • 客户端给 Cassandra 集群的任一随机节点发送写请求
      • &quot; 分割器 &quot; 决定由哪个节点对此数据负责
        • RandomPartitioner ( 完全按照 Hash 进行分布 )
        • OrderPreservingPartitioner( 按照数据的原始顺序排序 )
      • Owner 节点先在本地记录日志 , 然后将其应用到内存副本 (MemTable)
      • 提交日志 (Commit Log) 保存在机器本地的一个独立磁盘上 .
    • 31. Storage Model- 写相关特性
      • 关键路径上没有任何锁
      • 顺序磁盘访问
      • 表现类似于写入式缓存 (write through cache)
      • 只有 Append 操作 , 没有额外的读开销
      • 只保证基于 ColumnFamily 的原子性
      • 始终可写 ( 利用 Hinted Handoff)
      • 即使在出现节点故障时仍然可写
    • 32. Storage Model- 读操作 / 特性
      • 从任一节点发起读请求
      • 由 &quot; 分割器 &quot; 路由到负责的节点
      • 等待 R 个响应
      • 在后台等待 N - R 个响应并处理 Read Repair
      • 读取多个 SSTable
      • 读速度比写速度要慢 ( 不过仍然很快 )
        • 通过使用 BloomFilter 降低检索 SSTable 的次数
        • 通过使用 Key/Column index 来提供在 SSTable 检索 Key 以及 Column 的效率
      • 可以通过提供更多内存来降低检索时间 / 次数
      • 可以扩展到百万级的记录
    • 33. Anti-Entropy Gossip 通讯
      • Gossip 协议主要用来管理集群会员信息
      • 还用来管理各种系统状态 . 每个节点的状态以及其他会员的活动状态等 .
      • 通讯效率非常高 , 只需要 Log(N) 回合就可以将状态传递给集群的 N 个节点
      • 每隔 T 秒 , 每个节点都会自增自己的 Heartbeat 信息并通过 Gossip 传递给其他节点
    • 34. Gossip- 初时状态
    • 35. Gossip- 第一回合
    • 36. Gossip- 第 3 回合
    • 37. Gossip- 第 3 回合
    • 38. Gossip- 第 4 回合
    • 39. 故障检测
      • Cassandra 使用 Accrual 故障检测器
      • 在系统管理 , 复制 , 负载均衡等领域应用广泛
      • 它的输出值为一个数值 (Phi, Φ ), 表示此节点面临故障的可疑级别
      • 它也被称为自适应故障检测器 , 可根据网络环境做自适应调整
      • 应用设置相应的 Phi 值 , 触发可疑节点并做针对性的处理
      • 在 Cassandra 中 , 默认的 Phi 值为 5, 检测到故障的时间在 10-15 秒
        • 具体设置的 Phi 值表明达到这个可疑级别的节点被认为已经出现故障