介绍NoSQL基准测试：MongoDB，Cassandra和Couchbase

1 年 ago
科, 颖
1 minute

首先

简述

本文将介绍对以下NoSQL数据库进行的基准测试的内容。

    • MongoDB v3.6

 

    • DataStax Enterprise v6 (Cassandra)

 

    Couchbase Server v5.5

这里介绍的基准是由Altros公司于2018年进行的，并且可以从下面获取。

2018年NoSQL性能基准测试：Couchbase Server v5.5、DataStax Enterprise v6（Cassandra）和MongoDB v3。

目的 – 目标

这篇文章是为了以下目的而撰写和发布的。

    • Altoros社によるベンチマーク内容の紹介

 

    • Altoros社によるベンチマーク方法が不適切と考える部分についての指摘

 

    将来のベンチマーク実施のためのベースライン設定の試みとして

Altoros 公司基准测试概述

评价标准和工具

雅虎！云服务基准测试（YCSB）

工作负载类别

YSCB标准

    • ワークロード A: 更新処理

 

    ワークロード E: レンジスキャン

查询

    • クエリ１：ページネーション（OFFSETとLIMITによるフィルター）

 

    クエリ２：ジョイン（テーブル結合）

查询1和查询2分别表示以下域和场景。

    • 財務：フィルター処理されたトランザクションを一覧表示するためのサーバー側のページネーション

 

    eコマース: 顧客が利用するさまざまな製品やサービスに関する一連のレポート

环境

在同一地区内验证具有不同大小的以下三种群集。

    • 4 ノード

 

    • 10 ノード

 

    20 ノード

数据库实例

image.png

客户端实例

image.png

共同的条件

    • データサイズは、メモリーサイズと適合している状態

 

    • Durability（耐久性）オプション未使用

 

    各データセットに対して1 つのレプリカ（複製）

（注意）耐久性选项是指将数据在进行写入处理时的耐久性级别设置为高于默认水平的操作。例如，在创建副本或将数据同步到磁盘时，即使可以通过使用队列来处理，也会等待副本创建或数据永久化到磁盘的操作完成，而不使用队列，将其视为完成处理。

数据库的特定配置

Couchbase – 考驰贝斯

无论群集大小如何，每个节点都由数据服务、索引服务和查询服务组成。
Bucket被分配了可用RAM的60%（36,178 MB）。
索引服务被分配了可用RAM的约40%（约24 GB）。每个创建的索引都会复制到所有的索引服务上。

蒙古数据库

