5 个非常重要的数据 Oceanbase,TiDB,Cassandra,RocksDB,MemDB

1. Oceanbase

1.1 Oceanbase 基本架构

• 多副本：OceanBase 一般部署为三个 Zone，每个 Zone 由多个节点/服务器（OBServer）组成

• 全对等节点：每个节点均有自己的 SQL 引擎和存储引擎，各自管理不同的数据分区，完全对等

• 无共享：OceanBase 数据分布在各个节点上，不基于任何共享存储结构

• 数据分区：OceanBase 数据架构的基本单元，是传统数据库的分区表在分布式系统上的实现。

高可用+强一致：多副本+Paxos 协议，保证数据（日志）写（持久化）到三台机器中至少两台 （每个 Zone 中基线数据分布在 ChunkSever 上，有两个或三个副本，增量数据在 UpdateSever 上是一主一备）

ObProxy：百万级处理能力的代理，路由转发，轻量级 SQLParser，无状态

• 反向代理功能

• 性能需求

• 运维需求

1.2 Oceanbase 特性

• 高性能：存储采用读写分离架构，计算引擎全链路性能优化，准内存数据库性能。

• 低成本：使用 PC 服务器和低端 SSD，高存储压缩率降低存储成本，高性能降低计算成本，多租户混部充分利用系统资源。

• 高可用：数据采用多副本存储，少数副本故障不影响数据可用性。通过“三地五中心”部署实现城市级故障自动无损容灾。

• 强一致：数据多副本通过 paxos 协议同步事务日志，多数派成功事务才能提交。缺省情况下读、写操作都在主副本进行，保证强一致。

• 可扩展：集群节点全对等，每个节点都具备计算和存储能力，无单点瓶颈。可线性、在线扩展和收缩。

• 兼容性：兼容常用 MySQL/ORACLE 功能及 MySQL/ORACLE 前后台协议，业务零修改或少量修改即可从 MySQL/ORACLE 迁移至 OceanBase。

1.3 应用场景

金融级数据可靠性需求

金融环境下通常对数据可靠性有更高的要求，OceanBase 每一次事务提交，对应日志总是会在多个数据中心实时同步，并持久化。即使是数据中心级别的灾难发生，总是可以在其他的数据中心恢复每一笔已经完成的交易，实现了真正金融级别的可靠性要求。

让数据库适应飞速增长的业务

业务的飞速成长，通常会给数据库带来成倍压力。OceanBase 作为一款真正意义的分布式关系型数据库，由一个个独立的通用计算机作为系统各个节点，数据根据容量大小、可用性自动分布在各个节点，当数据量不断增长时，OceanBase 可以自动扩展节点的数量，满足业务需求。

连续不间断的服务

企业连续不间断的服务，通常意味着给客户最流畅的产品体验。分布式的 OceanBase 集群，如果某个节点出现异常时，可以自动剔除此服务节点，该节点对应的数据有多个其他副本，对应的数据服务也由其他节点提供。甚至当某个数据中心出现异常，OceanBase 可以在短时间内将服务节点切换到其他数据中心，可以保证业务持续可用。

1.4 正在使用的企业

1.5 薪资情况

1.6 相关文章或视频

阿里巴巴开源数据库--OceanBase从使用聊到架构剖析

2. TiDB

2.1 TiDB 整体架构

TiDB Server

TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（LVS、HAProxy 或 F5）对外提供统一的接入地址。

PD Server

Placement Driver（简称 PD）是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在那个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。

PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。PD 在选举的过程中无法对外提供服务，这个时间大约是 3 秒。

TiKV Server

TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度，这里也就是以 Region 为单位进行调度

2.2 TiDB 特性

• 一键水平扩容或者缩容，得益于 TiDB 存储计算分离的架构设计，可按需对计算、存储分别进行在线扩容、缩容，调整过程中对应用运维人员透明。

• 金融级高可用数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

• 实时 HTAP 提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复 制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

• 云原生的分布式数据库专为云而设计的分布式数据库，通过 TiDBOperator 可在公有云、私有云、混合云中实现部署工具化、自动化。

• 兼容 MySQL5.7 协议和 MySQL 生态兼容 MySQL5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

2.3 应用场景

• 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景。众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO(RecoveryTimeObjective)及 RPO(RecoveryPointObjective)无法真实达到企业所期望的值。TiDB 采用多副本+Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机 器出现故障时系统可自动进行切换，确保系统的 RTO<=30s 及 RPO=0。

• 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景。随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、 存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

• Real-time HTAP 场景。随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版 本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况 下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

