A. 分布式数据库需要考虑哪些问题
在设来计分布式数据库时，应特别考虑源如下几个方面的问题： 1. 数据保存 (存储分段/复制，横向/纵向表分区); 2. 目录管理(catalog management): 命名，数据独立性 3. 查询处理(基于代价的调优， 半合并)4. 数据更新(同步/异步)
B. 简述分布式数据库的模式结构
布式数据库系统通常使用较小的计算机系统，每台计算机可单独放在一个地方，每台计算机中都有DBMS的一份完整拷贝副本，并具有自己局部的数据库，位于不同地点的许多计算机通过网络互相连接，共同组成一个完整的、全局的大型数据库。
这种组织数据库的方法克服了物理中心数据库组织的弱点。首先，降低了数据传送代价，因为大多数的对数据库的访问操作都是针对局部数据库的，而不是对其他位置的数据库访问；其次，系统的可靠性提高了很多，因为当网络出现故障时，仍然允许对局部数据库的操作，而且一个位置的故障不影响其他位置的处理工作，只有当访问出现故障位置的数据时，在某种程度上才受影响；第三，便于系统的扩充，增加一个新的局部数据库，或在某个位置扩充一台适当的小型计算机，都很容易实现。然而有些功能要付出更高的代价。例如，为了调配在几个位置上的活动，事务管理的性能比在中心数据库时花费更高，而且甚至抵消许多其他的优点。
分布式数据库系统主要特点：
· 多数处理就地完成；
· 各地的计算机由数据通信网络相联系。
· 克服了中心数据库的弱点：降低了数据传输代价；
· 提高了系统的可靠性，局部系统发生故障，其他部分还可继续工作；
· 各个数据库的位置是透明的，方便系统的扩充；
· 为了协调整个系统的事务活动，事务管理的性能花费高；
数据分片
类型：
（1）水平分片：按一定的条件把全局关系的所有元组划分成若干不相交的子集，每个子集为关系的一个片段。
（2）垂直分片：把一个全局关系的属性集分成若干子集，并在这些子集上作投影运算，每个投影称为垂直分片。
（3）导出分片：又称为导出水平分片，即水平分片的条件不是本关系属性的条件，而是其他关系属性的条件。
（4）混合分片：以上三种方法的混合。可以先水平分片再垂直分片，或先垂直分片再水平分片，或其他形式，但他们的结果是不相同的。
条件：
（1）完备性条件：必须把全局关系的所有数据映射到片段中，决不允许有属于全局关系的数据却不属于它的任何一个片段。
（2）可重构条件：必须保证能够由同一个全局关系的各个片段来重建该全局关系。对于水平分片可用并操作重构全局关系；对于垂直分片可用联接操作重构全局关系。
（3）不相交条件：要求一个全局关系被分割后所得的各个数据片段互不重叠（对垂直分片的主键除外）。
数据分配方式
（1）集中式：所有数据片段都安排在同一个场地上。
（2）分割式：所有数据只有一份，它被分割成若干逻辑片段，每个逻辑片段被指派在一个特定的场地上。
（4）全复制式：数据在每个场地重复存储。也就是每个场地上都有一个完整的数据副本。
（5）混合式：这是一种介乎于分割式和全复制式之间的分配方式。
目前分布式数据库分配的设计，越来越多的采用寻找最优解的算法，比如遗传算法、退火机制等
查询优化
指在执行分布式查询时选择查询执行计划的方法和关系运算符的实现算法。根据系统环境的不同，查询优化所使用的算法也有所不同，通常分为远程广域网环境和高速局域网环境，其区别主要在网络的带宽。对于一元运算符可以采用集中式数据库中的查询优化方法。而对于二元运算符，由于涉及场地间的数据传输，因此必须考虑通信代价。分布式查询中常见的连接运算执行策略包括：
（1）半连接方法：利用半连接运算的转换方法R∞S=（RµS）∞S。假设场地1和场地2上分别有关系R和关系S，首先在S上执行连接属性上的投影并将结果传输至场地1，在场地1上执行关系R与投影的连接操作，再将结果传输至场地2与关系S执行连接操作。这种方法能够降低执行连接运算时的网络通信代价，主要适用于带宽较低的远程广域网络。
（2）枚举法方法：指枚举关系运算符的物理执行计划，通过对比执行计划的代价选择执行算法的方法。其中，连接运算符的物理执行计划包括嵌套循环方法、哈希连接法和归并连接法。枚举法主要适用于以磁盘IO代价为主的高速局域网环境。
C. 数据库设计分为哪几个步骤
(1)存储记录结构设计综合分析数据存储要求和应用需求，设计存储记录格式
(2)存储空间分配存储空间分配有两个原则：①存取频度高的数据尽量安排在快速、随机设备上，存取频度低的数据则安排在速度较慢的设备上
②相互依赖性强的数据尽量存储在同一台设备上，且尽量安排在邻近的存储空间上
从提高系统性能方面考虑，应将设计好的存储记录作为一个整体合理地分配物理存储区域
尽可能充分利用物理顺序特点，把不同类型的存储记录指派到不同的物理群中
(3)访问方法的设计一个访问方法包括存储结构和检索机构两部分
存储结构限定了访问存储记录时可以使用的访问路径；检索机构定义了每个应用实际使用的访问路径
(4)物理设计的性能评价①查询响应时间从查询开始到有结果显示之间所经历的时间称为查询响应时间
查询响应时间可进一步细分为服务时间、等待时间和延迟时间
在物理设计过程中，要对系统的性能进行评价
性能评价包括时间、空间、效率、开销等各个方面
⊙CPU服务时间和I/O服务时间的长短取决于应用程序设计
⊙CPU队列等待时间和I/O队列等待时间的长短受计算机系统作业的影响
⊙设计者可以有限度地控制分布式数据库系统的通信延迟时间
②存储空间存储空间存放程序和数据
程序包括运行的应用程序、DBMS子程序、OS子程序等
数据包括用户工作区、DBMS工作区、OS工作区、索引缓冲区、数据缓冲区等
存储空间分为主存空间和辅存空间
设计者只能有限度地控制主存空间，例如可指定缓冲区的分配等
但设计者能够有效地控制辅存空间
③开销与效率设计中还要考虑以下各种开销，开销增大，系统效率将下降
⊙事务开销指从事务开始到事务结束所耗用的时间
更新事务要修改索引、重写物理块、进行写校验等操作，增加了额外的开销
更新频度应列为设计的考虑因素
⊙报告生成开销指从数据输入到有结果输出这段时间
报告生成占用CPU及I/O的服务时间较长
设计中要进行筛选，除去不必要的报告生成
⊙对数据库的重组也是一项大的开销
设计中应考虑数据量和处理频度这两个因数，做到避免或尽量减少重组数据库
在物理设计阶段，设计、评价、修改这个过程可能要反复多次，最终得到较为完善的物理数据库结构说明书
建立数据库时，DBA依据物理数据库结构说明书，使用DBMS提供的工具可以进行数据库配置
在数据库运行时，DBA监察数据库的各项性能，根据依据物理数据库结构说明书的准则，及时进行修正和优化操作，保证数据库系统能够搜凯保持高效率地运行
6
程序编制及调试在逻辑数据库漏卜结构确定以后，应用程序设计的编制就可以和物理设计并行地展开程序模块代码通常先在模拟的环境下通过初步调试，然后再进行联合调试
联合调试的工作主要有以下几点：(1)建立数据库结构根据逻辑设计和物理设计的结果，用DBMS提供的数据语言(DDL)编写出数据库的源模式，经编译得到目标模式，执行目标模式即可建立实际的数据库结构
(2)调试运行数据库结构建立后，装入试验数据，使数据库进入调试运行阶段
运行应用程序，测试(3)装入实际的初始数据在数据库正式投入运行之前，还要做好以下几项工作：(1)制定数据库重新组织的可行方案
(2)制定故障恢复规范(3)制定系统的安全规范7
运行和维护数据库正式投入运行后，运行维护阶段的主要工作是：(1)维护数据库的安全性与完整性
按照制定的安全规范和故障恢复规范，在系统的安全出现问题时，及时调整授权和更改密码
及时发现返漏穗系统运行时出现的错误，迅速修改，确保系统正常运行
把数据库的备份和转储作为日常的工作，一旦发生故障，立即使用数据库的最新备份予以恢复
(2)监察系统的性能
运用DBMS提供的性能监察与分析工具，不断地监控着系统的运行情况
当数据库的存储空间或响应时间等性能下降时，立即进行分析研究找出原因，并及时采取措施改进
例如，可通修改某些参数、整理碎片、调整存储结构或重新组织数据库等方法，使数据库系统保持高效率地正常运作
(3)扩充系统的功能在维持原有系统功能和性能的基础上，适应环境和需求的变化，采纳用户的合理意见，对原有系统进行扩充，增加新的功能
D. 什么是分布式数据库结构
分类: 电脑/网络 >> 程序设计 >> 其他编程语言
问题描述:
请高人请点迷津
解析:
分布式软件系统(Distributed Sofare 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方式下更为灵活的解决方案。
--------------------
在分布式计算机操作系统支持下，互连的计算机可以互相协调工作，共同完成一项任务。
也可以这么解释:
一种计算机硬件的配置方式和相应的功能配置方式。它是一种多处理器的计算机系统，各处理器通过互连网络构成统一的系统。系统采用分布式计算结构，即把原来系统内中央处理器处理的任务分散给相应的处理器，实现不同功能的各个处理器相互协调，共享系统的外设与软件。这样就加快了系统的处理速度，简化了主机的逻辑结构.
易游贝贝祝你好运
E. NewSQL分布式数据库发展策略讨论
作者 石默研
本文对新一代NewSQL分布式数据库发展策略中的普遍困扰进行讨论，包括云原生（Cloud Native）与本地部署(On Premise)、HTAP进展方向、分布式与单机需求等分布式数据库商业与技术发展中难以决策的问题。
1. 困扰
分布式NewSQL数据库近年来蓬勃兴起，其原因显而易见：切中了业务与数据量不断增长的用户对关系型数据库RDBMS需求，这在传统RDBMS到大数据的发展阶段中，有相当一段时间是空白。同时，随着互联网技术的不断发展与普及，用云计算模式满足IT需求似乎已经成为未来 社会 产业互联网发展的明确趋势，也就是说，有一种共识：不久的将来，绝大多数产业的IT服务是从公共的、行业的或者私有的、混合的云计算中心提供的。这一共识又带来了云原生（Cloud Native）概念与技术的兴起，而分布式NewSQL数据库自然也应该是云原生的，这决定了其相当多的产品设计决策应以符合这一趋势为原则。然而，在当今的现实中，满足业务与数据量不断增长的RDBMS需求的用户，与云原生的用户，除了互联网企业外，大多数情况下，并不重合，需要On-Premise部署的用户仍然占有很大比重，这就带来了第一个困扰：云原生（Cloud Native）与本地部署(On Premise)对产品发展要求的矛盾。
另一个困扰，是关于HTAP，即交易与分析混合负载。HTAP是当今非常火的一个概念与技术，在交易库上直接进行分析，而不再是将“数据从交易库搬下来，挪到另一个数据库中去”这样的繁琐过程。可以毫不夸张的说： 历史 上规模性企业IT复杂度的相当一部分，都来自于“搬数据”，这导致了数据采集、实时采集、全增量合并、数据传输、数据加载、数据建模、数据质量、数据标准、企业级元数据管理等繁杂多样的技术环节的产生，导致了企业数据分布、数据流向、数据模型、主数据、基础数据平台、ODS/数据仓库/数据集市、数据治理等复杂的数据架构设计优化领域，导致了由于多系统大规模数据搬迁而带来的如数据交换平台之类的复杂调度工程......。咋眼一看，感觉该企业的数据技术好厉害，相关各领域的技术产品好丰富，技术人员的相关技能也好受欢迎。但如果在交易迟核宏库就能直接满足分析需求而不影响生产效能的话，这些复杂高级的技术环节不都成了“自己给自己造了一座山，还说自己爬的好辛苦”？然而，现实却是，问题并不这么简单，除了在交易库中进行分析会影响业务效能外，还有很多原因导致这一现象产生：交易库并不需要存储那么长的 历史 数据，而分析往往是需要建立在大量 历史 数据之上的；交易库的模型往往并不适合分析需求，多码册数情况下需要重要建模，如非常流行且价值不菲的各行业数仓主题模型；用于交易的OLTP数据库与用于分析的OLAP数据库，其技术体系完全不同；以及大型企业已固化的内部业务结构并没有留给交易/分析整合可实施的可行空间......等等。由于， 历史 积累的企业级数据体系相当复杂，HTAP的发明者迄今为止都没有系统表达完全替代数据分析需求、自顶而下重构企业数据体系的架构级策略，而是将产品重点定位在技术优化层面：在交易库上直接完成实时统计分析，满足高并发需求且不影响业务效能；或者是为实时分析统计/查询而建设的数据服务中间平台。然而，即使是暂时没有这种策略性的意向，在面向AP的产品具体研发中，又会发现明确的界限确实不好把握，随着一个个具体功能的不断完善，似乎假以时日，技术上也不是没有完全替代纯OLAP平台的可能性。那么，HTAP究竟如何定位呢？
再者就是规模化的分布式需求，与小规模的单机数据库需求（这里指逻辑上的单机）之间的矛盾：分布式数据库，自然而然是要应对规模化的数据管理需求的，长尾的小规模需求当然不应在产品设计考虑之列，同时，大炮轰苍蝇经常还打不好；然而，分布式NewSQL数据库又应该是云原生的，如果把云原生的业务含义理解为“全自助”，它应该以支持什么样的需求为主呢？现实看来，小规模长尾业务对云氏并原生数据库的需求最起码应该是占据相当大的比重的。显而易见，如果是大规模的数据管理需求，即使是部署在云上，DBPaaS的“全自助”是其核心需求吗？这种规模化的业务，如果是云上的On-Premise又需要做出哪些方面的改变？从互联网与云计算发展的 历史 来看，“云自助”，其最核心的商业动机当然包括给用户侧的运维带来了方便，但更重要的可能是给云服务运营商应对海量长尾客户的安装与运维带来了极大的成本优势。这正如银行的小微及个人消费贷款都要走互联网线上模式，而重客、大客甚至中小企业信贷仍然是以线下为主的策略一样，本质是成本问题，而不是客户方便性问题。于是，矛盾显而易见：分布式是面向规模客户的，起码是中、大型客户，而云原生却有可能、最起码相当一段时间内是要以长尾客户为主要服务对象的。
以上困扰实质上，都涉及到了NewSQL分布式数据库的产品发展策略问题。
2. 讨论
问题是客观而又普遍的，但分析与应对策略往往包含主观因素：人们的一个决定与决策，很多情况下并不由严格推理而来，而是心中已经有一个答案，再来找理由支持它。这里的讨论或许也并不能例外。
首先，来看看Cloud Native与On Premise。云原生本应是数据库即服务，然而目前真正有规模化数据增长需求的NewSQL应用相当多的情况下却是付费On Premise与免费On Premise区别，很多互联网企业的应用也可能只是部署在云基础设施上而已，真正的云原生更多是一些实验性、尝试性的需求。但云原生数据库在公有云、行业云以及大型私有云上已经逐渐在形成一种意识上的共识，其商业前景不可限量。也就是说，未来的数字化转型进程中，产业互联网的数据库部署，会逐渐向云基础设施迁移，长在云上。它可能是公有云，也可能是行业云，也可能是私有云，它们都是被定义为云原生NewSQL数据库的市场范围。当然，肯定还会有相当一部分数据库长在云下，这也不用纠结，将其排除在云原生市场战略目标之外即可，就是说，不需要考虑这部分客户需求对产品规划的影响，因为前一部分的份额已经足够大了。这样看来，以云原生为目标进行产品规划的逻辑没有问题，不过，还是要明确一点：长在云上的数据库是不是一定符合我们对“云原生”的既有理解？这里认为，即使未来，在云上形成了产业互联网数据库市场的主体，需要“全自助”的数据库即服务可能也是以面向长尾客户最为迫切、必不可少并且是核心本质，而对中大型以上的需求，“全自助”的意义相对有限，同时比较而言商业模式的转变或者更关键些。那么，如果是以“长在云上”为市场目标，似乎可以将其定义为“广义的云原生”，同时，只要是“长在云上”，那么“云原生”概念中高弹性、高可用、低成本、快速迭代、存算分离等技术优势也都能方便获得。而对“云原生”策略中“云原生”一词的理解不同，对产品规划决策的影响也应该有所不同：一是目前被认为是On Premise的客户需求，或许也就是未来“云原生”主体市场的需求；二是NewSQL数据库关于云原生服务的产品策划，对用户侧“自助”水平的决策或许可以更灵活实用。高水平自助确实可以减轻客户对IT的依赖程度，但这里认为，云原生与用户自行在云上购买资源进行On-Premise部署相比，最关键的价值在于商业模式的改变，能自助多少，不一定是最重要的，因为成为云服务商后，运营运维的工作只会更多，责任可能会更大，甚至有时连IaaS的运维也需要PaaS服务商兜底。但从一个个客户的本地服务，变成集中化云服务，就已经是本质性的模式转变了。总之，需要就事论事，回到原点，仔细分析后决策，而不是用概念教条的判断，因为概念本身的定义并不见得准确对应实际的业务需求。
再来看看HTAP，对这个问题，正如在其它文章中表达过的一样，本文的观点较为明确。一是随着计算能力与架构的升级，从技术上讲，AP与TP的界限会越来越模糊；另外特别是在云原生的新世界里，数据库的这一特性又犹为重要，因为云原生的重要作用之一就是要让客户尽量摆脱对IT运维的依赖，将越来越多的精力集中到自己的业务发展上来；同时端到端的能力提升对云原生商业模式的贯彻也至关重要（需要仔细分析下目前DBPaaS的技术要求是否完全符合这一原点的、本质性的动力），过去与纯OLAP数据库的优势比较纠结在这里也可以得到正面支持；再者，既然架构上已经走向了AP，就很难做到在产品规划上时刻厘清纯AP与混合负载的需求后，再将前者排除在外。于是，以“混合负载满足部分AP需求”应该是由于投入与阶段性市场策略导致的阶段性产品规划，而长远来讲，以一套技术架构满足大多数需求，应该是云原生NewSQL数据库的追求。
接下来，就是关于规模化分布式与小规模单机需求的矛盾了。现在看来，经过上面的讨论，这一点已经不是什么问题了：因为“长在云上”、从分散服务向集中服务的商业模式转变就是指广义的云原生，而不一定要以小微的、迫切需要全自助的长尾为主流，那么，云原生NewSQL数据库仍然应以规模化分布式为其主体的需求方向，而小规模单机则暂时可以不做为重点来考虑。
最后指出一点，希望也能引发进一步的思考：我们所批判的主机，也声称自己是分布式架构，暂且不论其是否客观，但在现实中主机需要被替代的核心问题并不是有没有分布式，而是：一、扩展不灵活带来成本问题：“我只需要扩展一个节点，你却让我再买一台主机”；二、不自主可控；三、往往是软硬件结合的设计策略，包括内存、网络、存储与IO上的软硬融合设计，而这一点，是否需要云原生数据库从广义的定义出发进行学习参考，也是需要进一步讨论的。
F. 分布式数据库系统(DDBS)概述
一 什么是分布式数据库
分布式数据库系统是在集中式数据库系统的基础上发展来的 是数据库技术与网络技术结合的产物
分布式数据库系统有两种 一种是物理上分布的 但逻辑上却是集中的 这种分布式数据库只适宜用途比较单一的 不大的单位或部门 另一种分布式数据库系统在物理上和逻辑上都是分布的 也就是所谓联邦式分布数据库系统 由于组成联邦的各个子数据库系统是相对 自治 的 这种系统可以容纳多种不同用途的 差异较大的数据库 比较适宜于大范围内数据库的集成
分布式数据库系统(DDBS)包含分布式数据库管理系统(DDBMS)和分布式数据库(DDB)
在分布式数据库系统中 一个应用程序可以对数据库进行透明操作 数据库中的数据分别在不同的局部数据库中存储 由不同的DBMS进行管理 在不同的机器上运行 由不同的操作系统支持 被不同的通信网络连接在一起
一个分布式数据库在逻辑上是一个统一的整体 即在用户面前为单个逻辑数据库 在物理上则是分别存储在不同的物理节点上 一个应用程序通过网络的连接可以访问分布在不同地理位置的数据库 它的分布性表现在数据库中的数据不是存储在同一场地 更确切地讲 不存储在同一计算机的存储设备上 这就是与集中式数据库的区别 从用户的角度看 一个分布式数据库系统在逻辑上和集中式数据库系统一样 用户可以在任何一个场地执行全局应用 就好那些数据是存储在同一台计算机上 有单个数据库管理系统(DBMS)管理一样 用户并没有什么感觉不一样
分布式数据库中每一个数据库服务器合作地维护全局数据库的一致性
分布式数据库系统是一个客户/服务器体系结构
在系统中的每一台计算机称为结点 如果一结点具有管理数据库软件 该结点称为数据库服务器 如果一个结点为请求服务器的信息的一应用 该结点称为客户 在ORACLE客户 执行数据库应用 可存取数据信息和与用户交互 在服务器 执行ORACLE软件 处理对ORACLE数据库并发 共享数据存取 ORACLE允许上述两部分在同一台计算机上 但当客户部分和服务器部分是由网连接的不同计算机上时 更有效
分布处理是由多台处理机分担单个任务的处理 在ORACLE数据库系统中分布处理的例子如
客户和服务器是位于网络连接的不同计算机上
单台计算机上有多个处理器 不同处理器分别执行客户应用
参与分布式数据库的每一服务器是分别地独立地管理数据库 好像每一数据库不是网络化的数据库 每一个数据库独立地被管理 称为场地自治性 场地自治性有下列好处
◆系统的结点可反映公司的逻辑组织
◆由局部数据库管理员控制局部数据 这样每一个数据库管理员责任域要小一些 可更好管理
◆只要一个数据库和网络是可用 那么全局数据库可部分可用 不会因一个数据库的故障而停止全部操作或引起性能瓶颈
◆故障恢复通常在单个结点上进行
◆每个局部数据库存在一个数据字典
◆结点可独立地升级软件
可从分布式数据库的所有结点存取模式对象 因此正像非分布的局部的DBMS 必须提供一种机制 可在局部数据库中引用一个对象 分布式DBMS必须提供一种命名模式 以致分布式数据库中一个对象可在应用中唯一标识和引用 一般在层次结构的每一层实施唯一性 分布式DBMS简单地扩充层次命名模型 实施在网络上唯一数据库命名 因此一个对象的全局对象名保证在分布式数据库内是唯一
ORACLE允许在SQL语句中使用全局对象名引用分布式数据库中的模式对象(表 视图和过程) 在ORACLE中 一个模式对象的全局名由三部分组成 包含对象的模式名 对象名 数据库名 其形式如
SCOTT EMP@SALES DIVISION ACME
一个远程查询为一查询 是从一个或多个远程表中选择信息 这些表驻留在同一个远程结点
一个分布式查询可从两个或多个结点检索数据 一个分布式更新可修改两个或两个以上结点的数据
一个远程事务为一个事务 包含一人或多个远程语句 它所引用的全部是在同一个远程结点上 一个分布式事务中一个事务 包含一个或多个语句修改分布式数据库的两个或多个不同结点的数据
在分布式数据库中 事务控制必须在网络上直辖市 保证数据一致性 两阶段提交机制保证参与分布式事务的全部数据库服务器是全部提交或全部回滚事务中的语句
ORACLE分布式数据库系统结构可由ORACLE数据库管理员为终端用户和应用提供位置透明性 利用视图 同义词 过程可提供ORACLE分布式数据库系统中的位置透明性
ORACLE提供两种机制实现分布式数据库中表重复的透明性 表快照提供异步的表重复;触发器实现同步的表的重复 在两种情况下 都实现了对表重复的透明性
在单场地或分布式数据库中 所有事务都是用MIT或ROLLBACK语句中止
二 分布式数据库系统的分类
( ) 同构同质型DDBS 各个场地都采用同一类型的数据模型(譬如都是关系型) 并且是同一型号的DBMS
( )同构异质型DDBS 各个场地采用同一类型的数据模型 但是DBMS的型号不同 譬如DB ORACLE SYBASE SQL Server等
( )异构型DDBS 各个场地的数据模型的型号不同 甚至类型也不同 随着计算机网络技术的发展 异种机联网问题已经得到较好的解决 此时依靠异构型DDBS就能存取全网中各种异构局部库中的数据
三 分布式数据库系统主要特点
DDBS的基本特点
( )物理分布性 数据不是存储在一个场地上 而是存储在计算机网络的多个场地上
逻辑整体性 数据物理分布在各个场地 但逻辑上是一个整体 它们被所有用户(全局用户)共享 并由一个DDBMS统一管理
( )场地自治性 各场地上的数据由本地的DBMS管理 具有自治处理能力 完成本场地的应用(局部应用)
( )场地之间协作性 各场地虽然具有高度的自治性 但是又相互协作构成一个整体
DDBS的其他特点
( )数据独立性
( )集中与自治相结合的控制机制
( )适当增加数据冗余度
( )事务管理的分布性
四 分布式数据库系统的优点
( )更适合分布式的管理与控制
分布式数据库系统的结构更适合具有地理分布特性的组织或机构使用 允许分布在不同区域 不同级别的各个部门对其自身的数据实行局部控制 例如 实现全局数据在本地录入 查询 维护 这时由于计算机资源靠近用户 可以降低通信代价 提高响应速度 而涉及其他场地数据库中的数据只是少量的 从而可以大大减少网络上的信息传输量;同时 局部数据的安全性也可以做得更好
( )具有灵活的体系结构
集中式数据库系统强调的是集中式控制 物理数据库是存放在一个场地上的 由一个DBMS集中管理 多个用户只可以通过近程或远程终端在多用户操作系统支持下运行该DBMS来共享集中是数据库中的数据 而分布式数据库系统的场地局部DBMS的自治性 使得大部分的局部事务管理和控制都能就地解决 只有在涉及其他场地的数据时才需要通过网络作为全局事务来管理 分布式DBMS可以设计成具有不同程度的自治性 从具有充分的场地自治到几乎是完全集中式的控制
( )系统经济 可靠性高 可用性好
与一个大型计算机支持一个大型的集中式数据库在加一些进程和远程终端相比 由超级微型计算机或超级小型计算机支持的分布式数据库系统往往具有更高的性价比和实施灵活性 分布式系统比集中式系统具有更高的可靠性和更好的可用性 如由于数据分布在多个场地并有许多复制数据 在个别场地或个别通信链路发生故障时 不致于导致整个系统的崩溃 而且系统的局部故障不会引起全局失控
( )在一定条件下响应速度加快
如果存取的数据在本地数据库中 那么就可以由用户所在的计算机来执行 速度就快
( )可扩展性好 易于集成现有系统 也易于扩充
对于一个企业或组织 可以采用分布式数据库技术在以建立的若干数据库的基础上开发全局应用 对原有的局部数据库系统作某些改动 形成一个分布式系统 这比重建一个大型数据库系统要简单 既省时间 又省财力 物力 也可以通过增加场地数的办法 迅速扩充已有的分布式数据库系统
五 分布式数据库系统的劣势
( )通信开销较大 故障率高
例如 在网络通信传输速度不高时 系统的响应速度慢 与通信相关的因素往往导致系统故障 同时系统本身的复杂性也容易导致较高的故障率 当故障发生后系统恢复也比较复杂 可靠性有待提高
( )数据的存取结构复杂
一般来说 在分布时数据库中存取数据 比在集中时数据库中存取数据更复杂 开销更大
( )数据的安全性和保密性较难控制
在具有高度场地自治的分布时数据库中 不同场地的局部数据库管理员可以采用不同的安全措施 但是无法保证全局数据都是安全的 安全性问题式分布式系统固有的问题 因为分布式系统式通过通信网络来实现分布控制的 而通信网络本身却在保护数据的安全性和保密性方面存在弱点 数据很容易被窃取
分布式数据库的设计 场地划分及数据在不同场地的分配比较复杂 数据的划分及分配对系统的性能 响应速度及可用性等具有极大的影响 不同场地的通信速度与局部数据库系统的存取部件的存取速度相比 是非常慢的 通信系统有较高的延迟 在CPU上处理通信信息的代价很高 分布式数据库系统中要注意解决分布式数据库的设计 查询处理和优化 事务管理及并发控制和目录管理等问题
六 分布式数据库系统 数据分片
类型
水平分片
按一定的条件把全局关系的所有元组划分成若干不相交的子集 每个子集为关系的一个片段
垂直分片
把一个全局关系的属性集分成若干子集 并在这些子集上作投影运算 每个投影称为垂直分片
导出分片
又称为导出水平分片 即水平分片的条件不是本关系属性的条件 而是其他关系属性的条件
混合分片
以上三种方法的混合 可以先水平分片再垂直分片 或先垂直分片再水平分片 或其他形式 但他们的结果是不相同的
条件
( )完备性条件
必须把全局关系的所有数据映射到片段中 决不允许有属于全局关系的数据却不属于它的任何一个片段
( )可重构条件
必须保证能够由同一个全局关系的各个片段来重建该全局关系 对于水平分片可用并操作重构全局关系;对于垂直分片可用联接操作重构全局关系
( )不相交条件
要求一个全局关系被分割后所得的各个数据片段互不重叠(对垂直分片的主键除外)
七 分布式数据库系统 数据分配方式
( )集中式 所有数据片段都安排在同一个场地上
( )分割式
所有数据只有一份 它被分割成若干逻辑片段 每个逻辑片段被指派在一个特定的场地上
( )全复制式 数据在每个场地重复存储 也就是每个场地上都有一个完整的数据副本
( )混合式 这是一种介乎于分割式和全复制式之间的分配方式
八 分布式数据库系统 体系结构
数据分片和数据分配概念的分离 形成了 数据分布独立型 概念
数据冗余的显式控制 数据在各个场地的分配情况在分配模式中一目了然 便于系统管理
局部DBMS的独立性 这个特征也称为 局部映射透明性 此特征允许我们在不考虑局部DBMS专用数据模型的情况下 研究DDB管理的有关问题
九 分布式数据库管理系统
接受用户请求 并判定把它送到哪里 或必须访问哪些计算机才能满足该要求
访问网络数据字典 了解如何请求和使用其中的信息
如果目标数据存储于系统的多个计算机上 就必须进行分布式处理
通信接口功能 在用户 局部DBMS和其他计算机的DBMS之间进行协调
在一个异构型分布式处理环境中 还需提供数据和进程移植的支持 这里的异构型是指各个场地的硬件 软件之间存在着差别
分布式数据库管理系统
lishixin/Article/program/Oracle/201311/16998
G. 如何用SQLServer建立分布式数据库
很多组织机构慢慢的在不同的服务器和地点部署SQLServer数据库——为各种应用和目的——开始考虑通过SQLServer集群的方式来合并。
将SQLServer实例和数据库合并到一个中心的地点可以减低成本，尤其是维护和软硬件许可证。此外，在合并之后，可以减低所需机器的数量，这些机器就可以用于备用。
当寻找一个备用，比如高可用性的环境，企橡纳业常常决定部署Microsoft的集群架构。我常常被问到小的集群(由较少的节点组成)SQLServer实例和作为中心解决方案的大的集群哪一种更好。在我们比较了这两个集群架构之后，我让你们自己做决定。
什么是Microsoft集群服务器
MSCS是一个WindowsServer企业版中的内建功能。这个软件支持两个或者更多服务器节点连接起来形成一个“集群”，来获得更高的可用性和对数据和应用更简便的管理。MSCS可以自动的检查到服务器或者应用的失效，并从中恢复。你也可以使用它来(手动)移动服务器之间的负载来平衡利用率以及无需停机时间来调度计划中的维护任务。
这种集群设计使用软件“心跳”来检测应用或者服务器的失效。在服务器失效的事件中，它会自动将资源(比如磁盘和IP地址)的所有权从失效的服务器转移到活动的服务器。注意还有方法可以保持心跳连接的更高的可用性，比如站点全面失效的情况下。
MSCS不要求在客户计算机上安装任何特殊软件，因此用户在灾难恢复的经历依赖于客户-服务器应用中客户一方的本质。客户的重新连接常常是透明的，因为MSCS在相同的IP地址上重启应用、文件共享等等。进一步，为了灾难恢复，集群的节点可以处于分离的、遥远的地点。
在集群服务器上的SQLServer
SQLServer2000可以配置为最多4个节点的集群，而SQLServer2005可以配置为最多8个节点的集群。当一个SQLServer实例被配置为集群之后，它的磁盘资源、IP地址和服务就形成了集群组来实现灾难恢复。
SQLServer2000允许在一个集群上安装16个实例。根据在线帮助，“SQLServer2005在一个服务器或者处理器上可以支持最多50个SQLServer实例，”但是，“只能使用25个硬盘驱动器符，因此如果你需要更多的实例，那么需要预先规划。”
注意SQLServer实例的灾难恢复阶段是指SQLServer服务开始所需要的时间，这可能从几秒钟到几分钟。如果你需要更高的可用性，考虑使用其神拆他的方法，比如logshipping和数据库镜像。
单个的大的SQLServer集群还是小的集群
下面是大的、由更多的节点组成的集群的优点：
◆更高的可用新(更多的节点来灾难恢复)。
◆更多的负载游如枣均衡选择(更多的节点)。
◆更低廉的维护成本。
◆增长的敏捷性。多达4个或者8个节点，依赖于SQL版本。
◆增强的管理性和简化环境(需要管理的少了)。
◆更少的停机时间(灾难恢复更多的选择)。
◆灾难恢复性能不受集群中的节点数目影响。
下面是单个大的集群的缺点：
◆集群节点数目有限(如果需要第9个节点怎么办)。
◆在集群中SQL实例数目有限。
◆没有对失效的防护——如果磁盘阵列失效了，就不会发生灾难恢复。
◆使用灾难恢复集群，无法在数据库级别或者数据库对象级别，比如表，创建灾难恢复集群。
虚拟化和集群
虚拟机也可以参与到集群中，虚拟和物理机器可以集群在一起，不会发生问题。SQLServer实例可以在虚拟机上，但是性能可能会受用影响，这依赖于实例所消耗的资源。在虚拟机上安装SQLServer实例之前，你需要进行压力测试来验证它是否可以承受必要的负载。
在这种灵活的架构中，如果虚拟机和物理机器集群在一起，你可以在虚拟机和物理机器之间对SQLServer进行负载均衡。比如，使用虚拟机上的SQLServer实例开发应用。然后在你需要对开发实例进行压力测试的时候，将它灾难恢复到集群中更强的物理机器上。
集群服务器可以用于SQLServer的高可用性、灾难恢复、可扩展性和负载均衡。单个更大的、由更多的节点组成的集群往往比小的、只有少数节点的集群更好。大个集群允许更灵活环境，为了负载均衡和维护，实例可以从一个节点移动到另外的节点。
H. 什么叫分布式数据库，有什么优点和缺点
①更适合分布式的管理与控制。
分布式数据库系统版的结构更适合具有地权理分布特性的组织或机构使用，允许分布在不同区域、不同级别的各个部门对其自身的数据实行局部控制。
②具有灵活的体系结构。
分布式DBMS可以设计成具有不同程度的自治性，从具有充分的场地自治到几乎是完全集中式的控制。
③系统经济，可靠性高，可用性好。
由于数据分布在多个场地并有许多复制数据，在个别场地或个别通信链路发生故障时，不致于导致整个系统的崩溃，而且系统的局部故障不会引起全局失控。
④在一定条件下响应速度加快。
如果存取的数据在本地数据库中，那末就可以由用户所在的计算机来执行，速度就快。
⑤可扩展性好，易于集成现有系统，也易于扩充。
I. 分布式数据库系统的数据分布方式有哪些(分布式数据库的特点是)
数据分布是分布式数据库的主要特征。实现数据访问的局部枯则化是分布式数据库设计的重要内容。文中桐段介绍了分布式数据库系统的主要特征及关键技术,重点对关系的分没轮棚割和分布式数据的访问进行了讨论。