在整个珠三角地区，商业气氛很浓厚，但是知识分享却相当的的落后，比起北京，上海，杭州等城市，算是落后了一个等级。这次由杨老师（@xmpp）组织的技术分享活动是难得的交流机会，由于对分布式存储有着浓厚的兴趣，周末就跑到广州去学习一下。

我们从别人的设计中主要获取的是思想，同时结合自己的应用来做相关的系统架构设计，Last.fm的Richard Jones写过一篇文章《反对关系数据库----一些分布式key/value数据存储系统比较》，中间阐述了各类分布式开源的key/value存储的系统的对比，给出了一些建议。但是更多的我们可以从大型应用的设计思想中获取养分，商业分布式key/value store主要有：

• Dynamo (Amazon)

• Cassandra (facebook)

• Voldemort (LinkedIn)

• PNUTS (Yahoo)

• Bigtable (Google)

• HyperTable(Baidu)

在实际的工作中，我们或许更关注key/value store，杨老师就 Berkeley db - memcachedb， Tokyo cabinet - Tyrant ， Redis做了相关的测试（单线程跑的），虽然Redis力克群雄，但是似乎内存占用太高，而且不合理的配置会导致系统的不稳定性，推荐使用Tokyo cabinet（Tokyo Cabinet是日本人 Mikio Hirabayashi开发的一款 DBM 数据库，该数据库读写非常快，哈希模式写入100万条数据只需0.643秒，读取100万条数据只需0.773秒，是 Berkeley DB 等 DBM 的几倍。Tokyo Cabinet 是一个DBM的实现。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列,既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念）

如果想获取更多的，点击这里观看杨老师的PPT大作。当然，免不了要说一下自己的收获。

1：互联网应用和电信应用的架构差别。在CAP理论（Consistency(一致性),Availability(可用性), Partition tolerance(分布) 三部分在系统实现只可同时满足二点，没法三者兼顾）中，互联网强调了可用性和分布，而电信，银行业强调了一致性和分布。而且电信业的系统架构强调了应对业务逻辑的变化，所以工作流，规则引擎可以派上大用场，而在互联网的应用架构中，业务逻辑的变化较少，强调减少用户等待时间。

2：关系数据库在电信行业不可或缺。由于业务的复杂性导致数据模型的复杂，所以电信系统的数据存储对关系数据库的依赖不会像互联网那样逐渐弱化，数据库的设计的好坏将对电信企业的系统稳定性和可用性产生很大的影响。Oracle DBA在电信行业是一个受欢迎的职业。

当然，赖勇浩的《选好业务与技术，单枪匹马做游戏》也相当不错，关注游戏开发比较少，就不写感受让人贻笑大方了。通过线下交流，除了收获知识外，还认识了一帮技术人员，感谢杨老师，感谢sina。