【问题标题】:Tokumx VS mongodb read performanceTokumx VS mongodb 读取性能
【发布时间】:2016-01-07 22:17:46
【问题描述】:

我正在通过比较 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 进行压力测试。 在测试计划中,我通过查看field2geo 字段按created_at desc 进行了简单的搜索。

<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 – HDD

但在我的测试中:

TOKUMX:

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:


MONGODB:


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

【问题讨论】:

  • 这就是为什么你不应该相信制造
  • 有人比较过 mongo3 和 toku 吗?他们说 mongo3 在性能上向前迈出了一大步。

标签: mongodb stress-testing tsung tokumx


【解决方案1】:

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

基本上:

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

如果您对我的压力测试感兴趣,可以在post 中找到它。

【讨论】:

    【解决方案2】:

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

    【讨论】:

    • 是的,这给了我另一个想法,应该 tokumx 是 mongodb 的替代品,或者我们只能在读取等特殊情况下使用 tokumx
    • TokuMX 非常擅长并发写入(索引维护)。也有人会争辩说,它的优势扩展到读取,因为更好的写入性能意味着您可以维护更多索引,从而提高读取效率。
    【解决方案3】:

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

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

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

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

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

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

    我认为,如果您开始解决这些问题,您就会发现自己所看到的差异,并且您有望接近一个能够为您提供可靠和可操作结果的基准。

    【讨论】:

    • 嗨@leif,感谢您的快速回复。我又做了一轮基于Linux机器的压力测试。还是得出同样的结论。请检查我的更新。顺便说一句,在我看来,tsung 提供了“吞吐量与并发性”。
    • 你几乎忽略了我的所有建议。请再通读一遍。可能只是 tokumx 不适合您正在测量的任何内容。
    猜你喜欢
    • 1970-01-01
    • 2013-12-04
    • 2020-01-07
    • 2014-04-06
    • 2016-08-02
    • 2016-10-31
    • 1970-01-01
    • 2012-10-14
    • 2013-09-01
    相关资源
    最近更新 更多