分布式图数据库

1. 数据库与hadoop与分布式文件系统的区别和联系

1. 用向外扩展代替向上扩展
扩展商用关系型数据库的代价是非常昂贵的。它们的设计更容易向上扩展。要运行一个更大
的数据库，就需要买一个更大的机器。事实上，往往会看到服务器厂商在市场上将其昂贵的高端机
标称为“数据库级的服务器”。不过有时可能需要处理更大的数据集，却找不到一个足够大的机器。
更重要的是，高端的机器对于许多应用并不经济。例如，性能4倍于标准PC的机器，其成本将大大
超过将同样的4台PC放在一个集群中。Hadoop的设计就是为了能够在商用PC集群上实现向外扩展
的架构。添加更多的资源，对于Hadoop集群就是增加更多的机器。一个Hadoop集群的标配是十至
数百台计算机。事实上，如果不是为了开发目的，没有理由在单个服务器上运行Hadoop。
2. 用键/值对代替关系表
关系数据库的一个基本原则是让数据按某种模式存放在具有关系型数据结构的表中。虽然关
系模型具有大量形式化的属性，但是许多当前的应用所处理的数据类型并不能很好地适合这个模
型。文本、图片和XML文件是最典型的例子。此外，大型数据集往往是非结构化或半结构化的。
Hadoop使用键/值对作为基本数据单元，可足够灵活地处理较少结构化的数据类型。在hadoop中，
数据的来源可以有任何形式，但最终会转化为键/值对以供处理。
3. 用函数式编程（MapRece）代替声明式查询（SQL ）
SQL 从根本上说是一个高级声明式语言。查询数据的手段是，声明想要的查询结果并让数据库引擎
判定如何获取数据。在MapRece中，实际的数据处理步骤是由你指定的，它很类似于SQL
引擎的一个执行计划。SQL 使用查询语句，而MapRece则使用脚本和代码。利用MapRece可
以用比SQL 查询更为一般化的数据处理方式。例如，你可以建立复杂的数据统计模型，或者改变
图像数据的格式。而SQL 就不能很好地适应这些任务。
4.
分布式文件系统（dfs）和分布式数据库都支持存入，取出和删除。但是分布式文件系统比较暴力，
可以当做key/value的存取。分布式数据库涉及精炼的数据，传统的分布式关系型数据库会定义数据元
组的schema，存入取出删除的粒度较小。
分布式文件系统现在比较出名的有GFS（未开源），HDFS（Hadoop distributed file system）。
分布式数据库现在出名的有Hbase，oceanbase。其中Hbase是基于HDFS，而oceanbase是自己内部
实现的分布式文件系统，在此也可以说分布式数据库以分布式文件系统做基础存储。

2. 这种分布式数据库应用，有没有现成的解决方案

很多公司都在开发自己的分布式数据库架构，且不少公司都可能使用上了，也有很多人在讲分布式数据库架构，这些是真正意义上的分布式数据库吗?
若要我加一个词的话, 我一般说伪分布式或者说所谓的分布式数据库架构，是跟陈国庆分享的NoSQL一样，只是起一个简单且好听点的名字，之所以谈这个话题，就是想与大家分享一下个人对伪分布式数据库架构的理解及所实践的。
PPT主要的内容主要有几点：什么是分布式数据库；什么是伪分布式数据库；分布式和伪分布式数据库架构的优缺点；伪分布式数据库架构适用的场景；二种伪分布式数据库架构的设计思路，一类适用于电子商务等领域，另外一类适合于SNS游戏等领域。
首先申明二个要点：第一点不支持分布式事务的，肯定不是分布式数据库；第二点分布式强调的是可用性、可靠性和数据一致性，其中数据一致性又分松散一致性和严密一致性，因为分布式数据库有不同的实现算法，为此数据一致性都有各种差异。
接下来，我们看一下分布式数据库的定义：由一组存储在网络中不同服务器上的数据组成，网络中每个节点具有独立执行局部应用的能力，也可以通过网络通信系统执行全局应用的能力。
为什么需要伪分布式数据库产品?是因为集中式数据库，当数据量越来越大，数据的读写量也越来越大，且无法通过垂直增加或升级硬件设备而满足的，以及越来越成为业务增长的瓶颈，那么我们就不得不考虑革新，采用一种更加有效、可行的方案解决。
伪分布式数据库的应用场景，稍微罗列了下：电子商务平台（C2C、B2B、B2C） 、SNS平台、IM即时通信软件、电子邮件系统、日志分析系统、SNS游戏、其他平台型网站。
大致总结了下，使用伪分布式数据库架构场景的三要素：
 大数据容量，且垂直升级扩展受限的；
 高并发事务型的；
 数据更新量远大于数据读取，且数据更新量非常大；
接下来我们看一下分布式数据库一个最独特的架构图，但是看之前，先了解下分布式数据库的四个是核心模块。我们把四个名词解释一下：
什么是局部数据库管理系统?
什么是全局数据库管理系统?
什么是全局数据字典?
什么是通信管理?
 LDBMS
建立和管理局部数据库，提供场地自治能力，执行局部应用及全局查询的子查询；
 GDBMS
提供分布透明性，协调全局事务执行，协调各局部DBMS完成全局应用，保证数据库全局一致性、执行并发控制、实现更新同步和提供全局恢复等功能；
 全局数据字典
