TD基本架构介绍

一、并行数据库及其主要研究的问题  
并行数据库系统（Parallel Database System）是新一代高性能的数据库系统，是在MPP和集群并行计算环境的基础上建立的数据库系统。
并行数据库技术起源于20世纪70年代的数据库机（Database Machine）研究，，研究的内容主要集中在关系代数操作的并行化和实现关系操作的专用硬件设计上，希望通过硬件实现关系数据库操作的某些功能，该研究以失败而告终。80年代后期，并行数据库技术的研究方向逐步转到了通用并行机方面，研究的重点是并行数据库的物理组织、操作算法、优化和调度策络。从90年代至今，随着处理器、存储、网络等相关基础技术的发展，并行数据库技术的研究上升到一个新的水平，研究的重点也转移到数据操作的时间并行性和空间并行性上。
并行数据库系统的目标是高性能（High Performance）和高可用性（High Availability），通过多个处理节点并行执行数据库任务，提高整个数据库系统的性能和可用性。
性能指标关注的是并行数据库系统的处理能力，具体的表现可以统一总结为数据库系统处理事务的响应时间。并行数据库系统的高性能可以从两个方面理解，一个是速度提升（SpeedUp），一个是范围提升（ScaleUp）。速度提升是指，通过并行处理，可以使用更少的时间完成两样多的数据库事务。范围提升是指，通过并行处理，在相同的处理时间内，可以完成更多的数据库事务。并行数据库系统基于多处理节点的物理结构，将数据库管理技术与并行处理技术有机结合，来实现系统的高性能。
可用性指标关注的是并行数据库系统的健壮性，也就是当并行处理节点中的一个节点或多个节点部分失效或完全失效时，整个系统对外持续响应的能力。高可用性可以同时在硬件和软件两个方面提供保障。在硬件方面，通过冗余的处理节点、存储设备、网络链路等硬件措施，可以保证当系统中某节点部分或完全失效时，其它的硬件设备可以接手其处理，对外提供持续服务。在软件方面，通过状态监控与跟踪、互相备份、日志等技术手段，可以保证当前系统中某节点部分或完全失效时，由它所进行的处理或由它所掌控的资源可以无损失或基本无损失地转移到其它节点，并由其它节点继续对外提供服务。
为了实现和保证高性能和高可用性，可扩充性也成为并行数据库系统的一个重要指标。可扩充性是指，并行数据库系统通过增加处理节点或者硬件资源（处理器、内存等），使其可以平滑地或线性地扩展其整体处理能力的特性。
随着对并行计算技术研究的深入和SMP、MPP等处理机技术的发展，并行数据库的研究也进入了一个新的领域，集群已经成为了并行数据库系统中最受关注的热点。目前，并行数据库领域主要还有下列问题需要进一步地研究和解决。
  （1）并行体系结构及其应用，这是并行数据库系统的基础问题。为了达到并行处理的目的，参与并行处理的各个处理节点之间是否要共享资源、共享哪些资源、需要多大程度的共享，这些就需要研究并行处理的体系结构及有关实现技术。
  （2）并行数据库的物理设计，主要是在并行处理的环境下，数据分布的算法的研究、数据库设计工具与管理工具的研究。
  （3）处理节点间通讯机制的研究。为了实现并行数据库的高性能，并行处理节点要最大程度地协同处理数据库事务，因此，节点间必不可少地存在通讯问题，如何支持大量节点之间消息和数据的高效通讯，也成为了并行数据库系统中一个重要的研究课题。
  （4）并行操作算法，为提高并行处理的效率，需要在数据分布算法研究的基础上，深入研究联接、聚集、统计、排序等具体的数据操作在多节点上的并行操作算法。
  （5）并行操作的优化和同步，为获得高性能，如何将一个数据库处理事务合理地分解成相对独立的并行操作步骤、如何将这些步骤以最优的方式在多个处理节点间进行分配、如何在多个处理节点的同一个步骤和不同步骤之间进行消息和数据的同步，这些问题都值得深入研究。
  （6）并行数据库中数据的加载和再组织技术，为了保证高性能和高可用性，并行数据库系统中的处理节点可能需要进行扩充（或者调整），这就需要考虑如何对原有数据进行卸载、加载，以及如何合理地在各个节点是重新组织数据。

