常用开源NoSQL原理与应用田琪（@摇摆巴赫）Agenda深入理解Redis.ppt

常用开源NoSQL原理与应用 田琪（@摇摆巴赫） Agenda 深入理解Redis Hash算法数据库介绍 LSM算法数据库介绍 HandlerSocket介绍 分布式数据库介绍 Why NoSQL? 关系数据库的问题 大数据的产生 存储需求的多样性 云时代的来临 深入理解Redis 一个更加强大的Memcached memcached场景与局限 只能做cache,不能做storage 没有数据结构支持 数据局部踢出现象 cache与存储资源访问能力落差 不能枚举全数据 访问性能仍有提升空间 redis 概述 a disk backed in-memory database 高性能网络接口 + 数据结构集合 redis 特点 key - structure 类型存储 支持数据可靠存储及落地 支持复制（cluster版本在开发） 单进程单线程高性能服务器 crash safe recovery slow 缺少内存管理算法，依赖第三方库 单机qps可以达到 10W (cpu是瓶颈) redis 数据类型 string hash list set sorted set redis 持久化机制 snapshot save 参数 aof appendfsync 参数 vm vm is not the way to go for the future diskstore 传统b-tree redis 复制 实现机制 快照同步 存在的问题 无增量复制 slave表重建 redis缺陷与优化 持久化IO机制 复制机制 内存管理 线程模型 故障恢复时间 持久化问题 – buffer io 持久化问题 - fsync fsync非常耗时 单进程阻塞操作 快照与fsync同时进行 复制缺陷 内存管理 缺少高效内存管理 额外内存占用过多 针对特殊场景做优化 开放地址Hash redis 使用场景 需要key - structure复杂数据结构 需要数据可靠存储 需要极高的单机qps using RAM as the new disk Hash算法数据库 Hash存储结构更合适简单kv存储 tokyocabint（tchdb） 特点 包含hash/btree等多种存储类型kv tchdb适合小数据量高速读写访问 tchdb随机磁盘IO次数平均 tchdb使用mmap io tchdb qps 大约在6W左右 tchdb存储结构1 tchdb存储结构2 LSM算法数据库 硬件变革推动算法变革 leveldb特点 bigtable tablet实现 LSM Tree算法 写性能极其出色 读性能依赖数据热度 SSD设备友好，不会写入放大 嵌入式DB，需要自己实现Server 分布式auto sharding支持友好 写性能 50MB/s,读性能 6W/s leveldb 存储结构 leveldb 的问题与场景 读IO次数不确定 查询指定key对应数据不存在的开销非常大 缺少高效内存管理算法 需要根据业务特点平衡merge时间点 投入使用需要一定的开发量 适合有明显时间热点访问规律的系统 配合SSD使用表现极其出色 riak(bitcask) 特点 存储结构简单 LSM Hash算法 全部key存储在内存中 全部查询只有1次磁盘IO QPS 大约在4~5W左右 bitcask 存储结构 bitcask 问题与场景 全部key需要存储在内存中 recovery重启需要重新load所有key merge时机的选择 适合配合SSD使用 handlersocket特点 NoSQL接口访问MySQL(Innodb) 解决SQL解析，查询优化等CPU开销 插件安装无数据迁移成本 QPS 可以达到8W handlersocket结构 handlersocket问题与场景 配合DDL使用有严重问题 写性能差，比传统SQL接口还要慢 只能支持Row Based复制 性能优势建立在没有磁盘IO瓶颈基础上 分布式NoSQL介绍 无中心化方案 无中心节点 数据一致性Hash分布 NWR数据多点备份 Read repair Hinted Handoff Gossip节点管理 中心化方案 中心节点提供路由 中心节点维护节点信息 对外访问代理节点 总结 关系数据库是单机存储时代的产物 NoSQL更能满足不同存储需求的多样性 NoSQL是SQL的延伸而不是取代 混合存储方案时代已经来临 架构师要具备不同存储方案选择的能力 谢谢大家 QA * * *