采取什么架构或者方法可以保证在海量数据情况下数据库系统的可用性，可靠性以及可扩展性？我在想：
1、如果采用主从设置/读写分离，可用性/可靠性/可扩展性都会得到提升，但是如果数据量很大，会存在数据同步以及单个数据库容量太大问题，最终也会影响数据库操作，也就说这种方式对数据库容量问题提升有限，遇到海量数据就会无能为力。
2、如果采用库表散列，数据库容量方面的瓶颈会得到有效解决，但可扩展性不太理想，每次分库都会将原来数据重新部署一次，如果数据库服务器太多，那么维护工作量将很大。而且分库并不能有效平衡数据库负载，可能有些服务器负载很大，有些却很小。
3、如果在数据库前端采用负载均衡，与1遇到的问题一样，还是容量问题。

那么到底采用什么方式/架构才能有效解决数据库容量与可用性/可靠性以及可扩展性呢？想看看各位，尤其是”混“在各种大型网站同仁的看法。希望大家不要认为我太唐突哟！

打签静坐高手指点，仅仅了解到我们这边是F5负载，读写库分离，优化查询算法，再详细的我去问问DBA，看他们怎么搞的。

这方面不了解，建议楼主到http://www.blogjava.net/BlueDavy/archive/2008/09/03/226749.html看看

这个是比较经典的了，基本上也是采用读写分离，库表散列以及负载均衡等技术。
可库表散列虽对容量可扩展较好，但可维护性/可靠性不太好，另外还有可能会有负载不均。
而读写分离/负载均衡虽然可靠性，为维护性都较强，但需要数据同步，而且最关键容量不太好扩展。

所以我特别想知道各位是如何同时兼顾容量扩展与可维护性的？

BigTable or Datastore

单就数据库的实现来说，扩展性能的方式，有几种：

NoSQL 方式，各种类型的NoSQL DB 软件各有千秋，但总之NoSQL 是一种潮流，容量受制于内存总量，但可用。

CSQL 方式的扩容或者 mysql 上sockethandler的方式加速，CSQL 是一种架设在DB 上层的应用，双向对等cache，好象稳定性有点问题，但还是可以的。商业的软件EMC的green-plum 数据库，看上去好象是个memcached+postgresql实现。Voltdb, Postgresql 的另类版本？不太懂。

各种不同BigTable 实现，包括taobao 的OB 开源数据库，或者各种基于Hadoop 的实现，这些类型有业务针对性的，选择慎重。

还有可能的方式包括sockimgrate方式的加速，应该可行。

具体来说，还是要有业务需求，针对性分析，基本测试，然后才能决定，现在的世道不象10年前，随便拉个开源的关系型数据库就能对付业务了。

嘿，这正是我要的！楼上的真是“及时雨"啊！

NoSQL 通常受制于 内存大小， 虽然可以通过增加机器的方式扩容， 可总还是有限制的。

很多NoSQL 的实现，都是提供的K-V模式的数据，mongodb的documnet模式例外，要深入研究再决定。

毕竟NoSQL 2009 以后才热起来的；