3

我通过比较 Tokumx 和纯 Mongodb 来进行读取性能压力测试。

tokumx 和 mongodb 都在同一台机器上运行。

硬件概述：

Model Name: Mac mini
Model Identifier: Macmini6,1
Processor Name: Intel Core i5
Processor Speed: 2.5 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB
Memory: 10 GB

每个实例中只有一个集合。每个集合中有 100,000 个条目。

对于 tokumx，它被创建为分区集合。但是对于 mongodb，它是作为普通集合创建的：

db.createCollection("sample", {partitioned: true, primaryKey:  {field1:1, _id: 1}});

对于这两种情况，索引如下所示：

db.sample.ensureIndex({field1:1});
db.sample.ensureIndex({field2:1});
db.sample.ensureIndex({field3:1});
db.sample.ensureIndex({field4:1});
db.sample.ensureIndex({geo:"2d"});
db.sample.ensureIndex({"created_at":1});

我正在使用Tsung进行压力测试。在测试计划中，我通过查找field2和按desc的geo字段顺序进行了简单的搜索。created_at

<clients>
<client host="localhost" use_controller_vm="false" maxusers="8000"/>
</clients>
<servers>
<server host="jchimac.thenetcircle.lab" port="8080" type="tcp"/>
</servers>
<load duration="5" unit="minute">
<arrivalphase phase="1" duration="5" unit="minute">
<users interarrival="0.03" unit="second"/>
</arrivalphase>
</load>

根据官方文件，交易应该类似于TOKUMX™ BENCHMARK VS。MONGODB – 硬盘

在此处输入图像描述

但在我的测试中：

托库克斯：

在此处输入图像描述

在此处输入图像描述

MongoDB：

在此处输入图像描述

在此处输入图像描述

我在这里问知道是否有人可以对此提供任何提示？我在整个测试中错过了什么吗？

更新：

我在 Linux(CentOS) 机器上又做了一轮测试：

CentOS release 6.5 (Final)
2.6.32-504.1.3.el6.x86_64 GNU/Linux
MemTotal:       24589896 kB
CPU: 12* (Intel(R) Xeon(R) CPU E5645  @ 2.40GHz)

示例数据如下所示：

{
  "_id": ObjectId("54867dc8ffbc15aa2bc3ee0e"),
  "_iid": 15,
  "_pid": 15,
  "uid": 102296,
  "nickname": "nickname_102296",
  "gender": 3,
  "image_id": 15,
  "created_at": 1418100168,
  "tag": 1,
  "geo": {
    "lat": 51.590449999999997033,
    "lon": 6.9671900000000004383
  }
}

每个集合有 1,000,000 个条目。

每个集合的索引（创建正常集合）：

db.createCollection("coll", {primaryKey:  {_pid:1, _id: 1}});
db.tokumx_coll.ensureIndex({gender:1}); 
db.tokumx_coll.ensureIndex({uid:1}); 
db.tokumx_coll.ensureIndex({geo:"2d"}); 
db.tokumx_coll.ensureIndex({_pid:1}); 
db.tokumx_coll.ensureIndex({_iid:1}); 
db.tokumx_coll.ensureIndex({"created_at":1});

测试计划也很简单：

{'$query', {gender,3,geo, {'$geoWithin', {'$center', [[48.72761, 9.24596], 0.005]}}}, '$orderby',{'_pid',-1}}

每次测试运行 1 小时的 Tsung 压力测试。并发是每秒 1 个请求。

  <load>
    <arrivalphase phase="1" duration="60" unit="minute">
      <users interarrival="1" unit="second"/>
    </arrivalphase>
  </load>

这是屏幕截图中的报告：

托库克斯：

tokumx 总结
tokumx 报告

蒙古数据库：

MongoDB总结 MongoDB报告

更新@2014.12.12 发现这个： https ://github.com/Tokutek/mongo/issues/1014

4

3 回答 3

3

MongoDB 的TokuMX 2.0.0 社区版仍然建立在 MongoDB 2.4 上，当我发表这篇文章时，它还没有 GEO 2dsphere 索引。因此，如果您要制作具有 GEO 索引的复合索引，则必须等待支持 geo 2dshere 索引的基于 MongoDB 2.6 的版本。

基本上：

  • “二维索引”：只有一个附加字段的复合索引，作为二维索引字段的后缀
  • “2dsphere 索引”：以标量索引字段（即升序或降序）作为 2dsphere 索引字段的前缀或后缀的复合索引

如果你对我的压力测试更感兴趣，你可以在这篇文章中找到它。

于 2014-12-31T02:00:05.803 回答
2

Sysbench 事务包括插入/更新/删除操作，但您描述的测试是只读的。TokuMX 取得比 MongoDB 高得多的 Sysbench 结果的一个重要原因是写入并发性。

于 2014-12-08T14:48:10.007 回答
2

很高兴看到您对 TokuMX 感兴趣。但是，在尝试从结果中得出结论之前，您应该回答一些关于您的基准测试设置的问题：

  1. 您在 Mac mini 上运行。TokuMX 仅支持在 OSX 上进行开发，不支持生产。我们已经在 Linux 上解决了 OSX 上的几个显式性能问题。如果您对评估 TokuMX 的性能感兴趣，您真的应该在专用硬件上的 Linux 上进行测试。

  2. 您从我们的营销材料中展示的图表描述了特定基准 (sysbench) 的吞吐量如何随着我们改变并发线程的数量而变化。Tsung 似乎没有衡量吞吐量与并发性，那么您为什么期望它具有与我们网站上的图表相似的特征呢？

  3. Tsung 的工作量和你的应用类似吗？你是如何选择你测试的架构的？它是否代表您的应用程序的数据模型？您的查询与您选择的索引不匹配；如果您想在 上测试查询field2, geo, created_at，那么您应该有一个根据该键对数据进行排序的索引。我希望您的应用程序不仅仅是不使用您在小型数据集上定义的任何索引的只读工作负载。更多地考虑如何设计一个代表您的应用程序的基准。或者更好的是，只需运行您的应用程序或跟踪它，并监控您关心的指标。

  4. 您的基准测试的运行时间仅为 5 分钟，并且大部分输出在运行过程中显示出显着的差异。如果您对此工作负载感兴趣，您可能希望运行更长时间（并且可能在更大的数据集上），收集大量数据，并比较 TokuMX 和 MongoDB 之间的吞吐量和延迟直方图。

  5. 为什么要创建分区集合？您是否创建了任何分区？这个范例是否符合您的应用程序的要求？

我认为，如果您开始解决这些问题，您将引导自己走向您所看到的差异，并且您有望接近一个能够为您提供可靠和可操作结果的基准。

于 2014-12-09T01:59:39.117 回答