b*******g
发帖数: 603 | 1 C*怎么不能做MQ, 我们的一组应用长年共享一个24节点的C*, 就是用来做message
queue, 支持publisher/subscriber多topic, 峰值100K/s 写没压力。读是批量读出的
，更没压力了。 |
p*****2
发帖数: 21240 | 2
这个跟Kafka怎么比较呀？
【在 b*******g 的大作中提到】
: C*怎么不能做MQ, 我们的一组应用长年共享一个24节点的C*, 就是用来做message
: queue, 支持publisher/subscriber多topic, 峰值100K/s 写没压力。读是批量读出的
: ，更没压力了。
|
w*s
发帖数: 7227 | 3 呵呵，看到这id笑死了，我去注册一个bestbug
【在 b*******g 的大作中提到】
: C*怎么不能做MQ, 我们的一组应用长年共享一个24节点的C*, 就是用来做message
: queue, 支持publisher/subscriber多topic, 峰值100K/s 写没压力。读是批量读出的
: ，更没压力了。
|
w**z
发帖数: 8232 | 4 其实你看一下Kafka怎么写盘，和C*很象， sequential write.但Kafka 是专门的mq, C
* 是column family, mq 是一个应用实例。
【在 p*****2 的大作中提到】
:
: 这个跟Kafka怎么比较呀？
|
p*****2
发帖数: 21240 | 5
C
为什么不用专门的mq kafka？
【在 w**z 的大作中提到】
: 其实你看一下Kafka怎么写盘，和C*很象， sequential write.但Kafka 是专门的mq, C
: * 是column family, mq 是一个应用实例。
|
w**z
发帖数: 8232 | 6 估计那时候还没有Kafka.
【在 p*****2 的大作中提到】
:
: C
: 为什么不用专门的mq kafka？
|
p*****2
发帖数: 21240 | 7
那如果新项目是不是应该上kafka
【在 w**z 的大作中提到】
: 估计那时候还没有Kafka.
|
d*******r
发帖数: 3299 | 8 我琢磨了下觉得不用上了... 因为没看出 kafka 到底有多大优势，而且还新，是
scala 写的，万一出个啥问题，我打个补丁都搞不定。不过可能我说得不对.
【在 p*****2 的大作中提到】
:
: 那如果新项目是不是应该上kafka
|
d*******r
发帖数: 3299 | 9 正想问二爷，你们哪些场景一定 Redis 配合着 MongoDB 一起用呀，MongoDB 有时勉
强当个 message service 用貌似也不慢吧。因为没有实测过，对 Redis 这种做 cache
和 message service 到底比 MongoDB 快多少没概念.
【在 p*****2 的大作中提到】
:
: 那如果新项目是不是应该上kafka
|
p*****2
发帖数: 21240 | 10
cache
看需求。如果我没记错的话，mongodb可以达到10K/sec, 不过mongo是多线程。而Redis
一个instance的单线程就比mongo要更快。如果上多进程的话，差距就出来了。
mongo比redis易用多了，所以如果性能要求不高的话，应该没啥问题。要求高性能就上
redis吧。
【在 d*******r 的大作中提到】
: 正想问二爷，你们哪些场景一定 Redis 配合着 MongoDB 一起用呀，MongoDB 有时勉
: 强当个 message service 用貌似也不慢吧。因为没有实测过，对 Redis 这种做 cache
: 和 message service 到底比 MongoDB 快多少没概念.
|
|
|
d*******r
发帖数: 3299 | 11 多谢，我也是这么想
请问你说的 10K/sec, 是 10Kbits/sec, 能给我 benchmark test 的 reference 么
估计 coltzhao 他们做游戏，一定要上 Redis 吧。
Redis
【在 p*****2 的大作中提到】
:
: cache
: 看需求。如果我没记错的话，mongodb可以达到10K/sec, 不过mongo是多线程。而Redis
: 一个instance的单线程就比mongo要更快。如果上多进程的话，差距就出来了。
: mongo比redis易用多了，所以如果性能要求不高的话，应该没啥问题。要求高性能就上
: redis吧。
|
p*****2
发帖数: 21240 | 12
不是我测的。应该是每秒读吧。
【在 d*******r 的大作中提到】
: 多谢，我也是这么想
: 请问你说的 10K/sec, 是 10Kbits/sec, 能给我 benchmark test 的 reference 么
: 估计 coltzhao 他们做游戏，一定要上 Redis 吧。
:
: Redis
|
b*******g
发帖数: 603 | 13 kafka doesn't support replication until 0.8. You can't really run it in the
cloud before 0.8. |
b*******g
发帖数: 603 | 14 傻逼太监又出来丢人了。这是cassandra最常见的time series.
time based UUID 做key, key扔入一个index CF 排序。index CF本身又可以sharding
分多行。
写是commit log, 根本不锁，完全并发。读的时候先读index CF, 给个start time
UUID, end
time UUID, 一次读出一行里的这些 key, 读column本身可以并发，然后拿这些key去读
纪录也是并发的。虽然没有写快。但是作为 MQ, 本身就是缓冲，不需要实时。
100K/s 写峰值完全没有压力。本质上就是无锁写，compaction的时候才sort. 读出的
时候已经排好了。 |
b*******g
发帖数: 603 | 15 time series 本来就是Cassandra的强项。傻逼太监实在是伸脸找打。 |
p*****2
发帖数: 21240 | 16
the
这样呀。0.8是不是不久前release了。
【在 b*******g 的大作中提到】
: kafka doesn't support replication until 0.8. You can't really run it in the
: cloud before 0.8.
|
p*****2
发帖数: 21240 | 17
有道理。我看了看message queue还是挺麻烦的，这样的话vert.x自己加一个可能还真
是卖点。不然就用redis凑活了
【在 d*******r 的大作中提到】
: 我琢磨了下觉得不用上了... 因为没看出 kafka 到底有多大优势，而且还新，是
: scala 写的，万一出个啥问题，我打个补丁都搞不定。不过可能我说得不对.
|
b*******g
发帖数: 603 | 18 Yes, it's only released recently.
https://issues.apache.org/jira/browse/KAFKA-50
【在 p*****2 的大作中提到】
:
: 有道理。我看了看message queue还是挺麻烦的，这样的话vert.x自己加一个可能还真
: 是卖点。不然就用redis凑活了
|
p*****2
发帖数: 21240 | 19
多谢大牛。话说你家用Clojure是神马情况呢？都是做data的人用？
【在 b*******g 的大作中提到】
: Yes, it's only released recently.
: https://issues.apache.org/jira/browse/KAFKA-50
|
b*******g
发帖数: 603 | 20 据我所知都是做data的人用。比如这个
https://github.com/Netflix/PigPen
【在 p*****2 的大作中提到】
:
: 多谢大牛。话说你家用Clojure是神马情况呢？都是做data的人用？
|
