2010数据库技术大会

2010年4月2日-3日，我们整个team参加了由IT168主办的2010数据库技术大会。我做了6年的Web前端，这是第一次参加大型的数据库会议，虽然大家都觉得本次大会内容深度不够，但对于我而言，仍然获益匪浅。

本次大会的核心议题就是高可用性。从传统的单主机应用到现在的大规模互联网应用，数据规模越来越大，单节点高性能主机的scale up扩展方式价格昂贵且扩展不便。基于大量普通PC服务器的scale out的分布式解决方案应运而生。主要的方案有：

1、读写分离
采用一个主库，多个读库的方式，提高了大量读取的可扩展和可靠性，弥补了普通PC服务器稳定性差的弱点。

2、共享存储 
多PC server + NAS网络存储的方式降低了主机成本，提高存储扩展性。

3、完全拆分
根据业务拆分成不同的单点，每个单点有自己的主从备份，单点之间shared nothing。这是成本最低的方案之一。

我们公司的数据库早已实现按照不同系统的垂直分割，将整个系统的压力划分到不同的子系统。对于单一系统的水平分割，跨数据中心的sharding也正在当前的项目中逐渐变为现实。我们的整体架构来看，我们在业界也是领先的。面向企业用户的定位，是我们和淘宝，Twitter这样的面向整个互联网提供服务的主要不同。数百万和数亿用户对系统的压力差别还是很大的。在互联网上，一人贡献，百人分享，即一人写百人读，这时读写分离的架构就可以提供很高的并发访问支持。我们的核心业务是在线会议，而且每分钟的会议都是要收费的，对于这样的实时性和一致性要求很高的数据，还是要用单一数据库更可靠。

磁盘技术的发展缓慢和内存价格的快速下滑，使得内存数据库和Key-Value成为大小数据库架构中的重要组成部分，性能提升非常明显。主要的适用场景是大量读取的结果缓存，减少对物理磁盘的访问；将复杂的查询预处理并缓存，降低系统实施计算和查询的压力；主要用与非核心数据，即便丢失也可以重新计算生成。

Tokyo Cabinet是个非常有意思的Key-Value实现。和Cassandra相比，TCTDB可以根据“字段”——相当于Cassandra中的column——检索出符合条件的key。支持运算符，可以对字段索引和排序，使得Key-Value的功能大大增强。不过索引只支持字符类型以及性能的下降又是需要在具体应用中取舍了。

列式数据库和CEP。我还是第一次听说这样的数据库产品。结合华尔街算法交易的案例介绍，使我感受到了列式数据库在海量数据分析中的优势。以列存储和读取的方式，当需要对于特定列数据进行分析的时候，自然比行读取的方式要高效。感觉列数据库很适合做索引，查询特定的条件返回rowid，通过rowid再去寻找行数据库中的数据。用水管来描述CEP很形象，也很好理解。CEP名为负责事件处理，是一种实时数据分析处理工具，数据“流过”CEP的时候即完成了过滤和分析。要分析的数据是按照时间划分的，可以根据时间来设定“水管”的长度，时间段越长，数据量越大，CEP的效率越低。

空间换时间是为了提高性能的常用方案。scale out，冗余存储可以将数据分散，降低集中读取的压力；预先计算可以将可预知的计算结果保存，减少实施计算压力；

Oracle收购Sun后，果然出硬件了。Exadata就是一款数据库与主机结合的硬件产品。将软硬件打包销售，一直都是厂商的有效销售方式之一，可以减少安装复杂度，维护成本。在数据库领域这样的打包销售恐怕还是头一回。而在Oracle高大形象下，MySQL依然平民，免费，易于部署和高性能都是吸引众多中小应用的关键。不过MySQL在对于分布式支持方面较弱，MySQL cluster的性能仍然不能满足较高的应用需求。

面对众多的日益复杂的数据库架构，DDL是今后数据库解决方案中的重要一环。将整个架构对应用透明，支持异构数据库的统一访问，数据路由，缓存等等都值得研究。

最后感叹一下计算机行业的发展，数据库本身只是计算机行业的众多方面之一，而这其中居然又包含了如此繁多复杂的技术和分支，对于技术人员来说，真的是学海无涯苦作舟啊，今后仍需继续努力刻苦学习。