• 数据汇聚、二次加工处理的场景。 当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成， 但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多， 业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。TiDB v4.0 在稳定性、易用性、性能、安全和功能方面进行了大量的改进

2.4 正在使用的企业

TiDB 凭借领先的技术能力及完善的商业服务支持体系，帮助金融、互联网、零售、物流、制造、公共服务等行业用户构建面向未来的数据服务平台。

目前，TiDB 已在全球超过 1500 家头部企业的生产环境中得到应用，包括 中国银行、光大银行、浦发银行、浙商银行、北京银行、微众银行、亿联银行、中国银联、中国人寿、平安人寿、陆金所、中国移动、中国联通、中国电信、中体骏彩、国家电网、理想汽车、小鹏汽车、VIVO、OPPO、百胜中国、中国邮政、顺丰速运、中通快递、腾讯、美团、京东、拼多多、小米、新浪微博、58 同城、360、知乎、爱奇艺、哔哩哔哩、Square（美国）、Dailymotion（法国）、Shopee（新加坡）、ZaloPay（越南）、BookMyShow（印度） 等。

2.5 薪资情况

2.6 相关文章或视频

TiDB概述和整体架构

3. Cassandra

Cassandra 是一个开源的、分布式、无中心节点、弹性可扩展、高可用、容错、一致性协调、面向列的 NoSQL 数据库

3.1 Cassandra 内部架构

3.1.1 Cassandra 集群（Cluster）

• Cluster

• Data center(s)

• Rack(s)

• Server(s)

• Node (more accurately, a vnode)

• Node（节点）：一个运行 cassandra 的实例

• Rack（机架）：一组 nodes 的集合

• DataCenter（数据中心）：一组 racks 的集合

• Cluster（集群）：映射到拥有一个完整令牌圆环所有节点的集合

3.1.2 协调者（Coordinator）

客户端连接到某一节点发起读写请求时，该节点充当客户端应用与集群中拥有相应数据节点间的桥梁，称为协调者，以根据集群配置确定环(ring)中的哪个节点应当获取这个请求。

使用 CQL 连接指定的-h 节点就是协调节点

• 集群中任何一个节点都可能成为协调者

• 每个客户端请求都可能由不同的节点来协调

• 由协调者管理复制因子（复制因子：一条新数据应该被复制到多少个节点）

• 协调者申请一致性级别（一致性级别：集群中有多少节点必须相应读写的请求）

3.1.3 分区器（Partitioner）

分区器决定了数据如何在集群内被分发。在 Cassandra 中，table 的每行由唯一的 primarykey 标识，partitioner 实际上为一 hash 函数用，以计算 primary key 的 token。Cassandra 依据这个 token 值在集群中放置对应的行。

Cassandra 提供了三种不同的分区器

• Murmur3Partitioner（默认）- 基于 MurmurHash hash 值将数据均匀的分布在集群

• RandomPartitioner - 基于 MD5 hash 值将数据均匀的分布在集群中

• ByteOrderedPartitioner - 通过键的字节来保持数据词汇的有序分布

3.1.4 虚拟节点（Vnode）

每个虚拟节点对应一个 token 值，每个 token 决定了节点在环中的位置以及节点应当承担的一段连续的数据 hash 值的范围，因此每个节点都拥有一段连续的 token，这一段连续的 token，组成了一个封闭的圆环。

没有使用虚拟节点, Ring 环的 tokens 数量=集群的机器数量. 比如一共有 6 个节点,所以 token 数=6.因为副本因子=3,一条记录要在集群中的三个节点存在. 简单地方式是计算 rowkey 的 hash 值,落在环中的哪个 token 上,第一份数据就在那个节点上,剩余两个副本落在这个节点在 token 环上的后两个节点.

图中的 A,B,C,D,E,F 是 key 的范围,真实的值是 hash 环空间,比如 0~2^32 区间分成 10 份.每一段是 2^32 的 1/10.节点 1 包含 A,F,E 表示 key 范围在 A,F,E 的数据会存储到节点 1 上.以此类推.

若不使用虚拟节点则需手工为集群中每个节点计算和分配一个 token。每个 token 决定了节点在环中的位置以及节点应当承担的一段连续的数据 hash 值的范围。如图上半部分，每个节点分配了一个单独的 token 代表环中的一个位置，每个节点存储将 row key 映射为 hash 值之后落在该节点应当承担的唯一的一段连续的 hash 值范围内的数据。每个节点也包含来自其他节点的 row 的副本。

