-
-
-
-
-
なぜパラレルRDBの方が速かったのか。論文では、Bツリーのインデックスによる高速化、最新のストレージ機構、圧縮機能、洗練された並列処理などを挙げています。
-
-
1. コンテンツの更新があった場合、PublisherはHubに更新をPOSTで通知する
2. Hubは新しいコンテンツをGETで取得、更新が実際に存在することを確認する
3. Hubは取得した更新情報をSubscriberのコールバックURLにPOSTで通知するSubscriberに更新情報がプッシュの形で届くのがポイントですね。 データのやりとりはAtomのフォーマットで行われます。 この方式のメリットとしては次のようなものがあります。
* Subscriberの利用者がよりリアルタイムに近い更新情報を得られること
* PublisherはHubだけに更新情報を通知すればよく、複数のSubscriberからアクセスが殺到する事態にはならないので負荷が軽減されること
* Subscriberが増加するなどして負荷が上がる場合、Hubを増やせばスケールすることが容易でありPublisherには影響が及ばないこと
-
-
-
Key で sort 済みの Key-Value Storage を作り始めたCommentsAdd Starrawwellrawwell
タイトルの通り Key で sort 済みの Key-Value Storage を作りはじめました。
良くある DHT だと Key の Hash を取る事で分散させるので順序情報を失ってしまうのですが、それを Skip Graph という仕組みで順序情報を保持したまま分散させることが可能になります。
sort 済みだとうれしいのは KVS に対して Range Query が可能になること。
例えば、empno-999 以上の value リストを 最新10件、KVS に要求するみたいなことが出来るようになります。
従来の KVS では上記のような Range Query は不可能だったので、そこは RDBMS に任せていたと思うんですが。（RDBMS で Range Query 後、Key のリストを KVS に投げるなど）
この辺りの RDBMS の負荷と分散しづらさを KVS 側で引き取り、かつ KVS のスケールアウトしやすさをそのまま維持しようというのが狙いです。
