当前位置：首页 > 实用文档 > 其他范文> 分布式数据库概述

分布式数据库概述

时间：2023-02-08 08:01:35 其他范文收藏本文下载本文

分布式数据库概述（精选7篇）由网友“麦当辣”投稿提供，下面是小编整理过的分布式数据库概述，欢迎阅读分享，希望对大家有所帮助。

分布式数据库概述

篇1：分布式数据库 Hypertable

Hypertable是一个开源、高性能、可伸缩的数据库，它采用与Google的Bigtable相似的模型，在过去数年中，Google为在 PC集群上运行的可伸缩计算基础设施设计建造了三个关键部分。第一个关键的基础设施是Google File System（GFS），这是一个高可用的文件系统，提供了一个全局的命名空间。它通过跨机器（和跨机架）的文件数据复制来达到高可用性，并因此免受传统文件存储系统无法避免的许多失败的影响，比如电源、内存和网络端口等失败，

第二个基础设施是名为Map-Reduce的计算框架，它与GFS紧密协作，帮助处理收集到的海量数据。第三个基础设施是Bigtable，它是传统数据库的替代。Bigtable让你可以通过一些主键来组织海量数据，并实现高效的查询。Hypertable是Bigtable的一个开源实现，并且根据我们的想法进行了一些改进。

项目主页：www.open-open.com/lib/view/home/1339253305568

篇2：分布式数据库概述

一、前言

随着传统的数据库技术日趋成熟、计算机网络技术的飞速发展和应用范围的扩充，数据库应用已经普遍建立于计算机网络之上，这时集中式数据库系统表现出它的不足：数据按实际需要已在网络上分布存储，再采用集中式处理，势必造成通信开销大；应用程序集中在一台计算机上运行，一旦该计算机发生故障，则整个系统受到影响，可靠性不高；集中式处理引起系统的规模和配置都不够灵活，系统的可扩充性差。在这种形势下，集中式DB的“集中计算”概念向“分布计算” 概念发展。分布计算主要体现在客户机/服务器模式和分布式数据库体系结构两个方面。

二、分布式数据库系统概述

随着传统的数据库技术日趋成熟、计算机网络技术的飞速发展和应用范围的扩大，以分布式为主要特征的数据库系统的研究与开发受到人们的注意。分布式数据库是数据库技术与网络技术相结合的产物，在数据库领域已形成一个分支。分布式数据库的研究始于20世纪70年代中期。世界上第一个分布式数据库系统 SDD-1是由美国计算机公司（CCA）于1979年在DEC计算机上实现。20世纪90年代以来，分布式数据库系统进入商品化应用阶段，传统的关系数据库产品均发展成以计算机网络及多任务操作系统为核心的分布式数据库产品，同时分布式数据库逐步向客户机/服务器模式发展。

三、DDBS(Distributed Database System)的分类

（1）同构同质型DDBS：各个场地都采用同一类型的数据模型（譬如都是关系型），并且是同一型号的DBMS。

（2）同构异质型DDBS：各个场地采用同一类型的数据模型，但是DBMS的型号不同，譬如DB2、ORACLE、SYBASE、SQL Server等。

（3）异构型DDBS：各个场地的数据模型的型号不同，甚至类型也不同。随着计算机网络技术的发展，异种机联网问题已经得到较好的解决，此时依靠异构型DDBS就能存取全网中各种异构局部库中的数据。

四、DDBS的特点和优缺点

DDBS的基本特点：

（1）物理分布性：数据不是存储在一个场地上，而是存储在计算机网络的多个场地上。

（2）逻辑整体性：数据物理分布在各个场地，但逻辑上是一个整体，它们被所有用户（全局用户）共享，并由一个DDBMS统一管理。

（3）场地自治性：各场地上的数据由本地的DBMS管理，具有自治处理能力，完成本场地的应用（局部应用）。

（4）场地之间协作性：各场地虽然具有高度的自治性，但是又相互协作构成一个整体。

DDBS的其他特点

（1）数据独立性

（2）集中与自治相结合的控制机制

（3）适当增加数据冗余度

