AWS Black Belt Techシリーズ Amazon DynamoDB
AWS Black Belt Techシリーズ Amazon DynamoDB 1. Amazon DynamoDB AWS Black Belt Tech Webinar 2014 Yuta Imai Solutions Architect, Amazon Data Services Japan, K.K. 2. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計とサンプル • 運用関連 • ツールとエコシステム • まとめ 3. Agenda • NoSQLとRDB • DynamoDBとは • テーブル設計とサンプル • 運用関連 • ツールとエコシステム • まとめ 4. よく見かけるNoSQLデータベース • Neo4j • Couchbase • DynamoDB • MongoDB • Riak • HBase • Cassandra 5. No
Amazon DynamoDB Update – JSON, Expanded Free Tier, Flexible Scaling, Larger Items | Amazon Web Services
AWS News Blog Amazon DynamoDB Update – JSON, Expanded Free Tier, Flexible Scaling, Larger Items Amazon DynamoDB Amazon DynamoDB is a fast and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale. Our customers love the fact that they can get started quickly and simply (and often at no charge, within the AWS Free Tier) and then sea
yrmcds 1.0.0 をリリースしました - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。去る 7 月に yrmcds という memcached 互換な KVS を公開したことをご案内しました。それから 5 ヶ月経ちましたが、今回は安定版となるバージョン 1.0.0 をリリースをご案内します。 ダウンロードはこちらからどうぞ: https://github.com/cybozu/yrmcds/releases/tag/v1.0.0 0.9.0 からの変更点を短くまとめるとバグがなくなって、memcached より多分高速になっています。ちょっと長めの記事ですが、末尾にいいことが書いてありますので、是非ご一読ください。 yrmcds の特長 レプリケーション サーバーサイドロック No slabs その他 memcached との差異 運用実績と性能 クライアント 0.9.0 からの変更一覧 バグ報告を募集します！ yrmcds の特長 y
yrmcds 1.0.0 の補足 - 誰かの役に立てばいいブログ
エンジニアなら詳細が気になるもの。というわけで、個人ブログのほうで yrmcds 1.0.0 リリース記事の技術的な補足をしておきます。 keepalived 使うの、split brain になるんじゃないの？ さてはプロの方ですね。困りますな、そういう突っ込みは！ 気になる人は split brain 起こさない heartbeat をご利用ください。 用途次第でまあどうでもいっかなーという人は keepalived の方が手軽かと思います。 サーバーサイドロックとレプリケーション ロック状態はレプリケーションされません。非同期レプリケーションなのでしても無駄というか。 するとロックした後、フェイルオーバーするとオブジェクトがロックされない状態になるわけです。危険です。 対策として導入したのが、バイナリプロトコルの RaU (Replace and Unlock) です。 このコマンド
yrmcds 0.9.0 リリース - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本泰宇です。 今回は memcached 互換で冗長構成を簡単に組める自社製 KVS である yrmcds のリリースをご案内します。 ... この Redis 全盛なご時世になんで？とか、repcached や Kyoto Tycoon があるじゃない、といったツッコミの嵐が聞えてきそうです。わかってます、わかってますから物を投げないで！ 順を追って説明しますので、批判はそれからにしてください！ 何が欲しいのか 私は日頃 cybozu.com のインフラで動作するソフトウェアを開発しています。リリース後もうすぐ２年になりますが、お蔭様で 4,000 社以上にご利用いただくまでになりました。商売繁盛で嬉しいのですが、運用側は日々増えるデータとアクセスを捌くべく奮闘しています。 ここのところ問題になっていたのが、MySQL に保存しているセッション情報でした。アプリ
開発メモ: KVSとシグナル機構でジョブキューを実現する
いわゆるkey-value storeを使っている際に、レコードの挿入もしくは更新を検知して即座に何らかの処理を行いたくなることはないだろうか。俺はあんまりないけど、結構そういう質問が来るので、きっと巷にはそういう要求があるのだろう。Kyoto Cabinetでそれを実現してみた。 ジョブキュー もうちょい具体的な例を挙げると、ジョブキューである。ここで、「foo」という名前のタスクを考えてみる。読み出し側（ワーカ）は、適当な名前をつけた条件変数を常に監視していて、そこにシグナルが飛んできたら即座にレコードを取得して処理を行いたい。しかし、「一定の間隔毎にレコードの検索を繰返して発見したら処理を行う」というポーリングスタイルにはしたくない。操作にどうしてもタイムラグが出るし、ポーリングのための無駄なトラフィックが発生するからだ。 シグナル待機処理と該当レコードの取得処理を行う擬似コードは以
開発メモ: Kyoto Tycoonベータ版リリースすた
ここのところ必死こいて作り込んでいたKyoto Tycoonだが、主要機能を実装しきって文書もそこそこ書けてきたので、ベータリリースということにした。プロジェクトページもちゃんと作ってある。 公式には英語の文書しか作らない方針なのだが、それだと国内ではなかなか使ってもらえないので、この場でチュートリアルを書いてみる。 Kyoto Tycoonとは プロセス組み込み軽量データベースライブラリであるKyoto Cabinetをネットワーク越しに利用できるようにするためのツールキットである。KCのデータベースを内部に持ったサーバプログラムと、それに接続してデータベースを操作するためのクライアントライブラリからなる。また、コマンドラインからサーバにアクセスするためのユーティリティもついてくるので、簡単に使い始められる。 製品コンセプトは、「永続的キャッシュサーバ」もしくは「memcachedの永続
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
分散 Key-Value ストア mio-0.0.1alpha をリリースしました - higepon blog
分散 Key-Value ストア mio-0.0.1alpha をリリースしました。(mio-0.0.1-alpha.tar.gz) Mio とは何か？ 範囲検索(range query) が出来る KVS です。例えば「key が "1000"〜"2000" にあるものを昇順に10件取り出す」という検索が可能です。 Mio は memcached 互換プロトコルを実装しているので、多くのプログラミング言語から簡単にアクセスする事が可能です。（後述のコード例参照） Mio のアーキテクチャ Mio は Skip Graphs（スキップグラフ）というアルゴリズムに基づいて実装されています。詳細はErlang 分散システム勉強会での発表資料 Mio - a distributed Skip Graph based orderd KVSをご参照ください。 インストール 最新の Erlang をイ
memcachedと“正反対”、Redisが仮想メモリをサポート － ＠IT
2010/09/07 KVS（キー・バリュー・ストア）に分類されるオープンソースのRedisの新バージョン、「Redis 2.0.0」が2010年9月5日にリリースされた。Redisはmemcachedと同様にキーと値のペアをメモリ上に保持するKVSの一種だが、3つの際立った特徴がある。1つはハッシュ以外のデータ構造もサポートしていることで、リスト型、集合型、順序付き集合型などのデータ構造が扱え、サーバ側でコレクションに対するpush/pop、コレクション同士のunion/intersection、数値のincr、decrなどの操作がアトミックに行える。バージョン2.0では複数の操作を1つにまとめてアトミックに操作するコマンドも増えている。 もう1つのRedisの特徴は、マスター・スレーブによるレプリケーション設定ができ、リード側のスケールアウトが容易にできること。 そして3つ目の特徴は、
CouchDBとMongoDBを比較してみた - Masatomo Nakano Blog
ドキュメント指向なKVSってことと、字面が似ていると言うことぐらいしか比較する意味がなさそうなCouchDBとMongoDBだけど、ここ2，3ヶ月で両方をそれなりに突っ込んで見てきたので比較してみた。実装面やパフォーマンス、ということよりはどちらかというと(私が感じる)思想的なものや、ユーザ側からの視点での比較。 共通するところ これはもう簡単に、 ドキュメント指向データベース - RDBMSのようなカラムと言ったものを持たずにスキーマレスで好きな情報を入れられる Javascript/JSONを使用 - データ自体もJSONというJavascript由来のフォーマットで持ち(MongoDBはJSONを元にしたBSONというものだが)、データベースのアクセスにはJavascriptを使用する スケールアウトするように考えられている NoSQLな流行 CouchDBの特徴 機能を限定している
開発メモ: 使ってみようTokyo Cabinet
この記事は、Software Design2010年2月号の特集「ほんとうに知りたいあなたのためのkey-valueストア講座」に寄稿した記事の校正前の版です。 DBMとは PerlやRubyやPHPなどのスクリプト言語が世の中に多数存在しますが、どの言語にも必ず連想配列もしくはハッシュと呼ばれる機構があります。これは、キーと値という二つのオブジェクトを関連付けて記憶しておき、キーに一致する値を効率的に取得するための機構です。プログラマの皆さんは日々当たり前のように使っている機能ですよね。 スクリプト言語組み込みの連想配列はメインメモリ上にデータを記録するので、プロセスが終了したらデータが消えてしまいますし、メインメモリの容量以上のデータが扱えないという問題があります。それを解決するのがDBM（DataBase Manager）です。DBMは連想配列をファイル上で実現したものですので、プロ
shirokaned - messagepack rpc + kyotocabinet + AnyEvent + Perl による適当な KVS の実装 - tokuhirom's blog
http://github.com/tokuhirom/shirokaned HTTP でデータを取得できる そして、その httpd を外部にみせても大丈夫インメモリデータベースLRU supportそれなりにはやい 同時1000接続程度で5000QPS程度でればいいかなーmater-master レプリケーションができる想定しているデータサイズは 4KB 程度で、レコード数は100万程度の LRU で OKキャッシュ用途なので、slave と master で一貫性は必要ないし、データの更新も一切ないvalue がなければ、再生成できるかんじってかんじの KVS があったらいいなあとおもった。 のでためしにかいてみた。 要素技術としては AnyEvent::MPRPC(AnyEvent を用いた messagepack rpc の perl 実装)daemontools(ロガーをつけた
Kyoto Cabinet 1.0.0リリース！ - mixi engineer blog
夏が近づくとウキウキしてくるmikioです。昨日ついにリリースされたKyoto Cabinet 1.0について今回は報告します。 1.0の位置づけ コミュニティ毎や製品毎にバージョン番号割り当ての方針は異なるわけですが、私の個人的なポリシーでは、1.0には特別な意味があります。すなわち、0.xのバージョンはbeta版的な位置づけで、「実サービスに使うのはちょっと待った方がいいですよ」ということを意味します。一方で、1.xはstable版的な位置づけで、「よろしければ実サービスでも使ってみてください」ということを意味します。私がstable版に設定する原則を以下に列挙します。 安定稼働を至上命題とする（バグがあればその修正を最優先する） APIを変更しない（変更するとしても後方互換性を維持する） DBファイルのフォーマットを変更しない（変更するとしても後方互換性を維持する） なるべく機能追加
kumofsはなぜスケールするか - Blog by Sadayuki Furuhashi
先日、分散Key-valueストア kumofs を公開しました。 多く方から反響とフィードバックをいただいています。ありがとうございます。 今回は、kumofs はなぜスケールするのか、なぜスケールすると言えるのかーということについて紹介したいと思います。 ところでスケーラビリティとは何か？ スケーラビリティとは、利用者や仕事の増大に適応できる能力・度合い とされています（端的！）*1 。Scalability を日本語にすると、拡張性 と訳されるようです。 ただ一口でスケーラビリティと言っても、様々な側面があります。ITシステムでは主には処理性能と運用に関することを指す場合が多いと思いますが*2、その中にも様々な側面があります。 なぜスケーラビリティが必要か スケーラビリティは システムなどが持つべき望ましい特性 であって、高いに越したことはありません。しかし、高いスケーラビリティはタ
分散Key-Valueストア「kumofs」を公開しました！ - Blog by Sadayuki Furuhashi
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - yapstudios/YapDatabase: YapDB is a collection/key/value store with a plugin architecture. It's built atop sqlite, for Swift & objective-c developers.
Tie-LevelDB-0.07 - A Perl Interface to the Google LevelDB NoSQL database - metacpan.org
FAL Labs
x.com