Tokumx VS mongodb读取性能

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

• MongoDB 2.6.4_1

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

每个实例中只有一个集合。每个集合中有100000个条目

对于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});

我过去经常做压力测试。 在测试计划中，我通过查看

field2

和

geo

字段顺序（按

created\u在
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>

示例数据如下所示：

{
  "_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
  }
}

每个集合有1000000个条目

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

测试计划也非常简单：

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

Tsung压力测试，每次测试运行1小时。并发性为每秒1个请求

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


Sysbench事务包括插入/更新/删除操作，但您描述的测试是只读的。TokuMX获得比MongoDB高得多的系统性能的一个重要原因是写并发性。
我很高兴看到您对TokuMX感兴趣。但是，在尝试从结果中得出结论之前，您应该回答一些有关基准设置的问题：

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

您在我们的营销资料中展示的图表描述了随着并发线程数量的变化，特定基准（sysbench）的吞吐量是如何变化的。Tsung似乎没有衡量吞吐量和并发性，那么为什么您希望它具有与我们网站上的图表类似的特性呢

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

您的基准测试的运行时间只有5分钟，并且大多数输出在运行过程中表现出显著的差异。如果您对该工作负载感兴趣，那么您可能希望将其运行更长的时间（可能在更大的数据集上），收集大量数据，并比较TokuMX和MongoDB之间的吞吐量和延迟直方图

为什么要创建分区集合？你创建了分区吗？此范例是否符合应用程序的要求

我认为，如果你开始解决这些问题，你会发现你所看到的差异，你将有望接近一个基准，为你提供可靠和可操作的结果。
对于MongoDB来说，它仍然建立在MongoDB 2.4之上，在我发表这篇文章时，它还没有GEO 2dsphere索引。因此，如果您正在制作地理索引，则必须等待基于MongoDB 2.6的版本，该版本支持地理索引

基本上：


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

如果你对我的更多压力测试感兴趣，你可以在这里找到。
这就是为什么你不应该相信Maketing有人比较mongo3和toku吗？他们说mongo3在性能上向前迈出了一大步。嗨@leif，感谢您的快速回复。我在Linux机器上做了另一轮压力测试。还是得出同样的结论。请检查我的更新。顺便说一句，在我看来，tsung提供了“吞吐量vs.并发性”。你几乎忽略了我所有的建议。请再通读一遍。这可能只是因为tokumx不适合你所测量的任何东西。是的，这给了我另一个想法，应该是tokumx是mongodb的替代品，或者我们只能在一些特殊情况下使用tokumx，比如读取，tokumx非常擅长并发写入（索引维护）。还有人可能会说，它的优势延伸到读取，因为更好的写入性能意味着您可以维护更多的索引，从而提高读取效率。
{'$query', {gender,3,geo, {'$geoWithin', {'$center', [[48.72761, 9.24596], 0.005]}}}, '$orderby',{'_pid',-1}} 

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