Oracle NoSQL 基本架构和工作机制

2014-01-21 ora_nosql

Oracle NoSQL 数据库系统包括两个主要部分:客户端和服务端。如上图所示,客户端(Java或C类库)“嵌入”到应用程序中,并提供API给应用程序调用。而服务端部署于多个逻辑上的存储节点上,每台存储节点映射到数据中心中的一台物理或者虚拟计算机。下文我们将详细介绍这些组件。


【服务端】

图一 复制节点及存储节点

NoSQL服务端是部署于多个存储节点(Storage Node或SN)的数据库集群。存储节点通常是配有本地持久存储(磁盘或固态硬盘)、具备单核或多核 CPU、内存和一个 IP 地址的物理计算机。存储节点越多,系统提供的总吞吐量或存储能力越大。而复制组中的复制因子(Replication Factor或RF)越高,即副本越多,系统的读请求的服务能力越大。

每个存储节点运行着一个或多个复制节点。每个复制节点只属于一个复制组。同一复制组中的节点全部含有相同的数据。每个组都有一个指定的主节点,该主节点负责处理所有数据修改操作(创建、更新和删除)。其他节点是只读副本,但可在主节点失效的情况下承担主节点的角色。典型情况下选择3副本(即RF=3),可确保系统能够应付两个复制节点同时发生的故障,并继续提供读操作服务。此参数可随应用程序对可靠性的要求高低做相应调整。

图一所示为具有 30 个复制组 (0-29) 的系统,30 个复制组存储在 30 个存储节点上,跨两个数据中心。每个复制组的 3 个复制节点(一个主节点,两个副本节点)分散在两个数据中心的存储节点上。请注意,我们将两个复制节点放在能力大的主数据中心中,将另外一个复制节点放在较小的从数据中心中。这种安排优化了主从数据中心的资源使用,并且达到了异地灾难备份的目的。如果主数据中心发生灾难性故障,从数据中心完成功能切换,继续提供服务。


【复制组】

Oracle NoSQL 数据库使用复制来确保发生故障时数据可用。其“单个主节点-多副本节点”的复制机制规定在主节点执行写入,然后再通过事务提交给副本节点。如果主节点发生故障,则复制组中的节点自动做出可靠的选择(使用 Paxos 协议),即选择其余节点之一作为主节点。新主节点然后负责写入。

图二 复制机制

如图二所示,主节点会定期将写操作(包括:插入、更新和删除)的事务日志信息同步或者提交到副本节点。此外,主节点还会定期向副本节点发送heartbeat(“心跳”)。如果没有收到主节点发来的heartbeat,副节点将认为主节点或网络可能出现故障,并且发起一次主节点选举来解决这次潜在的问题。通常这些问题可能是网络、介质、软件、甚至应用等引起的故障和异常。


【客户端】


客户端驱动程序会在内存中保存系统拓扑结构和复制组状态表 (RGST) 的副本。通过“哈希映射”和拓扑结构可以迅速地将“键”映射到分区(partition),并从分区映射到复制组。对于每个复制组,拓扑信息包含复制组中每个复制节点的存储节点的主机名、与复制节点关联的服务名以及每个存储节点所在的数据中心。客户端然后将 RGST 用于两个主要目的:确定复制组的主节点,以便向主节点发送写操作请求,并在复制组中跨所有节点进行负载平衡以便于读取操作。由于 RGST 是关键的共享数据结构,因此每个客户端和复制节点均保留自己的副本,以避免任何单点故障。

图三 复制组状态表


【增加记录的处理过程】


最后,我们来看看插入一条记录的处理过程,从而将请求从客户端到服务端的顺序理清楚。


图四 增加记录的处理流程


如图四所示,我们可以看出Oracle NoSQL数据库在处理写操作的具体步骤:

  1. 应用层通过调用ONDB API,执行数据库写请求 – putIfAbsent();

  2. 客户端驱动根据参数(即键值“katana”)做Hash 计算得到对应数据所在的分区ID(Partition ID);

  3. 使用分区表(Partition Table)将分区ID 映射得到对应的复制组;

  4. 针对复制组,客户端驱动程序查阅复制组状态表(RGST);

  5. 复制组状态表中存储了每个复制组中的节点信息,如类型(Type)、响应时间(Response)、主机(Host)等;

  6. 基于复制组状态表中的信息,再结合请求类型(读/写)以及事务策略(一致性和持久性选项),客户端驱动选择一个合适的存储节点去执行该请求。本次操作是写操作,定位到主节点。

  7. 主节点将该条记录保存到本地,并和该组里的其他副本节点同步该条记录。同步的过程可能是异步的,取决于写操作的持久性选项。