（4）事务管理的分布性

DDBS的优点

（1）具有灵活的体系结构

（2）适应分布式的管理和控制机构

（3）经济性能优越

（4）系统的可靠性高、可用性好

（5）局部应用的响应速度快

（5）可扩展性好，易于集成现有的系统

DDBS的缺点

（1）系统开销较大，主要花在通信部分。

（2）复杂的存取结构（如辅助索引、文件的链接技术），在集中式DBS中是有效存取数据的重要技术，但在分布式系统中不一定有效。

（3）数据的安全性和保密性较难处理。

五、数据分片

类型：

（1）水平分片：按一定的条件把全局关系的所有元组划分成若干不相交的子集，每个子集为关系的一个片段，

（2）垂直分片：把一个全局关系的属性集分成若干子集，并在这些子集上作投影运算，每个投影称为垂直分片。

（3）导出分片：又称为导出水平分片，即水平分片的条件不是本关系属性的条件，而是其他关系属性的条件。

（4）混合分片：以上三种方法的混合。可以先水平分片再垂直分片，或先垂直分片再水平分片，或其他形式，但他们的结果是不相同的。

条件：

（1）完备性条件：必须把全局关系的所有数据映射到片段中，决不允许有属于全局关系的数据却不属于它的任何一个片段。

（2）可重构条件：必须保证能够由同一个全局关系的各个片段来重建该全局关系。对于水平分片可用并操作重构全局关系；对于垂直分片可用联接操作重构全局关系。

（3）不相交条件：要求一个全局关系被分割后所得的各个数据片段互不重叠（对垂直分片的主键除外）。

六、数据分配方式

（1）集中式：所有数据片段都安排在同一个场地上。

（2）分割式：所有数据只有一份，它被分割成若干逻辑片段，每个逻辑片段被指派在一个特定的场地上。

（4）全复制式：数据在每个场地重复存储。也就是每个场地上都有一个完整的数据副本。

（5）混合式：这是一种介乎于分割式和全复制式之间的分配方式。

七、体系结构

数据分片和数据分配概念的分离，形成了“数据分布独立型”概念。

数据冗余的显式控制。数据在各个场地的分配情况在分配模式中一目了然，便于系统管理。

局部DBMS的独立性。这个特征也称为“局部映射透明性”。此特征允许我们在不考虑局部DBMS专用数据模型的情况下，研究DDB管理的有关问题。

八、分布式数据库管理系统

接受用户请求，并判定把它送到哪里，或必须访问哪些计算机才能满足该要求。

访问网络数据字典，了解如何请求和使用其中的信息。

如果目标数据存储于系统的多个计算机上，就必须进行分布式处理。

通信接口功能。在用户、局部DBMS和其他计算机的DBMS之间进行协调。

在一个异构型分布式处理环境中，还需提供数据和进程移植的支持。这里的异构型是指各个场地的硬件、软件之间存在着差别。

九、小结

（1）“分布计算”概念突破了集中式DBS的框架，数据分布使系统走上分布式DB的道路，功能分布使系统走上C/S道路。这是DBS的两个发展。

（2）C/S系统包括一个计算机网络，通常用一个局域网连结。几乎在所有情况下，客户机都是微机；服务器有时用小型机或大型机，但多数情况下也使用微机或高档微机。应用程序在客户机上处理，DBMS和OS的数据管理分放在服务器上。

（3）C/S结构经历了从两层、三层到多层的演变过程。总的趋势是使客户机越来越“瘦”，变成浏览器；而服务器的种类越来越多，容易实现系统的组装。

（4）C/S系统使应用与用户更加贴近，为用户提供较好的性能和更复杂的界面。

（5）分布式系统是在集中式系统的基础上发展而来的。DDB是数据库技术与网络技术结合的产物。随着计算机网络技术的飞速发展，DDBS日趋成为数据库领域的主流方向。

（6）DDB具有数据分布性和逻辑整体性的特点。DDBS能够支持涉及多个场地的全局应用。DDB的数据存储有数据分片和数据分配两种策略。

（7）DDB的模式结构为理解DDBS提供了一种通用的概念结构。分布透明性是DDBS追求的目标。DDBMS是负责管理分布环境下，逻辑集成数据的存取、一致性、有效性和完备性的软件系统。

（8）DDBS中数据分布在各个场地，系统中压倒一切的性能目标是尽量减少网络中传送信息的次数和传送的数据量。分布式查询中基于半联接的优化策略是常用的技术。

（9）对于并发控制和恢复，DDBMS环境中会出现大量在集中式DBMS环境中碰不到的问题。分布式的并发控制有主场地方法和主拷贝方法，再辅之于备份场地技术。

来源: 博客园

篇3：淘宝分布式数据库 OceanBase

OceanBase是一个支持海量数据的高性能分布式数据库系统，实现了数千亿条记录、数百TB数据上的跨行跨表事务，由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同完成，在设计和实现 OceanBase的时候暂时摒弃了不紧急的DBMS的功能，例如临时表，视图(view)，研发团队把有限的资源集中到关键点上，当前 OceanBase主要解决数据更新一致性、高性能的跨表读事务、范围查询、join、数据全量及增量dump、批量数据导入，

目前OceanBase已经应用于淘宝收藏夹，用于存储淘宝用户收藏条目和具体的商品、店铺信息，每天支持4～5千万的更新操作。等待上线的应用还包括CTU、SNS等，每天更新超过20亿，更新数据量超过2.5TB，并会逐步在淘宝内部推广。

项目主页：www.open-open.com/lib/view/home/1323510339593

篇4：分布式数据库的主要特点

分布式数据库的主要特点

(1)、数据独立性与位置透明性，数据独立性是数据库方法追求的主要目标之一，分布透明性指用户不必关心数据的逻辑分区，不必关心数据物理位置分布的细节，也不必关心重复副本（冗余数据）的一致性问题，同时也不必关心局部场地上数据库支持哪种数据模型．分布透明性的优点是很明显的．有了分布透明性，用户的应用程序书写起来就如同数据没有分布一样．当数据从一个场地移到另一个场地时不必改写应用程序．当增加某些数据的重复副本时也不必改写应用程序．数据分布的信息由系统存储在数据字典中．用户对非本地数据的访问请求由系统根据数据字典予以解释、转换、传送．

(2)、集中和节点自治相结合。数据库是用户共享的资源．在集中式数据库中，为了保证数据库的安全性和完整性，对共享数据库的控制是集中的，并设有DBA负责监督和维护系统的正常运行．在分布式数据库中，数据的共享有两个层次：一是局部共享，即在局部数据库中存储局部场地上各用户的共享数据．这些数据是本场地用户常用的．二是全局共享，即在分布式数据库的各个场地也存储可供网中其它场地的用户共享的数据，支持系统中的全局应用．因此，相应的控制结构也具有两个层次：集中和自治．分布式数据库系统常常采用集中和自治相结合的控制结构,各局部的DBMS可以独立地管理局部数据库，具有自治的功能．同时，系统又设有集中控制机制，协调各局部DBMS的工作，执行全局应用。当然,不同的系统集中和自治的程度不尽相同．有些系统高度自治，连全局应用事务的协调也由局部DBMS、局部DBA共同承担而不要集中控制，不设全局DBA,有些系统则集中控制程度较高，场地自治功能较弱。

(3)、支持全局数据库的一致性和和可恢复性，