存放全局概念模式、分片模式、分布模式的定义以及各模式之间映像的定义，存放有关用户存取权限的定义，保证全局用 户的权限和数据库的安全，存放数据完整性约束条件定义；
 通信管理
实现分布式数据库各场地之间消息和数据传递；

3. 解析：怎样理解分布处理和分布式数据库

一个分布式数据库在用户面前为单个逻辑数据库，但实际上是由存储在多台计算机上的一组数据库组成。在几台计算机 上的数据库通过网络可同时修改和存取，每一数据库受它的局部的DBMS控制。分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性。 在系统中的每一台计算机称为结点。如果一结点具有管理数据库 软件，该结点称为数据库服务器。如果一个结点为请求服务器的信息的一应用，该结点称为客户。在ORACLE客户，执行数据库应用，可存取数据信息和与用户交互。在服务器，执行ORACLE软件，处理对ORACLE数据库并发、共享数据存取。ORACLE允许上述两部分在同一台计算机上，但当客户部分和服务器部分是由网连接的不同计算机上时，更有效。 分布处理是由多台处理机分担单个任务的处理。在ORACLE数据库系统中分布处理的例子如： 客户和服务器是位于网络连接的不同计算机上。 单台计算机上有多个处理器，不同处理器分别执行客户应用。 SQL*NET是ORACLE网络接口，允许运行在网络工作站的ORACLE工具和服务器上，可存取、修改、共享和存储在其它服务器上的数据。SAQL*NET可被认为是网络通信的程序接口。SQL*NET利用通信协议和应用程序接口（API）为OARCLE提供一个分布式数据库和分布处理。 SQL*NET驱动器为在数据库服务器上运行的ORACLE进程与ORACLE工具的用户进程之间提供一个接口。 参与分布式数据库的每一服务器是分别地独立地管理数据库，好 像每一数据库不是网络化的数据库。每一个数据库独立地被管理，称为场地自治性。场地自治性有下列好处： ◆系统的结点可反映公司的逻辑组织。 ◆由局部数据库管理员控制局部数据，这样每一个数据库管理员责任域要 小一些，可更好管理。 ◆只要一个数据库和网络是可用，那么全局数据库可部分可用。不会因一个数据库的故 障而停止全部操作或引起性能瓶颈。 ◆故障恢复通常在单个结点上进行。 ◆每个局部数据库存在一个数据字典。 ◆结点可独立地升级软件。 可从分布式数据库的所有结点存取模式对象，因此正像非分布的局部的DBMS，必须提供一种机制，可在局部数据库中引用一个对象。分布式DBMS必须提供一种命名模式，以致分布式数据库中一个对象可在应用中唯一标识和引用。一般彩在层次结构的每一层实施唯一性。分布式DVMS简单地扩充层次命名模型，实施在网络上唯一数据库命名。因此一个对象的全局对象名保证在分布式数据库内是唯一。 ORACLE允许在SQL语句中使用佤对象名引用分布式数据库中的模式对象（表、视图和过程）。在ORACLE中，一个模式对象的全局名由三部分组成：包含对象的模式名、对象名、数据库名、其形式如： [email protected] 其中SCOTT为模式名,EMP为表名,@符号之后为数据库名. 一个远程查询为一查询,是从一个或多个远程表中选择信息,这些表驻留在同一个远程结点. 一个分布式查询可从两个或多个结点检索数据.一个分布式更新可修改两个或两个以上结点的数据. 一个远程事务为一个事务,包含一人或多个远程语句,它所引用的全部是在同一个远程结点上.一个分布式事务中一个事务,包含一个或多个语句修改分布式数据库的两个或多个不同结点的数据. 在分布式数据库中,事务控制必须在网络上直辖市,保证数据一致性.两阶段提交机制保证参与分布式事务的全部数据库服务器是全部提交或全部回滚事务中的语句. ORACLE分布式数据库系统结构可由ORACLE数据库管理员为终端用户和应用提供位置透明性,利用视图、同义词、过程可提供ORACLE分布式数据库系统中的位置透明性. ORACLE允许在SELECT(查询)、INSERT、UPDATE、DELETE、SELECT…FOR UPDATE和LOCK TABLE语句中引用远程数据。对于查询，包含有连接、聚合、子查询和SELECT …FOR UPDATE，可引用本地的、远程的表和视图。对于UPDATE、INSERT、DELETE和LOCK TABLE语句可引用本地的和远程的表。注意在引用LONG和LONG RAW列、序列、修改表和封锁表时，必须位于同一个结点。ORACLE不允许作远程DDL语句。 在单场地或分布式数据库中，所有事务都是用COMMIT或ROLLBACK语句中止。ORACLE提供两种机制实现分布式数据库中表重复的透明性：表快照提供异步的表重复；触发器实现同步的表的重复。在两种情况下，都实现了对表重复的透明性。

4. 大数据的分布式数据库的发展趋势如何

