此文章为Carol McDonald在2017年9月所写的文章的日文翻译。主题是对比MapR-DB与Cassandra、HBase等其他数据库的特点。这篇文章内容详实，涵盖了MapR-DB及MapR-FS基础技术的底层行为解析。我向Carol提出了翻译这篇文章的请求，她欣然同意，所以我在这里要向大家介绍一下。
由于时间过去了一段时间，Cassandra和HBase的行为可能已经发生了变化，希望大家可以谅解。
至于MapR-DB的行为，则没有发生任何变化。

---

如果涉及到要求高性能的产品的开发人员或架构师，就需要理解什么会产生差异。
这就像赛车手选择高性能赛车一样。
在这一点上，我之前写的关于详细架构的文章《深入了解HBase架构》、《Apache Drill架构：终极指南》和《如何使流先导的架构模式改变医疗平台》都非常受欢迎，希望大家这次也能喜欢。

在本篇文章中，我们将详细介绍MapR-DB的架构，并与具有相同NoSQL架构的Cassandra和HBase进行比较。我们将解释MapR-DB如何实现即时恢复、零数据丢失等功能，并具备快速、一致且可扩展的性能。

为什么选择NoSQL数据库？

简言之，选择NoSQL的动机是数据的容量、速度和多样性。MapR-DB提供了两种不同的模型来满足数据的多样性需求。

• HBase APIを持つワイドカラム型データモデル

 

(MongDB APIに類似した)Open JSON APIを持つドキュメント型モデル

最近ESG Labs的分析显示，在云环境中，就容量和速度而言，相较于Cassandra和HBase，结果显示快了将近10倍(数值越大表明性能越好)。

如何在保持规模性能的同时实现高速读写？

重要的是对并行执行进行分区，并尽可能减少磁盘读写的时间消耗。

关于关系模型的局限性

在使用关系模型时，我们需要对数据的存储进行规范化，消除冗余数据，并有效地使用存储空间。
然后，使用索引和连接查询来重新汇集所需的数据进行处理。
然而，由于索引创建涉及到大量的磁盘I/O操作，因此插入数据会花费时间。
此外，连接操作会导致大量数据的读取，成为瓶颈。
因此，关系模型无法在集群内进行水平扩展。

MapR-DB 被设计为自动分区，以实现低调的功能。

无论是使用HBase API还是JSON API，MapR-DB都会根据表的键范围自动在集群中进行分区。同时，集群中的每个服务器都拥有用于表的子集的数据源。MapR-DB具有“查询优先”的模式设计，所以请先考虑要执行的查询。然后设计行键，以实现数据的均匀分布和有效的主索引。不论是以文档（JSON）还是列（HBase）的形式，行应该被设计为包含同时读取的数据的组。在MapR-DB中，模式被非规范化为一行或一篇文档，存储在关系型世界中被索引的多表数据。通过键范围将数据分组，可以实现基于行键的快速读写。

请参考此链接以获取有关使用HBase API的MapR-DB模式设计的更多详细信息。

NoSQL如何实现高速写入

使用以B树为基础的传统数据库能够实现非常快速的读取，但由于磁盘I/O未经组织并且效率低下，实时更新的成本较高。

一方面，Log Structured Merge树（LSM树）的设计旨在通过最小化非顺序磁盘I/O的发生，提供比传统的基于B树的数据库更高的写入吞吐量。
LSM树在HBase、Cassandra、MongoDB等数据库中被广泛使用。
LSM树将更新写入到磁盘和内存中的日志中。
更新数据被追加到仅用于恢复的日志文件中，并在内存中进行排序。
当内存中的写入数据存储区域全部用完时，会被刷新到磁盘上的不可变新文件中。

阅读放大

LSM树的设计可以实现快速写入，但如果查询的行数据不存在于内存中，随着更多文件被写入磁盘，需要检索多个文件来获取目标行数据将变得必要。在这种情况下，读取速度将下降。（注：这被称为读取放大）

写入放大

为了加快读取速度，需要通过后台处理进程，通过命令或定期方式，读取多个文件并在内存中进行排序和合并，然后按照键值对形式对新生成的较大文件进行排序并写入，以实现紧凑化。

