常用开源NoSQL原理与应用

常用开源 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 大约在 45W左右 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是 SQ