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