MongoDB采用了层次化的集群拓扑结构，包括Router进程，Config服务器和数据分片。对于每个集群大小（4、10和20个节点），使用以下配置。

    • Configサーバーは、3つのメンバーからなるレプリカセットとして構成 (クラスタのノード数としてはカウントしない、別のコンピュータ）。

 

    • 各シャードは、3つのメンバーからなるレプリカ セット (プライマリ、1 つのセカンダリ、1 つのArbeiter)として構成。

 

    各クライアントに3つのmongos（Routerプロセス）をデプロイ

卡桑德拉

image.png

Altros公司基准测试: 工作负载分类详细信息

工作负载 A：更新处理。

详细情况

    • 読み取り： 50%

 

    • 更新： 50%

 

    • 4 ノード クラスタ: 5千万レコード (1レコード1KB)

 

    • 10 ノード クラスタ: 1 億レコード

 

    20 ノード クラスタ: 2 億レコード

查询

image.png

最终结果

image.png

工作负载 E：范围扫描

详细说明

    • 読み取り： 95%

 

    • 更新： 5%

 

    • 4 ノード クラスタ: 5千万レコード (1レコード1KB)

 

    • 10 ノード クラスタ: 1 億レコード

 

    20 ノード クラスタ: 2 億5千万レコード

在这次验证中的问题

以下是对本文的引述（来源）：“我们在文章开头中提到的 ‘对于Altoros公司提出的基准测试方法的一些不适当之处’，将在这次验证中进行指出。”

由于Couchbase中的扫描操作是在主键上执行的，因此已创建了以下主索引。

CREATE PRIMARY INDEX `ycsb_primary` ON `ycsb`
USING GSI WITH {"nodes": [...]}

在这里，可以看到关于Couchbase主要索引的误解。

实际上，在原文中所称为”Couchbase的主键”的是在将文档存储为键值存储时使用的键（文档ID），而不是索引的概念。

此外，Couchbase的主要索引是为了使针对该存储桶（上述的yscb）的任何查询成为可能（索引服务使得可以对该存储桶进行全记录扫描），而不是为了优化基于该键（文档ID）的搜索（请注意上述的DDL中只指定了存储桶名ycsb）。

为了优化后续查询的执行，需要创建一个索引，将meta().id作为”主键”的角色使用，作为（Couchbase概念中的）次要索引。

CREATE INDEX `yscb_primary` on `yscb`(META().id) using GSI;

Couchbase的N1QL查询是将SQL查询扩展为JSON的一种方式。作为键值存储的文档ID不是构成JSON数据的元素，而是用于定位元数据的位置，因此会使用类似META().~的指定方式。

查询

image.png

结果

image.png

查询1：分页（通过OFFSET和LIMIT进行过滤）

详细

    • 読み取り：　100%

 

    • 4 ノード クラスタ: 5百万顧客レコード (1レコード4KB)

 

    • 10 ノード クラスタ: 2千5百万顧客レコード

 

    20 ノード クラスタ: 5千万顧客レコード

查询

image.png

结果 (jié guǒ)

image.png

查询2：连接（表的合并）

详细情况

    • 読み取り：　100%

 

    • 4 ノード クラスタ: 5百万顧客レコード、５百万受注レコード (1レコード4.5KB)

 

    10 ノード クラスタ: 2千5百万顧客レコード、2千5百万受注レコード

20个节点的集群：五千万客户记录，五千万订单记录。

请用中文提供一个选项：查询

image.png

结果

image.png
image.png

最终

我在开头写道，本文的目的是作为未来基准测试的基线设定的试验。

作为基准标准，还有由Transaction Processing Performance Council组织的TPC基准。TPC基准包括TPC-C、TPC-H、TPC-R、TPC-W等类型，并且TPC-C是用于衡量OLTP/业务系统（以更新为中心）的工作负载，TPC-H是代表性的用于衡量OLAP/汇总性能（以OLAP/信息系统为中心）的工作负载。TPC-H和TPC-R主要用于决策支持/DWH处理，TPC-W则定位为基于Web的电子商务系统，用于处理事务。

我认为可以说YCSB和TPC提供了标准化数据库处理内容以用于比较。虽然有一些公开的工具用于性能评估环境，但似乎不能完全无需更改即可使用。首先，每个工具处理的数据库都是有限的，并且可能没有与最新版本的兼容性。在这种情况下，为了适应特殊的（不具备一般性的）工具，需要花费很多精力进行修改和添加脚本的工作，我对此感到疑问。

我作为一个自身的关注点，正在考虑通过将客户端处理通用化，实现在不同条件和环境下比较性能的可能性。从这个意义上说，我们可以构建一个作为REST服务器提供简单数据输入输出的Web应用程序，并使用以下类型的Web服务器性能测量工具。

    • Apache Bench

 

    • Apache JMeter

 

    • httperf

 

    weighttp

例如，使用Spring Data作为Rest服务器的实现，可以显示使用每个数据库的标准方法来访问数据库。此外，Spring Data还支持响应式编程模型，如Spring Data R2DBC，这意味着可以进行非阻塞API之间的比较，因此似乎是公平的。

为了进行具体的性能验证，同时在另一篇文章中，我们希望能够继续推进讨论（并实际执行）。

请提供参考资料。

TPC基准测试基础课程

使用Apache Bench轻松进行性能测试。

✖
广告
将在 10 秒后关闭
bannerAds