分布式数据库中各局部数据库应满足集中式数据库的一致性、可串行性和可恢复性。除此以外还应保证数据库的全局一致性、并行操作的可串行性和系统的全局可恢复性。这是因为全局应用要涉及两个以上结点的数据．因此在分布式数据库系统中一个业务可能由不同场地上的多个操作组成．例如, 银行转帐业务包括两个结点上的更新操作。这样，当其中某一个结点出现故障操作失败后如何使全局业务滚回呢？如何使另一个结点撤销已执行的操作(若操作已完成或完成一部分）或者不必再执行业务的其它操作(若操作尚没执行)？这些技术要比集中式数据库复杂和困难得多，分布式数据库系统必须解决这些问题．

(4)、复制透明性。用户不用关心数据库在网络中各个节点的复制情况，被复制的数据的更新都由系统自动完成。在分布式数据库系统中，可以把一个场地的数据复制到其他场地存放，应用程序可以使用复制到本地的数据在本地完成分布式操作，避免通过网络传输数据，提高了系统的运行和查询效率。但是对于复制数据的更新操作，就要涉及到对所有复制数据的更新。

(5)、易于扩展性。在大多数网络环境中，单个数据库服务器最终会不满足使用。如果服务器软件支持透明的水平扩展，那么就可以增加多个服务器来进一步分布数据和分担处理任务。

分布式数据库的优点

(1)具有灵活的体系结构。

(2)适应分布式的管理和控制机构。

(3)经济性能优越。

(4)系统的可靠性高、可用性好。

(5)局部应用的响应速度快。

(6)可扩展性好，易于集成现有系统。

分布式数据库的缺点

(1)系统开销大，主要花在通信部分。

(2)复杂的存取结构，原来在集中式系统中有效存取数据的技术，在分成式系统中都不再适用。

(3)数据的安全生和保密性较难处理。

篇5：分布式数据库管理系统 Mnesia

Mnesia是一个分布式数据库管理系统(DBMS),适合于电信和其它需要持续运行和具备软实时特性的Erlang应用，是构建电信应用的控制系统平台开放式电信平台(OTP)的一部分，

Mnesia试图解决典型电信系统的数据管理问题，具备一些在传统数据库中通常找不到的特性。电信应用有许多不同于传统数据库管理系统的需求。用Erlang语言实现的应用程序需要具备宽广的特性，这是传统数据库管理系统无法满足的。

Mnesia的设计要求如下：

快速实时的键(key)/值(value)查找

主要用于运营和维护的非实时复杂查询

由于分布式应用导致的分布式数据

高容错

动态重配置

复杂对象

Mnesia与其它大部分数据库管理系统的区别在于其是被设计用于解决电信应用中的典型数据管理问题，

因此，Mnesia有许多传统数据库的概念，如事务和查询，也有许多电信应用数据管理系统的概念，如高速实时操作，可配置的容错等级(在复制的意义上)以及不停机进行重新配置的能力等。Mnesia与Erlang编程语言是紧耦合的，使得Erlang几乎成为数据库编程语言。其最大的好处是在操作数据时由于数据库与编程语言所用的数据格式不同而带来的阻抗失配问题完全消失。

介绍内容来自百度百科

项目主页：www.open-open.com/lib/view/home/1331130157624

篇6：分布式数据库中间件CCobar初始化过程

Cobar-Server的源码地址：GitHub 欢迎Fork，

官方文档描述Cobar的网络通信模块见下图，

Cobar使用了Java的NIO进行处理读写，NIO是Java中的IO复用，而不需要对每个连接都建立一个处理线程。详细请看非阻塞I/O–Java NIO教程

Cobar的初始化流程图如下：

在Cobar实例化过程中三个XML配置文件的加载类图关系如下（具体的成员没有标明）：

这样Cobar系统就在运行了：

每个Processor都启动反应堆的两个线程R和W来处理NIO的输入和输出

一个connector线程，处理和后端的MySQL节点连接

一个acceptor线程，用于接受来自客户端的连接请求，

timer任务包括（时间定期更新、定时执行processor检查，用于清理资源回收、数据节点空闲超时检查、数据节点心跳包、Cobar集群心跳包）作者：GeekCome出处：极客来原文：分布式数据库中间件–(1) Cobar初始化过程提示：本文版权归作者，欢迎，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接。如果对文章有任何问题，都可以在评论中留言，我会尽可能的答复您，谢谢你的阅读

篇7：使用mysql federated引擎构建MySQL分布式数据库访问层

使用mysql federated引擎构建MySQL分布式数据库访问层

本文所描述的 federated属于 MySQL的一种特殊引擎，利用它可将本地数据表映射至远程 MySQL 数据表，从而就可以解决应用程序中繁多的跨机器连接数据库问题，拓扑图如下：

如此就可以构造出一个统一的数据访问入口，就大大提高了整个数据库系统的可维护性， Federated引擎是基于表级别的，只能将本地数据表定义为 Federated 引擎并映射至远程实体表，无法实现基于库级别的整体映射。

在本文中，我们将启用Federated 引擎的数据库访问入口服务器称为本地数据库，而将本地数据表对应的远程数据表，称之为实体表。

本地数据库需要启用Federated 引擎支持，而远程数据表无须 Federated 引擎支持。 Federated 引擎表使用标准的 MySQL 客户端协议与远程数据库建立 TCP 连接。

创建Federated 表的过程：

以root 登录远程 MySQL ，上创建合适的访问账号 grant all on DB1.* to 'federated'@'%' identified by 'federated'; flush privileges;

在远程MySQL 找到对应实体表的创建命令（如果是新表，请先建立好数据表，再执行此命令）假设在远程mysql 上有库名 DB1, 表名 tag, 执行以下命令找到远程表的结构： show create table DB1.tag 输出： CREATE TABLE tag ( id int(10) unsigned NOT NULL AUTO_INCREMENT, name varchar(128) NOT NULL, frequency int(10) unsigned NOT NULL DEFAULT '1', PRIMARY KEY (id) ) ENGINE=MyISAM AUTO_INCREMENT=6 DEFAULT CHARSET=utf8

假设我们要将远程的DB1.tag 映射至本地 DB.TableA 表上。那么我们应该保持本地虚拟表与远程实体表结构一致（结构可以有所差异，但会造成使用，管理上的麻烦）。根据远程实体表的创建命令，创建本地虚拟表 ( 结构部分完全一样，创建表选项有所差异 ) ：

登录本地Mysql 服务器，创建相应的数据库及表： create database DB; use DB; CREATE TABLE TableA ( id int(10) unsigned NOT NULL AUTO_INCREMENT, name varchar(128) NOT NULL, frequency int(10) unsigned NOT NULL DEFAULT '1', PRIMARY KEY (id) ) ENGINE=federated connection=“mysql://federated:federated@127.0.0.1 :3306/DB1/tag”;

这时，即建立好了federated 虚拟表，实际上本地 MySQL 只创建了表定义文件 , 而没有数据文件，

我们对本地虚拟表的数据修改，均会发送到远程机器上执行。

本地虚拟表名与远程表名，可不相同。

经过测试，这个引擎的一些额外特点： 1. 本地虚拟表与远程实体表之间是 TCP 长连接，并且是多个客户端利用的。所以不用担心因频繁建立连接带来的网络开销。 2. 本虚拟表表与远程实体表之间的网络连接断开后，当对虚拟表发起查询时，它会尝试重新连接远程实体表，所以我们不用担心网络连接断开造成的永久中断问题。 3. 如果无时间未对本地虚拟表作任何操作，虚拟表与实体表之间的连接将在远程主机的 wait_timeout 秒后自动断开，当对虚拟表发起查询时，连接又会重新建立。

一些注意事项： 1. 对本地虚拟表的结构修改，并不会修改远程表的结构 2. truncate 命令，会清除远程表数据 3. drop命令只会删除虚拟表，并不会删除远程表 4. 不支持 alter table 命令目前使用federated 最大的缺点： 1. select count(*), select * from limit M, N 等语句执行效率非常低，数据量较大时存在很严重的问题，但是按主键或索引列查询，则很快，如以下查询就非常慢（假设 id 为主索引） select id from db.tablea where id >100 limit 10 ; 而以下查询就很快： select id from db.tablea where id >100 and id<150

如果虚拟虚拟表中字段未建立索引，而实体表中为此字段建立了索引，此种情况下，性能也相当差。但是当给虚拟表建立索引后，性能恢复正常。

类似 where name like “str%” limit 1 的查询，即使在 name 列上创建了索引，也会导致查询过慢，是因为 federated引擎会将所有满足条件的记录读取到本，再进行 limit 处理。

这几个问题已经严重影响了federated 在实际环境中的应用。