二、并行数据库的基本体系结构 收藏
并行数据库要求尽可能的并行执行所有的数据库操作，从而在整体上提高数据库系统的性能。根据所在的计算机的处理器（Processor）、内存（Memory）及存储设备（Storage）的相互关系，并行数据库可以归纳为三种基本的体系结构（这也是并行计算的三种基本体系结构），即共享内存结构（Shared-Memory）、共享磁盘结构（Shared-Disk）和无共享资源结构（Shared- Nothing）。
1、共享内存（Shared-Memory）结构
该结构包括多个处理器、一个全局共享的内存（主存储器）和多个磁盘存储，各个处理器通过高速通讯网络（Interconnection Network）与共享内存连接，并均可直接访问系统中的一个、多个或全部的磁盘存储，在系统中，所有的内存和磁盘存储均由多个处理器共享。
在这种结构中，（1）提供多个数据库服务的处理器通过全局共享内存来交换消息和数据，通讯效率很高，查询内部和查询间的并行性的实现也均不需要额外的开销；（2）数据库中的数据存储在多个磁盘存储上，并可以为所有处理器访问；（3）在数据库软件的编制方面与单处理机的情形区别也不大。
这种结构由于使用了共享的内存，所以可以基于系统的实际负荷来动态地给系统中的各个处理器分配任务，从而可以很好地实现负荷均衡。
这种结构硬件资源之间的互连比较复杂，硬件成本较高；由于多个处理器共享内存，所以系统中的处理器数量的增加会导致严重的内存争用，因此系统中处理器的数量受到限制，系统的可扩充性较差；此外，由于共享内存的机制，会导致共享内存的任何错误将影响到系统中的全部处理器，使得系统的可用性表现得也不是很好。
2、共享磁盘（Shared-Disk）结构
该结构由多个具有独立内存（主存储器）的处理器和多个磁盘存储构成，各个处理器相互之间没有任何直接的信息和数据的交换，多个处理器和磁盘存储由高速通信网络连接，每个处理器都可以读写全部的磁盘存储。
这种结构常用于实现数据库集群，硬件成本低、可扩充性好、可用性强，且可很容易地从单处理器系统迁移，还可以容易地在多个处理器之间实现负载均衡。
这种结构的一个明显不足是多个处理器使用系统中的全部的磁盘存储，因此，当处理器增加时可能会导致磁盘争用而导致的性能问题。
这种结构还有另外一个不足：系统中的每一个处理器可以访问全部的磁盘存储，磁盘存储中的数据被复制到各个处理器各自的高速缓冲区中进行处理，这时会出现多个处理器同时对同一磁盘存储位置进行访问和修改，最终导致数据的一致性无法保障，因此，在结构中需要增加一个分布式缓存管理器来对各个处理器的并发访问进行全局控制与管理，这会带来额外的通信开销。
3、无共享资源（Shared-Nothing）结构
该结构由多个完全独立的处理节点构成，每个处理节点具有自己独立的处理器、独立的内存（主存储器）和独立的磁盘存储，多个处理节点在处理器级由高速通信网络连接，系统中的各个处理器使用自己的内存独立地处理自己的数据。
这种结构中，每一个处理节点就是一个小型的数据库系统，多个节点一起构成整个的分布式的并行数据库系统。由于每个处理器使用自己的资源处理自己的数据，不存在内存和磁盘的争用，提高的整体性能。另外这种结构具有优良的可扩展性——只需增加额外的处理节点，就可以以接近线性的比例增加系统的处理能力。
    这种结构中，由于数据是各个处理器私有的，因此系统中数据的分布就需要特殊的处理，以尽量保证系统中各个节点的负载基本平衡，但在目前的数据库领域，这个数据分布问题已经有比较合理的解决方案。
    由于数据是分布在各个处理节点上的，因此，使用这种结构的并行数据库系统，在扩展时不可避免地会导致数据在整个系统范围内的重分布（Re-Distribution）问题。