然而，由于该紧凑操作会引发大量的磁盘I/O从而降低写入吞吐量，因此称为写放大。
Cassandra在进行压缩时需要50%的可用磁盘空间，如果由于压缩而导致磁盘空间不足，操作系统将停止运行。
读/写放大会导致HBase和Cassandra出现无法预测的延迟增长。
根据ESG Labs最近的研究，MapR-DB相比Cassandra和HBase展现出最多10倍的性能提升，并且延迟在可预测的范围内且较低（如下图所示，数值越低表示性能越好）。

在MapR-DB中，如何降低延迟？

LSM树实现了比B树更快的写入速度，但读取性能较差。
此外，在LSM树中，平衡不过度紧缩的情况（会影响读取性能）和过度紧缩的情况（会影响写入性能）非常重要。
在MapR-DB中，我们处于这两者之间，既避免了像HBase和Cassandra那样的压力，又避免了过去系统中高随机IO的问题。
因此，我们能够提供非常稳定、延迟极低且吞吐量非常高的性能。

理解MapR-DB与其他系统所能做到的独特之处，需要先理解MapR Converged Platform。在Apache HBase和Apache Cassandra中，它们在仅支持追加文件的文件系统上运行，无法根据数据更改更新数据文件。而MapR的独特之处在于，MapR-DB表、MapR文件和MapR事件流具有高可伸缩性、可靠性，并且被集成为综合分布式数据存储MapR-XD。MapR-XD通过C++原生实现了随机读写文件系统，并且可以直接访问硬盘而不经过文件系统（如Ext3）。因此，MapR-DB可以高效地更新文件，而不是采取始终写入不可变文件的行为。

MapR-DB 通过 LSM 树和 B 树的混合模型，实现了一致性和高速的读写操作。与传统的 B 树模型不同，叶节点不会主动进行平衡，因此更新操作可以非常快速地执行。在 MapR-DB 中，更新操作被追加到小型的“微型”日志中，并存储在内存中。与将数据刷新到新文件的 LSM 树不同，当内存频繁地与读写文件系统合并时，MapR-DB 会重新构建“微型”数据。这意味着 MapR-DB 不需要进行压缩（“微型”日志在合并后不再需要，因此会被删除）。此外，在读取操作中，MapR-DB 利用 B 树快速访问目标附近的数据集，然后扫描这些数据集以查找相应的数据。

在HBase和Cassandra中的数据恢复

在讨论log仅用于恢复之前，我们先来解释一下恢复的过程。
为了实现在通用硬件上的可靠性，需要依赖存储多个冗余数据副本的复制模式。
那么在HBase中，恢复是如何进行的呢？
在HDFS中，文件被分割成64MB的块，并且每个块都以两个副本的形式跨越数据节点集群进行存储。

如果HDFS的DataNode崩溃，则该区域将被分配给其他DataNode。
在重新恢复日志内容之后，新的区域将变为可用。
换句话说，将尚未刷新到文件中的所有更新从日志中加载到内存中，并按键值对进行排序，然后将其刷新到新文件中。

HBase的恢复过程较慢，存在以下问题。

• HDFSが64MBという大きなBlock単位でディスクI/Oを行う

 

• HDFSファイルはread-onlyであり、ファイルごとに単一のwriteプロセスしかいない。ファイルへの書き込みが行われている間読み込み処理はできず、ファイルのクローズまでのトランザクション処理を行って初めて読み込み処理が可能となる。途中で失敗が発生した場合、閉じていないファイルは削除される

 

• HDFSとHBase間のレイヤーのため、新しいファイルが書き込まれたときにのみデータのローカリティが保証される。HBaseではリージョンがフェールーバ時に移動したりロードバランスしたデータがローカルに存在しない場合、リージョンサーバが他のノードからファイルを読み込む必要がある

 

• Log（もしくはWAL)は大きいので、再読込には時間がかかる

 

ファイルシステムと分離されていることから、フェールオーバが発生した際にはzookeeper/hbase-master/hbase-region-server/NameNode間でコーディネーションが必要になる

Cassandra 的情况怎么样呢？在 Cassandra 中，客户端会将写入请求发送到集群中的任何一个节点上，这个节点会作为客户端的代理来操作。
这个代理节点会查找具有数据副本的 N 个节点的位置，并将写入命令转发到所有这些节点。
如果某个节点发生故障，协调节点会继续向其他副本进行写入，导致故障节点上的副本处于不一致状态。