而使用虚拟节点允许每个节点拥有多个较小的不连续的 hash 值范围。如图中下半部分，集群中的节点使用了虚拟节点，虚拟节点随机选择且不连续。数据的存放位置也由 row key 映射而得的 hash 值确定，但是是落在更小的分区范围内。

使用 virtual nodes 的好处

• 无需为每个节点计算、分配 token

• 添加移除节点后无需重新平衡集群负载

• 重建异常的节点更快

3.1.5 复制（Replication）

当前有两种可用的复制策略：

• SimpleStrategy：仅用于单数据中心，将第一个 replica 放在由 partitioner 确定的节点中，其余的 replicas 放在上述节点顺时针方向的后续节点中。

• NetworkTopologyStrategy：可用于较复杂的多数据中心。可以指定在每个数据中心分别存储多少份 replicas。

复制策略在创建 keyspace 时指定，如

CREATE KEYSPACE Excelsior WITH REPLICATION = { 'class' : 'SimpleStrategy','replication_factor' : 3 };  CREATE KEYSPACE Excalibur WITH REPLICATION = {'class' :'NetworkTopologyStrategy', 'dc1' : 3, 'dc2' : 2};

其中 dc1、dc2 这些数据中心名称要与 snitch 中配置的名称一致.上面的拓扑策略表示在 dc1 配置 3 个副本,在 dc2 配置 2 个副本

3.1.6 八卦（gossip）

Gossip 协议是群集中节点相互通信的内部通信技术。 Gossip 是一种高效，轻量，可靠的节点间用于交换数据的广播协议，。 它是分散式的、容错和点对点的通信协议。 Cassandra 使用 gossipibing 来进行对等发现和元数据传播。

gossip 协议的具体表现形式就是配置文件中的 seeds 种子节点. 一个注意点是同一个集群的所有节点的种子节点应该一致.否则如果种子节点不一致, 有时候会出现集群分裂, 即会出现两个集群. 一般先启动种子节点,尽早发现集群中的其他节点.每个节点都和其他节点交换信息, 由于随机和概率,一定会穷举出集群的所有节点.同时每个节点都会保存集群中的所有其他节点.这样随便连到哪一个节点,都能知道集群中的所有其他节点. 比如 cql 随便连接集群的一个节点,都能获取集群所有节点的状态.也就是说任何一个节点关于集群中的节点信息的状态都应该是一致的!

gossip 进程每秒运行一次，与至多 3 个其他节点交换信息，这样所有节点可很快了解集群中的其他节点信息。由于整个过程是分散的，并没有一个节点去协调每个节点的 gossip 信息，每个节点都会独立地选择一个到三个节点进行 gossip 通信，它始终选择集群中活动着的对等节点，概率性的选择 seed 节点和不可达的节点。

gossip 协议和 tcp 三次握手比较相似，使用常规的广播协议，每轮只能有一条消息，并且允许消息在集群内部逐渐传播，但随着 gossip 协议，每条 gossip 消息都只会包含三条消息，增加了一定程度的逆熵。这个过程允许相互进行数据交换的节点之间快速的收敛。

首先系统需要配置几个种子节点，比如说 A、B, 每个参与的节点都会维护所有节点的状态，node->(Key,Value,Version),版本号较大的说明其数据较新，节点 P 只能直接更新它自己的状态，节点 P 只能间接的通过 gossip 协议来更新本机维护的其他节点的数据。

大致的过程如下:

• SYN:节点 A 向随机选择一些节点，这里可以只选择发送摘要，即不发送 valus,避免消息过大

• ACK:节点 B 接收到消息后，会将其与本地的合并，这里合并采用的是对比版本，版本较大的说明数据较新. 比如节点 A 向节点 B 发送数据 C(key,valuea,2),而节点 B 本机存储的是 C(key,valueb,3),那么因为 B 的版本比较新，合并之后的数据就是 B 本机存储的数据，然后会发回 A 节点。

• ACK2:节点 A 接收到 ACK 消息，将其应用到本机的数据中.

3.1.7 一致性（Consistency Level）

一致性指一行数据的所有副本集是否最新和同步。Cassandra 扩展了最终一致性的概念，对一个读或者写操作，所谓可调节的一致性的概念，指发起请求的客户端，可以通过 consistency level 参数，指定本次请求，需要的一致性。

写操作的一致性

注意：

即使指定了 consistency level ON 或 LOCAL_QUORUM，写操作还是会被发送给所有的 replica 节点，包括其他数据中心的里 replica 节点。consistency level 只是决定了，通知客户端请求成功之前，需要确保写操作成功的 replica 节点的数量。