目前，在并行数据库领域，Shared-Memory结构很少被使用了，Shared-Disk结构和Shared-Nothing结构则由于其各自的优势而得以应用和发展。Shared-Disk结构的典型代表是Oracle集群，Shared-Nothing结构的典型代表是Teradata，IBM DB2和MySQL的集群也使用了这种结构。

三、Teradata数据库的架构组成
       Teradata在整体上是按Shared Nothing 架构体系进行组织的（关于Shared Nothing及其它并行数据库体系结构请参考我的另一篇文章“并行数据库的基本体系结构”），由于Teradata通常被用于OLAP应用，因此单机的Teradata系统很少见，即使是单机系统，Teradata也建议使用SMP结构以尽可能地提供更好的数据库性能，我在后面的介绍中，都是按多机系统进行说明的。
根据Shared Nothing的组成结构特点，在物理布局上，Teradata系统主要包括三个部分：处理节点（Node）、用于节点间通信的内部高速互联（InterConnection）和数据存储介质（通常是磁盘阵列）。每个节点都是SMP结构的单机，节点的物理和逻辑结构如图2所示，多个节点一起构成一个MPP系统，多个节点之间的内部高速互联是通过一种被称为BYNET的硬件来实现的，整个系统的组成如图1所示。
单个节点的硬件结构
Teradata系统中的每个节点在物理上都是一个SMP处理单元，事实上就是一台多CPU或多核的计算机。节点硬件包括CPU、内存、用于安装操作系统和应用软件的本地磁盘、与外界交互的网卡及BYNET端口。节点的网卡根据具体的网络环境而不同，通常包括两种，一种是与IBM MainFrame连接的Channel Adapter，另一种就是我们熟悉的局域网网卡。通常情况下，一个节点上只会使用一种网卡，但会有多块网卡，分别用于不同的连接和冗余。
单个节点的软件结构
在软件结构上，每个节点自下向上包括操作系统软件（OS）、Teradata并行数据库扩展（PDE）和相关应用程序，其中PDE的主要职责是管理和运行虚拟处理器，其中主要包括PE和AMPs。
（1）Teradata并行数据库扩展（PDE，Parallel Database Extensions），是直接架构在操作系统之上的一个接口层，用于为Teradata提供并行环境，并保证这个并行环境的可运行性和健壮性。PDE的主要功能是执行虚拟处理器、进行Teradata并行任务调度、进行操作系统内核和Teradata数据库的运行时故障处理。
（2）虚拟处理器（VPROC，Virtual Processor），是一系列软件进程，这些进程驻留在一个节点上，依赖PDE环境运行，并接受PDE调度。我认为可以把VPROC理解为一些Teradata的底层服务进程。虚拟处理器完成Teradata数据处理的主要工作，按照工作性质的不同，虚拟处理器主要包括两大类——解析引擎和存取模块处理器。
（3）解析引擎（PE，Parsing Engine），用于进行客户系统（通常是使用Teradata数据库的应用程序的SQL请求）和存取模块处理器之间的通讯和交互，主要的功能包括任务控制（Session Control），SQL语句的解析、优化、查询步骤的生成和分发，并行化预处理和返回查询结果。一个节点上通常只有一个或两个PE在工作。
（4）存取模块处理器（AMP，Access Module Processor），这是Teradata数据库的关键进程，用于处理所有与数据有关的文件系统的操作任务，是Teradata数据库Share Nothing架构的核心表现。通常情况下，一个节点上会有多个AMP在工作，每个AMP分别负责文件系统上不同的、固定的数据的存取操作。
（5）虚拟磁盘（VDisk，Virtual Disk），这是一个纯粹的逻辑概念，事实上不应该把它认为是软件结构的一部分。典型的Teradata MPP系统的数据存储都是以磁盘阵列（Disk Arrays）的形式实现的，在物理上是一个个存放于标准磁盘阵列柜中的磁盘阵列模块。Teradata系统中的每个AMP在处理数据存储时，会根据一种哈希算法把不同的数据均匀地分散存储到磁盘阵列中的不同的磁盘上（详细内容会在后续系列文章中说明）。这样，在逻辑上，我们就把磁盘阵列中不同磁盘上存储着的那些由同一个AMP负责存储和维护的数据合并在一起，就像它们在一个磁盘上一样，这就是VDisk的概念了。
BYNET
在Teradata MPP系统中，各个节点间（确切地说是各个AMP之间）的内部高速互联是通过BYNET实现的，我们可以认为它就是Teradata系统中那些松散耦合的节点之间互相联系的通讯总线，但事实上，它却远远没有这么简单。
BYNET是一组硬件和运行在这组硬件上的一些处理通讯任务的软件进程的组合体，用于节点之间的双向广播（bidirectional broadcast）、多路传递（multicast）和点对点通信（point-to-point communication），同时，BYNET还实现SQL查询过程中的合并功能（在后面的“并行化查询技术”中会详细说明）。

