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