根据Datastax的说法，节点宕机是Cassandra中数据不一致的常见原因，需要通过修复熵工具的执行来定期修正。
Yammer的Robert Yokota报告称，与他们拥有的其他一致性强的系统相比，Cassandra不够可靠，而且由于缺乏一致性，处理起来更加困难。

MapR-DB 如何在不丢失数据的情况下实时进行恢复？

为了理解MapR-DB能够做到其他数据库不能做到的事情，需要理解能够24/7保持数据完整性的MapR文件系统。 在常规操作中，集群需要尽快写入和复制进入的数据。 当文件被写入MapR集群时，首先会被分割成称为“块”的单元用于分片。 每个块都以每秒2GB的速度写入容器中的8KB块集。 块被写入后，它们作为一系列块集进行复制。 这个过程会对每个块重复执行，直到整个文件被写入为止（MapR-XD的视频中有关于这个过程的动画）。 MapR确保所有写入都能够在没有崩溃等情况下执行。

HDFS在数据分片、副本位置和文件I/O方面使用单一的块大小，而MapR-XD则使用三种不同的块大小。
这些块大小的区别在于它们如何被使用，显示出了它们的重要性，具体如下。

• シャーディング用のサイズをより大きくすることは、ファイルに付随するメタデータのフットプリントがより小さいことを意味します

 

• レプリカのロケーションのサイズがより大きいことは、CLDBに対するレプリカのロケーションの問い合わせ回数がより少ないことを意味します

 

ディスクI/Oのサイズが小さいことはファイルがランダムに読み書きされることを意味します

在MapR-DB中，与HBase类似，表被分割成连续的行，并分配给区域或片段。但与之不同的是，MapR-DB中的片段存在于容器内部。由于表与文件系统集成在一起，MapR-DB可以确保数据的本地性。然而，由于HBase与文件系统分离，始终保证数据的本地性并不容易。

当节点下线时，CLDB将会将原本存在于该节点上的主要容器切换到其副本容器。
这个新的容器将作为MapR-DB表或文件的主要容器进行操作。

与其他数据库相比，MapR-DB最大的区别是它能够在不进行小型微日志(replay micro LOGs)的情况下从崩溃中立即恢复，换句话说，即使在恢复过程中，用户也可以访问数据库。如果有需要应用小型微日志的数据请求，它将在大约250毫秒内执行，对于大多数用户来说，几乎察觉不到的高速执行。

在HBase和Cassandra中，使用了大型恢复日志，而MapR使用每个Tablet约40个小型日志。由于现在服务器具有更多的核心，所以尽可能使用更多的核心以将小型日志写入并并行化恢复是合理的。此外，MapR-DB始终应用小型微日志，因此大多数日志处于空状态。

该架构使得MapR-DB能够以比HBase快100到1000倍的速度从崩溃中恢复。MapR将此操作称为”Instant Recovery”。

概括来说，存在于容器中的MapR-DB表格具有以下特点。

データ局所性の保証： テーブルデータはコンテナが存在するノードと同一のノード上に存在することが保証されます

コンテナのレプリカを使う、より賢いロードバランシング: もしタブレットがロードバランシングのために移動する必要がある場合、データが以前ローカルに存在することが保証されるコンテナレプリカに移動します

コンテナレプリカを使うより賢くシンプルなフェールオーバ: タブレットがフェールオーバ用にリカバーされる必要がある場合、コンテナレプリカからリカバーされますので、LOGとテーブルデータからなるデータがまだローカルであることが保証されます

MapR 数据平台

以下是一种中文翻译选项：
为了实现MapR-Data Platform，三个核心服务MapR-XD、MapR-DB和MapR-ES同时运行、分布、扩展，并支持群集中所有工作负载的可靠性和高性能。

在本文中我们介绍了架构的详细信息，但并没有完全介绍选择MapR-DB的所有理由。
请点击以下链接查看更多信息。

• MapR-DB 6.0 – The Modern Database for Global Data-Intensive Applications

 

• MapR-DB Product page

 

• Analyzing the Performance of MapR-DB, a NoSQL Database in the MapR Data Platform

 

• MapR-DB documentation

 

• An In-Depth Look at the HBase Architecture

 

• Architecture Matters for Production Success

 

Free ODT: MapR Data Platform Essentials

有关Cassandra的修复和维护的其他信息，请点击以下链接：
* Cassandra修复的真实世界故事
* PagerDuty：一年的Cassandra故障
* 不要满足于最终一致性