分布式Key Value Store.pdfVIP

分布式 Key Value Store 漫谈 V1.0 广州技术沙龙(09/08/08) Tim Yang / Agenda • Key value store 漫谈 – MySQL / Sharding / K/V store – K/V store性能比较 • Dynamo 原理及借鉴思想 – Consistent hashing – Quorum (NRW) – Vector clock – Virtual node • 其他话题 说明 • 不复述众所周知的资料 – 不是Key value store知识大全 • 详解值得讲解或有实践体会的观点 场景 • 假定场景为一IM系统，数据存储包括 – 1. 用户表(user) • {id, nickname, avatar, mood} – 2. 用户消息资料(vcard) • {id, nickname, gender, age, location…} – 好友表(roster) • {[id, subtype, nickname, avatar, remark],[id2,…],…} 单库单表时代 • 最初解决方案 – 单库单表, MySQL • 随着用户增长，将会出现的问题 – 查询压力过大 • 通常的解决方案 –MySQL replication及主从分离 单库单表时代 • 用户数会继续增大，超出单表写的负 载 • Web 2.0, UGC, UCD的趋势，写请求 增大，接近读请求 – 比如读feed, 会有 “like” 等交互需要写 • 单表数据库出现瓶颈，读写效率过低 分库分表时代 • 将用户按ID(或其他 字段)分片到不同数 据库 • 通常按取模算法 hash() mod n • 解决了读写压力问 题 但是，Shard ≠ 架构设计 • 架构及程序人员的精力消耗在 切分上 • 每一个新的项目都是重复劳动 不眠夜-resharding 通知：我们需要21:00-7:00停机维护 • 有办法避免吗？ Sharding framework • 框架，如hivedb – 隔离分库的逻辑 – 期望对程序透明，和单库方式编程 • 没有非常成功的框架 – 数据存储已经类似key/value – 期望用SQL方式来用，架构矛盾 • 框架之路也失败了，为什么？ 分库分表过时了 • 无需继续深入了解那些切分的奇巧淫技 • nosql! Key value时代 • 我们需要的是一个分布式，自扩展 的storage • Web应用数据都非常适合 key/value形式 –User, vcard, roster 数据 • {user_id: user_data} 百家争鸣 • Berkeley DB(C), MemcacheDB(C) • Bigtable, Hbase(Java), Hypertable(C++, baidu) • Cassandra(Java) • CouchDB(Erlang) • Dynamo(Java), Kai/Dynomite/E2dynamo(Erlang) • MongDB • PNUTS • Redis(C) • Tokyo