现在大数据是一个十分火热的技术，这也使得很多人都开始关注大数据的任何动态，因为大数据在某种程度上来说能够影响我们的生活。在这篇文章中我们就给大家介绍一下大数据的分布式数据库的发展趋势，希望这篇文章能够帮助大家更好理解大数据的分布式数据库的发展趋势。
其实不论是Hadoop还是分布式数据库，技术体系上两者都已经向着计算存储层分离的方式演进。对于Hadoop来说这一趋势非常明显，HDFS存储与YARN调度计算的分离，使得计算与存储均可以按需横向扩展。而分布式数据库近年来也在遵循类似的趋势，很多数据库已经将底层存储与上层的SQL引擎进行剥离。传统的XML数据库、OO数据库、与pre-RDBMS正在消亡；新兴领域文档类数据库、图数据库、Table-Style数据库与Multi-Model数据库正在扩大自身影响；传统关系型数据库、列存储数据库、内存分析型数据库正在考虑转型。可以看到，从技术完整性与成熟度来看，Hadoop确实还处于相对早期的形态。直到今天，很多技术在很多企业应用中需要大量的手工调优才能够勉强运行。同时，Hadoop的主要应用场景一直以来面向批处理分析型业务，传统数据库在线联机处理部分不是其主要的发展方向。同时Hadoop技术由于开源生态体系过于庞大，同时参与改造的厂商太多，使得用户很难完全熟悉整个体系，这一方面大大增加了开发的复杂度，提升了用户使用的难度，另一方面则是各个厂商之间维护不同版本，使得产品的发展方向可能与开源版本差别逐渐加大。
而分布式数据库领域经历了几十年的磨练，传统RDBMS的MPP技术早已经炉火纯青，在分类众多的分布式数据库中，其主要发展方向基本可以分为“分布式联机数据库”与“分布式分析型数据库”两种。对比Hadoop与分布式数据库可以看出，Hadoop的产品发展方向定位，与分布式数据库中列存储数据库相当重叠而在高并发联机交易场景，在Hadoop中除了HBase能够勉强沾边以外，分布式数据库则占据绝对的优势。目前，从Hadoop行业的发展来看，很多厂商而是将其定位改变为数据科学与机器学习服务商。因此，从商业模式上看以Hadoop分销的商业模式基本已经宣告结束，用户已经体验到维护整个Hadoop平台的困难而不愿被强迫购买整个平台。大量用户更愿意把原来Hadoop的部件拆开灵活使用，为使用场景和结果买单，而非平台本身买单。另外一个细分市场——非结构化小文件存储，一直以来都是对象存储、块存储，与分布式文件系统的主战场。如今，一些新一代数据库也开始进入该领域，可以预见在未来的几年中，小型非结构化文件存储也可能成为具备多模数据处理能力的分布式数据库的战场之一。
我们在这篇文章中给大家介绍了很多有关大数据分布数据库的发展前景，通过这篇文章我们不难发现数据库的发展是一个极其重要的内容，只有搭建分布式数据库，大数据才能够更好地为我们服务。

5. 大数据的分布式数据库技术的对比

大数据技术的实现离不开很多其他的技术，我们提到最多的就是Hadoop技术，其实就目前而言，Hadoop技术看似是自成一套体系，其实并不是这样的，Hadoop和Spark以及分布式数据库其实也是存在差异的，我们就在这篇文章中给大家介绍一下这些内容。
首先我们说一说大数据分析，现在的大数据分析体系以Hadoop生态为主，而近年来逐渐火热的Spark技术也是主要的生态之一。可以这么说，Hadoop技术只能算是以HDFS+YARN作为基础的分布式文件系统，而不是数据库。我们提到的Hadoop的历史可以向前追溯10年，当年谷歌为了在几万台PC服务器上构建超大数据集合并提供极高性能的并发访问能力，从而发明了一种新的技术，而这个技术，也是Hadoop诞生的理论基础。如果我们从Hadoop的诞生背景可以看出，其主要解决的问题是超大规模集群下如何对非结构化数据进行批处理计算。实际上，在Hadoop架构中，一个分布式任务可以是类似传统结构化数据的关联、排序、聚集操作，也可以是针对非结构化数据的用户自定义程序逻辑。
那么Hadoop的发展道路是什么样的呢。最开始的Hadoop以Big、Hive和MapRece三种开发接口为代表，分别适用于脚本批处理、SQL批处理以及用户自定义逻辑类型的应用。而Spark的发展更是如此，最开始的SparkRDD几乎完全没有SQL能力，还是套用了Hive发展出的Shark才能对SQL有了一部分的支持。但是，随着企业用户对Hadoop的使用越发广泛，SQL已经渐渐成为大数据平台在传统行业的主要访问方式之一。
下面我们就说一说分布式数据库，分布式数据库有着悠久的历史，从以Oracle RAC为代表的联机交易型分布式数据库，到IBM DB2 DPF统计分析性分布式数据库，分布式数据库覆盖了OLTP与OLAP几乎全部的数据应用场景。而大部分分布式数据库功能集中在结构化计算与在线增删改查上。但是，这些传统的分布式数据库以数仓及分析类OLAP系统为主，其局限性在于，其底层的关系型数据库存储结构在效率上并不能满足大量高并发的数据查询以及大数据数据加工和分析的效率要求。因此，分布式数据库在近几年也有着极大的转型，从单一的数据模型向多模的数据模型转移，将OLTP、联机高并发查询以及支持大数据加工和分析结合起来，不再单独以OLAP作为设计目标。同时，分布式数据库在访问模式上也出现了K/V、文档、宽表、图等分支，支持除了SQL查询语言之外的其他访问模式，大大丰富了传统分布式数据库单一的用途。一般来说，多模数据库的主要目的是为了满足具有高性能要求的操作型需求以及目标明确的数据仓库功能，而不是类似大数据深度学习等数据挖掘场景。这就是分布式数据库的实际情况。
我们在这篇文章中给大家介绍了大数据分析以及分布式数据库的相关知识，通过这些内容相信大家已经理解了其中的具体区别了吧，如果这篇文章能够帮助到大家这就是我们最大的心愿。

