キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると
2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
もう1つの、DBのかたち、分散Key-Valueストアとは
もう1つの、DBのかたち、分散Key-Valueストアとは：分散Key-Valueストアの本命「Bigtable」（1）（1/3 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 クラウド時代のデータベース「分散Key-Valueストア」 グーグルがインターネットの世界をここまで席けんできた最大の理由は何でしょうか。実は、それは同社の優れた検索技術ではありません。グーグルが成し遂げた最も大きなブレークスルーの1つは、同社が生み出した巨大な分散データストア、「Bigtable」にあります。 Bigtableは、Google検索をはじめ、YouTubeやGoogle Map、Google Earth、Google Analytics、Goog
Drizzleプロジェクトの目指すもの、その先を読む（1/3） － ＠IT
クラウドコンピューティング環境のような“massively concurrentな世界”で使えるデータベースを目指すDrizzle。その開発の方向性からこれからのWebシステムで求められるデータベースのあり方が見えるかもしれない。一足先にDrizzleに触れてみよう（編集部） Drizzleとは Drizzle とは、MySQLのもともとの目標である、使いやすさ、信頼性、そしてパフォーマンスに重点を置いたMySQLの派生プロジェクトで、Brian Aker氏（米サン・マイクロシステムズ CTO/Labs：元MySQL Director of Architecture）によって立ち上げられました。 MySQLと比較して機能面におけるDrizzleの大きな違いは、サーバアーキテクチャをマイクロカーネルにすることで、サーバ（MySQLでいうmysqld）には必要最小限の機能しか搭載せず、代わりに
Salesforceのデータベース - snippets from shinichitomita’s journal
すごい良い記事。 知られざる「マルチテナントアーキテクチャ」（2）～スケーラビリティのカギは組織ID － Publickey 知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey 頼まなくてもこういう記事を書いてくれる人が増えている（頼まれてないっすよね？）のは、SFDCにとって、デベロッパーマーケティングとして成功だと思う。大事にしてくださいね。 スキーマについて 上記記事では、データベースの物理スキーマについて、公開情報をもとに分析されています。 掟破りのスキーマ セールスフォースのアプリケーションで扱われるすべての数字や文字のデータは、Dataテーブルに保存される。このことがセールスフォースのデータベーススキーマの核心です。 Dataテーブルはどんなデータでも受け入れられるよう、次のようなスキーマになっています。恐らく、データベースに詳し
無いから作った人たち
データベース技術の世界に新顔が次々と登場している。米Danga Interactiveの「memcached」、ミクシィの「Tokyo Cabinet」と「Tokyo Tyrant」、楽天の「ROMA」、グリーの「Flare」などだ。いずれも半導体メモリーを使って大規模データベースを高速処理する技術である。面白いのは、4社ともIT製品を開発するメーカーではないことだ。 4社は、Webを使ったサービス事業を手掛ける企業であり、本来であればメーカーが開発した製品や技術を使う立場である。ところが、こうした「ユーザー企業」が自ら基盤技術を開発し、それを利用している。 memcachedやTokyo Cabinet/Tyrant、ROMA、Flareの中では、memcachedが一番古い。Danga Interactiveが自社のブログ・サービス「LiveJournal」を改善するために2003年に
key-value stores: Anti-RDBMS: A list of distributed key-value stores | Richard Jones, Esq.
Please Note: this was written January 2009 - see the comments for updates and additional information. A lot has changed since I wrote this. Perhaps you’re considering using a dedicated key-value or document store instead of a traditional relational database. Reasons for this might include: You're suffering from Cloud-computing Mania. You need an excuse to 'get your Erlang on' You heard CouchDB was
「キー・バリュー型データストア」開発者が大集合した夜
「発表者が自分よりも若い人ばかりだ」。外見が20代にしか見えない東京工業大学の首藤一幸准教授（1973年生）の驚くさまが、少し面白かった。2009年2月20日の夜、多くのWeb企業が注目する「キー・バリュー型データストア」を開発する若手技術者が、東京・六本木のグリー本社に一堂に会した。 キー・バリュー型データストア（またはキー・バリュー型データベース）は、大量のユーザーとデータを抱え、データベースのパフォーマンス問題とコスト高に頭を悩ませるWeb企業が注目する技術である。記者は同日に開催された「Key-Value Store 勉強会」に参加させてもらった。午後7時から11時まで、キー・バリュー型データストアを開発・研究する若手技術者が立て続けに登場し、1人15分の持ち時間で成果を発表し、議論を重ねるという集まりだ。 呼びかけ人であるプリファードインフラストラクチャー（PFI）最高技術責任者
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
