关系型模型之父Edgar F. Codd，在1970年Communications of ACM 上发表了《大型共享数据库数据的关系模型》，成为了永恒的经典，关系模型的语义设计易于理解，语法上嵌套、闭环、完整，因此在数据库领域，关系模型普及与流行了数年之久。
在此之后，IT世界涌现了很多非常著名的RDBMS（关系型数据库系统），包括了Oracle、MySQL、SQLServer、DB2、PostgreSQL等。
1. 传统关系型数据库的分布式瓶颈
但是RDBMS的技术发展由于架构上的限制，遇到了很多问题，例如：关系模型的约束必须在设计前明确定义好属性，这就难以像很多NoSQL一样，具有灵活可变的模式，很难适应敏捷迭代的需要。
其实最难解决的一个问题，就是数据表的分布式化。
为什么会导致如此现象呢？
本质上，由于关系模型在前期设计上的强关联，导致表表之间的连接关系变得极为紧密。
例如：有一种比较普遍的业务场景中连接操作，通过A->B->C的关联查找，然而这种关联所形成的链，就将A、B、C紧密地捆绑在了一起。
那么这种紧密关系带来了什么问题呢？
那就是RDBMS在设计之初，很难去考虑到数据表在分布式网络环境中的通讯解耦设计，而只是单纯的数据表本地文件的IO扫描，而且在过去低带宽的网络环境中，模型关系的分布式化，更是难以想象。
如下图所示：
我们从上图可以看到，教师、学生和课程这三张表具有多对多的紧密关系（其中还有一些未展示的中间表），那么这种紧密的关系投射到具体的数据库物理文件上，就是图中多个物理上的表文件(Table Data)，当我们查询时，就是通过关系逻辑对这些表文件进行了频繁的IO扫描。
在这种模式下，我们会发现一个问题，这些表实际上很难跨数据库而分布式拆分，也就是说，RDBMS很难以分布式形式，把教师表放到服务器1的数据库1上，学生表放到服务器2的数据库2上，课程表放到服务器3的数据库3上。
而且更难做到的是：将1万名学生总共10万次课程活动所产生的学生上课数据分拆成10个1万条数据表，再将表分布在不同的数据库中。
如下图所示：
我们提出一个假设：如果能将学生课程活动表拆分到分布式网络中多个数据库实例当中，那么就极大地降低了单台数据库的负载。这对于访问量和数据量已经规模化的应用系统来说至关重要。
然而对于RDBMS来说，这种假设的目标实现是一件非常痛苦且困难的事情，例如：我们可以在网上搜索到大量关于MySQL分库分表的文章，这类文章的主题都是在对RDBMS进行分布式化的分区操作。
但是这种操作并非数据库天然所支持，必须组建专业的数据工程师团队，耗费大量的时间对数据库进行精密地调节，必须自己去解决分布式集群的诸多问题，例如：容错、复制、分区、一致性、分布式事务等等，其难度可想而知，所以这不是一般技术企业所能承担的巨大维护成本。
随着互联网时代的发展，互联网应用系统面向高并发、海量数据的规模化趋势愈演愈烈，RDBMS对于数据表进行分布式化的瓶颈也越来越明显，这也就促成了NoSQL在互联网等领域快速发展，接下来我们重点看看NoSQL的解决方案。
2. 中心化分布式架构的弊端
2.1 Hadoop分布式文件系统(HDFS)
谈到大数据领域的分布式数据库体系，必然绕不开Hadoop，Hadoop实际上是一个系统生态，基于Hadoop生态的各种分布式数据库都依赖于一个数据底座——HDFS，其实最早Google发明了GFS分布式文件系统之后，进行了论文发表，然后在开源界才产生了Hadoop分布式文件系统(HDFS)。
如下图所示：GFS/HDFS的特点表现在顺序的、成块的、无索引的向文件块中写入数据，并在集群环境中按块(block)均匀分布存储，需要使用时，再通过MapReduce、Spark这些批处理引擎发起并行任务，按块，批次地读取分析。这样就把写入和并行读取的性能发挥到了极致，具备了任何建立索引的数据库都无法比拟的读写速度。
HDFS在对多个数据节点(DataNode)协调写入数据的过程中，一定是由一个中心化的服务进行了全局调度，那就是NameNode节点。
也就是说NameNode节点会是一个单点风险，若出现了故障，整个HDFS分布式文件系统集群就会出现崩溃。
因此HDFS为了NameNode的高可用(HA)，实现了极为复杂的NameNode HA架构。
但是，在同一时刻，只可能有一个NameNode为所有数据的写入提供调度支撑，也就是说从并发负载的角度，NameNode始终会是一个瓶颈。
由于HDFS是整个Hadoop生态的数据底座，那么Hadoop的分布式架构就始终围绕在分布式中心化的路线上前进，然而中心化架构最大的问题就在于无论上层建筑如何变化，传导到数据底座后，HDFS作为中心管理者，一定会在高并发、大规模访问情况下成为瓶颈。
另外从集群节点的伸缩扩展方面也有隐患，问题来自于元数据在NameNode内存中可能会出现溢出。
2.2 大规模结构化的分布式数据库(HBase)
然而HDFS是面向成块的大文件数据，无索引地追加读写，也就不具有数据随机查找能力，另外缺少结构化设计机制，像集合的数据项扫描、统计和分析就无法独立支撑，必须构建上层数据库系统合作来完成，因此就产生了鼎鼎大名的HBase。
如下图所示：我们可以从图中看到HBase的数据底座完全依赖HDFS，也就是说数据如何物理上分布是由HDFS所决定。
HBase实现了全局排序的K-V模型，满足海量数据的存放条件下通过行键定位结果，能达到毫秒级响应的数据库，或者通过主键排序扫描实现了统计分组。
尽管HBase对于大规模结构化数据的写入、排序扫描和聚合分析有着巨大的性能优势，但是HBase的查找设计目标并不是解决二次索引的大范围查找。
我们再看HBase完成数据切分的办法——Region切分，当Region（我们可以理解为数据表）追加数据超出阀值后，就要进行Region拆分，然后拆分出的新Region分布到别的RegionServer中。
这里有两个问题：
1）同一时刻向Region写入新数据的服务器必须是唯一的，那么这里就会出现RegionServer的高并发访问瓶颈。
2）由于分布式架构设计上的约束，使得HBase不具有二级索引，在随机查找过程中，只能根据全局的Region排序进行扫描，这就无法承载Web应用的数据随机查找的实时性。
因此HBase一般会作为大规模数据流形式导入的OLAP系统。
