细化解析web2.0与数据库之间的四点启示

导读：
　　一：专业数据库太贵，Web2.0通常承担不起
　　web2.0在承担数据管理任务的同时也要花很少的钱才行，web2.0应用通常是个人或者一个小组织建立起来的，大量的数据需要很大的cluster支撑，这个预算太高了。Second Life的数据库后端设计人员就说，他们早期使用One Cluster All Hail The Central Cluster，而最后这个大家伙不能完成数据任务而重新构建了集群。
　　Second Life的这个教训就是我们需要像日常用品的数据库，database as commodity，要便宜要实用。所以，可以想象MySQL应该是赚到了不少吧。其实，就连Google也应该负担不起这样的解决方案吧，使用超大的服务器和专业软件来对数据进行管理，当然适合不适合也是很重要的一个问题。但是Google也都会选择构建GFS和BigTable，并在此基础上对数据进行管理和构建web应用，因为他们可以使用大量的廉价PC。另外一点就是大量的数据具有更好的并行处理特性，工作非常类似于并行向量机模型，所以也就有了Map and Reduce。
　　二：“Flat files are not going to cut it”
　　平面文件并没有打算停止。并不是所有的web2.0 apps都选择数据库作为中心的数据管理和存储方案，flat files也有他自身的特点，尤其是对于一些只读操作。可以理解Google就是使用Flat files的。Bloglines的主力存储也是使用的flat files，“自从Bloglines上线以来，一直存档的14亿篇博客post，我们都存储在自己写的存储系统中，整个系统就是建立在flat files基础上，并且在多台机器中存有备份，非常类似于在GFS论文中描述的架构”。
　　Bloglines仅仅有少量的数据是存储在传统关系型数据库之中的，比如用户的基本信息，用户的订阅信息，Feed的基本信息等，而核心的海量的文章信息和结构都是存储在flat files中，然后尽力发挥memcached的功效，尽可能的把东西都放到内存当中。他说他们也可以使用Oracle，并建立一个巨大的SAN，但是将会耗费他们巨大的预算，包括硬件和软件的license。
　　三：有点不Fit
　　O'Reillay问Flickr的作者这样一个问题，“你是怎么把Tag分类学模型同传统数据库结合起来的，你如何管理tag云呢？”Flickr的作者说，“web2.0的很多特性都不能够很好的同传统数据库的规格化scheme设计融合在一起，通常，反规格化（是数据库里面讲的范型设计吗？），还有heavy caching才是能够在微秒级获得几千万tag云结果的措施。
　　你可以缓存那些很慢生成的视图或者结果，但是有时候他们太慢被生成，以至于每次重新生成这些缓冲结果的时候不得不完全霸占工作中的数据库服务器，这是不能容忍的。所以，需要特别专门的服务器来生成这些视图，我们一些数据视图都是一些服务器offline工作进行计算的”。确实，很多web2.0需要强大的数据来描述一些不同维度上的数据，比如数据全局的数据、上下文关系的数据等等等等。
　　将数据进行分割，Heavy Caching
　　O'Reillay谈到了在数据这方面的一些通用设计模式。很多人认为flat files不能够满足扩展性，而他却不这么认为。相反，他看到很多大的网站都在采用flat files来进行数据存储。他觉得发展的趋势不是从flat files到数据库，而是从flat files到成熟的自定义文件系统。
　　SQL的供应商们貌似没人能够解决这个问题，而也完全没有能解决这个问题的任何方案出现。很明显的是，目前也没有人在全文方面能够做好，像Lucene那种方式——‘把这些都搞进来，然后希望你能够找到他（shove all in, hope you can find it），也并不是很合适。上下文关系的环境是我们需要的，但是没有看到任何的数据库供应商能够解决这个问题。技术在这里，但是没有看到任何人能够找到可以使之工作的公共语言。

本文转自
http://tech.163.com/07/0822/10/3MGC01KC0009158K.html