6. 阿里云分布式数据库服务DRDS谁使用过 简单讲讲！

淘宝开源的TDDL和cobar的结合，放到了阿里云上就是DRDS，是商品，服务，可以购买使用的。可以在阿里云官网上注册免费试用。

=====================================================
随着互联网时代的到来，计算机要管理的数据量呈指数级别地飞速上涨，而我们却完全无法对用户数做出准确预估。我们的系统所需要支持的用户数，很可能在短短的一个月内突然爆发式地增长几千倍，数据也很可能快速地从原来的几百GB飞速上涨到了几百个TB。如果在这爆发的关键时刻，系统不稳定或无法访问，那么对于业务将会是毁灭性的打击。
伴随着这种对于系统性能、成本以及扩展性的新需要，以HBase、MongoDB为代表的NoSQL数据库和以阿里DRDS、VoltDB、ScaleBase为代表的分布式NewSQL数据库如雨后春笋般不断涌现出来。
本文将会介绍阿里DRDS的技术理念、发展历程、技术特性等内容。
DRDS设计理念
从20世纪70年代关系数据库创立开始，其实大家在数据库上的追求就从未发生过变化：更快的存取数据，可以按需扩缩以承载更大的访问量和更大的数据量，开发容易，硬件成本低，我们可以把这叫做数据库领域的圣杯。
为了支撑更大的访问量和数据量，我们必然需要分布式数据库系统，然而分布式系统又必然会面对强一致性所带来的延迟提高的问题，因为网络通信本身比单机内通信代价高很多，这种通信的代价就会直接增加系统单次提交的延迟。延迟提高会导致数据库锁持有时间变长，使得高冲突条件下分布式事务的性能不升反降（这个具体可以了解一下Amdahl定律），甚至性能距离单机数据库都还有明显的差距。
从上面的说明，我们可以发现，问题的关键并不是分布式事务做不出来，而是做出来了却因为性能太差而没有什么卵用。数据库领域的高手们努力了40年，但至今仍然没有人能够很好地解决这个问题，Google Spanner的开发负责人就经常在他的Blog上谈论延迟的问题，相信也是饱受这个问题的困扰。
面对这个难题，传统的关系数据库选择了放弃分布式的方案，因为在20世纪70~80年代，我们的数据库主要被用来处理企业内的各类数据，面对的用户不过几千人，而数据量最多也就是TB级别。用单台机器来处理事务，用个磁盘阵列处理一下磁盘容量不够的问题，基本上就能解决一切问题了。
然而，信息化和互联网的浪潮改变了这一切，我们突然发现，我们服务的对象发生了根本性变化，从原来的几千人，变成了现在的几亿人，数据量也从TB级别到了PB级别甚至更多。存在单点的单机系统无论如何努力，都会面对系统处理能力的天花板。原来的这条路，看起来是走不下去了，我们必须想办法换一条路来走。
可是，分布式数据库所面对的强一致性难题却像一座高山，人们努力了无数个日日夜夜，但能翻越这座山的日子看来仍然遥遥无期。
于是，有一群人认为，强一致性这件事看来不怎么靠谱，那彻底绕开这个问题是不是个更好的选择？他们发现确实有那么一些场景是不需要强一致事务的，甚至连SQL都可以不要，最典型的就是日志流水的记录与分析这类场景。而去掉了事务和SQL，接口简单了，性能就更容易得到提升，扩展性也更容易实现，这就是NoSQL系统的起源。
虽然NoSQL解决了性能和扩展性问题，但这种绕开问题的方法给用户带来了很多困扰，系统的开发成本也大大提升。这时候就有另外一群人，他们觉得用户需要SQL，觉得用户也需要事务，问题的关键在于我们要努力地往圣杯的方向不断前进。在保持系统的扩展性和性能的前提下，付出尽可能小的代价来满足业务对数据库的需要。这就是NewSQL这个理念的由来。
DRDS也是一个NewSQL的系统，它与ScaleBase、VoltDB等系统类似，都希望能够找到一条既能保持系统的高扩展性和高性能，又能尽可能保持传统数据库的ACID事务和SQL特性的分布式数据库系统。
DRDS发展历程
在一开始，TDDL的主要功能就是做数据库切分，一个或一组SQL请求提交到TDDL，TDDL进行规则运算后得知SQL应该被分发到哪个机器，直接将SQL转发到对应机器即可（如图1）。