四、数据分布机制（1） 概述
对于基于Shared Nothing架构的并行数据库来说，数据分布（Data Distributing）（或者被称为数据安置 Data Placement）是不可避免的；同时，整个系统的数据在多个处理单元上的分布状况也决定了系统的整体性能——如果大量的数据被分布在某一个（或少数几个）处理单元上，那么，这一个（或者少数几个）处理单元的工作负载会很大，进而成为系统整体性能的瓶颈。因此，对于基于Shared Nothing架构的并行数据库，如何在整个系统上进行数据分布是数据库整体设计时需要重点考虑的一个问题。Teradata作为业界最高效的并行数据库，其数据分布机制是其全部并行机制的底层核心，只要理解了Teradata的数据分布机制，就可以掌握Teradata的全部并行功能的实现机制。
Teradata的数据分布是整个系统范围内的数据分布，是跨AMP的数据分布，是针对每一个实体表的数据分布。在前面的讨论中我们知道，AMP是Teradata数据库系统中具体数据的持有者和直接操作者，整个Teradata数据库系统中的每一条数据都唯一关联到某一个AMP上。同时，对于系统中的每个表，其数据都会均匀（并非绝对均匀）地分布在系统中的全部AMP上，也就是说，在整个系统范围内容的所有AMP上，都有系统中的所有的实体表，只是同一个表在不同的AMP上实际存储的数据并不相同。那么，Teradata是如何做到这一点的呢？答案就是本篇文章要讨论的Teradata的基于哈希算法的数据分布机制。
在进行Teradata数据库的逻辑设计时，对于每一个表，都要指定一个“主索引”（Primary Index，简称PI，关于Teradata的索引，我将在后续的文章中进行详细说明），Teradata数据库引擎会根据这个主索引的实际值，同时根据系统的配置情况（主要是AMP的个数），通过一种哈希算法，为每个表的每一条数据都生成一个“行哈希值”（Row Hash Value），Teradata会根据这个行哈希值把数据分布到某一个确定的AMP上。
在上图所示的数据分布的过程中，在值20和30所在列上定义了Primary Index，系统的哈希算法根据20和30这两个值，生成了两个不同的行哈希值，之后系统根据这两个行哈希值的内容，把20和30各自所对应的行分别分布到了不同的AMP上进行存储了。
在获取数据的时候（SELECT、UPDATE、DELETE都是获取数据的SQL操作），系统会使用与进行数据分布时相同的哈希算法对20和30进行哈希运算，这会得到相同的行哈希值，系统就根据这个行哈希值直接定位到20或者30各自所在的AMP，并由各自对应的AMP返回要获取的行。
根据哈希算法，对于不同的Primary Index值，可能会计算出相同的行哈希值，这些具有相同的行哈希值的数据行就会被分布在同一个AMP上。这样，如果哈希算法选择得当，则可以基本保证，同一个表中的数据在整个Teradata并行系统的多个AMP上的分布是趋于均匀的。
对于一个Teradata系统，其哈希算法是确定的，而且是运行时不可变的，在系统的硬件不变的前提下（AMP数不变），这就保证了对于同一个Primary Index值，所生成的行哈希值也是相同的。因此，对于不同的表，尤其是有主-外键关联关系的表，通过慎重地定义Primary Index，可以做到那些经常要进行关联（往往是主-外键关联）的行会被分布到同一个AMP上，这大大缩短了数据库进行数据关联的时间，提高了Teradata系统的性能。