读一致性

3.2 Cassandra 特点

• 高可扩展性：Cassandra 具有高度的可扩展性，可以帮助您可随时添加更多硬件，以便根据需求附加更多客户和更多数据。

• 刚性结构：Cassandra 没有一个单一的故障点，它可用于无法承受故障的关键业务应用程序。

• 快速线性规模的性能：Cassandra 线性可扩展。它可以提高吞吐量，因为它可以帮助您增加群集中的节点数量。 因此，它保持快速的响应时间。

• 容错：Cassandra 是容错的。 假设集群中有 4 个节点，这里每个节点都有相同数据的副本。 如果一个节点不再服务，则其他三个节点可以按照请求进行服务。

• 灵活的数据存储：Cassandra 支持所有可能的数据格式，如结构化，半结构化和非结构化。 它可以帮助您根据需要更改数据结构。

• 简单的数据分发：Cassandra 中的数据分发非常简单，因为它可以灵活地通过在多个数据中心复制数据来分发所需的数据。

• 事务支持：Cassandra 支持事务，诸如原子性，一致性，隔离和持久性(ACID)等属性。

• 快速写入：Cassandra 的设计是在便宜的商品硬件上运行。 它执行快速写入，可以存储数百 TB 的数据，而不会牺牲读取效率。

3.3 Cassandra 应用场景

理想的 Cassandra 应用程序具有以下特征：

• 写入大幅度超出读。

• 数据很少更新，并且在进行更新时它们是幂等的。

• 通过主键查询，非二级索引。

• 可以通过 partitionKey 均匀分区。

• 不需要 Join 或聚合。

推荐使用 Cassandra 的一些好场景是：

• 交易日志：购买，测试分数，观看的电影等。

• 存储时序数据（需要您自行聚合）。

• 跟踪几乎任何事情，包括订单状态，包裹等。

• 存储健康追踪数据。

• 气象服务历史。

• 物联网状态和事件历史。

• 汽车的物联网数据。

• 电子邮件

3.4 Cassandra 正在使用的企业

3.4.1 思科案例

用例

思科商业更新云

商业分析与报告

3.4.4 其他使用情况

3.5 相关文章或视频

• 高性能存储引擎RocksDB模块详解
  

• RocksDB概念及简单应用
  

4.RocksDB

RocksDB 是用 C++编写的嵌入式 KV 存储引擎，由 Facebook 基于 levelDB 开发，它支持多种存储硬件，使用日志结构的数据库引擎(基于 LSM-Tree)来存储数据。

4.1 RocksDB 架构

Rocksdb 基础架构

RocksDB 读写流程

4.2 RocksDB 特点

RocksDB 相对传统的关系数据库的一大改进是采用 LSM 树存储引擎。

4.2.1 LSM 树（Log-Structured Merge Tree）

LSM-tree

LSM 树而且通过批量存储技术规避磁盘随机写入问题。 LSM 树的设计思想非常朴素, 它的原理是把一颗大树拆分成 N 棵小树， 它首先写入到内存中（内存没有寻道速度的问题，随机写的性能得到大幅提升），在内存中构建一颗有序小树，随着小树越来越大，内存的小树会 flush 到磁盘上。磁盘中的树定期可以做 merge 操作，合并成一棵大树，以优化读性能。

4.2.2 LevelDB 特点

LevelDB

• LevelDB 是一个持久化存储的 KV 系统，和 Redis 这种内存型的 KV 系统不同，LevelDB 不会像 Redis 一样狂吃内存，而是将大部分数据存储到磁盘上。

• LevleDb 在存储数据时，是根据记录的 key 值有序存储的，就是说相邻的 key 值在存储文件中是依次顺序存储的，而应用可以自定义 key 大小比较函数。

• LevelDB 支持数据快照（snapshot）功能，使得读取操作不受写操作影响，可以在读操作过程中始终看到一致的数据。

• LevelDB 还支持数据压缩等操作，这对于减小存储空间以及增快 IO 效率都有直接的帮助。

4.2.3 RocksDB 对 LevelDB 的优化

• 增加了 column family，这样有利于多个不相关的数据集存储在同一个 db 中，因为不同 column family 的数据是存储在不同的 sst 和 memtable 中，所以一定程度上起到了隔离的作用。

• 采用了多线程同时进行 compaction 的方法，优化了 compact 的速度。

• 增加了 merge operator，优化了 modify 的效率。