图1 TDDL数据库切分
开始的时候，这种简单的路由策略能够满足用户的需要，我们开始的那些应用，就是通过这样非常简单的方式完成了他所有的应用请求。我们也认为，这种方案简单可靠，已经足够好用了。
然而，当我们服务的应用从十几个增长到几百个的时候，大量的中小应用加入，大家纷纷表示，原来的方案限制太大，很多应用其实只是希望做个读写分离，希望能有更好的SQL兼容性。
于是，我们做了第一次重大升级，在这次升级里，我们提出了一个重要的概念就是三层架构，Matrix对应数据库切分场景，对SQL有一定限制，Group对应读写分离和高可用场景，对SQL几乎没有限制。如图2所示。

图2 数据库升级为三层架构
这种做法立刻得到了大家的认可，TDDL所提供的读写分离、分库分表等核心功能，也成为了阿里集团内数据库领域的标配组件，在阿里的几乎所有应用上都有应用。最为难得的是，这些功能从上线后，到现在已经经历了多年双11的严酷考验，从未出现过严重故障（p0、p1级别故障属于严重故障）。数据库体系作为整个应用系统的重中之重，能做到这件事，真是非常不容易。
随着核心功能的稳定，自2010年开始，我们集中全部精力开始关注TDDL后端运维系统的完善与改进性工作。在DBA团队的给力配合下，围绕着TDDL，我们成功做到了在线数据动态扩缩、异步索引等关键特征，同时也比较成功地构建了一整套分布式数据库服务管控体系，用户基本上可以完全自助地完成整套数据库环境的搭建与初始化工作。
大概是2012年，我们在阿里云团队的支持下，开始尝试将TDDL这套体系输出到阿里云上，也有了个新的名字：阿里分布式数据库服务（DRDS），希望能够用我们的技术服务好更多的人。
不过当我们满怀自信地把自己的软件拿到云上的时候，却发现我们的软件距离用户的要求差距很大。在内部因为有DBA的同学们帮助进行SQL review，所以SQL的复杂度都是可控的。然而到了云上，看了各种渠道提过来的兼容性需求，我们经常是不自觉地发出这样的感叹：“啊？原来这种语法MySQL也是可以支持的？”
于是，我们又进行了架构升级，这次是以兼容性为核心目标的系统升级工作，希望能够在分布式场景下支持各类复杂的SQL，同时也将阿里这么多年来在分布式事务上的积累都带到了DRDS里面。
这次架构升级，我们的投入史无前例，用了三年多才将整个系统落地完成。我们先在内部以我们自己的业务作为首批用户上线，经过了内部几百个应用的严酷考验以后，我们才敢拿到云上，给到我们的最终用户使用。
目前，我们正在将TDDL中更多的积累输出到云上，同时也努力优化我们的用户界面。PS：其实用户界面优化对我们这种专注于高性能后端技术的团队来说，才是最大的技术挑战，连我也去学了AngularJS，参与了用户UI编。
DRDS主要功能介绍
发展历史看完了，下面就由我来介绍一下目前我们已经输出到云上的主要功能。
【分布式SQL执行引擎】
分布式SQL引擎主要的目的，就是实现与单机数据库SQL引擎的完全兼容。目前我们的SQL引擎能够做到与MySQL的SQL引擎全兼容，包括各类join和各类复杂函数等。他主要包含SQL解析、优化、执行和合并四个流程，如图3中绿色部分。

图3 SQL引擎实现的主要流程
虽然SQL是兼容的，但是分布式SQL执行算法与单机SQL的执行算法却完全不同，原因也很简单，网络通信的延迟比单机内通信的延迟大得多。举个例子说明一下，我们有份文件要从一张纸A上誊写到另外一张纸B上，单机系统就好比两张纸都在同一个办公室里，而分布式数据库则就像是一张纸在北京，一张纸在杭州。
自然地，如果两张纸在同一个办公室，因为传输距离近，逐行誊写的效率是可以接受的。而如果距离是北京到杭州，用逐行誊写的方式，就立刻显得代价太高了，我们总不能看一行，就打个“飞的”去杭州写下来吧。在这种情况下，还是把纸A上的信息拍个照片，【一整批的】带到杭州去处理，明显更简单一些。这就是分布式数据库特别强调吞吐调优的原因，只要是涉及到跨机的所有查询，都必须尽可能的积攒一批后一起发送，以减少系统延迟提高带来的不良影响。
【按需数据库集群平滑扩缩】
DRDS允许应用按需将新的单机存储加入或移出集群，DRDS则能够保证应用在迁移流程中实现不停机扩容缩容。

图4 DRDS按需进行平滑扩缩
在内部的数据库使用实践中，这个功能的一个最重要应用场景就是双11了。在双11之前，我们会将大批的机器加入到我们的数据库集群中，抗过了双11，这批机器就会下线。
当DRDS来到云上，我们发现双11其实不仅仅只影响阿里内部的系统。在下游的各类电商辅助性系统其实也面对巨大压力。在双11前5天，网聚宝的熊总就找到我说，担心撑不过双11的流量，怕系统挂。于是我们就给他介绍了这个自动扩容的功能怎么用，他买了一个月的数据库，挂接在DRDS上。数据库能力立刻翻倍，轻松抗过了双11，也算是我印象比较深刻的一个案例了。
因为我们完全无法预测在什么时间点系统会有爆发性的增长，而如果在这时候系统因为技术原因不能使用，就会给整个业务带来毁灭性的影响，风口一旦错过，就追悔莫及了。我想这就是云计算特别强调可扩展能力的原因吧。
【小表广播】
小表广播也是我们在分布式数据库领域内最常用的工具之一，他的核心目的其实都是一个——尽可能让查询只发生在单机。
让我们用一个例子来说明，小表广播的一般使用场景。

