一周技术文档分享
Posted in other on 二月 11th, 2010 by kafka0102
1、SYNCHRONIZING DATABASES IN DIFFERENT GEOGRAPHIC LOCATIONS
翻出很久之前的一篇文章，该文提出了跨地域同步数据的问题。就Mysql来说，如果数据需要在两个地域传输，使用双主复制模式是较为简单的方法。如果mysql能支持多主复制模式，多地域的数据复制或许就解决了。但多主复制很难搞，这种多点并发复制很难自动化的处理提交冲突的问题。
2、LinkedIn Search: A Look Beneath the Hood
http://thenoisychannel.com/2010/01/31/linkedin-search-a-look-beneath-the-hood/#
这篇揭示LinkedIn的检索系统PPT很不错，尽管我对检索了解不多。对检索结果，LinkedIn没有采用通常的cache方式，而是重新计算。Cache检索结果的好处是提高性能，但无法保证cache数据的真实性，而LinkedIn期望每一次的检索结果都是准确的数据。LinkedIn采用数据库分区、大内存缓存DB数据的方式提高DB查询效率，以至于像双向好友关系也是实时查询的。LinkedIn对Lucene打的实时检索补丁，也很值得研究。
http://developers.facebook.com/news.php?blog=1&story=358
Facebook爆出的HipHop对PHP社区绝对是爆炸性的消息，如果它开源的话，估计会被众多公司研究和采用。HipHop原理是将PHP代码翻译成C++代码，再编译成二进制程序执行。这一方式和LiteXml类似，都是为了克服脚本语言解释过程的低性能，而在生产环境迂回成编译性程序执行。不过，HipHop会因为C++语言的限制而失掉一些PHP语法功能，尽管不是很重要的说。我倒是很期望PHP能做成虚拟机，不失开发效率，也一样能提高解释执行的性能。
4、HOW FARMVILLE SCALES TO HARVEST 75 MILLION PLAYERS A MONTH
该文分享了一个social game的技术经验，但没有什么太细节的东西。只有最后大众化的LESSONS LEARNED可以汇总下：
1）对于写多读少的social game，采用in-memory架构，异步提交数据是王道。
2）系统内的组件间低耦合，即便某个组件挂掉，也不会完全影响整个系统的使用。当系统出现性能等问题时，可以关闭一些不必要的功能来缓解问题。
3）缓存Facebook的数据。
4）对新功能做好性能预估及应对方案。
5）抽样部分数据来做分析。
5、When should you store serialized objects in the database?
Peter的文章总会跟来一堆人的争论。Peter反对在mysql中使用无模式的blob字段，它给出的理由主要有：
1）查询时需要获取整个数据，即便只需要其中部分。
3）blob字段在更新时需要复制的数据更大，并且非定长会造成数据碎片。
3）如MIN, MAX, AVG函数不能使用。
4）blob字段内容没有类型约束检查，需要程序保证，这可能带来潜在的问题。
以用户信息这样的数据类型来说，它的典型特点是：1）一个id对应着一堆属性信息。2）需要针对属性字段做查询条件。这种情况的最简单的做法是，建立一张多属性的schema表和一堆属性索引，但这会带来属性查询的低性能。所以，像FriendFeed、Twitter等，是将属性数据和索引分开。在此基础上，问题只是属性数据的存储是要还是不要schema。如果要schema，peter提到的问题都不是问题，但也带来新的问题：1）属性增加需要修改表结构，这是很折腾人的事情。2）如果属性很多，表结构需要的列数会很多，一个解决方法是，可以将属性分成几类分别存储。实际上，如果在mysql前面有cache（或者Mysql自己的cache够大）来缓存主用户信息，而更新又不是很频繁，blob存储是没什么太大问题的。
=============================== 华丽的终止符 ================================
相关日志
Leave a Comment
