• 1. NoSQL 应用视角扩展性,可用性与可靠性的抉择系统中心 陈晟 2011-12
  • 2. 提要简介 NoSQL: Why 扩展性,并发度,新趋势 NoSQL: What 基本原理,核心技术,典型产品 NoSQL: When 性能vs扩展性,响应时间vs吞吐量,一致性vs可用性 NoSQL @pwrd 我们的工作:HBase性能指标、适用场景和应用范例 总结2
  • 3. 关于 NoSQL 一种数据库 不是文件 (通常)OLTP 非关系型的数据库 没有严格的schema (通常)没有join 更好的性能和扩展性 3Row Key Value
  • 4. NoSQL is about Choice.Jan Lehnardt, CouchDB
  • 5. NoSQL: Why扩展性 并发度 新趋势5
  • 6. 数据发展趋势数据量爆炸式增长6数据关系愈加复杂数据结构多样化应用结构分布化
  • 7. Scale Up vs Scale Out7PerformancePerformanceScale UpScale Out
  • 8. 传统关系数据库的应对方案缓存: 缓解读压力 内存hold住热数据 读写分离Master-Slave Master写入瓶颈 Slave复制延时 集群共享存储 Share everything 表分区 数据库分区 Share nothing8数据量与事务的增长 严重影响DB响应时间http://www.codefutures.com/database-sharding/
  • 9. 关系数据库的困难数据结构严格定义 扩展性 扩展读,困难 扩展写,基本不可能 当你这么做的时候,它通常已经不是关系数据库了 分表分库 手工拆分操作复杂,需要停服 拆分牺牲了关系:跨库join 成本 9
  • 10. ACID VS BASEAtomic Consistent Isolation Durability10Basically Available 支持分区失败 Soft state 无连接的软状态 Eventually consistent 最终一致 退一步海阔天空 Welcome to NoSQL严格一致是影响扩展性的关键瓶颈
  • 11. NoSQL What基本原理 核心技术 产品分类11
  • 12. CAP理论分布式系统的数据分片不可避免 P为必选 一致性和100%的可用性不可兼得 比如,网络坏了,DB不能用了 DB宕机 数据不一致 AP型系统 MySQL主从 CP型系统 OracleRAC 12Of the three properties of shared-data systems - data consistency, system availability, and tolerance to network partitions - only two can be achieved at any given time. -- Eric Brewer, 2000Consistency 一致性Availability 可用性Partitions 分布性√一致性和可用性,二者选其一
  • 13. 13
  • 14. NoSQL产品分类14种类原理数据模型典型产品Key-ValueAmazon Dynamo 论文键值对Voldmort,RedisColumn-FamilyGoogle Bigtable 论文列、列族Hbase,CassandraDocumentLotus Notes键值对的集合的集合MongoDBGraphic图论
  • 15. Key-Value15种类原理数据模型典型产品Key-ValueAmazon Dynamo 论文键值对Voldmort,RedisColumn-FamilyGoogle Bigtable 论文列、列族Hbase,CassandraDocumentLotus Notes键值对的集合的集合MongoDBGraphic图论
  • 16. Dynamo一致性 Eventually Consistence 最终一致 Read Repair 读修复 分布性 Consistent Hashing 一致性哈希 可用性 Gossip Protocol P2P通讯 Hinted Handoffs 写入转移16Amazon‘s highly available key-value store, 2007 如何构建一个分布式的哈希表
  • 17. 一致性:最终一致最终一致 与可用性权衡的结果 如果系统确保一定的时间不做任何变更,最终所有的查询都会返回相同的最新值17多个节点上的数据副本
  • 18. 一致性:Qurom可定制的一致性模型 18N — 数据复制的份数 W — 更新数据是需要保证写完成的节点数 R — 读取数据的时候需要读取的节点数W+R>N,写的节点和读的节点重叠,则是强一致性 W+R<=N,则是弱一致性
  • 19. 一致性:读修复每次读取时都读取所有的副本 只返回一个副本的数据 对所有副本应用Checksum或Timestamp校验 如果存在不一致 取出所有的数据并做合并 将最新的数据写回到不同步(out of sync)的节点 19
  • 20. 分布性:一致性Hash普通Hash partion = key % n_servers partion = key % (n_servers + 1) 增减节点会改变所有key的分布策略 一致性Hash20节点A~B之间的所有key写入B只有A~B之间的key受影响节点B挂掉, 节点A~C之间的所有key写入C
  • 21. 分布性:一致性Hash一致性Hash的负载均衡 21整个环分成Q等分 S个节点 每个节点对应Q/S个虚拟节点 Q>>S
  • 22. 可用性:GossipGossip:流言蜚语 无须中间节点 每隔一段时间,一个节点就会随便找一个曾经有过通信的节点与其交换一下其它节点的健康状态。 Hinted Handoff 如果负责某个key值的某个节点宕机了,另一个节点会被选择作为其临时切换点,以临时保存在故障节点上面的写操作。这些写操作被单独保存起来,直到故障节点恢复正常,临时节点会把这些写操作重新迁移给刚刚恢复的节点 22
  • 23. Voldmort典型的Dynamo实现23多种序列化方式Json, Thrift, Avro, Protobuf可配置的持久化存储:BDB,MySQLJAVAAPK-V
  • 24. Redis列表数据结构 Map, Set, Sorted Set, Linked List 高性能:10-100k ops (内存Hold住数据) 主从复制,客户端实现一致性哈希 应用 小数据(与内存匹配,或容易分片),极高IOPS 缓存 消息队列24列表操作计数发布-订阅ANSI CCPK-V
  • 25. Column-Based25种类原理数据模型典型产品Key-ValueAmazon Dynamo 论文键值对Voldmort,RedisColumn-FamilyGoogle Bigtable 论文列、列族Hbase,CassandraDocumentLotus Notes键值对的集合的集合MongoDBGraphic图论
  • 26. Big Table数据结构:列式存储 26A distributed storage system for structured data, 2006 如何在GFS上构建一个分布式的数据库基于列的访问,性能高 对稀疏数据,空间利用率高
  • 27. LSM Tree普通索引 B+ Tree 有序索引 插入新记录时改写leaf 大量随机写:压力很大27LSM Tree Log Structure Merge 先写内存,定期刷到磁盘 Write Ahead Log WriteReadMemoryFile1File2FileNDISK定期刷写后台归并Disk LogP.E.O'Neil,E.Cheng,D.Gawlick,andE.J.O'Neil.Thelog-structuredmerge-tree (LSM-tree).ActaInformatica.1996.磁盘顺序写:100MB/s, 磁盘随机写:10ms/次, 100次/秒 内存当硬盘用,硬盘当磁带用
  • 28. Big Table 读写28分布式 文件系统SSTable内部 记录顺序排列持久化
  • 29. Big Table 读写Create: 新记录写入memtable Read: 先读memtable,再找相应的sstable Update: 新版本写入memtable Delete: 删除标记写入memtable Minor Compact 小SSTable合并成大的 Major Compact 处理多个版本 (MaxVersion) 处理生命时间(TTL) 处理删除标记 29A Tablet
  • 30. Big Table 构架30包含多个Tablet
  • 31. HBase31分布式协调服务 HMaster高可用 Client连接高可用持久化依赖HDFS客户端直接访问 数据节点Name Node单点故障JAVACPColumn
  • 32. CassandraBig Table 列式数据模型 SSTable存储结构 Dynamo 复制模式:可定制的一致性模型 分布式结构:一致性Hash,Gossip P2P 32JAVAAPColumn
  • 33. Cassandra33适用场景 大量数据,高IOPS rowkey随机分布基于本地磁盘Bloom Filter筛选
  • 34. Document-Based34种类原理数据模型典型产品Key-ValueAmazon Dynamo 论文键值对Voldmort,RedisColumn-FamilyGoogle Bigtable 论文列、列族Hbase,CassandraDocumentLotus Notes键值对的集合的集合MongoDBGraphic图论
  • 35. MongoDB数据结构:B-Json35C++CPDoc适用场景:平滑MySQL替代 写入>> MySQL,带索引的读 ≈ MySQL,无索引的读 > MySQL自动分片 自动主从复制 自动故障恢复 B+Tree 多列二级索引 Group By Map ReduceReplica Set PrimarySecondaryArbitrary保存系统元数据 任意一台宕机 即变只读客户端路由 无持久化状态 信息从config获得Chunk
  • 36. NoSQL When性能 vs 扩展性 响应时间 vs 吞吐量 一致性 vs 可用性36
  • 37. 我的应用程序慢在哪里?37一个用户访问就很慢大量用户访问才会慢性能问题扩展性问题响应时间吞吐量在可接受的响应时间内 追求最大吞吐量
  • 38. NoSQL or not数据量 超过一台机器的处理能力 迅速增长 数据模型 schema易变 反范式,避免join rowkey:顺序,随机,组合rowkey 访问模式 读>写,写>读 事务 查询条件,聚合 现实考虑 业务需求 技术团队:解决未知问题,运维实力 产品成熟度:大企业支持,更新频率,社区 38
  • 39. 产品选型一致性要求高 CP型系统 注意提高主节点的可靠性 可用性要求高 AP型系统 数据量不太大,并发要求高 Redis, LevelDB 离不开MySQL,又需要扩展性 MongoDB 39
  • 40. NoSQL @pwrdHBase40
  • 41. HBase 特性高吞吐 写入为纯内存操作,写快于读 Rowkey有序排列,顺序读取性能高 随机读 内置Block Cache 强一致性 行级事务 原子的读-修改-写入操作 高可用 基于HDFS 单个数据节点损坏,数据不会丢,服务不会停 易扩展 在线增加节点 扩容,提高性能 41
  • 42. HBase 性能指标42
  • 43. HBase 适用场景大量数据,高并发随机查询 Facebook: 收件箱 Alipay: 交易记录 海量数据,低并发区段查询 Facebook:实时ETL StumbleUpon:ODS Trend Micro:日志存储查询 实时统计 Facebook:分享插件统计 StumbleUpon:广告平台43原子计数器 高并发写入内存Hold住热数据 水平扩展以提高性能日志数据有序存储 水平扩展以提高容量
  • 44. 用户登录日志查询44KEYLrsxopuseridlogtimegameidactionidroleidgroupnamelineidperiodpeerintintbytebyteintintbyteintbyte[4]441144144数据结构每天2200万条记录 入库时间1分钟 查询时间20ms
  • 45. 用户角色信息查询按userid查询玩过的所有角色 按userid,roleid查询角色信息(chardata) 等级、经验、金钱等 可查变化历史 不变的记录不占空间45KEYSVnsorlemuseridgameidroleidlogtimenamegroupnameoccupationracelevexpmoneyallintbyteintintstrintshortshortshortlongint4244422284数据结构快照时间准静态列族常变列族
  • 46. BI系统中的NoSQL游戏Log注册充值广告渠道客服……接口层采集与格式化Oracle RAC 集群Hadoop 集群HBase 集群加载数据仓库调度模块监控模块校验模块WEB 报表多维 分析短彩信与邮件ad hoc 接口数据 推送Android与iOS 客户端规则 预警自助 分析 处理游戏 Log 多维 检索数据挖掘 模块备份与恢复
  • 47. 47日志多维检索原型设计日志源Kafka持久化消息队列RAM MQDISK MQHBase ClusterSolr CloudNode1shard1shard2Node2shard2shard3Node3shard1shard3Solr ManagerRegion Server 1Region Server 2Region Server 3HBase Master查 询 应 用复杂条件 查询统计Key查询ZOOKEEPER 分布式协调管理
  • 48. 总结48
  • 49. NoSQL的核心特征牺牲部分关系型数据库的特性 关系模型 数据的一致性 查询的通用性 解决关系型数据库不能解决的问题 扩展性:分布式处理存储和读写压力 可靠性:多个数据副本,自动故障恢复 免费,开源49
  • 50. 结语不是传说 我的数据库很慢,换NoSQL就好了 也不是历史的倒退 NoSQL真弱,join都不支持 NoSQL是一种抉择。50
  • 51. NoSQL is about Choice.
  • 52. And so is Life.
  • 53. 参考资料NoSQL Databases: Why, what and when, http://www.slideshare.net/quipo/nosql-databases-why-what-and-when Scalability, Availability & Stability Patterns, http://www.slideshare.net/jboner/scalability-availability-stability-patterns NoSQL 生态系统 http://blog.nosqlfan.com/html/2171.html Designs, Lessons and Advice from Building Large Distributed Systems, http://norvig.com/21-days.html, Jeff Dean: dean-keynote-ladis2009.pdf http://www.slideshare.net/guestdfd1ec/design-patterns-for-distributed-nonrelational-databases http://www.slideshare.net/jbellis/what-every-developer-should-know-about-database-scalability http://www.slideshare.net/pavlobaron/big-data-nosql-efs11-pavlo-baron http://www.slideshare.net/marin_dimitrov/nosql-databases-3584443 http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores 吃蟹,视觉中国MongoDB应用实践,http://www.slideshare.net/iammutex/mongodb-7569240 http://bjclark.me/2009/08/nosql-if-only-it-was-that-easy/ http://www.datastax.com/2011/10/are-nosql-databases-now-mainstream http://www.slideshare.net/jbellis/cassandra-open-source-bigtable-dynamo 53
  • 54. 54Numbers Everyone Should KnowL1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns Mutex lock/unlock 25 ns Main memory reference 100 ns Compress 1K bytes with Zippy 3,000 ns Send 2K bytes over 1 Gbps network 20,000 ns Read 1 MB sequentially from memory 250,000 ns Round trip within same datacenter 500,000 ns Disk seek 10,000,000 ns Read 1 MB sequentially from disk 20,000,000 ns Send packet CA->Netherlands->CA 150,000,000 nsTHANKS.