图5 小表广播场景
图5中，如果我想知道买家id等于0的用户在商城里面买了哪些商品，我们一般会先将这两个表join起来，然后再用where平台名=”商城” and buyerID = 0找到符合要求的数据。然而这种join的方式，会导致大量的针对左表的网络I/O。如果要取出的数据量比较大，系统延迟会明显上升。
这时候，为了提升性能，我们就必须要减少跨机join的网络代价。我们比较推荐应用做如下处理，将左表复制到右表的每一个库上。这样，join操作就由分布式join一下变回到本地join，系统的性能就有很大的提升了，如图6所示。

图6
【分布式事务套件】
在阿里巴巴的业务体系中存在非常多需要事务类的场景，下单减库存，账务，都是事务场景最集中的部分。
而我们处理事务的方法却和传统应用处理事务的方案不大一样，我们非常强调事务的最终一致性和异步化。利用这种方式，能够极大地降低分布式系统中锁持有的时间，从而极大地提升系统性能。

图7 DRDS分布式事务解决套件
这种处理机制，是我们分布式事务能够以极低成本大量运行的最核心法门。在DRDS平台内，我们将这些方案产品化，为了DRDS的分布式事务解决套件。
利用他们，能够让你以比较低的成本，实现低延迟，高吞吐的分布式事务场景。
DRDS的未来
阿里分布式数据库服务DRDS上线至今，大家对这款产品的热情超出了我们的预期，短短半年内已经有几千个申请。
尽管还在公测期，但是大家就已经把关系到身家性命的宝贵在线数据业务放到了DRDS上，我能够感受到这份沉甸甸的信赖，也不想辜负这份信赖。
经过阿里内部几千个应用的不断历练，DRDS已经积累出一套强大的分布式SQL执行引擎和和一整套分布式事务套件。
我也相信，这些积累能够让用户在基本保持单机数据库的使用习惯的前提下，享受到分布式数据库高性能可扩展的好处。
在平时的DRDS支持过程中，我面对最多的问题就是，DRDS能不能够在不改变任何原有业务逻辑和代码的前提下，实现可自由伸缩和扩展呢？十分可惜的是，关系数据库发展至今，还没有找到既能保留传统数据库一切特性，又能实现高性能可扩展数据库的方法。
然而，虽不能至，吾心向往之！我们会以“可扩展，高性能”为产品核心，坚定地走在追寻圣杯的路上，并坚信最终我们一定能够找寻到它神圣的所在。
作者简介：王晶昱，花名沈询，阿里巴巴资深技术专家。目前主要负责阿里的分布式数据库DRDS（TDDL）和阿里的分布式消息服务ONS（RocketMQ/Notify）两个系统。

7. 分布式数据库和区块链的区别在哪些方面

区块链是一种共享的分布式数据库技术。尽管不同报告中对区块链的一句话介绍措辞都不相同，但以下4个技术特点是共识性的。
1. 去中心化（Decentralized）：图1的左侧描述了当今金融系统的中心化特征，右侧描述的是正在形成的去中心化金融系统，其没有中介机构，所有节点的权利和义务都相等，任一节点停止工作都会不影响系统整体的运作；
2. 去信任（Trustless）：系统中所有节点之间无需信任也可以进行交易，因为数据库和整个系统的运作是公开透明的，在系统的规则和时间范围内，节点之间无法欺骗彼此；
3. 集体维护（Collectively Maintain）：系统是由其中所有具有维护功能的节点共同维护的，系统中所有人共同参与维护工作；
4. 可靠数据库（Reliable Database）：系统中每一个节点都拥有最新的完整数据库拷贝，修改单个节点的数据库是无效的，因为系统会自动比较，认为最多次出现的相同数据记录为真。
比特币、以太坊、DECENT这些项目的区块链都是具备这些特点的。

8. 图数据库和关系数据库的区别

1、数据存储方式不同。

关系型和非关系型数据库的主要差异是数据存储的方式。关系型数据天然就是表格式的，因此存储在数据表的行和列中。数据表可以彼此关联协作存储，也很容易提取数据。

与其相反，非关系型数据不适合存储在数据表的行和列中，而是大块组合在一起。非关系型数据通常存储在数据集中，就像文档、键值对或者图结构。你的数据及其特性是选择数据存储和提取方式的首要影响因素。

2、扩展方式不同。

SQL和NoSQL数据库最大的差别可能是在扩展方式上，要支持日益增长的需求当然要扩展。

要支持更多并发量，SQL数据库是纵向扩展，也就是说提高处理能力，使用速度更快速的计算机，这样处理相同的数据集就更快了。

因为数据存储在关系表中，操作的性能瓶颈可能涉及很多个表，这都需要通过提高计算机性能来客服。虽然SQL数据库有很大扩展空间，但最终肯定会达到纵向扩展的上限。而NoSQL数据库是横向扩展的。

而非关系型数据存储天然就是分布式的，NoSQL数据库的扩展可以通过给资源池添加更多普通的数据库服务器(节点)来分担负载。

