Lazy MySQL DBA

上次那个测试结果，不太令人满意。
api调用的时候，对一致性要求太高，导致cassandra性能下降不少。
于是换了一个哥们来压测cassandra，而且还非常专业得画了图出来。
测试场景就没什么好说了（Cassandra两个节点互备，MySQL单台），直接上结果图好了：
写的TPS和响应时间，横坐标为线程数：

读的TPS和响应时间，横坐标为线程数：

Cassandra最近很火爆，有开发兄弟想往上面迁移数据，于是这星期做了MySQL和Cassandra的性能测试。

Cassandra集群（四台）和MySQL（一台）做了相应的读写对比测试。测试场景是key-value形式的，Cassandra 400w个key，MySQL 200w个key，每个key下存放100个column。column name是时间戳，value是平均长度为0.5k的随机数据。
Cassandra的replica facor是2，InnoDB的innodb_flush_log_at_trx_commit是2。

随机写 Tps 平均响应时间（ms） 最大响应时间(ms)
MysqL 5300 7.42 2562
Cassandra 12000 1.64 3685

随机读 Tps 平均响应时间（ms） 最大响应时间(ms)
MysqL 1010 78.92 1969
Cassandra 1200 68.23 4006

因为测试的时候只是用了一台MySQL，而cassandra使用了四个节点。所以MySQL最终的TPS，写入要乘以2，读取要乘以4。
本次测试的结果中，MySQL的读取性能远远高于Cassandra，而写入微微弱于Cassandra。
这个结果和java代码写入数据的模式有关，不代表MySQL在任何场景下都读取都强于Cassandra。

搜索三大要素：数据来源、预处理、查询。
在Sphinx+MySQL的架构中，MySQL主要提供了数据来源和查询接口，真正进行全文索引建立和查询的是Sphinx。
MySQL里面存放真正的数据；Sphinx从MySQL中获取数据建立全文索引；应用程序使用相应的api与Sphinx交互以获得真正的数据（此处的api包含SQL接口、php接口，以及其他一些编程语言能够调用的接口）。
(more…)

MyISAM自带的全文索引无法与ORACLE相比。要想在MySQL上使用全文索引，那就只能看第三方的工具罗。
据说Sphinx很不错，于是看了下安装方法，之后有时间再做性能压测。
(more…)