タグ

kvsに関するjazzanovaのブックマーク (7)

  • 54行で分散KVSを実装する(レプリケーション機能付き) - Blog by Sadayuki Furuhashi

    Ruby と MessagePack-RPC があれば、簡単なkey-valueストレージは簡単に作れます。54行で書けます(レプリケーションと負荷分散機能付き。サーバー38行、クライアント16行)。 簡単なKVSをベースにして、ログ集計や遠隔デプロイ、遠隔管理機能などの機能を追加していけば、ちょっと便利なサーバープログラムをサクサク自作できるハズ。 この分散KVSは、(keyのハッシュ値 % サーバーの台数)番目のサーバーにkeyを保存します。また、サーバーの名前順でソートしたときの「次のサーバー」と「次の次のサーバー」にデータをレプリケーションします。 すべてのサーバーで同じ設定ファイルを使います。サーバーごとの設定は引数を自分のホスト名に書き換えるだけなので、デプロイが容易です。 MessagePack-RPC for Ruby を使うと、分散しないkey-valueストレージ*1は

    54行で分散KVSを実装する(レプリケーション機能付き) - Blog by Sadayuki Furuhashi
  • Webアプリをとりまく最近のKVS事情、雑感 - Tous Les Jours 攻防記

    RDBの復権はしばらくないと思う 最近目にしたのは、「これからRDBが十分速くなっていくので、memcachedに代わってRDBがまた使われるようになる」という意見。これはしばらくの間は無いんじゃないかと思う。全データがオンメモリだったとしても、KVSはRDBより一桁以上速い(Memcachedで100,000req/sec出せるマシンで、MySQLのpkeyによる単純なSELECTをした場合、10,000req/sec出るかどうか)。SQLパーサやらなんやらを捨てない限りこの速さには対抗できない。RDBには、1コネクション1スレッドというモデルが持つ、接続数がスケールしないという制約もある。 また、memcacheプロトコルは、get_multiが使える。get_multiを効果的に活用した場合、RDBとの差はさらに広がると思う。 RDBで大丈夫なアプリも Viewキャッシュが効果的なア

    Webアプリをとりまく最近のKVS事情、雑感 - Tous Les Jours 攻防記
  • Key で sort 済みの Key-Value Storage を作り始めた - higepon blog

    タイトルの通り 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 側

    Key で sort 済みの Key-Value Storage を作り始めた - higepon blog
  • 追記型オブジェクトストレージ「Kastor」(pre-alpha) - Blog by Sadayuki Furuhashi

    Facebookで写真配信のために使われているストレージシステム「Haystack」に関する情報が公開されました。(Needle in a haystack: efficient storage of billions of photos) Facebookは最初はNFSを使っていたようです。しかし写真の1枚1枚をファイルとして保存していたため、ディレクトリエントリなどのinodeメタデータの総量がキャッシュに収まらないサイズになってしまい、一つの写真を保存したり取り出したりするのにHDDのシークが複数回発生していたのがボトルネックになっていたそうです。 (もしかしたら「NetAppは高すぎた」のがもっと重要だったかも知れません:Facebook、独自の写真配信ネットワーク、Haystackを完成―収益性の改善に寄与か?) シークの問題を軽減するために、profile用などの小さな写真はキ

    追記型オブジェクトストレージ「Kastor」(pre-alpha) - Blog by Sadayuki Furuhashi
  • Moneta:Tokyo CabinetやMemcacheのようなKey-Valueストアへのインターフェイス

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    Moneta:Tokyo CabinetやMemcacheのようなKey-Valueストアへのインターフェイス
  • 「キー・バリュー型データストア」開発者が大集合した夜

    「発表者が自分よりも若い人ばかりだ」。外見が20代にしか見えない東京工業大学の首藤一幸准教授(1973年生)の驚くさまが、少し面白かった。2009年2月20日の夜、多くのWeb企業が注目する「キー・バリュー型データストア」を開発する若手技術者が、東京・六木のグリー社に一堂に会した。 キー・バリュー型データストア(またはキー・バリュー型データベース)は、大量のユーザーとデータを抱え、データベースのパフォーマンス問題とコスト高に頭を悩ませるWeb企業が注目する技術である。記者は同日に開催された「Key-Value Store 勉強会」に参加させてもらった。午後7時から11時まで、キー・バリュー型データストアを開発・研究する若手技術者が立て続けに登場し、1人15分の持ち時間で成果を発表し、議論を重ねるという集まりだ。 呼びかけ人であるプリファードインフラストラクチャー(PFI)最高技術責任者

    「キー・バリュー型データストア」開発者が大集合した夜
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 1