3、对事务性的支持不同。

如果数据操作需要高事务性或者复杂数据查询需要控制执行计划，那么传统的SQL数据库从性能和稳定性方面考虑是你的最佳选择。SQL数据库支持对事务原子性细粒度控制，并且易于回滚事务。

虽然NoSQL数据库也可以使用事务操作，但稳定性方面没法和关系型数据库比较，所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。

9. 数据库都有哪些

数据库是一组信息的集合，以便可以方便地访问、管理和更新，常用数据库有：1、关系型数据库；2、分布式数据库；3、云数据库；4、NoSQL数据库；5、面向对象的数据库；6、图形数据库。

计算机数据库通常包含数据记录或文件的聚合，例如销售事务、产品目录和库存以及客户配置文件。

通常，数据库管理器为用户提供了控制读写访问、指定报表生成和分析使用情况的能力。有些数据库提供ACID(原子性、一致性、隔离性和持久性)遵从性，以确保数据的一致性和事务的完整性。

数据库普遍存在于大型主机系统中，但也存在于较小的分布式工作站和中端系统中，如IBM的as /400和个人计算机。

数据库的演变

数据库从1960年代开始发展，从层次数据库和网络数据库开始，到1980年代的面向对象数据库，再到今天的SQL和NoSQL数据库和云数据库。

一种观点认为，数据库可以按照内容类型分类:书目、全文、数字和图像。在计算中，数据库有时根据其组织方法进行分类。有许多不同类型的数据库，从最流行的方法关系数据库到分布式数据库、云数据库或NoSQL数据库。

常用数据库：

1、关系型数据库

关系型数据库是由IBM的E.F. Codd于1970年发明的，它是一个表格数据库，其中定义了数据，因此可以以多种不同的方式对其进行重组和访问。

关系数据库由一组表组成，其中的数据属于预定义的类别。每个表在一个列中至少有一个数据类别，并且每一行对于列中定义的类别都有一个特定的数据实例。

结构化查询语言(SQL)是关系数据库的标准用户和应用程序接口。关系数据库易于扩展，并且可以在原始数据库创建之后添加新的数据类别，而不需要修改所有现有应用程序。

2、分布式数据库

分布式数据库是一种数据库，其中部分数据库存储在多个物理位置，处理在网络中的不同点之间分散或复制。

分布式数据库可以是同构的，也可以是异构的。同构分布式数据库系统中的所有物理位置都具有相同的底层硬件，并运行相同的操作系统和数据库应用程序。异构分布式数据库中的硬件、操作系统或数据库应用程序在每个位置上可能是不同的。

3、云数据库

云数据库是针对虚拟化环境(混合云、公共云或私有云)优化或构建的数据库。云数据库提供了一些好处，比如可以按每次使用支付存储容量和带宽的费用，还可以根据需要提供可伸缩性和高可用性。

云数据库还为企业提供了在软件即服务部署中支持业务应用程序的机会。

4、NoSQL数据库

NoSQL数据库对于大型分布式数据集非常有用。

NoSQL数据库对于关系数据库无法解决的大数据性能问题非常有效。当组织必须分析大量非结构化数据或存储在云中多个虚拟服务器上的数据时，它们是最有效的。

5、面向对象的数据库

使用面向对象编程语言创建的项通常存储在关系数据库中，但是面向对象数据库非常适合于这些项。

面向对象的数据库是围绕对象(而不是操作)和数据(而不是逻辑)组织的。例如，关系数据库中的多媒体记录可以是可定义的数据对象，而不是字母数字值。

6、图形数据库

面向图形的数据库是一种NoSQL数据库，它使用图形理论存储、映射和查询关系。图数据库基本上是节点和边的集合，其中每个节点表示一个实体，每个边表示节点之间的连接。

图形数据库在分析互连方面越来越受欢迎。例如，公司可以使用图形数据库从社交媒体中挖掘关于客户的数据。

访问数据库:DBMS和RDBMS

数据库管理系统(DBMS)是一种允许您定义、操作、检索和管理存储在数据库中的数据的软件。

关系数据库管理系统(RDBMS)是上世纪70年代开发的一种基于关系模型的数据库管理软件，目前仍然是最流行的数据库管理方法。

Microsoft SQL Server、Oracle数据库、IBM DB2和MySQL是企业用户最常用的RDBMS产品。DBMS技术始于20世纪60年代，支持分层数据库，包括IBM的信息管理系统和CA的集成数据库管理系统。一个关系数据库管理系统（RDBMS）是一种数据库管理软件是在20世纪70年代开发的，基于关系模式，仍然是管理数据库的最普遍的方式。

希望能帮助你还请及时采纳谢谢

10. 什么是分布式数据库

分布式软件系统(Distributed Software Systems)是支持分布式处理的软件系统,是在由通信网络互联的多处理机体系结构上执行任务的系统。它包括分布式操作系统、分布式程序设计语言及其编译(解释)系统、分布式文件系统和分布式数据库系统等。

分布式操作系统负责管理分布式处理系统资源和控制分布式程序运行。它和集中式操作系统的区别在于资源管理、进程通信和系统结构等方面。

