mysql,Linux,HighPerformance,ruby on Rails

2010年1月24日星期日

保持简单即最优-Mysql的部署原则

建议在考虑此方案时一定要三思。为什么?参考这里 Kiss KISS KISS. 其实Schema-Less没有错,但不能什么场景都上此方案,要
分析利弊,减少不必要的应用层复杂度。
文中提到的Serialized objects的保存技术,就是(entity-attribute-value) EAV, 说一下总结的缺点:
1.它对搜索不友好(都压缩存在一字段里,肯定不能搜索),这确实是一个问题。FriendFeed使用变相index,解决了它需要解决的问题。但只能是规避。
2.Select精确选择字段是不成了,每次都是SELECT * FROM xx,当然使用Memcache可以很少的解决此问题。
3.不能加约束(constraints),应用层需要作校验,其实就是增加了数据层的复杂库。
4.如果使用Json,不能使用Number和IP的原始形式存储,必须转换成String。这点好像不是那么重要,因为我们可以使用的文本协议有很多。比如Google的
protobuf

其实最重要的原则在Kiss KISS KISS中已经说的很清楚。对于刚开始的应用,使用Master-slaver足以。不要使用什么"优化",那些
其实就是"扯淡"。对于Scaling out方案更是应该简单有效为主,说白了,对于Mysql而言,一台Master及一台或几台slaver就是"最佳方案"。

--
tommy xiao
E-mail: xiaods(AT)gmail.com

没有评论:

发表评论