IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
![Charming Python: Functional programming in Python, Part 3](https://cdn-ak-scissors.b.st-hatena.com/image/square/976d6b25b135fedb9c2be132b02244d48574a5af/height=288;version=1;width=512/http%3A%2F%2Fwww.ibm.com%2Fdeveloperworks%2Fi%2Fdw-social-201508.png)
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つ目の特徴は、
はじめに NoSQL(Not Only SQL)という言葉が注目を集めています。これは「RDBMSが得意なことはRDBMSで、不得意なところにはRDBMSにこだわらず、用途に合ったデータストアを使いましょう』という考え方です。最近では、いわゆるNoSQLデータベース (key-valueストアや各種データベース) が次々と登場してきています。 そこで今回から数回に渡り、それぞれのNoSQLデータベースの特徴や具体的な使い方について紹介していきます。 RDBMSの強みとは そもそも、MySQLやPostgreSQLなどのRDBMSの弱みを補うため、様々なNoSQLデータベースが登場してきたわけですが、RDBMSにはたくさんの強みがあることも忘れてはいけません。 RDBMSの強み データの一貫性 (トランザクション) 更新時のコストが少ない(JOINが前提でテーブルが正規化されている)
NoSQLミドルウェアの特徴をもう少し細かく挙げてみます。分量の都合もあり個別には触れませんが、それぞれのNoSQLミドルウェアで差別化部分に関してはかなり詳細に説明がされていますので、ぜひそちらを参照してみてください。 高速に動作する リレーションモデルではないデータモデル スケールアウト型アーキテクチャ コモディティサーバによって構築される スキーマフリー SPOF(単一故障点)を持たない 自動的に複数台へレプリケーションする イベンチュアルコンシステンシまたは一貫性の選択が可能 SQLのような強力なクエリ言語を持たず、シンプルな問い合わせしかできない Cassandraとは何か NoSQLミドルウェアの筆頭といえばGoogle BigTableやAmazon Dynamoですが、オープンソースの世界でもいろいろなものが出てきています。その中でも最近特に注目を集めているのが、Apach
実績 Cassandra は、Digg をはじめ、Facebook, Twitter, Reddit, Rackspace, Cloudkick, Cisco, SimpleGeo, Ooyala, OpenX など、大規模でアクティブなデータセットを持つ多くの企業で実際に使われています。最も大規模な実働クラスタでは、150 台以上のマシンに 100 TB を超えるデータが格納されています。 高い耐障害性 障害に備えて、データは複数のノードに自動的にレプリケートされます。複数のデータセンターにまたがるレプリケーションもサポートされています。故障したノードは、ダウンタイムなしにリプレースできます。 非集中的 クラスタ内のすべてのノードは対等です。ネットワークボトルネックはありません。SPOF (単一障害点) もありません。 ユーザーに主導権 更新ごとに同期レプリケーションまたは非同期レプリケ
前回はNoSQLデータベースとRDBMSの設計思想の違いを解説しました。今回は、それを踏まえてNoSQLデータベースでデータベースを設計するときに覚えておきたいポイントを解説します。(編集部) NoSQLデータベース設計のセオリーとは? 前回は、NoSQLデータベースが登場してきた背景や、リレーショナルデータベース管理システム(RDBMS)との違いを解説し、いくつかの代表的なNoSQLデータベース製品を紹介しました。長年、データ管理の分野で主役を担ってきたRDBMSはデータ一貫性を強く保持する仕組みを備えていましたが、半面その特徴ゆえにネットワーク上の複数のサーバにデータを分散すると(分散環境)十分に性能を発揮できず、スケールアウトによる性能向上が困難であるという弱点を持っています。 分散環境において高い性能を発揮するNoSQLデータベースの世界では、一体どのような考え方でデータベースを設
注目を集めるNoSQLデータベース 数年ほど前から、分散KVS(Key-Value Store)や列指向(Column-Oriented)データベース、ドキュメント指向(Document-Oriented)データベースなどの新しいデータベース技術が注目を集めています。これらの新しいデータベース技術は、リレーショナルデータベース管理システム(RDBMS)とは異なる考えに基づいているので、よく「NoSQL」データベース(注1)と総称されています。 注1:「NoSQL」という言葉はもともと「近年登場している、RDBMS以外の(つまりSQLを使わない)データベース」を総称、表現したものであり、その後から「SQLは不要だ」というイメージを持つキーワードのようになってきました。データベース開発者の中には、このようなRDBMSに対するネガティブなイメージを好まず、NoSQLを「Not Only SQL(
kumofsの起動 kumo-managerの起動 まずkumo-managerを起動します。kumo-managerを起動するのはserv1, serv2の2台となります。 serv1でのkumo-managerの起動 $ kumo-manager -v -l serv1 -p serv2 2010-08-05 20:14:05 ./manager/init.h:43: start manager 192.168.47.101:19700 2010-08-05 20:14:07 ../rpc/client_tmpl.h:157: connecting to 192.168.47.102:19700 2010-08-05 20:14:07 ../rpc/client_tmpl.h:199: connect failed 192.168.47.102:19700: Connection re
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
夏が近づくとウキウキしてくるmikioです。昨日ついにリリースされたKyoto Cabinet 1.0について今回は報告します。 1.0の位置づけ コミュニティ毎や製品毎にバージョン番号割り当ての方針は異なるわけですが、私の個人的なポリシーでは、1.0には特別な意味があります。すなわち、0.xのバージョンはbeta版的な位置づけで、「実サービスに使うのはちょっと待った方がいいですよ」ということを意味します。一方で、1.xはstable版的な位置づけで、「よろしければ実サービスでも使ってみてください」ということを意味します。私がstable版に設定する原則を以下に列挙します。 安定稼働を至上命題とする(バグがあればその修正を最優先する) APIを変更しない(変更するとしても後方互換性を維持する) DBファイルのフォーマットを変更しない(変更するとしても後方互換性を維持する) なるべく機能追加
What is Memcached? Free & open source, high-performance, distributed memory object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering. Memcached is simple yet powerful.
greeさんで開催されたKey Value Store勉強会に行ってきました。 時間にして4時間超え、内容も国内のKey-Value Storeなソフトウェアの最前線の話ばかりで相当なボリューム。以下、メモってたのを残しておきたいと思います。(誤字、脱字、内容に誤りを含むものなどありましたらお伝えください)また、発表者の方やプロダクトについて、ざっくり調べてURL見つけられたものについてはリンク張っています。 森さん / 末永さん groonga Sennaの後継エンジン 融通が効かないのがSennaのデメリット スコア算出式のカスタマイズなど Sennaの転置索引 索引の構成部品を自由に組み合わせて使える APIもいろいろ QL DB Low Level memcached互換のkey-value store バイナリのみ対応 計測 クライアント memstorm-0.6.8 mem
Protocol -------- Clients of memcached communicate with server through TCP connections. (A UDP interface is also available; details are below under "UDP protocol.") A given running memcached server listens on some (configurable) port; clients connect to that port, send commands to the server, read responses, and eventually close the connection. There is no need to send any command to end the sessi
主な3つの機能について実装状況を示してみました。 「データ永続化」とは、ストレージサーバを再起動してもデータが失われないようにデータをメモリではなくHDD等に格納できる機能です。例えば、memcachedはメモリにデータを置くため、ストレージサーバを再起動するとデータが失われます。 「データ冗長化」とは、格納したデータがストレージサーバ側で自動的に複数のストレージサーバにコピーが作られる機能です。1台(または数台)のストレージサーバがダウンしてもデータが失われることはありません。 「データ分散」とは、キーのハッシュ値等を元にデータの格納先のサーバを振り分ける機能で、負荷分散を図ることができる機能です。なお、memcached、Tokyo Tyrantにはサーバ側での分散機能はありませんが、クライアント側のライブラリによって格納先サーバを分散させることも可能です。 memcachedプロトコ
What is Apache Cassandra? Apache Cassandra is an open source NoSQL distributed database trusted by thousands of companies for scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く