CN101128827A - 用于交换网络中分布式数据管理的方法和装置 - Google Patents
用于交换网络中分布式数据管理的方法和装置 Download PDFInfo
- Publication number
- CN101128827A CN101128827A CNA2006800058701A CN200680005870A CN101128827A CN 101128827 A CN101128827 A CN 101128827A CN A2006800058701 A CNA2006800058701 A CN A2006800058701A CN 200680005870 A CN200680005870 A CN 200680005870A CN 101128827 A CN101128827 A CN 101128827A
- Authority
- CN
- China
- Prior art keywords
- data
- channel
- access system
- key
- data storage
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
一种数据访问系统将数据处理从数据存储器中去耦合,从而提供了改善的可访问性、完整性、缩放性和其它特征。该系统包括:布置在虚拟分区中每个均可独立访问的数据库单元,多个数据处理单元,以及用于在所述虚拟分区之间切换所述数据处理单元的交换网络,从而将数据处理能力动态分配给各个虚拟分区。
Description
技术领域
本发明涉及一种用于数据管理的方法或装置,尤其涉及但并不专用于使用分布式架构的这种方法或装置。
背景技术
分布式数据储存库
多数关键业务数据储存库都创建为运行在通过数据网络互联的若干计算服务器上的分布式系统,即分布式数据储存库。分布式数据储存库的实例有:文件系统、目录和数据库。将关键业务数据储存库创建为分布式系统主要是为了提供高可用性和高缩放性。
1.提供高可靠性,以使得单个计算服务器故障在整体上不会损害包括每个数据元素在内的数据储存库的可用性。
2.以两种尺度提供了高可靠性:(1)数据量和(2)读/写交易率(吞吐量)。在任一情况下,如果可以向系统添加更多的计算服务器来支持更多的数据量和/或更高的交易率,则分布式数据储存库都具有高缩放性。关键业务分布式数据储存库的缩放性还要求“在线缩放性”,其意思是该系统可以在继续提供数据管理服务的同时进行缩放。
实时事件处理
当分布式数据储存库是执行实时事件处理的数据应用服务时,那么还期望分布式数据储存库以支持高响应性。
3.为实时数据储存库提供高响应性,以使得能够以高概率保证在预定时间量内完成每次读取和每次写入交易。在实时数据储存库中,同样期望高可用性和在线缩放性需求,以在故障和缩放性事件期间保持系统的连续高响应性。
实时事件处理数据应用的实例有:电信通话控制,移动电话归属位置寄存器(HLR)、互联网多媒体系统(IMS),归属用户服务器(HSS)、在线银行和交易系统。
期望关键业务实时数据储存库系统具有高可用性、高缩放性和高响应性。支持这些需求组合非常具有挑战性。响应性需求可能建议为交易分配专用计算资源,或者使专用计算资源专用于交易,以确保其在要求的时间量内完成。该策略使得典型的流水线和分时处理调度对于加速交易率的效率变低,同样也会不利地影响响应性。
另一方面,高可用性需求通常建议将每个关键业务数据项存储在高度可用的存储设备上(例如,RAID-独立磁盘冗余阵列),这意味着在提交和完成之前需要将每次写入交易写入至磁盘。另外,在写入计算机元件已经故障的情况下,数据将不可访问。即使当运行在具有大量CPU(SMP-对称多处理)的大型计算服务器上时,该策略仍降低了所实现的交易率。
在许多情况下,关键业务数据储存库可以同时由若干不同计算实体(客户机)来访问以进行读/写交易,因此分布式数据储存库还需要提供系统范围(system-wide)的一致性。如果从每个客户机的观点来看,每个数据元素值中的改变顺序相同,则认为数据储存库具有“一致性”(或“顺序一致性”)。
在支持众多并发客户机执行写入交易的分布式数据储存库的多数实现中,一致性需求在交易率方面还是系统缩放性的限制因子。其原因在于,写入交易必须串行化,因而在未定的(pending)写入交易已经完成之前,通常必需延迟读取交易。当不同的交易访问不同数据元素(即,独立交易)时,由于数据在系统内部组织的方式(例如,在相同磁盘上,在相同存储器上等等),因此通常执行读/写交易的串行化。
“全部共享”(Shared All)分布式高速缓存一致性架构
传统的分布式数据储存库(诸如Oracle实时应用群集以及其它群集)使用高度可用的存储器(通常使用RAID技术)来存储关键业务数据,同时在内存保持数据副本的本地高速缓存一致性(CacheCoherence)。该“全部共享”分布式高速缓存一致性架构可以提供灵活的主动/主动(active-active)N+M高度可用性,使得可以利用所有的计算节点来共享所有的数据处理负荷。在一个或更多节点故障的情况下,可以利用幸存节点来接管故障节点所进行的数据处理。
在图1中示出了“全部共享”分布式高速缓存一致性架构。该架构能够提供读取交易率的缩放性,即向系统添加更多节点可以增加读取交易率。然而,由于需要在所有本地高速缓存之间协调每次写入,因此“全部共享”分布式高速缓存一致性架构通常没有得到或者甚至得到负的写入交易速率缩放性。因此,当向系统添加更多节点时,要花费很长时间来提交和完成每次写入交易,因此要在所有本地高速缓存之间维持高速缓存的一致性。当交易中大部分是写入交易时,提交和完成写入交易的延迟增长使得“全部共享”分布式高速缓存一致性架构不再适合于支持要求实时交易处理的应用。当存在大的写交易率时,就无法满足响应性要求,而由于上述提及的实时事件处理应用通常具有高写入交易速率,因此这成为难以解决的问题。因此,“全部共享”分布式高速缓存一致性架构不适合于这种大规模展开的应用。
“无共享”(Shared Nothing)数据分割架构
其它分布式数据储存库(诸如IBM DB2 UDB和MySQL)使用诸如图2中示出的“无共享”数据分割架构。在无共享架构中,分布式数据储存库系统被分割成若干独立的分布式数据储存库子系统,并且每个管理不同的数据部分。在“无共享”数据分割架构中,每个分区可以看作是“全部共享”分布式高速缓存一致性子系统,每个分区均具有其自己的高度可用的存储器。
该“无共享”数据分割架构克服了写入率缩放性问题,这是由于该系统具有的独立分区越多,就可以以无阻塞的方式对不同的分区并发地执行越独立的写入交易。因此,通过这种架构的写入提交响应性也可以得到很好的处理。
“无共享”数据分割架构的关键在于将计算资源分割与数据分割紧密耦合。这意味着,计算资源静态地分配给每个数据分区。当系统写入率增加时,那么扩大系统的仅有方式是将系统重新分割成更多分区,并将更多的计算资源分配给新的分区。该缩放过程通常将要求在分区之间对数据进行重新分配,并且该过程不能在不损害系统继续提供高响应在线数据库服务能力的情况下实现。因此,重新分割通常需要计划的整个系统的停机时间。因此,在“无共享”数据分割架构中可以实现在线缩放性。另外,为了全部利用“无共享”数据分割架构的潜在并发性,客户机应用程序通常需要知晓数据划分的方式,这意味着重新分割事件同样要求客户机应用程序自身的改变。这使得管理和维护“无共享”数据分割架构的耗费很大。
“内存”数据储存库架构
已经出现了其它的数据储存库架构,所述的架构集中在降低交易延迟以提供更好的响应性以及提供整体更优的交易率。通过在单台机器的一个充分大的内存中保持所有的数据,并通过在内存内部直接执行所有数据库操作来实现所述目标。访问计算机工作存储器的延迟比访问诸如磁盘的存储设备短数个数量级。因此,通过在内存中管理所有数据,数据储存库可以得到更短的交易延迟,因而得到更高的交易率。
关键业务内存数据储存库通常将系统复制成两个或更多相同实例,以经过局域网使在复制实例之间内存数据连续同步(与“全部共享”架构的高速缓存一致性机制中相同)。基于网络的数据提交增加了完成写入交易的延迟,并因此还降低了写入交易速率。然而,基于网络的数据同步启用了故障容错。
当上述变化时,就可能提供两种或更多冗余数据储存库,同时在储存库之间进行更新。
现在参考图3,图3示出了具有故障容错的内存储存库。
内存数据储存库不能超出单个计算服务器提供的性能和写入交易速率进行缩放。缩放内存数据储存库系统的性能和/或写入交易速率的仅有方式是向计算系统添加更多的内存,或者在计算系统的内存容量最大时,将系统移至具有内存更大和CPU更多的更大计算机系统(即更大的SMP服务器)。两种缩放性策略都要求计划的系统停机时间,因此就不能遵从高可用性和在线缩放性要求。仅通过添加更多的计算服务器既无法缩放性能也无法缩放写入交易速率。
内存数据储存库通常要求应用程序和数据库协同定位来实现最大性能和较小延迟。这增加了数据库的实际成本,这因为数据库是按照每个CPU来定价的,但是CPU并不仅仅专用于数据库,还用于应用程序。因此消耗CPU和内存资源的实际应用显著降低了数据库的实际价值性能。另一方面,将内存数据库和应用程序划分成独立的单元使得资金的最大利用耗费在数据库上,因此这种做法通常降低了使用内存数据库开始可以得到的性能。
因此广泛认为存在对结合了上述系统的所有优点并避免了其不利之处的系统的需要,并且得到这样的系统将会非常有利。
发明内容
根据本发明的一个方面,提供了一种数据访问系统,所述系统包括:
布置在虚拟分区中的每个均可独立访问的数据库单元;
多个数据处理单元;以及
交换网络(结合了一个或更多互连的交换单元),所述交换网络用于在虚拟分区之间切换数据处理单元,从而将数据处理能力动态地分配给各个虚拟分区。
优选地,每个数据库单元可作为各个网络信道独立访问。
所述系统可以包括用于对数据执行散列处理(hashing process)的散列单元,其中通过散列处理的结果将数据分配给各个数据库单元。
优选地,以一个或更多表集合的形式来分配数据。优选地,以具有主关键字(primary key)和/或一个或更多辅助关键字的记录的集合形式来分配每个表。对关键字之一执行散列处理,此处是表的引导关键字(leading key)。表的引导关键字可以是包括复合关键字的任何关键字,复合关键字其意思是多于一个字段和/或非唯一关键字和/或外关键字。
优选地,以具有主关键字和可能的一个或更多辅助关键字的记录形式分配数据,并且其中基于引导关键字为每个记录分配主地址,即“主散列”,并且还可能地基于辅助关键字分配一个或更多辅助地址,也称作辅助散列。
两个或更多表可以共享相同的引导关键字。通常这种关键字还可以是外关键字,但是并不是必须的。结果是,对于来自共享相同主关键字的不同表中的所有记录,主散列地址保持相同。因此在需要时还可以作为单个数据实体来管理所述记录。
两个或更多表还可以共享一个或更多辅助关键字,因此来自不同表中的记录同样可以共享辅助散列地址。
该系统可以包括解析单元,用于将辅助地址解析为相应的主地址。
优选地,解析单元包括至少一个路由器。还可以提供备份路由器,以确保系统的高可用性。仅一个备份路由器就足以确保在一个路由器故障之后,剩余的路由器仍能继续进行辅助地址至主地址的解析,因而使得使用辅助地址可以继续得到数据元素。
还可以通过使系统保持内部索引表来进行辅助关键字解析,即路由,所述内部索引表根据辅助关键字是否唯一,将辅助关键字映射到一个或更多主关键字。使用辅助关键字作为索引表的引导关键字跨过所有虚拟分区对内部索引表执行散列。在这样的情况下,通过读取索引表来执行将辅助关键字路由为主关键字,与读取其它表时的方式相同。
该系统可以配置成使得通过若干数据处理单元来管理和存储每个虚拟分区,使得在数据处理单元故障后,系统仍可以提供对所有数据的访问。
优选地,每个虚拟数据分区具有奇数个副本。奇数确保了版本之间的多数表决能够通常地工作。优选地,通过基于多数的群组决定来执行所有数据处理,包括写入和读取操作,并且即使当因某些数据处理单元故障而每个虚拟分区中的少数副本丢失时,系统仍可以继续提供数据的不中断访问。少数副本具有的最大尺寸是系统的故障容错的等级。例如,如果系统对于每个虚拟数据分区具有5个副本,那么在没有失去对于每次读写交易的多数表决的情况下,能够丢失高达每个虚拟数据分区的两个副本。在没有失去系统中每个数据元素的可访问性的情况下,可以丢失高达两个的副本。
该系统可以包括选举(election)功能,用于为每个虚拟分区动态指定数据处理单元其中之一作为群首或者协调器,以在冲突和并发写入操作之间进行仲裁。
该系统可以包括选举功能,用于为虚拟分区动态分配数据处理单元。
该系统可以包括在第一数据处理单元故障后被触发的自愈合机制,使得将丢失副本的虚拟数据分区重新分配给所有或者部分剩余数据处理单元。结果是使得系统的故障容限回到目标水平。
电信级(carrier grade)系统的通常需求是5个9的可用性(99.999%)。现在,对于大型系统,假定每个基础数据处理单元本身具有99.9%的可用性并假定在数分钟内触发自愈合机制,则具有每条数据记录或者虚拟分区的三个副本就足够了。对于超出5个9水平的和/或兆级别大型系统的极佳可用性,具有5个副本就足够了。除非另外定义,此处使用的所有技术和科技术语的含义与本发明所属技术领域普通技术人员通常所理解的含义相同。此处仅仅示出了所提供的物质(materials)、方法和实例,并且其目的不是为了进行限制。
本发明的方法和系统的实施涉及到手动、自动或者两者结合完成或者执行特定的选择任务或者步骤。另外,根据本发明的方法和系统的优选实施例的实际装置和设备,可以通过硬件或者软件或者其结合在任何固件的任何操作系统上完成若干所选步骤。例如作为硬件,本发明的所选步骤可以作为芯片或者电路得以实施。作为软件,本发明的所选步骤可以作为通过使用任何适当操作系统的计算机执行的多个软件指令得以实施。在任何情况下,本发明的方法和系统的所选步骤可以描述为通过诸如用于执行多种指令的计算平台的数据处理器来执行。
附图说明
此处仅参考附图通过实例的方式描述本发明。现在将详细地具体参考附图,需要强调的是,仅仅为了示例性地讨论本发明优选实施例而以实例的方式特别示出了本发明,并且介绍的目的是为了提供认为最有用的内容,并使得更容易理解本发明的原理和概念方面的描述。关于这一点,不是更详细地示出本发明的结构细节,而是示出了基本理解本发明所需的内容,结合附图的描述使得本领域技术人员清楚本发明的若干形式可以如何在实际中具体得以实施。
附图中:
图1示出了现有技术的全部共享分布式高速缓存一致性架构;
图2示出了现有技术的无共享架构,其中将数据分割成不同的数据节点,并如同管理具有分布式高速缓存一致性的全部共享一样来管理每个分区;
图3示出了现有技术的内存数据储存库结构的故障容错,其中所有数据保持在内存中,并在不同计算单元的两个或更多内存之间进行完全复制和同步;
图4示出了根据本发明的优选实施例的简化图示,其中使用交换信道网络以在虚拟分区和计算单元之间进行动态映射,在这种简化情况下,没有复制虚拟分区,并且在计算单元和虚拟分区之间可以存在一对多关系,因此每个计算单元存储和管理一个或更多虚拟数据分区的单个副本;
图5示出了图4中架构的简化图示,但是此次使用了数据复制,因此在计算单元和数据复制之间存在多对多关系:每个计算单元存储和管理了一个或更多虚拟数据分区,而每个数据分区由3个计算单元进行存储和管理;
图6-8示出了根据本发明优选实施例的分层数据组织的树形结构,其可以使用基于分层的虚拟分区来代表;
图9示出了根据本发明优选实施例的分割程序的简化流程图。
图10A和10B示出了具有两级子信道的信道,还示出了根据本发明优选实施例的信道分层内的微储存库的分配。
图11和12B示出了图4架构的部件的简化方框图,其中根据本发明的优选实施例虚拟分区是基于分层结构;
图12A示出了使用本发明优选实施例的三阶段提交写入操作的简化流程图;
图12C示出了根据本发明优选实施例的故障恢复操作的简化流程图;
图12D示出了根据本发明优选实施例的自愈合操作的简化流程图;
图13和图14示出了根据本发明优选实施例作为自愈合机制一部分的数据微储存库和服务器的重新映射的方框图;
图15示出了根据本发明优选实施例的信道交换网络图和组播生成树(multicast spanning tree);
图16示出了根据本发明优选实施例的网络的一部分,并示出了客户设备;
图17和18示出了根据本发明的优选实施例的分布式信道散列实施的方框图;
图19和图20A分别示出了根据本发明优选实施例如何使用辅助关键字执行数据映射的方框图和流程图;
图20B示出了在存储了3和5个副本以及两个不同可用性等级情况下,每秒钟操作次数相对于数据存储单元数量XDB的可用性和性能图表;
图21和22示出了根据本发明的优选实施例如何维持过程状态的方框图;
图23示出了根据本发明的优选实施例使用用于维持过程状态的状态数据的方框图;
图24示出了本发明优选实施例的简化视图,其中按照群组来交换信道。
具体实施方式
本实施例包括用于使用组播域网络创建分布式数据储存库的装置和方法。本实施例的数据储存库包括将数据分割从计算机资源分割中去耦合。这种架构的优势在于,它提供了得到保障的响应性、高可用性、高缩放性和动态在线缩放性。提供了一种类似于无共享架构的系统,但是通过将数据映射到网络信道来使用虚拟分割替代物理分区,所述网络信道是一种群组地址。然后通过使用交换网络寻址管理和路由将网络信道动态映射至计算资源。其结果是提供了数据分割从计算资源分配中的去耦合。数据处理从数据存储器脱离关系,因而可提供的虚拟信道数量仅仅受到网路寻址空间的限制。可以任意地对数据处理资源进行重新分配。
在一个实施例中,用于搜索数据的寻址空间可以包含单个数据记录的多个地址,所述单个数据记录允许使用主关键字、辅助关键字或者附加关键字来分配数据。
下面描述的实施例描述了“网内(in-network)”数据储存库架构。该架构定义了分布式数据储存库系统的创建,所述分布式数据储存库系统在分布式架构上结合了“全部共享”、“无共享”和“内存”的所有优势,同时又避免了每种解决方案的缺点,这将在下面更加详细地说明。该架构具有上述“内存”架构的响应性。同时,“网内”架构具有上述“全部共享”架构的N+M高度可用性和对称的负荷平衡,但是没有会限制系统的缩放性和响应的阻塞元素。
另外,此处描述的“网内”架构具有上述“无共享”架构的无阻塞数据分割属性。然而,在不同的数据分区之间不需要进行明确的数据分割或者进行明确的计算资源分配,因此系统可以实现计算元件之间的动态负荷平衡和真正的高速响应性,下面将说明这一点。
参考附图结合说明书可以更好地理解根据本发明的装置和方法的原理和操作。
在详细地说明本发明的至少一个实施例之前,应当理解的是本发明在应用时并不受附图中示出和下面说明书中所阐述的部件结构和结构细节的限制。本发明能够具有其它实施例或者能够以各种方法来实施或者执行。同样还应当理解的是,此处使用的措辞和术语是用于说明的目的,而不应看作是限制。
现在参考图4,图4示出了本发明的第一优选实施例的示意图示。数据访问系统包括布置在虚拟分区中的每个均可独立访问的数据库单元以及多个数据处理单元。还提供了切换单元,用于在所述虚拟分区之间切换所述数据处理单元,从而将数据处理的能力动态分配给各个虚拟分区。更加具体地讲,在图4中,数据分区401.1,...,401.M被映射到信道1,...,M。计算节点403.1至403.K,每个都包括内存并经过交换机连接至信道,从而建立了栅格式(grid-type)网络。
图4示出了其中使用交换信道网络在虚拟分区和计算单元之间进行动态映射的架构。在该简化情况下,没有复制虚拟分区,并且在计算单元和虚拟分区之间可以存在一对多关系,因此每个计算单元存储和管理一个或更多虚拟数据分区的单个副本。
图4中示出的分布式数据储存库架构以这种无阻塞的方式来组织数据和处理的能力,因此使内存中独立读/写交易服务的并发性最大化,同时提供较高级别的响应性、一致性和较容易的缩放性。
上述优势通过以下操作来实现:
1.将数据分割从计算资源分割中去耦合。结果是以结合了“全部共享”的零管理缩放性方式实现了“无共享”的无阻塞并发性。
2.管理内存的数据,从而实现了上面提到的“内存”架构。
通过使用交换信道网络并生成此处称作信道的中间网络架构来执行对数据分区和计算资源分区的去耦合,使得将数据分割静态地映射到网络信道,同时可以将计算资源动态地分配给那些网络信道。因此分配给一个或更多信道的每个计算服务器在其内存中保持映射到其信道中的所有数据分区。
计算服务器和信道之间的映射并不需要是一对多的关系,还可以是多对多的关系。因此可以将若干计算服务器分配给相同信道,使得数据分区在内存被复制并使其在分配给同一信道的所有计算服务器之间得到同步。
现在参考图5,图5以略微更加详细的方式示出了图4中的实施例,以说明数据从复制的计算分区中去耦合。与图4中相同的部分给出了相同的附图标记,并且不再再次提及,除非在理解该相同实施例时需要。交换信道网络允许任何数据分区根据需要动态地连接至任何计算节点。
图5具有与图4相同的基本架构,但是不同之处在于提供有数据复制。数据复制允许在计算单元和数据复制之间的多对多关系。每个计算单元存储和管理了一个或更多虚拟数据分区,而每个数据分区由3或5个计算单元进行存储和管理。
图5的实施例中包括下列要素:
1.通过使用中间网络信道并经过交换信道网络实施独立的双映射,将数据分区从计算分区中去耦合:
a.数据分区401.1-401.M至基本网络信道信道1,...,信道M的一对一静态映射。
b.计算服务器403.1...403.k至信道信道1,...,信道M的多对多动态映射。
2.提供网络信道方法来利用标准分组网络,以确保线速度(wirespeed)响应性和信道分配的实时重新配置。
3.其中的分布式数据管理协议是数据访问协议或XDAP。
4.使用路由网络的数据索引以及分割的索引表处理,来确保经过备选的辅助索引对相同数据访问的线速度。
图5中示出的分布式数据储存库架构以这种无阻塞的方式来组织数据和处理能力,因此使内存中独立读/写交易服务的并发性最大化,而没有损害响应性级别、一致性、缩放性和可用性级别。
上述优势通过以下操作来实现:
将数据分区从计算资源分割中去耦合,实现了具有“全部共享”透明缩放性的“无共享”无阻塞并发性,管理跨过网络进行内存中复制的数据分割,实现“内存”的响应性和故障容限。
现在将通过描述可应用于最多数据储存库的分层数据分割来说明本发明的另外方面。本发明可以应用于若干数据类型,包括但并不仅限于所提及的那些数据类型。数据类型描述之后是如何使用发布-订购(publish-subscribe)网络信道将分层数据分区从计算分割中去耦合的描述,然后讨论如何使用标准分组网络来实施这种“被发布被订购”的网络信道。
在信道实施之后,描述的是上面已提到的核心分布式数据管理协议(XDAP),所述协议确保了线速度数据同步、交易完整性、故障容限、在线缩放性和自愈合。
下面是利用标准路由网络以及索引表分割处理的索引方法的描述。
数据分割分层
现在参考图6,图6示出了树形数据分层601。数据储存库中的数据元素通常被分割成类似树的结构中的分层,所述类似树的结构代表了“部分”关系或者整个次序的关系。例如,关系数据库就以这种模式进行组织。每种模式以表进行组织。每个表具有记录列表,每个记录具有不同的关键字值。
部分关系(p)很好定义了这种分层中的关系。在上面的实例中:″音乐库″603″唱片数据库″605″爵士唱片″607″Power ofThree″609″Limbo.mp3″611。
图7示出了另一实例文件系统。图7的实例示出了组织成文件夹分层结构的目录系统701。在该分层结构中,每个文件夹包含其它的文件和/或文件夹。每个文件包括块列表。
在上面的文件系统实例中也很好的定义了部分关系():“根目录文件夹”703″程序文件夹″705″Adobe文件夹″707″Acrobat6.0文件夹″709″AcroRd32.exe文件″711.
现在参考图8,图8示出了树形结构的又一实施例。在图8中,将文件目录创建为列表树810,而该列表中的每个元素要么是数据记录要么是数据记录列表。
在树801中,数据以分层形式进行组织,因此每个数据元素在数据储存库中具有唯一的“坐标”,例如″DNS目录″″.i1″″.co.i1″″.xeround.co.i1″″www.xeround.co.i1″.
数据元素坐标唯一表示了该元素,因此可以总是作为写入交易的一部分来提供。在许多情况下,还在读取交易中提供特定的数据坐标。例如为了解析www.xeround.co.i1域名的IP地址,将在目录查询中提供特定的坐标。然而,一些读取查询还可以指代该分层中的更高的等级,例如“all domain names in.co.i1”(所有.co.i1中的域名)。在这种情况下,该查询“选择”子树以从中读取信息。
此处在下面描述的实施例教导了一种使用基于分层散列函数来组织数据和处理数据储存库中资源的方法,所述方法将所有数据元素映射到构成分布式数据储存库骨干(back-bone)的网络信道的分层中,所述分布式数据储存库支持所有类型的查询,同时提供了响应性、数据一致性、交易完整性、超高缩放性、动态在线缩放性和高度可用性。
数据分区从计算分区中的去耦合
创建的分布式基于分层散列数据储存库包括组播网络信道的分层结构,这使得可将不同查询路由至不同信道,另一方面使得不同的计算服务器可以订购任何信道集来接收其所有消息。此处在下面列举了可用于实现这种发布-订购网络信道机制的不同标准的网络技术。
现在参考图4,在信道中其自身定义了命令“≥”,该命令的意思是“位于相同信道或者子信道中”,即,信道1≥信道1.1≥信道1.1.1,同时信道1.1≥信道1.2且信道1.2≥信道1.1。
在图9的流程图中示出了去耦合,所述去耦合包括下列部分:
●微(μ)分割903:将全球数据储存库静态和虚拟地分割成多个独立微储存库(μ储存库905),每个订购至不同的信道集。微储存库的数目可以上千或者甚至更多。
●散列907:对数据储存库坐标使用单调的基于分层散列函数,以将所述数据储存库坐标映射至信道。当abh(a)≥h(b)时,散列函数h( )具有单调性。该方案使用了理想的散列函数(即在目标信道中均匀分布)来使得并发性最大化。散列函数实际将全局数据储存库分割成许多独立的μ储存库。
●复制909:将每个μ储存库复制成一式三份(或者甚至五份或者更多)的相同独立副本。将所有相同μ储存库的副本订购给相同的信道集。正如将在下面更加详细讨论的那样,使用多数原理用于查询交易完整性、数据一致性和高度可用性的结果。
●分布和洗牌911:μ储存库副本聚集至计算服务器中。每个μ储存库是计算服务器上的单个进程、线程、表或者子表。因此,将每个计算服务器订购给其μ储存库的信道。μ储存库在计算服务器之间得到良好的分布和洗牌,以使得负荷平衡最大化以及依存性和阻塞最小化。
现在将参考图10A,图10A示出了被分成子信道的信道系列的概念图。因此,信道1被分成信道1.1和信道1.2。依次又将信道1.1分成子信道1.1.1,1.1.2和1.1.3。
现在参考图10B,图10B示出了分配给信道和子信道的微储存库。从应用了复制和洗牌原理的实例可以看出的是,订购给子信道的每个μ储存库还订购给了级别在该信道之上的所有信道。
网络信道发布-订购方法
此处以发布-订购机制来提供网络信道,使得每个服务器可以在任何信道上发布消息,即发送消息。然而,仅仅预先订购给信道的服务器可读取在信道上正在发布的消息。可以在任何时间将任何服务器动态地订购给任何信道或者从任何信道中取消订购(un-subscribe)。同时可以将给定服务器订购给许多信道。
下面将描述使用标准分组网络来实施这种网络“发布订购”信道的若干方法。
分布式数据访问和管理协议XDAP
回头参考图9,在被称为“查询路由器”(或XDR-数据路由器)分布式计算部件中执行坐标散列807。现在参考图11,图11示出了使用查询路由器1101.1,1101.3的网络架构。每个查询路由器同时处理多个请求。可以存在与解决方案所需的查询路由器一样多的查询路由器,以支持生成读/写查询/交易的所有数据储存库客户机。将每个客户机预先配置成依靠一个或更多特定查询路由器工作。查询路由器代表至其客户机的数据储存库,因此查询路由器接收读/写查询、执行查询并然后将查询状态或者结果值返回给客户机。
查询路由器使用下列通用算法来处理查询:
查询路由器使用根据引导或者辅助关键字形成的查询坐标来将查询散列并路由至正确的信道。应当注意,每个服务器可以写至任何信道。然而,仅仅订购给信道的服务器会接收到其消息。读取交易处理与写入(插入、更新、删除)交易处理不同。查询路由器可以将单个查询变换成若干读取交易、写入交易和锁定动作。查存路由器生成这种查询执行计划或者访问计划,然后如下所述执行每种这样的交易。正如数据库领域中通常使用和公知的方式一样来执行锁定动作。
读取交易:在一个阶段中执行基于引导关键字的读取交易,所述一个阶段即“切换阶段”,其中读取请求被切换至正确的信道,接着该过程等待被订购给该信道的μ储存库,以相对于其自身的内部数据储存库独立计算读取查询,并将其结果返回给请求数据路由器。在从μ储存库接收到与读取查询结果相关的足够信息之后,数据路由器对信息进行整合,计算查询,并将结果返回给客户机。
通过使路由阶段在切换阶段之前,来执行基于辅助关键字的读取交易。该路由阶段包括将辅助关键字映射到主关键字,接着在如上所述的切换阶段中使用所述主关键字。路由阶段可以通过使用路由器来实现,或者还可以通过依赖于正确的辅助索引表执行读取交易来实现。辅助索引表将辅助关键字映射至原始表中的引导关键字。因此,索引表的引导关键字是原始表的辅助关键字,因而如同上述一个切换阶段中的基于引导关键字的交易一样,来执行这种索引读取交易。当通过网络路由器来实施该路由阶段时,XDR则使用将辅助关键字映射到唯一网络地址的另一散列部分(hash faction),所述读取交易被发送至所述唯一网络地址。路由器现在接收消息以重新定向该查询,或者将该查询路由至正确的信道,以使得从XDR的观点来看,基于辅助关键字的读取交易同样需要单个阶段。
写入交易:写入交易通过订购给给定信道的所有服务器来接收。然而,写入交易的分布式提交过程通过特定协调器来管理,所述特定协调器从使用三阶段提交协议的给定信道成员中选出。一旦在协调器的管理下完成了三阶段提交,协调器以写入交易完成指示向XDR回报,然后指示被转发给客户机。因为允许从不同源同时访问相同数据记录,因此需要协调器,在同时写入尝试事件中仍必需维持数据完整性。
将使读者参考与基于多数的群首选择(leader election)相关的部分,此处将在下面更加详细描述与协调器的选择相关的细节。
更加详细地讨论了在提供无阻塞并发处理、顺序一致性、交易完整性和故障容限的同时进行的写入查询和读取查询处理。
写入交易处理
现在将参考图12A,图12A示出了写入交易的简化流程图。写入交易可以包括插入、修改或者删除交易。插入交易总是指定了添加至它的特定数据记录的全部坐标“C”,即引导关键字。然而,删除和修改交易并没有提供引导关键字。它们可以提供辅助关键字值或者某些其它搜索标准。在未把引导关键字指定为写入交易的一部分的情况下,那么XDR需要最先执行读取交易,所述读取交易用来查找需要修改或删除的所有记录,然后使用手头的引导关键字值执行写入交易。此处图12A的描述假定已经识别了写入交易的引导关键字。为了确保已在所有副本中成功完成写入操作,写入操作使用所有μ储存库副本来执行3阶段提交协议。如上所述,该提交协议由被选择为协调器的一个服务器来协调。
特别地,为每个信道都选出一个协调器。由协调器来启动任何交易的提交。协调器使得独立的交易串行化。并发读取,其含义是发生在写入访问期间的读取访问通常使用更新之前的记录版本来完成,或者备选地,等待更新后的版本。如果应用程序请求在更新期间执行读取时,则读取还可能会失败。同样,一旦写入已经提交(响应已经发送给查询路由器)时,就新的读取不会接收先前的版本作为响应。
协调器优选使用单调计数器来标记其在每个信道上启动的每次交易。3阶段提交的第一阶段是发送交易给所有的参与者。因此协调器发送交易给所有参与者。下一步骤是选择他们的预提交(pre-commit)或放弃响应。经过单个协调器来维持原子交易(Atomictransactions),因此信道的所有成员相对于每次交易一直完全同步地工作。因此,响应必须总是相同(以三阶段提交的术语来讲,是预提交或者放弃)。由于完全同步,因此当响应为预提交(即,存在协议阶段的合并)时,信道成员可以即刻在本地提交交易。当接收到多数肯定应答时(预提交或者放弃),协调器可以以适当的响应来响应查询路由器。
在写入操作期间,为了能够在协调器故障的情况下恢复,所有成员保留有交易信息。为了维持信道成员的整体同步特性,协调器持续将交易转发至所有成员,直至他们已经全部应答。需要重复转发或者说随后缺少应答表明信道中存在故障,必须重新组织该信道以反映出该故障。一旦存在关于交易以及什么部件出现故障的一致意见,则可以对其进行整理,这是由于信道成员的多数投票能够产生多数意见,因此进行恢复。然后协调器可以在常规的三阶段提交协议中发送本质上与最终提交的消息相似的消息,将所述消息中继至同意该交易的所有成员,接着可以清除它的所有信息。
现在,将复合交易管理分解为原子交易集,一个协调器负责整个交易,而其它协调器可以处理原子子交易。在一个或更多原子子交易故障时,那么复合交易协调器负责退回或者取消复合集中已经完成的其它原子子交易。
为减少网络报文,且由于中继相同交易的其它部分相关信息不需要实时进行,因此“其它部分”信息还可以作为“捎带确认”(piggyback)在其它交易上发送。更加具体地,每个常规交易消息包含有最大交易id,该交易ID之前的所有交易或者包括该交易的所有交易已经全部被信道放弃。
这种协议可以经得起信道中少数成员(包括协调器本身)的任何故障,同时维持数据库的原子性、一致性、隔离、持久性或者ACID属性。数据库系统的ACID属性允许数据的安全共享。没有这些ACID属性,每天发生诸如使用计算机系统来购买产品将非常困难,并且不准确的可能将很大。因此,如果同时多于一个人试图从给定的计算机化目录来购买相同的尺寸和颜色的毛线衫-常规事情,ACID属性使得零售商能够使这些毛线衫购买交易免于相互交叠--使零售商免遭错误的存货和帐户平衡。将上述操作转换为写入访问,则上述协议确保了总体监控程序负责整个信道,以使得可以在控制之下保持写入操作。
上面协议的根本效果在于,如果多数成员已经对给定交易做出应答,那就如同已经从那些机器中移除了对象的先前版本一样,随后的任何读取决不包含对象的先前版本。随后读取将得到新版本或者超时。当恢复时,要么已经对所有成员实施了写入交易,或者原始多数中所有成员或者至少一个成员仍具有交易内容,因此将确定最终对当前成员实施了写入交易。一旦这种情况发生时,那么读取将不会再超时,其将包含对象的新版本。
数据记录的每次成功写入生成了唯一的“证书”,即当前记录的顺序写入号,只要该协议已经成功操作,则对于所有副本,期望的是记录最后数值证书都是相同的。该证书用于作为读取过程一部分的数值认证。
读取过程
如同上述写入查询一样,查询的读取过程要求查找正确的记录,然后输出查找之后的信息。正如将重新想起的,相同的数据记录存在于多于一个的位置处。
现在,通常以引导关键字来存储数据记录,所述引导关键字可以是从中检索记录的第一可搜索字段。数据记录还可以具有其它可搜索字段。优选地构造数据库使得引导关键字的使用可以被散列以提供记录的直接寻址。
如果读取查询包括数据元素的引导关键字,则:
1.通过XDR将该查询散列并切换至正确的信道。
2.根据该信道,每个具有该记录版本的XDB接收该查询。
3.通过XDB将结果返回给请求XDR,包括记录内容和指示最后写入操作的证书。
4.在XDR接收到足够(多数)的一致结果(即相同值和相同证书)之后,将检索的内容作为结果值发送回客户机。
如上所述,现在多于一个字段是可检索的。因此,在主要打算通过姓名来查找特定号码电话的电话号码簿的情况下,姓名字段将构成主关键字。然而,如果需要电话号码簿还可以反向查询,因此可以输入号码来查找姓名。在这种情况下,查询将包括非引导关键字。如果读取查询包括这种数据元素的非引导关键字(可以是主索引或辅助索引),那么读取查询首先依赖于索引表进行匹配,以提供主关键字。在上述实例中,电话号码是唯一的,因此可以产生单一的结果,但是许多这种关建字并不必然就是唯一的,而是可以检索到多于一个的结果。查询过程然后如上所述使用引导关键字或者多个引导关键字来定位数据元素或者多个数据元素。下面将更加详细地参考辅助索引。如果检索主关键字,那么将产生正确信道。
现在搜索查询可以根本不包括关键字。当读取查询不包括数据元素的主关键字时,也没有至该数据元素的辅助索引(即这是一个flat“搜索”查询),则该读取查询必须“选择”分层中的一个或更多级别以在其中搜索(或者默认是全部搜索,其含义是选择了根目录)。图6的文件目录结构上进行的不是关键字的条件查询的实例如下:
1.查询长于10分钟的爵士曲目(选择了“爵士唱片”)
2.查找25岁或者更年轻的艺人的唱片(联合查询-选择了“爵士唱片”和“艺人库”)
图12B示出了用于将图6的分层转换为信道分层的分层散列函数映射。在图12的映射中,图6的结构表和每个数据库被映射到符号为超级信道1、超级信道2等的超级信道,并将给定表内的所有数据元素映射到子信道集合。例如,将“爵士唱片”表映射到超级信道2.1,将所有的爵士记录入口散列到信道2.1.x集。
引用了特定爵士记录的任何读取查询被直接映射到信道2.1.x其中之一。然后,如果在数据库中存在记录,那么就在所有μ储存库副本中将详情订购给相同信道。
任何“选择了”“爵士唱片”表的读取查询将映射到超级信道2.1。接收搜索查询的每个μ储存库相对于其内部储存库独立地执行查询,并返回检索到的任何结果。查询路由器将多数原理应用于每个单独μ储存库结果的副本,然后合并所有结果将其返回给客户机。
通过原子“选择”交易的序列作为复合交易来实施联合数据查询。一次可以执行单独的查询,布置复合查询以确保一个选择的结果影响在下面选择中根据联合数据查询要求的任何逻辑进行的查询。
恢复和自愈合
现在将参考图12C,图12C示出了自愈合过程的简化图示。上述该系统承受任何单个故障,因此任何单个故障不会损害系统的可用性和功能性。系统中故障容限的等级可以通过使用每个数据记录的更多μ储存库副本来进行配置。然而,当出现故障时,系统失去了一些“故障容限”等级,并且可能不会在另一些故障中幸免。因此,现在将讨论称作“自愈合”的“故障容限恢复”机制,该机制自动恢复要求的故障容限等级。
在下面,我们将描述故障容限恢复的完全对称的分布式自愈合机制,在第一次故障之后的一个可配置的时间量触发该机制。
μ储存库中的故障可以通过位于相同信道上的同等物(peer)来自动识别。
当检测到μ储存库故障时,可以实施下列恢复过程:
1.μ储存库所属的其它信道成员识别出信道上的储存库之一出现故障。如果信道的协调器不是有故障的协调器,那么该协调器通过向信道中添加新的服务器来启动信道成员集合的改变,以招待(host)丢失的μ储存库副本。通过信道协调器使新近被重新招待的副本与信道重新同步。随后信道上的写入交易反映出图12D中描述的该变化。
2.备选地,如果故障服务器是信道的协调器,那么信道中的剩余服务器选出新的信道协调器,所述新的信道协调器协调服务器至信道的添加,并协调信道数据的添加,如上面1中的图12D所述。
正如在图12C中所述,当服务器故障时,需要在所有故障服务器订购的信道中进行恢复过程。在某些这些信道中,故障服务器是协调器,因此作为恢复过程的一部分,需要为信道选出新协调器。为了协调所有恢复信道的恢复过程,选出一个总体“自愈合”协调器,以通过使用预先编辑的恢复计划或者如果需要通过生成新的恢复计划来协调恢复过程。这样的恢复计划可以认为是如图14所示的“恢复矩阵”,其规定了在故障的服务器上招待的每个μ储存库副本应当有效地移植到幸存服务器中的哪一个。使用该系统,数据重新平衡,因此故障服务器的损失对其招待的μ储存库上的数据可用性的影响最小。
现在将参考作为图表的图13,其中七个列B1,...,B7代表七个服务器。这七个服务器之间的服务器招待了三十五个信道C1,...,C35。每个服务器被订购给15个信道-通过方框中的填充来代表,每个订购代表了正在招待的μ储存库。因此,正如所示出的那样,七个服务器每个均招待15个μ储存库。每个μ储存库复制了三次,以给出映射到35个信道的35个基础μ储存库的一式三份总计105个副本。B1和C11之间的交叉被填充,其含义是服务器2正招待μ储存库11的副本,且因此还被订购至信道11。
现在参考图14,图14示出了如何改变图13的结构以补偿谈论的第三个服务器的故障。虽然B3故障,但是在其它两个位置存在有以黑色阴影标出的服务器3上的所有储存库。在恢复计划中,举例来讲服务器7从紧急信道接收到“服务器3停机”的紧急信号,然后启动三个新的μ储存库复制过程来复制位于信道1,3和4上的储存库,从而复制在B3/C1、B3/C2和B3/C4丢失的微储存库。从在那些信道上所订购的其它两个副本中复制内容。同样,服务器6复制信道6,8和10上的内容。服务器5复制信道11、15和18上的内容。服务器4复制信道19、22和26上的内容,然后服务器2和1在其之间共享信道30至33。以黑色阴影示出了复制的储存库。
信道实施
如上所述,信道实施了等级散列简图。信道可以被简单地认为是μ储存库之间的共享媒体。然而当添加储存库时,通常共享媒体并不能很好地缩放。这是因为当密度增加时,共享媒体在所有的储存库上增加了处理压力。
因此通过打开了互连节点图的切换底层结构和支持μ储存库作为叶子的最小组播生成树来实现最有效的网络架构。
现在参考图15,图15示出了表示组播生成树的信道交换网络图的示意图示。
可以定义具有应用转发节点的应用层交换网络。作为DHT(分布式散列表)实施中的界标(Land Mark),转发节点也是公知的。在物理、链路或者网络层中使用映射到标准网络技术的地址空间的信道散列函数是有效的。这种方法允许切换散列图经过现有的标准网络设备来实施。这种信道散列图使得能够毁坏用于实现信道的计算层,并能够导致信道内分布式切换散列的线速度处理。因此,这种散列图的使用使得散列示意图能够有效、高速、节省成本且高度缩放地实现。
基于标准的信道实施
基于可以保存散列分层的地址空间的标准包括:
●IETF IP V4或V6
●ATMF ATM VCI VPI
●IEEE 802.D Ethernet dotl QinQ VLAN
●ITUT E.164
还支持标准组播信道内联注册/订购协议的标准网络环境例如包括:
●用于IP的IGMP
●用于VLAN的GARP
●用于ATM的UNI-NNI信令
还可能选择非分层地址空间,诸如IEEE MAC地址,并构造多层子网网络以实现信道散列方案。有效实施的实施例是在通用公共MPLS骨干上经过Martini或类似隧道进行封装的IEEE dotI Q in Q VLAN,其通过标准硬件支持线速处理,并且还容易封装在通用公共网络的基础设施中。备选地,还可以经过通用公共ATM骨干上的LANE/MPOA来封装IEEE dotI Q in Q VLAN,以提供多地点的实施。
现在参考图16,图16示出了网络布置的简化图示,其中P开关(P)通向提供商边缘(PE)设备,所述提供商边缘设备依次通向客户边缘(CE)设备。客户边缘(CE)设备实施IEEE 802 dotlQ VLAN,并支持数据存储器。根据CPE端口和标签,CE利用Q倍增标签中的Q(Q in Q double tags)将通信量朝着公共/专用服务提供商边缘(PE)设备散列至上行链路。PE将CE上行链路通信量通过端口和VLAN散列至MPLS上的隧道。信道被散列至MPLS的内部IP地址空间,并根据路由描述符将这些地址空间散列到MPLS的标签方案,并将其转发至提供商(P)核心交换机。跨过共享分布式信道实施的所有地点,P核心交换机根据标签直接散列或者通过进一步散列成DWDM频率、TDM时隙或者其它适当的传输转换机制来散列通信量。使用基于标准网络技术的上述方法,允许系统利用网络技术中的继承散列。因此,可以使用VLAN标签、IP地址、标签切换、时间或波长复用以线速度为数据提供散列数据关键字和整个线能力。
分布式散列流程实施的实例如下:
CPE和CE存储区域分布散列流程:
数据关键字->信道->VLAN标签->标签+端口->超级标签.标签+上行链路端口
PE和P公共区域分布式散列流程:
上行链路端口+VLAN->隧道ID->LSP IP连接->内部标签->外部标签。
光传输基本散列流程:
外部标签+端口->光波长(WDM)和/或光时隙(SONET)。
为了更进一步的描述,此处将在下面把读者引导至特定信道实施相关的部分。
现在参考图17,图17示出了各个散列阶段如何对无穷大尺寸的高速存储网络实施信道分布散列表。图17示出了分布式目录的实施。在分布式目录实施的情况下,客户机查询协议是LDAP(轻量级目录访问协议)。
现在参考图18,图18示出了根据本发明优选实施例的网络布局的信道散列实施。图18的实施示出了具有客户机边缘设备的中心网络环。中心网络环周围是数据库XDB和查询公式定制或者切换单元XDR。
现在描述使用VLan技术和GVRP注册协议实现了接入点和存储元件XDB之间分布式数据库通信的实施。
基于GVRP的信道实施
为了得到非常有效的信道实施,此处描述的用于实施发布-订购网络信道的方法使用了VLAN技术和GVRP动态注册技术。
分布式数据库系统由两种元件构成,访问元件XDR和数据存储元件XDB。如上所述,元件之间的通信经过信道。每个信道代表存储在数据库中的一些数据的子集。包括每个信道的数据存储元件的集合可以因各种原因,随时间而改变。保持访问元件和包括信道的实际数据存储元件之间的信道连通性是非常关键的。为了执行原子提交操作,数据存储元件还使用相同的信道在数据存储元件之间进行通信。当数据存储元件在它们之间进行通信时,还从数据本身推断通信的信道选择。
当前方法的效力在于发送至信道的数据仅仅从发送器发送一次。然后使用以最小需要对该消息进行的网络复制,数据到达所有信道元件,以便确保该消息到达所有目的地。
提出的方法包括下列组成部分:
1.系统中的每个逻辑信道通过使用IEEE 802.Iq VLAN技术的VLAN来物理实施。
2.存储元件是信道上的数据接收器。
a.存储元件通过周期性发送适当VLAN的GVRP注册消息作为信道接收器。
b.允许存储元件加入多个VLAN,通常它们需要作为中继端口(trunk port)连接至以太网交换机。
c.存储元件还可以将该信道上的数据发送至另外的信道成员。存储元件通过使用信道标签发送广播消息来执行该操作。仅当存储元件注册了适当的VLAN时,才仅到达另外的存储元件。
3.接入点是数据至信道的发送器。
a.为了允许接入点发送数据至多个信道,接入点发送标记有IEEE
802.1q VLAN的广播消息。
b.为了允许接入点生成标记包,通常接入点需要作为中继端口连接至以太网交换机。
c.接入点本身不在信道上接收数据;因此它们不应该加入信道。接入点不必执行任何GVRP信令。
4.元件所连接的以太网交换机需要支持VLAN标签和GVRP信令。为了效率起见,对于不是接收器的中继端口,使用VLAN标签对该端口上的输入数据进行标记。由于在信道上发送的所有数据将必须在接入点处进行过滤,因此这是有效解决方案中的要素。
5.从数据存储元件发送至接入点的响应消息可以是标准IP消息或者标准以太网单播消息。
现在,在WAN网络上的虚拟LAN上传送VLAN标记包的解决方案已经存在。为此,IETF组织已经起草了若干提议。还有包括来自诸如Cisco的领先厂商的若干实施。因此可能使用标准VLAN和GVRP技术作为用于实施低等待时间分布式散列表的方法的基础,所述散列表用作数据库接入点和数据存储元件之间的通信信道。然后数据通信就成为了数据本身的函数(即,通过散列数据元素来选择通信)。
该方法在生成的大量消息中是有效的,这是由于发送器将打算供信道上多个收信者使用的消息作为单个消息进行发送。仅以实际到达所有目的地所需的最小量来复制所述消息。
基于IGMP侦听的信道实施
为了高效的信道实施,此处描述的方法使用了IGMP协议和广泛实施的IGMP侦听,这将在下面更加详细地进行描述。
本方法的效力在于发送至信道的数据仅仅从发送器发送一次。使用以最小需要对该消息进行的网络复制,数据然后到达所有信道成员,以便确保该数据到达所有目的地。
本实施例的方法包括以下组成部分:
1.系统中的每个逻辑信道使用专用IP组播地址来实现。
2.IP组播消息通常在以太网交换机内部使用以太网广播消息进行发送,如同在交换机上存在多个收信者一样。当代的以太网交换机通常使用公知为IGMP侦听的技术,通过深入查找包以及利用IP组播地址来避免将这种包广播至所有的交换机端口。还通过在交换机上观察IGMP协议通信,交换机就可以知道IP包与哪些端口相关。这种广泛使用的技术称为IGMP侦听。当此处建议的方法以最优方式与交换机一起使用时,具有更加显著的效果。
3.存储元件是信道上的数据接收器。
a.通过使用IGMP协议成为适当IP组播地址上的数据收信者,存储元件作为信道接收器。
b.存储元件可以在信道上发送数据给其它信道元件。上述操作通过将IP消息发送至与该信道相关的组播地址来实现。由于仅仅其它存储元件对于该组播地址的接收进行了注册,所以该IP消息仅到达与信道相关的该其它存储元件。
4.接入点是至信道的数据发送器。
c.在信道上使用IP消息来发送数据,将目的地址组设为与该信道相关的组播地址。
d.接入点本身不在信道上接收数据,因此接入点并未加入任何信道。接入点不必执行任何IGMP信令。
5.通过使用利用IGMP侦听的以太网交换机,该解决方案的效率得到显著提高。
6.从数据存储元件发送至接入点的响应消息可以是标准IP消息或者标准以太网单播消息。
7.IGMP在经过WAN链接进行穿越(traversal)时是有效的。仅当至收信者的路由或者路径出现分叉时,才对包进行复制。
因此就可能使用标准IGMP技术作为实现低等待时间分布式散列表的方法的基础,所述散列表用作数据库接入点和数据存储元件之间的通信信道,并使通信是数据自身的函数(即,通过对数据元素进行散列来选择通信)。
当以太网交换机具有IGMP侦听能力时,该方法变得更加有效。由于发送器将打算供信道上多个收信者使用的消息作为单个消息进行发送,因此生成的消息数量最小。为了使消息到达所有收信者,网络硬件将仅仅在需要的最少点处对消息进行复制。
基于以太网单播的信道实施
此处描述的方法使用通信信道的以太网(单播)通信。
本方法基于以太网单播消息的使用,即使用单播消息来执行信道内的通信。以太网单播发送器是消息源,而不管发送器本身是否是信道中的成员。当使用成员MAC地址作为以太网目的地址将消息单播至每个成员时,将打算到达信道的每个消息复制到所有的信道成员。因此,需要维持每个信道MAC地址成员列表的机制。本发明的方法包括不管每个元件是否是信道成员,都使其与信道通信,并维持其自身的MAC地址成员列表。这些列表随着通信故障而动态更新,并促使更新成员列表。从在两个网络地址之间维持临时映射高速缓存的意义上讲,所提出方法的信道成员解析协议本质上与公知的ARP协议责任相同。主要不同在于,ARP协议保持了IP地址和MAC地址之间的一对一映射,而所提出的方法将单个信道地址转换成若干MAC地址。
每个元件维持信道至MAC地址信息的该元件自己的高速缓存。然后当试图发送消息给信道时,通过元件访问该高速缓存。并从该高速缓存中移除旧信息。当在高速缓存中的信息不足时,利用信道解析协议来得到所需信息,所述信道解析协议的消息将在下面描述。如果目标数量低于某个功能最小值,则认为信息不充分。对于上述数据库,该最小值是信道成员的多数。同样,如果元件在信道上产生消息,但是却没有在某个时间帧内接收到充分的响应,所述时间帧比旧信息的高速缓存老化移除超时时间更短,则元件明确地刷新相关信道信息。
基于以太网单播的信道实施中使用的消息
在公知为信道解析协议(下文中称作CRP)的所提出方法的信道成员协议中使用了下列消息。
1.CRPjrequest消息是以太网广播消息,用于请求一个或更多信道的成员将其MAC地址发送给请求器。请求器还使用以下选项来标记与每个信道相关的其自身状态。
a.请求器未将自身认为是信道的成员。
b.请求器是信道的常规成员(数据存储元件之一)。
c.请求器是信道的协调器。这意味着在信道内请求器是当前负责协调原子提交过程的元件-参见本文在别处对协调器的讨论。
2.CRP_response消息是响应于CRPjrequest消息从信道成员发送的以太网单播消息。响应消息包括信道上的响应元件具有的所有消息,包括信道上每个元件的角色。响应消息包括信道列表。对于每个信道,存在成员的MAC地址以及成员在信道中的角色列表,即该成员是否是信道的常规成员或者信道的当前协调器。
a.通常,信道的协调器知晓信道中的所有成员。
b.通常,常规成员仅知晓他们自身。
c.此处单播消息的备选实施方式是使用以太网广播消息来广播该消息。其优势在于,该信息也可以与其它元件相关,因此将降低系统中请求的总体数量。其不利之处在于,广播可能与其它元件无关,因此将使网络极度充斥。
3.存储元件周期性地通过发送包括其全部信道成员状态信息的以太网广播消息来进行广播。这种广播消息与CRP响应具有相同的内部结构。
基于以太网单播的信道实施的扩展
1.可以以微小的改变来使用相同的方法,例如使用不可靠(或可靠)的广播和单播报文发送的另一层的两种技术,例如,Infmiband。
2.通过使用IP通信(作为原始IP或者作为UDP包)来取代以太网单播,可以使相同的方法适用于IP技术。此外,使用所有存储元件都参加的IP组播来取代以太网广播也是可行的。
因此可能使用广泛可用的以太网单播通信来作为实施低等待时间分布式散列表的方法,所述低等待时间分布式散列表用作数据库接入点和数据存储元件之间的通信信道。散列允许通信是数据本身的函数,其意思是通过对数据元素进行散列来选择通信。
如上所述,在不损害数据的情况下,读取操作基本可以同时实施,然而写入操作可能会彼此干扰。
XDAP协议中使用的基于多数的群首选举协议
下面描述了在分布式异步网络中基于多数的群首选举的实施例,从而使得可以选出引导处理单元,以便提供基于写入操作的决策执行控制。
到目前为止,已经在分布式系统中对容许各种类型的节点和链接故障的协议进行了大量工作,该领域的技术论文包括:
Leader Election in the Presence of Link Failures,GurdipSingh,IEEE Transactions on Parallel and Distributed Systems7(3),1996年3月。
Leader Election in Asynchronous Distributed Systems,Scott D.Stoller,Technical Paper,Computer ScienceDepartment,Indiana University,Bloomington,IN,USA,2000年3月9日。
过去已经并行地对为了原子提交而进行的群组决策的鲁棒性协议进行了大量工作。从1998年提交给耶路撒冷希伯来大学的作者为IditKeidar的“Consistency and High Availability of InformationDissemination in Multi-Processor Networks”(博士论文)的第八章中可以找到很好的概括。
据本发明人所知,科学界还没有关注到在相同单一环境中分布式计算机域内的群首选举问题和原子提交问题。同时,在多数原子提交算法中,都需要协调器。通过使用群首选择算法的群组来选择协调器。在能够承受链接和部件故障的实际分布式计算环境的环境下,两个域的分割导致在成功决定时分割解决方案的成功是不一致的。换言之,在目前技术中,比较荒谬的是存在这种情形,其中故障模式和算法选择可能选举出不能协调原子提交的群首。同样,荒谬的是,在目前的技术中还存在这样的情形,其中故障模式和元素选择使得不选举群首,尽管存在有能够成功协调原子提交的节点。
为了克服上述现有技术中的缺陷,此处教导的群首选择与基于多数的三阶段原子提交紧紧结合在一起。因此,就可能防止不一致的成功或者群首选举过程决定的失败以及因此基于多数的三阶段原子提交的失败。
本解决方案期望的直接结果是生成IMS-ready数据库。本解决方案提供了一种方式,该方式满足了计划用于数百万客户的IMS顺从电信网络推广应用提出的数据库所需的保障等待时间、高吞吐量和连续可用性,这是由于该方式包括能够经受各种类型的若干故障的分布式解决方案。经受若干故障的部分能力包括在若干故障情形中执行原子提交的能力。为了执行原子提交,优选的是群首选举和原子提交算法本身可以在若干故障情形中成功进行。群首选举和原子提交算法的紧密耦合使得群首选举算法相对较小,所述群首选举算法相对于故障比所需通信的节点内模式所需的其它群首选择算法更加具有弹性。即,所需的节点内通信是基于多数的三阶段提交的所需最小值。
通过考虑包括数据库的节点的组群大小,紧密耦合算法提供了一流的简单操作。可以将该算法概括成未知大小的群。
其核心是,建议的紧密耦合算法基于Garcia-Molina邀请算法的增强。1982年1月,IEEE Transactions on Computers,C-31(1):47-59的“Elections in a distributed computing system”,作者HectorGarcia-Molina。该算法包括将群首选择和3PC故障容错协议结合成一个协议。所述一个协议用于在相同故障场景中保障选举和提交。
下面对选举算法的高级特征进行描述。
基于多数的群首选举协议的高级阶段
根据本发明的优选实施例,在下列接合点(juncture)执行群首或者协调器选举:
1.系统初始化:当所有节点(或者处理)初始化并首次加入分布式数据库时,不存在目前己知的协调器。因此选举出协调器,所有节点确认该选举,以确保协调器众所周知。
2.节点加入:例如在重新引导之后,当新的节点接入系统时,优选地确认当前的协调器。因此,通过新节点的加入并不触发选举过程,即使当新节点的唯一标识符高于当前协调器的唯一标识符时,也是如此。正如将在下面所讨论的,在选举过程中使用该标识符。该算法的期望特征是试图尽可能地维持当前协调器,以限制协调器转换操作发出的数据库系统上的任何性能消耗。
3.协调器故障:当协调器故障时,例如当协调器机器崩溃时,优选通过仍然连接的所有节点来执行选举。本质上,该选举与系统初始化时调用的选举是相同的。
4.连接故障:当协调器和不包括多数节点(换言之少于(N-1)/2节点)的节点群从多数节点断开时,优选由仍然连接的多数节点选举出新协调器。一旦重新开始所有通信时,包括先前协调器的少数节点优选承认新协调器的关系,并加入。
5.根据要求的选举:协调器优选在不提名自己的情况下调用选举过程。如果协调器识别出作为协调器功能的问题(CPU、内存、heat等)时,这种情况可能发生,决定将职责移交至备选节点。
基于多数的群首选举协议的算法
协调器选举协议要求每个元件具有唯一标识符,要求特定的系统消息,具有预定数量的选举状态,并要求特定的定时信号和超时。现在来处理这些问题.
1.唯一标识符(UID):为每个节点(或者过程)分配一个唯一标识符(UID)。存在用于生成UID的各种公知技术。最简单的是使用系统上的MAC地址作为UID。
2.消息:AU消息共享相同的公知成员列表。下面是在示例选举场合中使用的消息列表。频率涉及其中对信令使用了频分复用的实施例。
2.1I_AM_ELECTED_COORD:这是由协调器使用F1频率周期性发送的广播消息。该消息用于所有系统节点,并用于确保系统节点仍然与协调器进行通信。
2.2I_AM_COORD_CANDIDATE:这是一个在选举期间发送的广播消息。认为自己是协调器候选者的节点以频率F2来广播该消息。
2.3I_ELECT_YOU:这是从节点发送至可能协调器的单播消息。作为I_AM_COORD_CANDIDATE消息的响应和I_AM_ELECTED_COORD消息的响应而发送该消息。
2.4IS_THERE_COORD:这是当开始参与选举时,T3超时时由每个节点发送的广播消息。
3.XDB选举状态:
下列列表是元件或节点在选举过程中或者选举期间可能进入的实例状态的列表。
3.1.IS_THERE_COORD:该“is there coord”状态是元件或节点开始参与选举时的初始状态。如上所述T3是发出IS_THERE_COORD消息之后的静默期,在静默期间,倾听查看是否有选举消息。
3.2.CANDIDATE(候选):当节点进行候选状态时,该节点通过发送I_AM_COORD_CANDIDATE消息将自己提名为协调器。该节点保持候选状态最多T6时间。如果当时另一节点已经成为协调器,则该节点将尝试并且加入该协调器。如果接收到具有更高UID的节点的消息,所述具有更高UID的节点是本节点还没有放弃为其投票的那个节点,则本节点将为那个节点进行投票。如果达到T6超时,则该节点将为另一节点进行投票,即使其具有较低UID。
3.3.VOTED(已投票):当一个节点想要投票赞成另一节点作为协调器时,则进入“已投票”状态。在已投票状态时,该节点仅仅可以投票赞成一个候选者。通常,该节点将投票赞成具有最高UID的节点,但是也存在对于这种事实的考虑,即如果投票赞成某节点并未导致该候选者成为协调器的成功结论,那么下次该节点进入该状态时将改变其投票,并选择最近尚未为其投票的节点之中UID最高者。
如果该状态中的节点已经跨过了候选状态,则该节点停止发送其自己的候选资格的消息。
在期间没有收到来自投票候选者的信息的T4超时之后,该节点移动至IS_THERE_COORD状态。该机制允许最后改变投票。
在该候选者未能成为协调器且没有选出其它协调器的T5超时之后,节点移动至IS_THERE_COORD状态。该机制允许最后改变投票。
3..ELECTED(被选出):当接收到对其候选人资格的广播的多数投票(该响应被认为是“I_ELECT_YOU”消息)时,候选者将从候选状态进入该状态。一旦进入该状态,该节点就承担了协调器的责任,包括发送I_AM_ELECTED_COORD广播。
3.5.ACCEPT(接受):这是这样一种状态,在该状态节点接受广播I_AM_ELECTED_COORD消息的节点成为协调器,即使该节点已投票赞成了某个其它节点或者已经将其本身认为是候选者。
4.定时器:下面的时间、定时器和频率列表由选举过程使用。
4.1F1-发送I_AM_ELECTED_COORD消息所采用的频率。时间T1=1/F1。
4.2.F2-处于候选状态的节点发送I_AM_COORD_CANDIDATE消息所采用的频率。时间T2=1/F2
从经验上讲,所确定的良好实践是:
4.3F2=2.5×F1
4.4.T3-在IS_THERE_COORD状态期间观测网络信息流通量的时间间隔。
4.5T3=5×T1,此处T1=1/F1。
4.6.T4-自上次投票赞成其候选者(作为对候选消息的响应)的时间间隔,在此期间,没有处理来自已经投票赞成的候选者的任何广播。假定该节点已经临时投票赞成了另外的节点,并且应当允许该节点在该点通过重新开始选举来改变其投票。
T4=10×T1
4.7.T5-在此期间节点始终如一地投票赞成特定节点但投票赞成的那个节点却没有成功赢得多数的时间间隔。随后,节点重新开始选举。
T5=200×T1
4.8.T6-用于倘若一个节点不能赢得多数也没有收到另外选出的协调器的消息或者来自具有更高UID的候选者的消息的情况下,来限制该节点继续作为候选者的时间的时间间隔。该节点放弃其候选人资格,并寻找另一节点为其投票。
T5=500×T1
4.9.T7-这是通常的选举超时。如果协调器选举没有在该时间帧内结束,则重新开始整个选举过程。
T5=1000×T1
4.10T8-T8是超时。T8超时之后,认为投票期满。
T8=30×T1
4.11T9-T9是超时。T9超时之后,不再认为候选节点是候选者。
T9=7×T1
本算法的一个值得注意的要素是,进行了特殊设计以满足选出群首目的的方式,所述群首将成为分布式数据库的协调器,该协调器要求与所有其他数据库节点双向通信以执行三阶段原子提交。其它的节点并不必在它们之间进行通信。
通常讨论的算法具有当且仅当要求的通信模式存在时才能决定群首选举的优势,与其相比,该观点产生了不同的算法。
通过使用辅助索引作为基础
将记录映射到网络地址的数据记录访问
在上面的数据管理系统中,为数据库、目录、注册(registry)、存储系统或储存库提供了一种实施,该实施基于使用映射/散列函数将数据记录的引导关键字映射到网络地址的数据记录索引的实施和用于执行该操作所定义的XDAP数据访问协议的实施。
然而,仅基于引导关键字来访问数据并不总是有效的。至少有时存在需要被搜索的辅助关键字、第三关键字和另外基本关键字。
因此除主关键字之外,要为搜索能力添加本发明的其它优势,即利用标准高速网络设备以高速度、高吞吐和高缩放性来存储和获取用于读取和写入的数据记录的能力。使用所描述的技术,将功能扩展成使得能够与前面描述的基于主索引的访问以相同方式使用辅助索引来访问数据。
本实施例教导了在使用辅助关键字作为基础以将记录映射到网络地址的系统中访问数据记录的技术和实现。随后如同使用主地址一样,辅助地址可以用于使用标准网元件以非阻塞线速度来存储和取出远程计算机上的数据记录。
因此,我们可以将通过市民政府机构来保持的记录作为实例。所述记录可以包括如下字段:姓名、社会安全号、家庭地址、电话号码和护照号码。期望所有字段全部可以是可搜索的,但是仅仅有一个关键字可以成为引导关键字并直接散列至主网络寻址系统。
可以使用下列方案将字段分类为主字段和辅助字段:记录人员;主关键字:社会安全号(用作将记录映射到网络地址7:9:B:8:4:A的引导关键字)。辅助关键字1是家庭地址;辅助关键字2是电话号码,辅助关键字3是护照号码。
优先为了效率来选择主关键字。因此将最可能被检索的字段或者最可能总是给出唯一结果的字段选择作为主关键字的主字段。可以唯一或者不唯一的辅助关键字还可以供数据管理系统的客户机应用程序来使用以访问数据记录。
辅助关键字可以限定涉及多于一个字段的任何复合值集合或者值的范围。例如,我们可以假定年龄的复合值:未达法定年龄者且家庭地址可以用于访问留在特定房屋中的儿童的数据记录。
传统上,即现有技术,使用基于计算机的数据结构和搜索过程(主要是诸如2/3树、红/黑树或者AVL树的搜索树)来实施辅助及主数据记录索引。使用这些方法来实施基于辅助关键字的访问,实质上是后退到主索引的交叉索引,妨碍了当使用引导关键字访问时实施上述系统的益处。
在上述数据管理系统中,使用标准网络来存储和取回数据记录。所描述的是当搜索记录时,该方法如何避免内存访问时的瓶颈和线路阻塞。当在检索到引导关键字之前通过辅助关键字来搜索数据时,使用传统或者现有技术中的技术实施的辅助关键字搜索损害了所有这些益处。仅仅一旦已经检索到主关键字,随后操作将变得无阻塞并且有效。这意味着,对于使用辅助关键字访问数据的所有查询,在访问内存和基于磁盘的数据结构的时刻周围,容易发生连续的线路阻塞。
直至现在,数据管理系统大多都是基于单个计算机,或者备选地被分割成可以通过计算机网络访问并作为分层系统管理的多个数据系统-在上文中群首被称作后台。在这些实施中的索引通常是基于支持搜索过程并使用结构的内存或者磁盘中数据结构,诸如搜索树。
在这些限制更多的环境中,这种结构通常足够了,这是由于招待数据管理系统的服务器在速度和容量上与招待客户机应用程序的那些计算机成比例增长。因此,如果服务器支持N台客户机(并且比客户机计算机快N倍),并且通过技术优势(摩尔定律)使这些客户机处理能力增长了K倍,那么服务器将是(N*K),因此使用服务器内存和CPU的数据索引实现将继续满足需要。
然而,当今还存在计算机对等式通信应用程序的增长模式,而不仅仅是客户机服务器应用。当这些应用需要作为对等式通信的边界效应进行数据访问时,那么以前出现的线性度就不能再应用。如果有N台计算机参加了对等式应用,那么在访问相关数据管理系统时((N*(N-1)/2次会话)可能产生N平方的压力因子,这就打破了比例线性度。
在诸如用户电话技术的经典对等式应用中,从未使用诸如商业数据库的标准通用数据管理系统,直到现在因该确切原因而用于在线数据管理操作。这种解析网络中电话位置的操作是专用电话技术网络和应用专用网络信令的组成部分,而不是通用数据管理系统的组成部分。
只是在现在,作为通用网络开始用于大规模对等式应用,所述大规模对等式应用要求当用来解析和存储在线呼叫数据时,通用数据管理系统与网路活动的整个多项压力(Metcalf定律)相匹配
与上面的方案相同,下面的实施例教导了如何使用网络实施数据记录访问来克服瓶颈。网络链路层是系统的基础和骨干,而不是计算机内存或者磁盘,因此就可能实施使用网络层覆盖层和向每个记录中添加网络层地址的索引。因此,正因为我们可以在相同链路层网络上覆盖多个网络层子网,因此我们可以对数据覆盖多个索引方案,并使用有效的并发标准网络设备来继续实现数据管理系统。
因此,正如所说明的那样,主数据记录访问通过将每个记录关联和映射到以太网链接层网络和MAC地址来实现。此外,然后将辅助索引作为覆盖在相同以太网链接层网络上的多个IP子网来实现,并且可以使用标准路由器以及分布式路由器和路由方法将辅助索引的网络地址映射到主关键索引的MAC。因此,通过标准网路部件,即路由器来实现映射到主关键字的辅助关键字,所述路由器正好用于实施为其设计的功能。通过同时对链路层地址和网络层地址(在该实例中是MAC地址和IP地址)使用分组寻址,就可以仍然存在数据副本和非唯一索引。
在图9中示出了根据本发明的实施例使用辅助关键字的数据访问技术,并且该技术包括下列元件,与上面提及的相同:
XDR-用于接收数据访问查询的对象XDR1...,XDRn。
XDB-在位置A、B、C和D用于存储数据记录的对象,XDB1...12。
XDAP协议-用于存储和取回给定记录多个副本、包复制、丢失包以及丢失元件或段的协议。
此外,交换机1901是在网络结构中互连的链路层对象并且连接所有XDB和XDR,以及
路由器1903-对于给定网络地址,将包从一个链路层地址转发至具有另一链路层地址的目的地的网络层对象。
图19示出了使用路由器以支持使用分布式索引路由器在网络上的多索引。如在上面已经说明的那样,系统还包括负荷平衡和冗余。
现在参考图20,图20示出了允许通过根据主关键字布置的数据库的辅助关键字进行搜索的单臂式路由器。基于辅助关键字的查询由XDR2002发布,并被定向至路由器2004。路由器接收查询并在其路由表中查找辅助关键字,以找到相应的主关键字。主关键字以正常的方式进行散列,并使用散列结果将查询定向至XDB2006。然后将该查询转发给具有恰当的XDB的相同网络作为目标链路层地址。
根据本实施例使用数据访问系统和特别使用辅助关键字的实例是移动电话技术,其中SIM卡ID和电话号码都是关键字,尽管其中每一个均是主关键字。辅助关键字(假定是电话号码)相关的所有查询被映射到分配给这些关键字的子网的网络地址中。将足够的单臂路由器插入至数据访问网路,使得当接收到涉及电话号码的查询时,XDR将该号码映射成网络地址,然后将其转发给子网的路由器。路由器将查询转发至恰当的XDB,其中MAC地址对应于该主关键字。当XDB具有最近辅助关键字更新、采用了相关网路层地址且使用子网路由器执行了标准注册过程时,路由器可以透明地得到该主关键字。这实际上是与在计算机中配置IP地址的方式相同方式工作的。
关键是在网络上访问和索引大容量数据和网络应用的结果。该技术可以用于形成大型分布式存储、基于通信基础架构或者完全分布在互联的终端站之间的数据库。
上述使用的一个实例是用于要求在非常严格的时间或者其它性能限制内进行数据查找的服务,即具有高度限制的服务质量要求的服务。
通过使用作为另外的表进行
存储和散列的辅助索引来访问数据记录
此处描述了不使用路由器来实现辅助索引的另外的方式,但是仍然提供了经过辅助索引对数据记录的非阻塞实时访问。在无共享分布式数据存储库中,使用分割关键字来分割表并将其分布在不同的计算资源之间。在这种无共享架构中,辅助关键字通常还分布在不同的分区之间,使得每个分区保持有属于该分区的子表的辅助关键字。当支持给定分区范围内的数据库操作时,表分割相对于其相应子索引的这种紧密协同定位具有益处。
例如,支持CDR(呼叫数据记录)的数据库可以以日期进行分割,即所有在某个日期进行的呼叫属于一个分区。CDR数据库的辅助索引的实例是主叫电话号码。在这种分割实例中,通过在特定日期内进行的所有通话的相同分区中,利用该日期内进行的所有呼叫的主叫号码来协同定位子索引,使得某些普通查询的计算具有效率(例如,通过给定日子内的给定用户进行的所有呼叫)。
然而,在许多其它情况下,使用分割数据本身协同定位分割子索引将形成阻塞式数据结构,使得通过辅助索引的数据访问不可缩放。
例如,上述提及的使用ID号码的数据库可以是引导关键字或者分割关键字。如果对于每个ID号码分区rage,对电话号码辅助索引进行子索引,那么使用电话号码访问数据记录将要求把查询广播至所有客户。
在不使用路由器的情况下,仍能经过辅助索引提供对数据记录的非阻塞实时访问的实现辅助索引的另一方式是,此处描述的网内分布式数据管理的一部分。将电话号码辅助索引作为另一表来实现,即具有两个字段“电话号码”和“ID号码”的“索引表”。然后对该索引表进行分割,使得辅助索引字段“电话号码”成为索引表的引导关键字。每次原始表改变时,通过系统自动更新辅助表。在系统中作为另外的表对辅助表进行管理(在读取和写入操作方面)。因此,以线速度来执行对索引表中的入口的访问,如同使用引导关键字访问任何数据元素一样。因此,使用辅助关键字访问原始表中的数据元素通过以下步骤实现:
1.使用索引表引导关键字来访问索引表,并接收原始表的引导关键字。
2.使用结果得到的引导关键字来访问原始表数据元素。
该散列索引表交叉分区的方法允许用户通过使用基于两个引导关键字的数据元素访问、以非阻塞的方式使用其辅助关键字来定位任何数据元素,所述基于两个引导关键字的数据元素访问首先访问索引表,然后访问原始表。
系统的可用时间(uptime)模型
下面示出了仅仅使用3-5个复制实现的5个9和更多(>99.999%)的系统可用性。
基于上述的内存分布式数据系统,可能的是作为计算元件数目以及将虚拟数据分割映射到计算元件的方式的函数来计算期望的系统可用性。
如上所述,在计算节点之间的虚拟数据分割副本的彻底洗牌使得计算节点之间的整体负荷平衡和内部相关性增加。另一方面,通过将计算节点布置在分配给信道组中的集合(此处称作弹性集合)中,正如从图24中可以看出的那样,可以增加系统的可用性。现在由于每个弹性集合可以失去副本中的少数,且系统将仍然可用,因此系统整体的弹性非常高。
下面是针对于系统中每个计算元件“时间片”而使用的可用时间模型。
每年服务器的平均故障次数 | 2 | |
最大自愈合持续时间 | 0.5 | 小时 |
每个服务器“时间片”的每年易损性时间 | 1 | 小时 |
平均服务器“时间片”可用性(工作或者自愈合) | 99.989% | |
“9S”可用性服务器“时间片”的数目 | 3.94 |
系统可用性模型
使用上述系统可用性模型就可能计算图20B中示出的图表。上面的图表假定每个XDB的性能是每秒15000次操作(如在实验室测试中得到证实的一样)。
正如从图表中可以看出的那样,要为高达200个XDB且每秒生成大约一百万交易的系统提供5个9以上的可用性(>99.999%),三个副本就足够了。这样的系统对于支持多达80,000,000-100,000,000客户的大多数IMS应用商(carrier)级别应用程序是足够的。
正如可以从上面图表中看出的那样,5个副本为该容量的系统提供了大于8个9(>99.999999%)的可用性,并且可以为提供以下性能的4-5倍的系统提供大于6个九的可用性:
弹性集合数目:s
每个弹性集合中的XDB数目:1
数据副本:r=2m+1
服务器可用性:1-p
系统可用性:
上述性能超出了IMS系统实际需要的范围。
并发数据库客户机之间的服务质量的管理
现在将从交易等待时间和吞吐量方面描述并发数据库客户机之间的服务质量管理(QoS)的实施例。现在的数据库服务级别度量通常指:
(1)诸如读取记录或者写入记录的原子数据库操作的等待时间,和
(2)并发会话的数目。
(3)交易速率
此外,在数据库中实施等待时间保证通常通过对特定任务设置优先权来实现。在下列环境中保障等待时间度量就具有问题:
1.当系统负荷很高时(系统负荷影响等待时间度量)。
2.分布式数据库(系统分布使得很难限制操作持续时间)。
实时数据库是广泛使用在众多领域(诸如电子商务、电信和制造业)中的实时应用的基本部件。通过实时应用提供的服务级别来评估实时应用。服务级别用于度量终端用户的体验。终端用户体验包括:
1.服务可用性:
2.用户可以在任何希望的时刻得到服务;
3.服务的响应性
服务响应是否足够快。
4.服务总质量
服务本身是否足够好-用户的总体体验。
本质上讲,实时应用服务级别是通过应用平台内部的任一单个元件实现的服务级别的串联。
实时应用正在演化,并且它们明显地:
1.本质上更加分布。
2.具有不可预测的工作负荷。
3.具有未预料的访问方式。
4.开始面向服务而不是客户机-服务器。
目前认为没有数据库或者没有专用的分布式实时数据库实施服务质量机制来保障数据库:
(a)每个接入点的可用性(吞吐量:每秒钟的操作数目),
(b)响应性(每次原子操作限制的等待时间),和
(c)数据的新颖度和一致性(数据是最新且准确的)。
必须保证上述度量,同时使得存在下列共同条件:
1.使得数据库分布在任意数目的位置。
2.数据库可以启动任意数目的并发接入点。
3.数据库可以无差别地执行任何操作的结合。
4.数据库在任何工作负荷下无差别地执行。
本实施例包括网内实时数据库。该实施例使用网络将该数据库变换成单个全球交叉定位网络服务。如同从网络本身继承的若干特性一样,在其它类型的网络中,QoS的度量是延迟、带宽和改善的丢失特性。数据库Qos的新概念满足了实时应用服务级别协议的需求。
现在描述的实施例是建议并实施了QoS概念的第一数据库,所述QoS概念可以用来将实时应用服务级别度量映射到实时数据库性能度量。
这种度量可以包括
1.每个访问节点的保障的数据库吞吐量:
a.不依赖于数据库工作负荷
b.不依赖于并发访问节点的数目(每个节点可以服务于不同的应用程序)
2.保障每次原子操作的数据库等待时间:
a.不依赖于操作混合
b.不依赖于数据库工作负荷
c.不依赖于数据物理位置
d.不依赖于数据模式
3.应用质量数据库数据一致性:
a.不依赖于数据物理位置
b.不依赖于整个系统中的数据复制的数目
如此处在任何地方所讨论的那样,在数据库内发生故障的情况下提供了最有成果的实践。
正如上面关于图4所描述的那样,分布式数据库系统是一种包括三种基本类型节点的服务器群集:访问节点、数据节点和交换节点。访问节点主要处理客户机请求并相应地返回响应。数据节点主要在其存储器内存储数据记录并管理数据,例如检索数据记录或者在非易失性存储器上存储数据记录。交换节点主要连接所有群集节点,并在各个节点之中路由消息。访问节点和数据节点都可以位于任何物理位置,而不依赖于系统内的其余节点。
本质上可以映射成具有服务级别度量的实时应用的保障QoS的实时数据库概念可以包括各种QoS度量,每种QoS度量均可以各种方式来实施。下面公开了可能的数据库QoS度量以及可能的实施实践,然而可以使用其它方法来实施这些和更多的QoS度量。
保障的吞吐量
该目标是要保障数据库客户机(实时应用程序)每秒钟可以执行的原子操作的数目。原子操作包括:创建记录、读取记录、修改记录、删除记录。吞吐量级别视应用需求而定。
本实施例目前能够通过以下来保障吞吐量QoS度量:
·吞吐量缩放性:本实施例的分布式数据库最终可以通过简单地向其群集中添加更多节点(访问节点、数据节点、交换节点)来无限制缩放其吞吐量。每个访问节点保障了特定的吞吐量(每秒钟X次操作),而系统总吞吐量是所有访问节点吞吐量的总和。因此,应用可以要求任何需要的吞吐量。
·吞吐量分配机制:本实施例实施了吞吐量控制机制,使得系统管理员能够分配每个访问节点的吞吐量配额。特定应用可以使用与所需要的数目一样多的访问节点,以满足吞吐量要求。虽然应用吞吐量受到分配给访问节点的吞吐量配额的限制,所述访问节点是该应用用来访问数据库的节点,但是允许使用该相同数据库资源的其它应用来保障它们所需吞吐量。
保障每次原子操作的低等待时间
该目标与执行原子操作所需的时间捆绑在一起,要保持其尽可能地低。原子操作包括:创建记录、读取记录、修改记录、删除记录。等待时间的上限值不应当受到系统瞬时负荷的影响或者受到数据物理位置相对于访问节点物理位置的影响。
根据本实施例的系统中的一个双程(roundtrip)操作如下:
访问节点(解析)->交换(转发请求)->数据节点(处理)->交换(转发响应)->访问节点(响应)。
该目标是使得典型的双程操作的每个子阶段的等待时间最小化。本实施例的系统当前通过以下方式来保障低等待时间QoS度量:
·基于多数的数据访问和数据亲和力:我们期望确保节点和瞬时网络断开都不会影响数据的可用性或者系统的性能。因此,我们保持数据记录的若干复制,每个复制都存储在不同的数据节点上。当读取或者写入数据记录时(参考““基于多数的群首”):
ο当前正在请求存储该数据记录的所有数据节点选择协调器。该协调器负责管理和监控请求时的操作。
ο读取/写入记录要求仅与数据复制的多数一样多的数量。这确保了故障节点不会使操作变慢。
ο系统管理员可以定义数据亲和力策略。其含义是,可以将多数数据的位置设置为与其接入点尽可能得近,从而平衡网络(交换)等待时间。
·并发性和负荷平衡:每个数据节点负责管理数据在所述不同数据节点中均匀分布的数据的部分。每个数据节点独立于其它节点,即每个数据节点可以与其它数据节点同时对数据进行处理。即使当系统在高负荷下工作时,这也使得能够实现每次操作的短等待时间。本实施例的数据库可以根据需要作为许多数据节点添加至它群集中。系统具有的数据节点越多,就存在更加并发的数据处理能力,因此每次操作的等待时间就越短。通过添加更多的数据节点,可以保持低等待时间级别。
·数据分组和网络技术:本发明的优选实施例提供了网络和交换节点,以便连接访问节点与数据节点。该系统涉及将数据库表分成原子记录并将其分组。在网络上传送每条记录,并在网上的不同位置(数据节点)进行存储。这意味着,不管当前执行的操作数目或者数据格式,任何数据记录以基础网络QoS级别的线速度到达其数据节点并返回。
保障的实时数据新颖度和一致性
该目标是确保数据记录的任何改变可以立即有效。该应用还可以总是检索最近更新数据,并确定该数据在整个系统中是一致的。
本实施例目前使用若干机制和算法来确保数据新颖度。
·三阶段提交:这在本文中的其它地方进行了讨论。
·基于多数的数据访问和纠错。这在上文中进行了讨论。
数据节点故障情况下的最具成效的实践
数据库优选地保障其QoS级别。然而,在数据节点故障的情况下,系统尽力使用其剩余资源来满足所要求的QoS。
本发明优选的实施例使用若干机制和算法来确保数据新颖度:
·不限制访问节点的数目:本实施例能够启用任何数目的访问节点。访问节点允许每个应用连接至多于一个的访问节点。在一个访问节点故障的情况下,应用可以使用其它节点工作,从而确保其访问率(吞吐量)不会降低。
·自动的自愈合:本实施例实施了其数据节点的自愈合机制。由于每条数据记录在不同节点处具有若干副本,因此当数据节点故障时,仍可在剩余的数据节点中得到数据。因此,剩余的数据节点负责该数据的响应。在整个系统资源中,数据亲和力最优,因此工作负荷在群集内部的所有数据节点中均匀分布。假设剩余的数据节点具有能力来存储分配的额外数据量且这些剩余数据节点并未被充分利用,则维持数据库交易的并发性。该并发性确保了可同时处理的操作数目和每个操作等待时间遵照QoS的需求。在没有足够的资源来处理额外数据的情况下,系统仍以最优的方式来利用其资源,从而尽其最大努力来满足QoS的需要。
实时数据库是实时应用的基本部件。通过服务级别来度量实时应用。应用服务级别是诸如实时数据库的应用平台内每个节点的服务级别的串联。数据库QoS使得能够将应用服务级别度量映射成数据库性能度量,以确保不依赖于瞬时系统负荷或者访问方法的实时应用服务级别。
使用N+M高可用性的网内数据库
和状态(Stateful)应用的事故恢复
下面介绍使用N+M高可用性的网内数据库和状态应用的事故恢复。
实时状态事件处理程序
基于会话的实时事件处理应用需要维持当前会话的状态。在该会话的历史(即“状态”)的上下文中对属于给定会话的每个新事件进行处理。通常基于包的应用简单处理单个包并传递所述单个包,但是这样并不总是足够的。在许多情况下,可能需要根据会话的状态对包进行不同的处理。这种应用被称作状态的应用。
实时状态事件处理应用的实例有:电信呼叫控制和软件切换,移动电话归属位置寄存器(HLR),互联网多媒体系统(IMS)的归属用户服务器(HSS)、服务选择网关(SSG)、AAA服务器、在线计费服务器、寄宿(Boarder)控制器、防火墙、在线银行和交易系统。
高可用性和事故恢复
高可用性(HA)和实时状态事件处理应用的故障恢复要求在不同的服务器之间实时地复制应用的内部状态并使其同步,以确保状态故障转移。在故障恢复计划(DRP)的情况下,在不同位置中的不同服务器之间实施应用内部状态的实时复制和同步。
现在仅仅用于实时状态事件处理应用的DRP和HA模型是1+1模型。在1+1可用性模型中,应用服务器是成对的,每个服务器具有其单独的故障转移服务器。可以显式地或者隐式地使两个服务器的内部状态保持同步。
隐式内部状态同步高可用性1+1模型
通过将系统的所有输入同时馈送至两个服务器,并允许每个服务器同时对称地处理相同事件,来实施隐式内部状态同步。其结果是,两个应用服务器同时保持了对称内部状态。然而,两个服务器的性能降为单个服务器的性能。
可以使用隐式内部状态同步模型来使多于两个的应用服务器之间的状态得到同步,以实现多于一个故障的故障容错。然而,所有隐式同步服务器的性能将仍然等效于单个服务器的性能。
现在参考图21,示出了一种隐式状态同步1+1HA模型,其中两个单元,即主单元2101和辅助单元2102都存储了处理状态。隐式同步工作在两个单元之间,从而确保两个单元不但同时更新而且实时更新。
显式内部状态同步高可用性1+1模型
现在参考图22,使用显式内部状态同步来克服隐式内部状态同步的资源利用效率低的问题。显式状态同步在两个服务器之间使用专用连接和协议来在服务器之间实时交换内部状态。每个服务器可以独立地处理不同的会话和事件。然而,每个服务器具有两个服务器的内部状态。当其中一个服务器故障时,那么第二服务器就可以继续处理所有会话和事件,这是由于它已经将更新后的状态存储在内部了。
图22示出了显式状态同步1+1HA模型,其中服务器1经过使用显式状态同步协议的链路2202连接至服务器2,以确保每个服务器都具有两种状态。
当在1+1HA模型中使用显式内部状态同步时,可以同时充分利用两个服务器。然而,当其中一个服务器停机时,系统的性能就降低为单个服务器性能,即降低了50%。这可能导致系统提供的服务质量严重降级。因此,即时在显式内部状态同步的情况下,每个服务器并不可能利用其微弱的性能使得在故障情况下服务降级不那么严重。这就降低了资源利用。
显式内部状态同步通常受到1+1模型的限制,这是由于在典型情况下,实时状态事件处理应用并不能处理比实时产生事件更多的实时状态同步事件。因此,内部状态同步不能提供超出一个故障的故障容错。
正如在本实施例中一样,使用网内高可用的数据库来实现N+M模型,就可能提供网内分布式的、普遍存在的、高可用性和非阻塞数据库,以便以显式的方式、实时地、同步许多实时状态事件处理应用程序的内部状态,从而实现N+M HA模型。N+M HA模型意味着在到达M个服务器故障的情况下确保系统的可用性,以提供N个服务器的最小性能。这可通过在使用N+M HA模型的N+M个服务器上运行该系统来实现。
在N+M HA模型中,可以充分利用所有的N+M个服务器,同时每个服务器故障仅仅降低了系统性能的1/N+M。或者可以利用N+M个服务器到达N个全部利用的服务器的级别,使得每个独立的服务器故障并不降低系统性能,一直到M个服务器故障的极限。在两种情况下,资源利用为N/N+M,这典型地比1+1HA模型可用的最大利用率50%高得多。由于即使对于象10一样大的N,M也通常为1或2,因此N+M HA模型可以实现的资源利用通常在85%-95%之间。
正提议的N+M HA模型和DRP的数据库中心实时状态同步模型不是使用当前数据库技术的可选项,所述可选项具有阻塞的盘内或者内存内架构,无法进行缩放来支持同时在不同位置的N个不同客户机的大量并发写入。
N+M高可用性的数据库中心实时状态同步模型
本发明实施例提供了一种无处不在且高可用的N+M HA和DRP的数据库中心实时状态同步模型,其提供了:
1.更高的资源利用率:大约90%相对于当今可以实现的最大极限值50%。
2.更高的故障容错级别:远远超出当今可获得的单个故障容错。
本优选实施例将当今使用的显式状态同步机制从对等式、一对一协议延伸至客户机服务器的一对多模型,所述一对多模型使用全球网络、无处不在且非阻塞的数据库来存储来自所有位置的所有实时状态处理应用实例的所有状态。在一个或更多应用实例故障的情况下,利用幸存的应用实例,通过来自状态数据库的所有需要状态的实时同步,在相同位置和/或其它位置通过幸存应用程序实例来执行所有会话处理的状态恢复。
本实施例基于当今在显式状态同步1+1高可用性模型中使用的相同的多应用实例环境。实际上,本发明实施从1+1高可用性模型至N+M高可用性模型的改进既不要求对应用实例进行任何改变,也不要求对应用环境进行任何增强。
在当今显式状态同步1+1高可用性模型中使用的现有技术的多应用实例环境中,每个实时状态事件处理应用实例使其内部状态与其对等者实时同步。在对等者其中之一故障的情况下,应用环境将事件和消息从故障的服务器重新路由至其幸存的同步对等者。
本实施例所提供的是:每个应用实例使其状态与状态数据库实时同步,正如同在对等式架构中一样,甚至使用了相同的协议。然而,与对等式方案不一样的是,只要没有故障,就仅将状态写入至状态数据库,而不返回应用实例使状态同步。
现在参考图23,图23示出了使用状态数据库的N+M高可用性模型。
在一个或更多应用实例故障的情况下,诸如在对等式的情况下,将事件和消息从故障服务器重新路由至某些或者所有的幸存应用实例。这里有两种系统可以操作的模式:
1)推(Push)同步模式:正如同对等式情况一样,应用环境将属于给定故障服务器的所有事件和消息重新路由至相同位置或另一位置中的幸存服务器其中之一。在这种情况下,状态数据库通过将状态“推”至幸存服务器使其抢先与适当状态同步,再一次正好使用与对等式同步所使用的相同协议。
2)拉(Pull)同步模式:在这种情况下,应用环境将事件和消息从故障服务器重新路由至不同服务器和/或相同位置的所有幸存服务器。因此,接收未识别的消息或者事件的每个幸存服务器,由于并没有消息或者事件的状态,因此抢先从状态数据库中“拉”出该状态。
在同一实施中可以同时存在推模式和拉模式。在这种情况下,推模式可以看作是“预先获取”状态的类型,所述状态将会根据需要被逐一请求。
如上所述,本实施例提供了一种网络分布的、无处不在的高可用性和非阻塞数据库,从而以显式的方式使得许多实施状态事件处理应用的内部状态实时同步,进而实现了N+M HA模型,以因子2增加了资源利用率,同时又提供了无限制的故障容错级别。
对于实施1+1HA的显式状态同步机制的系统,可以实现上述目标,而无需改变应用实例或者操作环境。
内存数据库系统定价模型
下面讨论的是适合于上述实施例和其它类似应用的定价模型。得出了使用特定关键客户数值的基于数值的DBMS(数据库管理系统)定价模型,所述特定关键客户数值诸如交易速率、能力和吞吐量。
诸如Oracle,IBM、DB2以及其它供应商的当前供应商使用的现有授权定价DBMS软件使用了他们的定价系统的参数,这些参数并不是关键客户利益的重点,因此这些软件被认为是不公平的或者是专断的,尤其是在服务提供商的利益方面是最佳的,相反,对于客户却最差。
下面是现有定价系统的调查:
1.用户/客户/DB-客户机模型-该要价与连接至或者允许连接至数据服务器的用户/客户/DB-客户机的数量相关。从客户观点来看,在一些用户/客户/DB-客户机具有巨大用户,而另一些很少使用的情况下,基于用户的定价产生了低效率。基于用户的定价对于所有用户都是相同的,而不考虑实际的使用级别。
2.处理器数目模型-在该模型中,收费的数目是基于系统利用的处理器的数目,在同一多CPU服务器(SMP)中或者跨过运行在群集配置(例如Oracle RAC)中的不同服务器来对CPU进行计数。有时,对多核CPU的每个核进行计数。每个核/CPU的价格相同,而不考虑CPU的时钟速度以及随后添加的CPU的边缘性能贡献。关于该边缘性能贡献,需要注意的是,在多CPU配置中,在SMP和/或群集配置中,当把处理器添加至系统时,存在每个处理器中的边缘效应递减。添加的第十个处理器远远小于第一个处理器的贡献。这意味着虽然每个处理器的支付费用是相等的,但是每个附加处理器的附加边缘效应越来越低,因此从用户的观点来看产生了低效率。此外,用户感到他们必须为DBMS软件的CPU低效利用支付额外费用,并且感到DBMS厂商没有积极的动机来改善他们软件产品的CPU效率。对于供应商来讲,最节省成本的方式是简单的添加CPU直到实现所需的性能,而不是对系统进行重新配置以最优方式提供性能。
本实施例的DBMS软件许可定价模型旨在创建基于数值的定价模型,其中客户对他所接收的服务进行付费,即他看到他为其付费的参数直接与所得到的益处相关。因此,本实施例是从用户观点上基于DBMS系统的实际性能来定价。因此使用了诸如峰值交易吞吐量的参数,而不是诸如每CPU或者每个用户的技术参数。
本实施例的DBMS许可定价模型是基于系统的实际峰值吞吐量:
软件许可价格=每秒吞吐量*的#×每吞吐量的价格**。
*吞吐量可以通过下列方式来度量:
1.每秒中的数据库交易数量。
2.数据库客户机和数据库服务器之间通信(包括所有查询和返回结果)的总数据库交易比特率。总交易比特率以兆/秒来度量。
**每吞吐量的价格可以与下列因素相联系:
1.以GB为单位的数据库容量;
2.客户/用户的总数;
3.或者,也可以是固定的数目。
定价的优选方案是客户机直接对每单位吞吐量进行付费,单位吞吐量是通过软件使用率推导出的关键性能值。
实例:
每吞吐量的价格:
GB=<3 $3,000
GB=<6 $4,000
GB>6 $5,000
每秒钟的吞吐量 | #GB存储器 | 每吞吐量的价格 | 总价 |
1,000 | 3 | $3,000 | $3,000,000 |
1,000 | 4 | $4,000 | $4,000,000 |
2,000 | 4 | $4,000 | $8,000,000 |
表1示范性参数和相应收费
与过去的较低需求相反,对于每秒钟的超高吞吐量存在逐渐增长的需求。该逐渐增长的需求有望随着IP电话服务部署的增长而急剧增加。同时,在过去用户要为低效率支付费用,而本发明的实施例避免了这种要求。费用支付直接与交易吞吐量相联系。客户机对作为关键数值的系统的总峰值吞吐量进行付费,并且该付费不与诸如CPU数目或用户数目等其它技术参数相联系。
可以预料的是,在该专利的寿命期间,将会开发出许多相关的装置和系统,此处术语的范围,尤其是术语网络、数据库管理、Qos和吞吐量,是要包括所有这种先验的新技术。
应当理解的是,为了清楚起见而在各个实施例的上下文中描述的本发明某些特征还可以结合在单个实施例中来提供。相反,在单个实施例的上下文中简短进行描述的本发明的各个特征还可以单独提供或者以适当的子组合形式来提供。
尽管本发明已经结合了特定的实施例进行了描述,但是很明显的是,存在许多对于本领域技术人员显而易见的备选方式、变型和改变。因此本发明是要包含所有落在所附权利要求书的精神和广阔范围内的这种备选方式、变型和改变。此处在说明书中提到的所有公开、专利和专利申请通过引用的方式将其所有内容包括在整个说明书中,就如同分别明确地指出通过引用的方式将每个单独的公开、专利和专利申请包含在此一样。此外,该申请中的任何参考的引用或者证据不应认为是承认这种参考可以作为本发明的现有技术得到。
Claims (43)
1.一种数据访问系统,包括:
布置在虚拟分区中每个均可独立访问的数据库单元;
多个数据处理单元;以及
用于在所述虚拟分区之间切换所述数据处理单元的交换网络,从而将数据处理能力动态分配给各个虚拟分区。
2.根据权利要求1所述的数据访问系统,其中所述交换网络包括交换单元互连。
3.根据权利要求1所述的数据访问系统,其中每个数据库单元可作为各个网络信道独立访问。
4.根据权利要求1所述的数据访问系统,还包括用于对数据执行散列处理的散列单元,并且其中通过所述散列处理的结果将数据分配至各个数据库单元。
5.根据权利要求4所述的数据访问系统,其中以具有主关键字和至少一个辅助关键字的记录形式来分配数据,并且其中对所述主关键字执行散列处理。
6.根据权利要求5所述的数据访问系统,配置有至少一个路由器,以将辅助关键字和所述已散列的主关键字之间的关系制成表,使得经过所述路由器可以使基于各个辅助关键字的搜索查询与所述主关键字相关。
7.根据权利要求5所述的数据访问系统,配置有至少一个附加的自动管理内部索引表,以映射辅助关键字和所述已散列的主关键字之间的关系,使得经过所述内部索引表可以使基于各个辅助关键字的搜索查询与所述主关键字相关。
8.根据权利要求1所述的数据访问系统,其中至少在两个数据分区对数据进行至少一次复制。
9.根据权利要求1所述的数据访问系统,包括选举功能,用于动态地指定所述数据处理单元其中之一作为协调器来在冲突的写入操作之间进行仲裁。
10.根据权利要求9所述的数据访问系统,其中所述协调器被配置成有规则地发送它继续作为协调器的信号,并且其中所述选举功能被配置成当所述规则信号中断时重复所述动态指定。
11.根据权利要求10所述的数据访问系统,其中当所述动态指定得出结论时,由所述动态指定打断的写入操作从最超前的可恢复位置重新开始。
12.根据权利要求9所述的数据访问系统,其中在记录改变操作后,所述协调器被配置成为记录指定唯一的证书,从而提交相对照的所述记录版本。
13.根据权利要求4所述的数据访问系统,其中以具有至少三个关键字的记录的形式来指定数据,其中每个记录指定有基于所述关键字之一的主地址和基于剩余的所述关键字之一的辅助地址。
14.根据权利要求13所述的数据访问系统,包括解析单元,用于将辅助地址解析成相应的主地址,随后使用相应的主关键字来查找辅助关键字所限定的记录。
15.根据权利要求14所述的数据访问系统,其中所述解析单元包括至少一个路由器。
16.根据权利要求15所述的数据访问系统,其中所述解析单元还包括至少一个备份路由器。
17.根据权利要求8所述的数据访问系统,其中在一个或更多所述数据处理单元故障后,所述交换机构被配置成用于将数据分区版本重新指定给所述数据处理单元的剩余的单元,以使得可以维持所有所述虚拟分区的可用性。
18.根据权利要求1所述的数据访问系统,其中每个虚拟分区存储在预定数目的数据处理单元上,使得在给定的数据处理单元故障后,仍继续可以访问所有的数据。
19.根据权利要求18所述的数据访问系统,其中所述预定数目至少为3。
20.根据权利要求19所述的数据访问系统,其中至少为3的所述数目为奇数,以使得能够在所述复制的虚拟分区之间进行多数投票,从而确保所述数据的完整性。
21.根据权利要求20所述的数据访问系统,其中所述奇数至少为5。
22.根据权利要求1所述的数据访问系统,还包括:使用度量功能,用于度量所述数据访问系统的个体客户的使用率;以及开帐单功能,用于基于其峰值使用率来向所述客户开帐单。
23.一种数据访问系统,包括:
数据处理单元;
数据存储单元;
交换系统,用于在所述数据处理单元和所述数据存储单元之间进行动态切换;和
使用度量功能,用于度量所述数据访问系统的个体客户的使用率,以及开帐单功能,用于基于其峰值使用率来向所述客户开帐单。
24.一种提供高可用性、高缩放性的数据存储和查询系统的方法,包括:
提供数据查询装置;
提供与所述数据查询装置分离的数据存储装置;以及
提供交换系统,以在当前查询的影响下在所述数据存储装置和所述数据查询装置之间进行动态连接。
25.根据权利要求24所述的方法,包括提供所述数据存储装置作为多个信道。
26.根据权利要求25所述的方法,包括作为记录来存储每个数据项,并以所述信道的预定数目来提供任何给定的数据记录副本。
27.根据权利要求26所述的方法,其中所述预定数目是奇数。
28.根据权利要求27所述的方法,还包括在所述奇数个副本之间使用多数投票来确保所述数据的完整性。
29.根据权利要求26所述的方法,包括将所述数据记录的字段设置为主关键字,并对所述主关键字进行散列,以对所述信道进行寻址。
30.根据权利要求29所述的方法,包括将所述数据记录的字段设置为辅助关键字,并提供用于使所述辅助关键字和所述主关键字之间相关的至少一个路由器。
31.根据权利要求25所述的方法,其中所述信道是发布订购信道。
32.根据权利要求24所述的方法,其中所述数据存储装置包括多个数据存储单元,所述方法包括将数据以多个副本的形式存储在多个数据存储单元中,并且当检测到任何给定数据存储单元故障时,在所述给定数据存储单元中存储的数据单元的其它地方进行另外的复制。
33.根据权利要求32所述的方法,其中经过查询来访问所述数据,并且对于给定查询的响应取决于与所述数据相关的当前状态。
34.根据权利要求33所述的方法,还包括在至少一个数据存储单元故障的情况下,通过各个数据存储单元之间的显式状态同步来保持所述当前状态。
35.根据权利要求34所述的方法,其中所述显式状态同步是拉同步。
36.根据权利要求34所述的方法,其中所述显式状态同步是推同步。
37.根据权利要求24所述的方法,还包括度量客户的使用率。
38.根据权利要求37所述的方法,其中所述使用率被度量为峰值使用率。
39.根据权利要求38所述的方法,包括基于所述峰值使用率向所述客户开帐单。
40.一种提供具有数据存储资源和数据处理资源的数据储存库的方法,包括:
提供所述数据存储资源的动态分割;
提供所述数据处理资源的动态分配;和
在所述数据存储资源和所述数据处理资源之间使用动态切换,使得所述数据存储资源的所述动态分割从所述数据处理资源的所述动态分割中去耦合。
41.根据权利要求40所述的方法,包括将个体数据项复制到所述数据存储资源中的至少两个位置,并为所述至少两个位置提供群组地址。
42.根据权利要求40所述的方法,包括为所述数据储存库指定多种状态,使得当检测到所述储存库故障时,能够恢复到所述检测之前的状态。
43.一种无共享数据储存库,包括多个数据分区和数据项,每个数据项具有主关键字以及一个或更多辅助关键字,其中所述主关键字限定所述数据分区,每个辅助关键字作为另外的自动管理内部索引表来实施,所述内部索引表以辅助关键字来分割,并且映射了辅助关键字和所述分割主关键字之间的关系,使得基于各个辅助关键字的搜索查询可以经过所述内部索引表与所述主关键字相关。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US65544105P | 2005-02-24 | 2005-02-24 | |
US60/655,441 | 2005-02-24 | ||
US60/733,768 | 2005-11-07 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN101128827A true CN101128827A (zh) | 2008-02-20 |
Family
ID=39096067
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNA2006800058701A Pending CN101128827A (zh) | 2005-02-24 | 2006-02-21 | 用于交换网络中分布式数据管理的方法和装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101128827A (zh) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102341803A (zh) * | 2009-03-05 | 2012-02-01 | 桑迪士克以色列有限公司 | 响应于触发事件而优化所存储内容的传送的系统 |
CN102413166A (zh) * | 2011-09-22 | 2012-04-11 | 上海西本网络科技有限公司 | 分布式交易方法及其系统 |
CN102541990A (zh) * | 2010-12-07 | 2012-07-04 | 国际商业机器公司 | 利用虚拟分区的数据库重新分布方法和系统 |
CN102804183A (zh) * | 2010-03-15 | 2012-11-28 | 微软公司 | 在持续工作负荷下的数据重新组织 |
CN103399790A (zh) * | 2013-08-20 | 2013-11-20 | 浙江中控技术股份有限公司 | 一种基于分布式实时数据库系统的事务提交方法及装置 |
CN105119745A (zh) * | 2015-08-19 | 2015-12-02 | 浪潮(北京)电子信息产业有限公司 | 一种用于提高db2 dpf可用性的方法及系统 |
CN107045426A (zh) * | 2017-04-14 | 2017-08-15 | 北京粉笔蓝天科技有限公司 | 一种多副本读取方法和系统 |
CN107360268A (zh) * | 2017-06-23 | 2017-11-17 | 北京奇艺世纪科技有限公司 | 一种数据包处理方法、装置及设备 |
CN107637047A (zh) * | 2015-05-08 | 2018-01-26 | 高通股份有限公司 | 聚合目标和探索查询 |
CN107656981A (zh) * | 2017-09-08 | 2018-02-02 | 中国科学院计算机网络信息中心 | 一种基于标识技术的数据共享和管理方法及系统 |
CN110896506A (zh) * | 2018-09-12 | 2020-03-20 | 萨伯康姆有限责任公司 | 用于对光传输系统进行安全分区以提供多客户端管理访问的技术和实现其的网络管理系统 |
CN115424658A (zh) * | 2022-11-01 | 2022-12-02 | 南京芯驰半导体科技有限公司 | 存储单元的测试方法、装置、电子设备、存储介质 |
-
2006
- 2006-02-21 CN CNA2006800058701A patent/CN101128827A/zh active Pending
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102341803A (zh) * | 2009-03-05 | 2012-02-01 | 桑迪士克以色列有限公司 | 响应于触发事件而优化所存储内容的传送的系统 |
CN102804183B (zh) * | 2010-03-15 | 2016-03-09 | 微软技术许可有限责任公司 | 在持续工作负荷下的数据重新组织 |
US10061830B2 (en) | 2010-03-15 | 2018-08-28 | Microsoft Technology Licensing, Llc | Reorganization of data under continuous workload |
CN102804183A (zh) * | 2010-03-15 | 2012-11-28 | 微软公司 | 在持续工作负荷下的数据重新组织 |
US9684702B2 (en) | 2010-12-07 | 2017-06-20 | International Business Machines Corporation | Database redistribution utilizing virtual partitions |
CN102541990B (zh) * | 2010-12-07 | 2015-05-20 | 国际商业机器公司 | 利用虚拟分区的数据库重新分布方法和系统 |
CN102541990A (zh) * | 2010-12-07 | 2012-07-04 | 国际商业机器公司 | 利用虚拟分区的数据库重新分布方法和系统 |
CN102413166A (zh) * | 2011-09-22 | 2012-04-11 | 上海西本网络科技有限公司 | 分布式交易方法及其系统 |
CN103399790A (zh) * | 2013-08-20 | 2013-11-20 | 浙江中控技术股份有限公司 | 一种基于分布式实时数据库系统的事务提交方法及装置 |
CN103399790B (zh) * | 2013-08-20 | 2016-12-28 | 浙江中控技术股份有限公司 | 一种基于分布式实时数据库系统的事务提交方法及装置 |
US10880198B2 (en) | 2015-05-08 | 2020-12-29 | Qualcomm Incorporated | Aggregating targeted and exploration queries |
CN107637047A (zh) * | 2015-05-08 | 2018-01-26 | 高通股份有限公司 | 聚合目标和探索查询 |
CN107637047B (zh) * | 2015-05-08 | 2020-07-31 | 高通股份有限公司 | 聚合目标和探索查询 |
CN105119745A (zh) * | 2015-08-19 | 2015-12-02 | 浪潮(北京)电子信息产业有限公司 | 一种用于提高db2 dpf可用性的方法及系统 |
CN107045426A (zh) * | 2017-04-14 | 2017-08-15 | 北京粉笔蓝天科技有限公司 | 一种多副本读取方法和系统 |
CN107360268A (zh) * | 2017-06-23 | 2017-11-17 | 北京奇艺世纪科技有限公司 | 一种数据包处理方法、装置及设备 |
CN107656981A (zh) * | 2017-09-08 | 2018-02-02 | 中国科学院计算机网络信息中心 | 一种基于标识技术的数据共享和管理方法及系统 |
CN110896506A (zh) * | 2018-09-12 | 2020-03-20 | 萨伯康姆有限责任公司 | 用于对光传输系统进行安全分区以提供多客户端管理访问的技术和实现其的网络管理系统 |
CN110896506B (zh) * | 2018-09-12 | 2024-03-26 | 萨伯康姆有限责任公司 | 用于对光传输系统进行安全分区以提供多客户端管理访问的技术和实现其的网络管理系统 |
CN115424658A (zh) * | 2022-11-01 | 2022-12-02 | 南京芯驰半导体科技有限公司 | 存储单元的测试方法、装置、电子设备、存储介质 |
CN115424658B (zh) * | 2022-11-01 | 2023-01-31 | 南京芯驰半导体科技有限公司 | 存储单元的测试方法、装置、电子设备、存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7644087B2 (en) | Method and apparatus for data management | |
CN101128827A (zh) | 用于交换网络中分布式数据管理的方法和装置 | |
US8676951B2 (en) | Traffic reduction method for distributed key-value store | |
CN105324770B (zh) | 有效读出副本 | |
US20130110873A1 (en) | Method and system for data storage and management | |
US9201742B2 (en) | Method and system of self-managing nodes of a distributed database cluster with a consensus algorithm | |
Auradkar et al. | Data infrastructure at LinkedIn | |
CA2913036C (en) | Index update pipeline | |
CN103345502B (zh) | 分布式数据库的事务处理方法和系统 | |
CN102855284A (zh) | 一种集群存储系统的数据管理方法及系统 | |
CN106993064A (zh) | 一种基于Openstack云平台实现海量数据可伸缩性存储的系统及其构建方法与应用 | |
US10712964B2 (en) | Pre-forking replicas for efficient scaling of a distributed data storage system | |
US11263270B1 (en) | Heat balancing in a distributed time-series database | |
Waqas et al. | Transaction management techniques and practices in current cloud computing environments: A survey | |
US11409771B1 (en) | Splitting partitions across clusters in a time-series database | |
CN102316154B (zh) | 优化对基于联盟基础结构的资源的访问 | |
CN107547657A (zh) | 一种基于云存储系统中单点数据编号的方法、装置以及存储介质 | |
US11366598B1 (en) | Dynamic lease assignments in a time-series database | |
Cooper et al. | PNUTS to sherpa: Lessons from yahoo!'s cloud database | |
CN107678688A (zh) | 一种基于云存储系统中的管理冗余副本的方法、装置和存储介质 | |
JPS61285535A (ja) | ハイブリツド・デイレクトリ・デ−タ分散システム | |
Marungo | A primer on NoSQL databases for enterprise architects: The CAP theorem and transparent data access with MongoDB and Cassandra | |
Plantikow et al. | Transactions for distributed wikis on structured overlays | |
Thant et al. | Improving the availability of NoSQL databases for Cloud Storage | |
Bouharaoua et al. | A quorum-based intelligent replicas management in data grids to improve performances |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |