云计算环境下关系数据库的思考

在内存即硬盘的时代，在普通服务器就可拥有4核或者8核的多线程时代，随着NOSQL数据库的大规模应用，不仅要思考一个问题，显然，NOSQL在很多方面还不能完全取代传统的关系数据库RDBMS，现有的基于关系数据库的应用要移植到云计算环境中，是改变程序适应NOSQL数据库，还是改造现有的关系数据库以适应云计算环境？目前看来，前者似乎更加可行，而这里思考的是后者！关系数据库难以横向扩展，主要的瓶颈在文件系统，数据库的数据存储在文件系统上，对数据库表的修改，添加，删除，都需要对文件系统进行操作，在关系数据库兴起的时候，很难想象关系数据库会把同一个表的数据存在多个服务器上，目前关系数据库的扩展主要是通过分表和分区等技术，而在云计算领域，设想一种理想的情况，云计算的文件系统是分布式透明的N个节点的服务器，关系数据库对文件系统的操作是通过分布式的文件系统来进行的，一个表的数据存放按照记录分布在多个节点，查询，join等所有数据库的底层操作使用MapReduce进行任务的分配，这要比目前的分区和分表等技术对用户来说更为透明，而这和分表等技术原理上相同，只不过是数据库底层提供了实现，对用户来讲没有任何改变。

能不能实现不是这里考虑的重点，重点是如果能够实现将极大的减少传统程序向云计算领域迁移的成本，使用过Google App Engine的同学都知道，写个App需要用特定的API，即使提供有传统的JPA接口，也有不少功能不支持，现有的应用不经过大规模的修改是难以部署到GAE上的。

改造的难点有一部分取决于数据库文件的保存方式，不少数据库文件是单个文件，所有的表在一个文件，有的数据库则是多个文件，每个表一个文件，个人感觉后一种数据库保存方式改造起来更容易，可将数据库的表按照记录的索引到达一定限度分开保存在多个节点，查询，删除，修改行记录的实现都要改变以适应多个节点，而插入恰恰是开销最小，只需要找到最后一个节点就可，而查询的功能可通过缓存行记录到内存得到有效的改善！

改造的另外一个难点是需要一个能够和这种操作相适应的分布式的文件系统，而这种文件系统是可随机访问和修改的，以后再谈关于这个文件系统的思考。

至于这样的关系数据库能不能实现，希望自己能做这方面的尝试，已经选好了数据库，改造方面的工作还是挺大的！