タグ

kvsに関するkazutanakaのブックマーク (35)

  • Pusher | Leader In Realtime Technologies

    © 2024 Pusher Ltd. All rights reserved. Pusher Limited is a company registered in England and Wales (No. 07489873) whose registered office is at MessageBird UK Limited, 3 More London Riverside, 4th Floor, London, United Kingdom, SE1 2AQ.

    Pusher | Leader In Realtime Technologies
  • Redis Sentinel at Flickr | code.flickr.com

    We recently implemented Redis Sentinel at Flickr to provide automated Redis master failover for an important subsystem and we wanted to share our experience with it. Hopefully, we can provide insight into our experience adopting this relatively new technology and some of the nuances we encountered getting it up and running. Although we try to provide a basic explanation of what Sentinel is and how

  • ニコニコ生放送に見る Redis 活用ノウハウ 記事一覧 | gihyo.jp

    運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します⁠。個別にライセンスが設定されている記事等はそのライセンスに従います。

    ニコニコ生放送に見る Redis 活用ノウハウ 記事一覧 | gihyo.jp
  • 12年後のCAP定理: "法則"はどのように変わったか

    設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と

    12年後のCAP定理: "法則"はどのように変わったか
  • ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか?

    スクウェア・エニックスの人気RPG「ドラゴンクエスト」シリーズの最新作「ドラゴンクエストX(ドラクエ10)」はシリーズ初のオンライン作品となりましたが、その舞台裏は一体どうなっていたのか。ゲームの世界観を支えるサーバシステムがどのように構成されているのかということや、ドラゴンクエストⅩならではの仕組みや機能から開発の苦労話まで、株式会社スクウェア・エニックス開発部プログラマ森山朋輝さんが語っています。 タイトル | CEDEC 2012 | Computer Entertaintment Developers Conference http://cedec.cesa.or.jp/2012/program/NW/C12_P0040.html 森山朋輝: 皆様、日はお集まり頂きどうもありがとうございます。このセッションを担当させて頂きます、株式会社スクウェア・エニックス開発部所属の森山朋輝と

    ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか?
  • memcached(プロトコル)のデータレプリケーション - (ひ)メモ

    国内だけでなく国外(なぜか主に中国語)でもまだrepcachedについて言及してるのをちらほら見かけるのですが、repcachedはmemcached 1.2.8ベースですし(memcached 1.4.5に対応してる人もいるようですが)いまならKyoto Tycoon使えばいいんじゃないかと思うのです。 Kyoto Tycoonなら: memcachedプロトコルプラグインを使えば、Kyoto Tycoonがそのままmemcachedの代替になる(memcachedプロトコルを喋るクライアントコードはそのままでよい) Tokyo Tyrantと違ってexpireもOK memcachedの代替が目的なら、速いオンメモリDB(StashDBとか)でOK 非同期レプリケーションもできる ホットスタンバイ側のサーバリソースが無駄に思うなら、keyに応じてmodとかでリクエストするサーバを2台の

    memcached(プロトコル)のデータレプリケーション - (ひ)メモ
  • 第1回 NoSQL、そしてCassandraとは | gihyo.jp

    NoSQLミドルウェアの特徴をもう少し細かく挙げてみます。分量の都合もあり個別には触れませんが、それぞれのNoSQLミドルウェアで差別化部分に関してはかなり詳細に説明がされていますので、ぜひそちらを参照してみてください。 高速に動作する リレーションモデルではないデータモデル スケールアウト型アーキテクチャ コモディティサーバによって構築される スキーマフリー SPOF(単一故障点)を持たない 自動的に複数台へレプリケーションする イベンチュアルコンシステンシまたは一貫性の選択が可能 SQLのような強力なクエリ言語を持たず、シンプルな問い合わせしかできない Cassandraとは何か NoSQLミドルウェアの筆頭といえばGoogle BigTableやAmazon Dynamoですが、オープンソースの世界でもいろいろなものが出てきています。その中でも最近特に注目を集めているのが、Apach

    第1回 NoSQL、そしてCassandraとは | gihyo.jp
  • Cassandra: Fact vs fiction

    Cassandra has seen some impressive adoption success over the past months, leading some to conclude that Cassandra is the frontrunner in the highly scalable databases space (a subset of the hot NoSQL category). Among all the attention, some misunderstandings have been propagated, which I'd like to clear up. Fiction: "Cassandra relies on high-speed fiber between datacenters" and can't reliably repli

  • fallabs.com

    fallabs.com 2023 著作権. 不許複製 プライバシーポリシー

  • Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server

    UPDATE: Oracle officially released memcached daemon plugin that talks with InnoDB. I'm glad to see that NoSQL+MySQL has become an official solution. It's still preview release but will be very promising. Let's try it to make it better! Most of high scale web applications use MySQL + memcached. Many of them use also NoSQL like TokyoCabinet/Tyrant. In some cases people have dropped MySQL and have sh

    Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server
  • NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance

    ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ

    NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
  • kumofs-0.4.0リリース - CAS操作をサポート - Blog by Sadayuki Furuhashi

    新たにCAS(Compare-And-Swap)をサポートした、kumofs-0.4.0をリリースしました。 memcachedのテキストプロトコルで、getsコマンドとcasコマンドを新たに使うことができます。 後方互換性は保たれています*1。新機能を利用するには、kumo-gatewayとkumo-serverを更新してください。 CASとは? CAS(Wikipedia)は Compare-And-Swap の略で、ある値を取得したあと、その値が別のプロセスから更新されていなければ(Compare)変更を適用する(Swap)という操作を、アトミックに実行することができます。 CASを利用することで、kumofs上にキューやカウンタ、連想配列、ロックなどを実装することが可能になります。 例えば kumofs でキューを実現する擬似コードは、次のようになります: KEY = "myque

    kumofs-0.4.0リリース - CAS操作をサポート - Blog by Sadayuki Furuhashi
  • kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi

    前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが(たぶん^^;)、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。(個人で開発している場合など、開発リソースが小さい場合はなおさら) そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います(もちろん、アルゴリズムも重要ですが)。 分散システムには複雑

    kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi
  • kumofsから学ぶNot only SQLの技術 - Blog by Sadayuki Furuhashi

    NoSQLを知る〜kumofsから学ぶNot only SQL技術 と題して、Developers Summit 2010で発表しました。 twitterの#devsumi2010 kumofsを見る限りでは大変ご好評をいただいたようで、ひとまずほっとしています。 プレゼンテーションの資料を公開しました。内容はどれも同じですが、クリックで進むムービー版がオススメです。 クリックで進むムービー(クリック/矢印キーで進む) PDF Keynoteファイル(Keynote '09が必要) NoSQLを知るView more presentations from frsyuki. Consistent Hashingとdouble-hash-spaceアルゴリズムの紹介は、68ページ以降にあります。 第101回 カーネル読書会 2月25日に楽天タワーで行われるカーネル読書会でも、kumofs関連

  • KumoFS, a database success story

    Superfeedr is growing, and we want to add value for our clients. Our newest feature requires us to store a lot of data, so we went out to look for appropriate solutions in the NoSQL ecosystem. The first decision was Riak, featuring persistent storage on disk and a very tunable clustering layer. The current use-case consists of simply pulling a feed from the database, extend it with the newest entr

    KumoFS, a database success story
  • MessagePack: It's like JSON. but fast and small.

    It's like JSON. but fast and small. MessagePack is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it's faster and smaller. Small integers are encoded into a single byte, and typical short strings require only one extra byte in addition to the strings themselves. Next: MessagePack is supported by over 50 programming languages and environm

  • Schema-Free MySQL vs NoSQL - igvita.com

    By Ilya Grigorik on March 01, 2010 Amidst the cambrian explosion of alternative database engines (aka, NoSQL) it is almost too easy to lose sight of the fact that the more established solutions, such as relational databases, still have a lot to offer: stable and proven code base, drivers and tools for every conceivable language, and more features than any DBA cares to learn about. Not to mention t

  • Cassandra @ Twitter: An Interview with Ryan King

    There have been confirmed rumors[1] about Twitter planning to use Cassandra for a long time. But except the mentioned post, I couldn’t find any other references. Twitter is fun by itself and we all know that NoSQL projects love Twitter. So, imagine how excited I was when after posting about Cassandra 0.5.0 release, I received a short email from Ryan King, the lead of Cassandra efforts at Twitter s

    Cassandra @ Twitter: An Interview with Ryan King
  • 分散ストレージの収束する方向 - sdyuki-devel

    サーバーサイドの分散ストレージについて。広域P2Pとかデータセンター間で同期するとかCDN云々は知らない。 kumofsのアプリケーション-Gateway間のインタフェースは Get(key) だが、Gateway-Server間のインタフェースは実は GetByHash(key, partitioning-id)(とGetByHashIfModified(key, partitioning-id, time))だったりする。(実際の名前は違うけど意味は同じ) 現状ではpartition-idはkeyにハッシュ関数を掛けて自動生成するが、実際には任意の値を指定できる。 つまり関連するkeyには同じpartitioning-idを指定して同じノードに保存されるようにして、partitioning-idが同じkey同士ならトランザクションできるようにすることも、案外に容易にできる。 Consi

    分散ストレージの収束する方向 - sdyuki-devel
  • kumofs関連資料まとめ - Blog by Sadayuki Furuhashi

    随時更新予定。 ツールなど 2010-01-08 kumofsの死活監視はこんな感じでNagiosでやってます - (ひ)メモ 検討と検証 2010-04-01 kumofsに10MBのvalueを入れるとどうなるか実験してみた - sdyuki-devel 2010-02-24 KVS(NoSQL)のまとめと「これから」の設計手法 - どっかのBlogの前置きのような 2010-02-01 kumofs その4・速度比較してみた - とあるWEBプログラマの軌跡(仮) 設計とアーキテクチャ 2010-04-26 hbstudy#10「ずばり動く!kumofs と ずばり動かないケース」 2010-04-25 丸レク2010「分散Key-valueストアkumofsの思想と設計」 2010-02-09 kumofsはなぜ落ちないか 2010-01-26 kumofsはなぜスケールするか 2