-
- いいね！0
saka1
@saka1_p
「いままでデータをロストしたことはない」というのは、前向きな意味なのだろうけど、まだ地雷を踏んでいないという意味にも取れるし、ちょっと悩むところではある #yjmu
2016-11-04 19:21:08
saka1
@saka1_p
REST APIを提供。Protobufのインタフェースもあるんだろうか（リポジトリを軽く見た感じ、少なくとも内部的には使ってそうな雰囲気ある） #yjmu
2016-11-04 19:24:01
saka1
@saka1_p
Pulsarを作ったのは「なかったから」。マルチテナントは確かになさそう。スループットとレイテンシの両立、ふつうは両立しないと考えて、片方諦めちゃうんだろうか #yjmu
2016-11-04 19:27:55
Kenji Yoshida
@xuwei_k
"Kafka doesn't scale well with many topics" #yjmu kafka disだ、いいぞもっとやれ pic.twitter.com/wPSEv0aWgL
2016-11-04 19:30:28
拡大
saka1
@saka1_p
bookieを保持するのは、実際上は別ノードになるのかな？ （Apache BookKeeperをよくわかっていない） #yjmu
2016-11-04 19:47:49
Kenji Yoshida
@xuwei_k
producerとconsumerはbrokerとしか通信しない、と。 apache kafkaも結局version上がるたびにzookeeperとあまり通信しない方向になってる気がするし、そうなるよなー #yjmu pic.twitter.com/EqAfjNemNE
2016-11-04 19:48:41
拡大
saka1
@saka1_p
Service DiscoveryはZookeeperのラップみたいな感じなのだろうか（適当）。クライアントは楽になりそう #yjmu
2016-11-04 19:49:02
saka1
@saka1_p
データの遅延書き込みをするのに永続性が担保できているのはなぜなんだろう。ちゃんと聞き取れなかった。うーん、ジャーナルに別で書いてる？ #yjmu
2016-11-04 19:56:42
saka1
@saka1_p
シングルノード、1KBメッセージで10万msg/sいけるのか。永続化のために全部writeしてるなら、100MB/sぐらい出てることになるけど。HDDなのかな。 #yjmu
2016-11-04 20:00:31
saka1
@saka1_p
もうちょっと現実的なシナリオでのベンチマークを知りたいなあ。数百〜数千トピック、複数ノードへのreplication付きだとどうなるか #yjmu
2016-11-04 20:09:17
Kenji Yoshida
@xuwei_k
#yjmu pulsarはconsumer, producerとbroker間がprotobufらしい、最高だ… twitter.com/xuwei_k/status…
2016-11-04 21:10:46
Kenji Yoshida
@xuwei_k
apache kafkaさんのプロトコル、せめてprotobufとかを元に定義されてたら(protobuf使える言語では)ある程度理解やクライアント実装楽になる気がするけど、linkedinやconfluent的にはavroだし、絶対ない(今後も完全独自プロトコル)だろうなぁ・・
2016-02-11 20:58:22