• 将 flush 和 compaction 分开不同的线程池，能有效的加快 flush，防止 stall。

• 增加了对 write ahead log(WAL)的特殊管理机制，这样就能方便管理 WAL 文件，因为 WAL 是 binlog 文件。

4.2.4 RocksDB 架构分析

优势:

• 所有的刷盘操作都采用 append 方式，这种方式对磁盘和 SSD 是相当有诱惑力的；

• 写操作写完 WAL 和 Memtable 就立即返回，写效率非常高。

• 由于最终的数据是存储在离散的 SST 中，SST 文件的大小可以根据 kv 的大小自由配置，因此很适合做变长存储。

劣势：

• 为了支持批量和事务以及上电恢复操作，WAL 是多个 CF 共享的，导致了 WAL 的单线程写模式，不能充分发挥高速设备的性能优势（这是相对介质讲，相对 B 树等其他结构还是有优势）；

• 读写操作都需要对 Memtable 进行互斥访问，在多线程并发写及读写混合的场景下容易形成瓶颈。

• 由于 Level0 层的文件是按照时间顺序刷盘的，而不是根据 key 的范围做划分，所以导致各个文件之间范围有重叠，再加上文件自上向下的合并，读的时候有可能需要查找 level0 层的多个文件及其他层的文件，这也造成了很大的读放大。尤其是当纯随机写入后，读几乎是要查询 level0 层的所有文件，导致了读操作的低效。

• 针对第三点问题，Rocksdb 中依据 level0 层文件的个数来做前台写流控及后台合并触发，以此来平衡读写的性能。这又导致了性能抖动及不能发挥高速介质性能的问题。

• 合并流程难以控制，容易造成性能抖动及写放大。尤其是写放大问题，在笔者的使用过程中实际测试的写放大经常达到二十倍左右。这是不可接受的，当前我们也没有找到合适的解决办法，只是暂时采用大 value 分离存储的方式来将写放大尽量控制在小数据。

4.3 应用场景

4.3.1 适用场景

• 对写性能要求很高，同时有较大内存来缓存 SST 块以提供快速读的场景；

• SSD 等对写放大比较敏感以及磁盘等对随机写比较敏感的场景；

• 需要变长 kv 存储的场景；

• 小规模元数据的存取；

4.3.2 不适合场景

• 大 value 的场景，需要做 kv 分离；

• 大规模数据的存取

4.4 正在使用的企业

4.5 相关文章或视频

• 高性能存储引擎RocksDB模块详解
  

• RocksDB概念及简单应用
  

5.MemDB

5.1 MemDB 架构

内存数据库 memdb 是一个灵活的内存数据库，提供事务支持，具有 SQL 读写能力，支持多中心广域网集群部署，用于构建和加速需要超高速数据交互并具有高可扩展性的应用系统。在云的另一端云洞察带你去玩大数据不能做成花瓶的新鲜肉云洞察的三项高超技能富含身体系统。

5.2 MemDB 特点

• MemDB 是定位于【memcache、redis】与【mysql】间的一个 key/value 持久存储平台。

• 与 Memcache、redis 不同，MemDB 通过扩充存储引擎满足不同类型数据、业务规则的数据的高效存储于操作。

• 对于不同的引擎，Unistor 对外提供一致的访问 API。但存储引擎可以通过 MemDB API 的扩展字段，对接口进行裁剪、扩展，以满足自己业务的需要。

• MemDB 虽自身不支持分组，但用户可以基于 Key 的范围进行划分(也可基于 hash)。系统对基于 key 范围的数据导出提供支持。key 的大小比较及 hash，有用户的存储引擎决定

• MemDB 通过 zookeeper 实现集群以保证系统的高可用。一个集群对外不分主、从内部进行消息的转发。支持用户建立 master、slave 集群。

• MemDB 提供可配置的 Read、write Cache 以保证读写的高效。

• MemDB 有自己的 binlog，保证系统数据的高可靠，而且数据同步采用多连接防止阻塞。支持高效的跨 IDC 数据同步。

• MemDB 提供完备的运行信息共运维使用。此信息可通过监控端口的 mc stats 指令获取，也可以通过 get/gets 接口获取，此时 i 参数的值为 2(获取系统信息)。

• MemDB 提供统一的运维工具。

• MemDB 的存储引擎开发非常简单。

5.3 应用场景

属于云计算洞察包括三类产品之一，其他两类产品为大数据处理平台 Hadoop、分布式并行数据库 MPP

5.4 正在使用的企业

5.5 相关文章或视频

• 分布式事务内存数据库--MemDB