分布式程序设计语言用于编写运行于分布式计算机系统上的分布式程序。一个分布式程序由若干个可以独立执行的程序模块组成,它们分布于一个分布式处理系统的多台计算机上被同时执行。它与集中式的程序设计语言相比有三个特点：分布性、通信性和稳健性。

分布式文件系统具有执行远程文件存取的能力,并以透明方式对分布在网络上的文件进行管理和存取。

分布式数据库系统由分布于多个计算机结点上的若干个数据库系统组成,它提供有效的存取手段来操纵这些结点上的子数据库。分布式数据库在使用上可视为一个完整的数据库,而实际上它是分布在地理分散的各个结点上。当然,分布在各个结点上的子数据库在逻辑上是相关的。

---------------

分布式数据库系统是由若干个站集合而成。这些站又称为节点，它们在通讯网络中联接在一起，每个节点都是一个独立的数据库系统，它们都拥有各自的数据库、中央处理机、终端，以及各自的局部数据库管理系统。因此分布式数据库系统可以看作是一系列集中式数据库系统的联合。它们在逻辑上属于同一系统，但在物理结构上是分布式的。

分布式数据库系统已经成为信息处理学科的重要领域，正在迅速发展之中，原因基于以下几点：

1、它可以解决组织机构分散而数据需要相互联系的问题。比如银行系统，总行与各分行处于不同的城市或城市中的各个地区，在业务上它们需要处理各自的数据，也需要彼此之间的交换和处理，这就需要分布式的系统。

2、如果一个组织机构需要增加新的相对自主的组织单位来扩充机构，则分布式数据库系统可以在对当前机构影响最小的情况下进行扩充。

3、均衡负载的需要。数据的分解采用使局部应用达到最大，这使得各处理机之间的相互干扰降到最低。负载在各处理机之间分担，可以避免临界瓶颈。

4、当现有机构中已存在几个数据库系统，而且实现全局应用的必要性增加时，就可以由这些数据库自下而上构成分布式数据库系统。

5、相等规模的分布式数据库系统在出现故障的几率上不会比集中式数据库系统低，但由于其故障的影响仅限于局部数据应用，因此就整个系统来讲它的可靠性是比较高的。

特点

1、在分布式数据库系统里不强调集中控制概念，它具有一个以全局数据库管理员为基础的分层控制结构，但是每个局部数据库管理员都具有高度的自主权。

2、在分布式数据库系统中数据独立性概念也同样重要，然而增加了一个新的概念，就是分布式透明性。所谓分布式透明性就是在编写程序时好象数据没有被分布一样，因此把数据进行转移不会影响程序的正确性。但程序的执行速度会有所降低。

3、集中式数据库系统不同，数据冗余在分布式系统中被看作是所需要的特性，其原因在于：首先，如果在需要的节点复制数据，则可以提高局部的应用性。其次，当某节点发生故障时，可以操作其它节点上的复制数据，因此这可以增加系统的有效性。当然，在分布式系统中对最佳冗余度的评价是很复杂的。

分布式系统的类型，大致可以归为三类：

1、分布式数据，但只有一个总? 据库，没有局部数据库。

2、分层式处理，每一层都有自己的数据库。

3、充分分散的分布式网络，没有中央控制部分，各节点之间的联接方式又可以有多种，如松散的联接，紧密的联接，动态的联接，广播通知式联接等。

---------------------

什么是分布式智能?
NI LabVIEW 8的分布式智能结合了相关的技术和工具，解决了分布式系统开发会碰到的一些挑战。更重要的是，NI LabVIEW 8的分布式智能提供的解决方案不仅令这些挑战迎刃而解，且易于实施。LabVIEW 8的分布式智能具体包括:

可对分布式系统中的所有结点编程——包括主机和终端。尤为可贵的是，您可以利用LabVIEW图形化编程方式，对大量不同类型的对象进行编程，如桌面处理器、实时系统、FPGA、PDA、嵌入式微处理器和DSP。
导航所有系统结点的查看系统——LabVIEW Project Explorer。您可使用Project Explorer查看、编辑、运行和调试运行于任何对象上的结点。
经简化的数据共享编程界面——共享变量。使用共享变量，您可轻松地在系统间(甚至实时系统间)传输数据且不影响性能。无通信循环，无RT FIFO，无需低层次TCP函数。您可以利用简单的对话完成共享变量的配置，从而将数据在各系统间传输或将数据连接到不同的数据源。您还可添加记录、警报、事件等数据服务――一切仅需简单的对话即可完成。
实现了远程设备及系统内部或设备及系统之间的同步操作——定时和同步始终是定义高性能测量和控制系统的关键问题。利用基于NI技术的系统，探索设备内部并编写其内部运行机制，从而取得比传统仪器或PLC方式下更为灵活的解决方案。

--------------------

在分布式计算机操作系统支持下，互连的计算机可以互相协调工作，共同完成一项任务。

也可以这么解释:
一种计算机硬件的配置方式和相应的功能配置方式。它是一种多处理器的计算机系统，各处理器通过互连网络构成统一的系统。系统采用分布式计算结构，即把原来系统内中央处理器处理的任务分散给相应的处理器，实现不同功能的各个处理器相互协调，共享系统的外设与软件。这样就加快了系统的处理速度，简化了主机的逻辑结构.

易游贝贝祝你好运