>去年年底做的测试，当时他们官网开着，发了邮件和问题，也无人受理，生产使用，请谨慎再三。
微博上去骂下他们。;-)
2014-03-10 22:43 GMT+08:00 成 :
> count的确不会合并，理解就好了，这种情况很少，没啥奇怪。
>
> 不知是否是我测试的问题，对比了MySQL自带的replication、MySQL
> Cluster、Cobar几种方式，使用比较简单的配置形式，得到Cobar性能最差的结论。
> 我的确只部署了一个cobar
> master，但在比较高并发时，感觉对系统cpu和内存（内存这块，估计是我的配置问题，但看看满世界的XML就头疼）资源的利
count的确不会合并，理解就好了，这种情况很少，没啥奇怪。
不知是否是我测试的问题，对比了MySQL自带的replication、MySQL
Cluster、Cobar几种方式，使用比较简单的配置形式，得到Cobar性能最差的结论。
我的确只部署了一个cobar
master，但在比较高并发时，感觉对系统cpu和内存（内存这块，估计是我的配置问题，但看看满世界的XML就头疼）资源的利用率很低，远低于mysql
cluster。
去年年底做的测试，当时他们官网开着，发了邮件和问题，也无人受理，生产使用，请谨慎再三。
在 2014年2月27日 下午7:09，苏沛 写道：
> 不知道有
不知道有哪位有用这过阿里的cobar不？
他官方网站挂了，找到的资料都不太全。
请问有什么好的blog或技术分享？
另外对 cobar 分库搜索结果有一些疑问
假设 table_a 分到了4个库
>select count(*) from table_a;
我期待的结果是 一条记录
实际返回的是是4调记录
请问 cobar 不会对 count 的结果进行合并吗？ 还是我使用方式不对？
--
苏沛
--
您收到此邮件是因为您订阅了 Google 网上论坛的“广州 GNU/Linux 用户组”论坛。
要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 g