四、Teradata 数据库技术概略之三 —— 数据分布机制 哈希算法

我们知道，哈希（Hash）是一个数据映射的过程，该过程将任意长度的的二进制值映射为某一固定长度的二进制值，后面的这个生成的固定长度的二进制值被称为哈希值（Hash Value），而哈希过程中为了映射而使用的具体方法被称为哈希函数（Hash Function），也就是通常所说的哈希算法。根据哈希算法和冲突处理办法，可以把哈希生成的哈希值分布到一个有限的线性地址空间上，不同的哈希值可能会被分布到相同的地址空间，这样就构成了一个表，这个表就是哈希表（Hash Table），或者被称为散列（因此哈希函数有时也被称为散列函数）。在哈希表中，每一个哈希值都唯一地对应于表中的某一个存储位置，这个位置被称为哈希地址（Hash Address）。哈希表中，对应于前面有限的线性地址空间中的某一个空间地址的一系列哈希地址在整体上被称为哈希桶（Hash Bucket），对于一个已经存在的哈希表，其哈希桶的数量是固定的。下面两个表格所表示分别是使用“N Mod 6”和“N Mod 8”两种算法（取模是最简陋但最具有代表性的哈希算法）生成的哈希表，表中绿色背景的部分代表了哈希桶，在两个表中，我们可以分别称它们为1号哈希桶和4号哈希桶。同时我们可以看到，两个哈希表的哈希桶的数量分别为6个和8个。
Teradata提供了几种不同的哈希算法供用户选择，用于处理其数据分布，这些哈希算法相互之间没有本质上的不同，主要的区别就是为了处理不同的字符集。对于一个Teradata系统，只能使用一种哈希算法，并且，该哈希算法在运行时不可修改。Teradata的哈希算法最终生成的是一个32位长度的哈希值。
从上一篇的讨论中我们知道，Teradata根据要存储的每条记录的Primary Index（以后简称PI）值生成一个行哈希值，而这个行哈希值决定了这条记录具体会被分布到哪个AMP上。Teradata把行哈希值切分成两个部分，前一部分叫做哈希桶数（Hash Bucket Number），后一部分是保留值（Remainder），其中哈希桶数部分的值决定了该行哈希值所对应的记录会被分配到哪个哈希桶中（也就决定了该行哈希值所对应的记录会被分布到哪个AMP上），而哈希桶数部分的长度则决定了系统中最多可以有多少个哈希桶。在切分时又包括两种切分方式，一种是切分成“16＋16”的形式，另一种是切分成“20＋12”的形式。这样，在“16＋16”方式中，系统中共包括216即65536个哈希桶，在“20＋12”方式中，系统中共包括220即1048576个哈希桶。
Teradata的行哈希值的长度为32位，其最多有大约42亿（232）个可能的值，因此，为了在整个系统中唯一标识某一条数据记录，Teradata在每个行哈希值后面又增加了一个32位的唯一值（Uniqueness Value），并与行哈希值连接在一起，称为RowID。具体组成可以参考下图。RowID通常是被表的Secondary Index（SI，将在后文“索引”部分详细说明）所使用，用于在Teradata数据库中快速定位数据记录。
Teradata 数据库技术概略之四 —— 数据分布机制（3） Hash Map
从前面文章的介绍中我们知道， Teradata根据要存储的每条记录的PI值按照某种哈希算法生成一个行哈希值，生成的这个行哈希值的前16位或20位代表了这个行哈希值在哈希表中的哈希桶的编号，而这个哈希桶号则决定了这条记录具体会被分布到哪个AMP上，那么，Teradata是如何根据哈希桶号就知道把数据分布到对应的AMP上的呢？这就要通过本篇所要讨论的Hash Map（至于Hash Map，我一直也找不到合适的中文译法，称为“哈希地图”或者“哈希图”都有那么点意思，但我感觉都不太好，所以在后面的介绍中，我就都直接使用Hash Map了）。
我们可以把Hash Map理解成一种机制，它最终使得Teradata把某个数据记录分布到某个AMP上。在逻辑上，可以认为Hash Map是一个二维表，表中总共包含了65536或者1048576个单元格，每个单元格中记录了一个哈希桶号，而这个哈希桶号唯一对应了Teradata系统中的一个AMP，整个二维表中，会有多个哈希桶号对应到一个AMP上。
根据上面的描述可以得出这样的结论：（1）对于一个给定的Teradata系统，Hash Map的内容是确定的；（2）对于多个不同的Teradata系统，如果它们使用相同的哈希桶数（65536或者1048576），而且它们包含了相同的AMP个数，那么，它们的Hash Map是完全相同的，是可互换的。
由于Teradata系统要保证数据记录尽可能均匀地分布到系统中所有的AMP上，也就是说65536或者1048576个哈希桶号要尽可能平均地对应到每个AMP上，但由于AMP个数的原因，这个“平均”往往不可能真正做到。我们举例说明，假设系统使用65536个哈希桶，系统中共有200个AMP，那么我们可以计算得出：其中136个AMP上会分配到328个哈希桶，而另外的64个AMP上会分配到327个哈希桶。这就导致了在数据分布上的“倾斜”（Skew）的问题，而且这种倾斜通常是不能避免的。可以计算一下倾斜率：
（328-327）÷ 328 × 100 ＝ 0.31％
下面的表格列出了在系统配置为65536个哈希桶时，不同AMP数的情况下的倾斜率：
可以看到，随着AMP数的增加，倾斜率也在近似线性地增加，所以在建设Teradata系统的时候，对系统的哈希桶数要进行慎重选择，Teradata的推荐做法是：当系统中的AMP数大于1000时，把系统的哈希桶数设置为1048576，以尽量减小数据分布的倾斜率。
在Teradata系统中，Hash Map是一直驻留在内存的，系统建立完成后，Hash Map就一直存在且一成不变，直到系统的哈希桶数被改变或者系统中的AMP数发生了变化（由于变化的代价很高，这两种情况都不常见）。Hash Map是由BYNET维护的，并且在生成后会被复制传送到系统中的每个节点（并非AMP）上。
为了满足不同的管理需要，每个Teradata系统都同时存在着五种不同类型的Hash Map，它们分别是 Current Configuration Primary Map、Current Configuration Fallback Map、Reconfiguration Primary Map、Reconfiguration Fallback Map、Bit Map Hash Map。关于这些Hash Map的具体作用和相互之间的不同之处，请参考Teradata的相关资料。
Teradata系统通过Hash Map把数据记录分布到AMP上，数据记录到达AMP后，AMP会根据该数据记录的RowID来确定该数据记录具体存储在存储介质的什么位置上。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9999499/viewspace-615213/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9999499/viewspace-615213/