我在 TokuDB 引擎上做了一些性能测试(我在 Dell PowerEdge R720 上使用 Tokutek 网站上的 mariadb-5.5.30-tokudb-7.0.4，内存为 128GB，TokuDB 的默认内存分配为 64GB - tokudb_cache_size) 并且出现了一些真正出乎意料的事情。
在测试场景中，我在一个空表(33 列、1 个主 auto_increment 键、5 个索引)上插入了大约 9000 万行，同时我注意到显着的速度性能与 MyISAM 引擎相比，数据压缩，即从 15K 到 20K 记录/秒 和 30G 数据到 7G TokuDB，查询性能急剧下降(没有索引是集群)。
特别是简单查询:select count(*) from test_table; MyISAM 花费了 0.0001 秒，而 TokuDB 花费了 20 秒。还查询扫描所有 90M 行表(where column_not_indexed = something)，对于 MyISAM 花费了大约 2 分钟，对于 TokuDB，它们的持续时间超过 5 分钟 !所有其他查询也有性能下降。对于相同大小的表，它们都不比 MyISAM 好。
因此，虽然我认为 TokuDB 使用的分形树索引在查询速度方面具有出色的性能，但事实并非如此。有没有测试过 TokuDB 的人有同样的问题，或者可以给出如何提高查询性能的提示？
建表语句为:
CREATE TABLE `table` (
`Event` bigint(20) NOT NULL AUTO_INCREMENT,
`TimeStamp` bigint(20) NOT NULL DEFAULT '0',
`Field_1` smallint(4) NOT NULL DEFAULT '0',
`Field_2` bigint(12) NOT NULL DEFAULT '0',
`Field_3` varchar(40) NOT NULL DEFAULT '',
`Field_4` bigint(15) DEFAULT NULL,
(...)
PRIMARY KEY (`Event`) USING BTREE,
KEY `Index_ts` (`Timestamp`),
KEY `Index_1` (`Field_1`),
KEY `Index_2` (`Field_2`),
KEY `Index_3` (`Field_3`)
)ENGINE=TokuDB DEFAULT CHARSET=latin1
一些查询是:
SELECT count(*) FROM table
**MyISAM:0.00981429 TokuDB:21.40218998**
SELECT Field_2, Timestamp FROM table IGNORE KEY (Index_3, Index_1) WHERE (Field_3 LIKE "%asweb.be") AND (Field_1 < 42) ORDER BY Timestamp LIMIT 2000
**MyISAM:125.9707183 TokuDB:356.6146628**
SELECT Field_2, Timestamp FROM table IGNORE KEY (Index_1) WHERE (Field_4 = "206012216849912") AND (Field_1 < 42) ORDER BY Timestamp LIMIT 2000
**MyISAM:120.0966643 TokuDB:293.2259202**
SELECT Field_2, Timestamp FROM table IGNORE KEY (Index_1) WHERE (Field_2 = "32475731333") AND (Field_1 < 42) ORDER BY Timestamp LIMIT 100000
**MyISAM:0.00552937 TokuDB:0.18659729**
还有:
Query 1: SHOW PROFILE CPU FOR QUERY 1;
Status Duration CPU_user CPU_system
Queried about 88450000 rows 0.001905 0 0
Queried about 88460000 rows 0.001902 0.004 0
Queried about 88470000 rows 0.001906 0 0
Queried about 88480000 rows 0.001905 0.004 0
Queried about 88490000 rows 0.001664 0 0
Queried about 88500000 rows 0.001907 0.004 0
Queried about 88510000 rows 0.001898 0 0
Queried about 88520000 rows 0.001903 0.004001 0
Queried about 88530000 rows 0.001902 0 0
Queried about 88540000 rows 0.001903 0.004 0
Queried about 88550000 rows 0.001661 0 0
Queried about 88560000 rows 0.001905 0 0
Queried about 88570000 rows 0.001901 0.004 0
Queried about 88580000 rows 0.001912 0 0
Queried about 88590000 rows 0.001902 0.004 0
Queried about 88600000 rows 0.001908 0 0
Queried about 88610000 rows 0.001664 0.004001 0
Queried about 88620000 rows 0.001899 0 0
Queried about 88630000 rows 0.001905 0.004 0
Queried about 88640000 rows 0.001901 0 0
Queried about 88650000 rows 0.0019 0.004 0
Queried about 88660000 rows 0.001661 0 0
Queried about 88670000 rows 0.001906 0.004 0
Queried about 88680000 rows 0.001895 0 0
Queried about 88690000 rows 0.001907 0 0
Queried about 88700000 rows 0.001907 0.004001 0
Queried about 88710000 rows 0.001905 0 0
Queried about 88720000 rows 0.001663 0.004 0
Queried about 88730000 rows 0.001905 0 0
Queried about 88740000 rows 0.001903 0.004 0
Queried about 88750000 rows 0.001899 0 0
Queried about 88760000 rows 0.001898 0.004 0
Queried about 88770000 rows 0.001898 0 0
Queried about 88780000 rows 0.001665 0.004001 0
Queried about 88790000 rows 0.0019 0 0
Queried about 88800000 rows 0.001903 0.004 0
Queried about 88810000 rows 0.001909 0 0
Queried about 88820000 rows 0.001903 0.004 0
Queried about 88830000 rows 0.001663 0 0
Queried about 88840000 rows 0.001902 0 0
Queried about 88850000 rows 0.001901 0.004 0
Queried about 88860000 rows 0.001903 0 0
Queried about 88870000 rows 0.0019 0.004001 0
Queried about 88880000 rows 0.001904 0 0
Queried about 88890000 rows 0.001662 0.004 0
Queried about 88900000 rows 0.001903 0 0
Queried about 88910000 rows 0.001901 0.004 0
Queried about 88920000 rows 0.001905 0 0
Queried about 88930000 rows 0.001904 0.004 0
Queried about 88940000 rows 0.001898 0 0
Queried about 88950000 rows 0.001666 0.004001 0
Queried about 88960000 rows 0.001901 0 0
Queried about 88970000 rows 0.001905 0.004 0
Queried about 88980000 rows 0.001899 0 0
Queried about 88990000 rows 0.001907 0 0
Queried about 89000000 rows 0.00166 0.004 0
Queried about 89010000 rows 0.001903 0 0
Queried about 89020000 rows 0.001899 0.004 0
Queried about 89030000 rows 0.001905 0 0
Queried about 89040000 rows 0.0019 0.004001 0
Queried about 89050000 rows 0.0019 0 0
Queried about 89060000 rows 0.001662 0.004 0
Queried about 89070000 rows 0.001897 0 0
Queried about 89080000 rows 0.001901 0.004 0
Queried about 89090000 rows 0.001894 0 0
Queried about 89100000 rows 0.001897 0.004 0
Queried about 89110000 rows 0.001891 0 0
Queried about 89120000 rows 0.001667 0 0
Queried about 89130000 rows 0.001899 0.004001 0
Queried about 89140000 rows 0.001901 0 0
Queried about 89150000 rows 0.001903 0.004 0
Queried about 89160000 rows 0.00191 0 0
Queried about 89170000 rows 0.001662 0.004 0
Queried about 89180000 rows 0.001906 0 0
Queried about 89190000 rows 0.001903 0.004 0
Queried about 89200000 rows 0.0019 0 0
Queried about 89210000 rows 0.001904 0.004001 0
Queried about 89220000 rows 0.001897 0 0
Queried about 89230000 rows 0.001663 0.004 0
Queried about 89240000 rows 0.001902 0 0
Queried about 89250000 rows 0.001906 0 0
Queried about 89260000 rows 0.001905 0.004 0
Queried about 89270000 rows 0.001903 0 0
Queried about 89280000 rows 0.001894 0.004 0
Queried about 89290000 rows 0.00166 0 0
Queried about 89300000 rows 0.001903 0.004001 0
Queried about 89310000 rows 0.001901 0 0
Queried about 89320000 rows 0.0019 0.004 0
Queried about 89330000 rows 0.001904 0 0
Queried about 89340000 rows 0.001661 0.004 0
Queried about 89350000 rows 0.001892 0 0
Queried about 89360000 rows 0.001808 0.004 0
Queried about 89370000 rows 0.000027 0 0
end 0.000008 0 0
query end 0.000008 0 0
closing tables 0.000008 0 0
freeing items 0.000007 0 0
updating status 0.000029 0 0
logging slow query 0.000005 0 0
cleaning up 0.000005 0 0
闻起来像 bug ？
最佳答案
MyISAM 在全表扫描上击败了 InnoDB 和 TokuDB，因为它基本上只是按顺序扫描文件。
关于mysql - MariaDB 中的 TokuDB 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18697054/
总的来说，我对ruby还比较陌生，我正在为我正在创建的对象编写一些rspec测试用例。许多测试用例都非常基础，我只是想确保正确填充和返回值。我想知道是否有办法使用循环结构来执行此操作。不必为我要测试的每个方法都设置一个assertEquals。例如:describeitem,"TestingtheItem"doit"willhaveanullvaluetostart"doitem=Item.new#HereIcoulddotheitem.name.shouldbe_nil#thenIcoulddoitem.category.shouldbe_nilendend但我想要一些方法来使用
我试图在一个项目中使用rake，如果我把所有东西都放到Rakefile中，它会很大并且很难读取/找到东西，所以我试着将每个命名空间放在lib/rake中它自己的文件中，我添加了这个到我的rake文件的顶部:Dir['#{File.dirname(__FILE__)}/lib/rake/*.rake'].map{|f|requiref}它加载文件没问题，但没有任务。我现在只有一个.rake文件作为测试，名为“servers.rake”，它看起来像这样:namespace:serverdotask:testdoputs"test"endend所以当我运行rakeserver:testid时
作为我的Rails应用程序的一部分，我编写了一个小导入程序，它从我们的LDAP系统中吸取数据并将其塞入一个用户表中。不幸的是，与LDAP相关的代码在遍历我们的32K用户时泄漏了大量内存，我一直无法弄清楚如何解决这个问题。这个问题似乎在某种程度上与LDAP库有关，因为当我删除对LDAP内容的调用时，内存使用情况会很好地稳定下来。此外，不断增加的对象是Net::BER::BerIdentifiedString和Net::BER::BerIdentifiedArray，它们都是LDAP库的一部分。当我运行导入时，内存使用量最终达到超过1GB的峰值。如果问题存在，我需要找到一些方法来更正我的代
Rails2.3可以选择随时使用RouteSet#add_configuration_file添加更多路由。是否可以在Rails3项目中做同样的事情？ 最佳答案 在config/application.rb中:config.paths.config.routes在Rails3.2(也可能是Rails3.1)中，使用:config.paths["config/routes"] 关于ruby-on-rails-Rails3中的多个路由文件，我们在StackOverflow上找到一个类似的问题
我需要从一个View访问多个模型。以前，我的links_controller仅用于提供以不同方式排序的链接资源。现在我想包括一个部分(我假设)显示按分数排序的顶级用户(@users=User.all.sort_by(&:score))我知道我可以将此代码插入每个链接操作并从View访问它，但这似乎不是“ruby方式”，我将需要在不久的将来访问更多模型。这可能会变得很脏，是否有针对这种情况的任何技术？注意事项:我认为我的应用程序正朝着单一格式和动态页面内容的方向发展，本质上是一个典型的网络应用程序。我知道before_filter但考虑到我希望应用程序进入的方向，这似乎很麻烦。最终从任何
我在我的项目中添加了一个系统来重置用户密码并通过电子邮件将密码发送给他，以防他忘记密码。昨天它运行良好(当我实现它时)。当我今天尝试启动服务器时，出现以下错误。=>BootingWEBrick=>Rails3.2.1applicationstartingindevelopmentonhttp://0.0.0.0:3000=>Callwith-dtodetach=>Ctrl-CtoshutdownserverExiting/Users/vinayshenoy/.rvm/gems/ruby-1.9.3-p0/gems/actionmailer-3.2.1/lib/action_mailer
刚入门rails，开始慢慢理解。有人可以解释或给我一些关于在application_controller中编码的好处或时间和原因的想法吗？有哪些用例。您如何为Rails应用程序使用应用程序Controller？我不想在那里放太多代码，因为据我了解，每个请求都会调用此Controller。这是真的？ 最佳答案 ApplicationController实际上是您应用程序中的每个其他Controller都将从中继承的类(尽管这不是强制性的)。我同意不要用太多代码弄乱它并保持干净整洁的态度，尽管在某些情况下ApplicationContr
我想向我的Controller传递一个参数，它是一个简单的复选框，但我不知道如何在模型的form_for中引入它，这是我的观点:{:id=>'go_finance'}do|f|%>Transferirde:para:Entrada:"input",:placeholder=>"Quantofoiganho?"%>Saída:"output",:placeholder=>"Quantofoigasto?"%>Nota:我想做一个额外的复选框，但我该怎么做，模型中没有一个对象，而是一个要检查的对象，以便在Controller中创建一个ifelse，如果没有检查，请帮助我，非常感谢,谢谢
我注意到像bundler这样的项目在每个specfile中执行requirespec_helper我还注意到rspec使用选项--require，它允许您在引导rspec时要求一个文件。您还可以将其添加到.rspec文件中，因此只要您运行不带参数的rspec就会添加它。使用上述方法有什么缺点可以解释为什么像bundler这样的项目选择在每个规范文件中都需要spec_helper吗？ 最佳答案 我不在Bundler上工作，所以我不能直接谈论他们的做法。并非所有项目都checkin.rspec文件。原因是这个文件，通常按照当前的惯例，只
我正在使用active_admin，我在Rails3应用程序的应用程序中有一个目录管理，其中包含模型和页面的声明。时不时地我也有一个类，当那个类有一个常量时，就像这样:classFooBAR="bar"end然后，我在每个必须在我的Rails应用程序中重新加载一些代码的请求中收到此警告:/Users/pupeno/helloworld/app/admin/billing.rb:12:warning:alreadyinitializedconstantBAR知道发生了什么以及如何避免这些警告吗？ 最佳答案 在纯Ruby中:classA