常用開源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版本在開發(fā)） 單進程單線程高性能服務器 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 傳統(tǒng) b-tree redis 復制 實現機制 快照同步 存在的問題 無增量復制 slave表重建 redis缺陷與優(yōu)化 持久化 IO機制 復制機制 內存管理 線程模型 故障恢復時間 持久化問題 buffer io 持久化問題 - fsync fsync非常耗時 單進程阻塞操作 快照與 fsync同時進行 復制缺陷 內存管理 缺少高效內存管理 額外內存占用過多 針對特殊場景做優(yōu)化 開放地址 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對應數據不存在的開銷非常大 缺少高效內存管理算法 需要根據業(yè)務特點平衡 merge時間點 投入使用需要一定的開發(fā)量 適合有明顯時間熱點訪問規(guī)律的系統(tǒng) 配合 SSD使用表現極其出色 riak(bitcask) 特點 存儲結構簡單 LSM Hash算法 全部 key存儲在內存中 全部查詢只有 1次磁盤 IO QPS 大約在 45W左右 bitcask 存儲結構 bitcask 問題與場景 全部 key需要存儲在內存中 recovery重啟需要重新 load所有 key merge時機的選擇 適合配合 SSD使用 handlersocket特點 NoSQL接口訪問 MySQL(Innodb) 解決 SQL解析，查詢優(yōu)化等 CPU開銷 插件安裝無數據遷移成本 QPS 可以達到 8W handlersocket結構 handlersocket問題與場景 配合 DDL使用有嚴重問題 寫性能差，比傳統(tǒng) SQL接口還要慢 只能支持 Row Based復制 性能優(yōu)勢建立在沒有磁盤 IO瓶頸基礎上 分布式 NoSQL介紹 無中心化方案 無中心節(jié)點 數據一致性 Hash分布 NWR數據多點備份 Read repair Hinted Handoff Gossip節(jié)點管理 中心化方案 中心節(jié)點提供路由 中心節(jié)點維護節(jié)點信息 對外訪問代理節(jié)點 總結 關系數據庫是單機存儲時代的產物 NoSQL更能滿足不同存儲需求的多樣性 NoSQL是 SQ