第1回 大規模データではRDBMSのどこがボトルネックになるのか？ | gihyo.jp
RDBMSはオワコン？ 「右を向いても左を向いても“ビッグデータ”というキーワードが闊歩する時代に、いまさらRDBMSの話題？」 本連載のタイトルを見てそう思われたかもしれません。 「ディスクベースのRDBMSはオワコン、これからは○○（お好きなアーキテクチャを入れてください）の時代だ！」 とおっしゃる方もいるかと思います。 しかし、むしろ多くの企業がビッグデータに注目しているおかげで、RDBMS側でも大規模データを取り扱うニーズが増えています。 大規模データを取り扱う時にボトルネックとなる5つのポイント 数百ギガバイトといったレベルのRDBMSであれば、現場のエンジニアの方にとってはあたりまえの世界でしょう。しかし、テラバイトを大きく超えたデータを扱う場合には、ボトルネックの傾向が変化するのはご存じでしょうか。 次の図は、RDBMSにまつわるボトルネックを示したものです。 図1 大規
Trees In The Database - Advanced data structures
Storing tree structures in a bi-dimensional table has always been problematic. The simplest tree models are usually quite inefficient, while more complex ones aren't necessarily better. In this talk I briefly go through the most used models (adjacency list, materialized path, nested sets) and introduce some more advanced ones belonging to the nested intervals family (Farey algorithm, Continued Fra
かわいいリレーショナルデータベース作った - きしだのHatena
リレーショナルデータベースの勉強用に、最低限の機能をもったリレーショナルデータベースを作ってみました。 今回実装した最低限の機能というのは、射影(select)・選択(where)・結合(join)です。 テーブル作成 テーブル作成は次のようになります。 Table shohin = Table.create("shohin", new String[]{"shohin_id", "shohin_name", "kubun_id", "price"}); shohin.insert(1, "りんご", 1, 300) .insert(2, "みかん", 1, 130) .insert(3, "キャベツ", 2, 200) .insert(4, "わかめ", null, 250) .insert(5, "しいたけ", 3, 180); System.out.println(shohin);
Clojureの作者が作ったデータベースDatomicが凄い
プログラミング言語Clojureの作者Rich Hickey氏率いるClojure HackerのチームがDatomic(デートミックと発音するらしい)というデータベースをリリースしました。これが何やらとてつもないです。10年先を行ってる技術じゃないでしょうか。 まだ本番サービスは始まっていませんが開発環境用のライブラリが配布されています。 Datomicは斬新なアーキテクチャなので一言で説明するのはとても難しいです。 私が理解できたことを簡単に説明します。 2014/1/20追記 ライセンスモデル、サポートストレージ、サービスとしてではなく独立して使用する形になるなど記事作成時の内容から色々変更が合った部分を更新しました。 変更不可なAppend-onlyデータベース 従来のデータベースで、あるレコードを変更するというのはそのレコードに対応した場所があり、そこのデータを書き換えるというこ
Hamster DB – A Data Science Blog
Online data science provides the students with a flexible and affordable path towards a very lucrative data science job. According to the bureau of Labor Statistics the projected employment growth for database administrators is 11% with the current average salary for database administrators standing at $87,020. The increasing popularity of data analytics and data base administrators adds to the ev
基礎から理解するデータベースのしくみ（9）
図10●レコード・クラスタリングの仕組み。ハッシュ値にしたがって，empとemp_histの二つのテーブルで同じenoを持つレコードを一つのテーブルに格納している RDBMSが備えるさまざまな高速化手法 RDBMSは，ここまで説明してきた基本的なデータの格納のしかたや操作方法に加え，高速化のための手法をいろいろ用意しています。Part2の最後に，これらの手法をざっと紹介しておきましょう。 ●ハッシュ・インデックス キャッシュ・バッファのサイズや使われ方にもよりますが，一般にBツリー・インデックスを使って巨大なデータベースにアクセスする際には，ルート・ノードだけがキャッシュ・バッファにあるのが普通です。そのため，レコードにたどりつくまでにブランチ・ノード，リーフ・ノード，データベース・レコードと何回もディスクにアクセスしなければなりません。これを1回のアクセスでレコードを取得できるようにしよ
ランキングのつくりかた:Kenn's Clairvoyance
遅ればせながら、あけましておめでとうございます。 先週には、ベイエリアの友人たちがやっているEchofonがPostUpに買収されるなど、幸先のよい新年のスタートとなりました。 さて、最近ホットなマーケットといえばソーシャルゲームですが、ゲームといえばリーダーボード。ハイスコアのランキングで友人や見知らぬ人たちと競うのは、ビデオゲームが誕生した1970年代から欠かせない要素でした。 ところが、インターネット経由で100万人規模のプレイヤーがつながるようになってきた現在、その全体をランキングづけするのは、技術的にも大きなチャレンジとなってきました。 今回は、そのリーダーボードのつくりかたについて、ぼくらの作っているソーシャルゲーム・プラットフォームであるPankiaの運用で得られた知見を共有したいと思います。 自分の順位を知る方法 リーダーボードの基本的な考え方はシンプルで、それはつまり「ユ
Webアプリをとりまく最近のKVS事情、雑感 - Tous Les Jours 攻防記
RDBの復権はしばらくないと思う 最近目にしたのは、「これからRDBが十分速くなっていくので、memcachedに代わってRDBがまた使われるようになる」という意見。これはしばらくの間は無いんじゃないかと思う。全データがオンメモリだったとしても、KVSはRDBより一桁以上速い（Memcachedで100,000req/sec出せるマシンで、MySQLのpkeyによる単純なSELECTをした場合、10,000req/sec出るかどうか）。SQLパーサやらなんやらを捨てない限りこの速さには対抗できない。RDBには、１コネクション１スレッドというモデルが持つ、接続数がスケールしないという制約もある。 また、memcacheプロトコルは、get_multiが使える。get_multiを効果的に活用した場合、RDBとの差はさらに広がると思う。 RDBで大丈夫なアプリも Viewキャッシュが効果的なア
WebアプリのDBスキーマレス化がRubyにぴったりな件 - Tous Les Jours 攻防記
という題で、RubyKansai#37で発表させていただきました 内容は、WebアプリケーションのDBのスキーマレス化について。 スキーマレスなDBアクセスのための、拙作DBインターフェースライブラリ「SimpleResource」の紹介も合わせて盛り込みました。SimpleResourceは、スキーマレスなデータを保存するためのKVS DBインターフェースライブラリで、Rubyで書かれています。レコード単位のロック機構、インデックス機能等を備えている他、ActiveRecordに近い使い勝手で利用することができます。ストレージには現在MySQLとTokyoTyrantにのみ対応しています。（FriendFeedの同様の試みもかなり参考になりました。詳細はまた後日にエントリで上げたいと思ってます） SimpleResourceは、GitHub上で開発を続けていくつもりです。 http://
NoSQL登場の背景、CAP定理、データモデルの分類
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
RDBに代わるスケーラブルなデータモデルの必要性 - sdyuki-devel
このあたりの内容を卒業研究にする予定で、中間報告書まで書いたけど、整理と裏付けが全然追いつかなくて卒論なんて書けそうにないので、とりあえずテキトーにブログに書いておくなど。 データストアには、状態を永続化して共有する機能と、データモデル（状態を操作する意味論）を規定する機能の、２つの機能がある。この２つの機能を、より使いやすく、より高速に、よりスケーラブルに提供することが求められる。そうでないとシステム全体が成り立たない。 冗長化とか負荷分散とか、ハードの質に頼らない高性能なシステムを構築したいときは、「状態を持たないようにする」のが定石になる。同じ状態を２台のホストで同期し続けたり、状態を分割しながら整合性を保ち続けるのは、非常に難しい。このため、状態は共有データストアに保存しておくのがもっとも簡単で、現実的な解になる。 MVCアーキテクチャにおけるViewとControllerはMod
Second Life Blogs
May is Mental Health Awareness Month and Second Life offers a variety of sanctuaries that provide support, peace, and healing for those who may be facing challenges. From serene retreats that foster mindfulness to supportive gatherings where you can connect with others, these destinations are invaluable resources. Whether you’re looking to engage in group discussions, enjoy soothing environments,
FriendFeedはどのようにスキーマレスなデータをMySQLに格納しているか - モジログ
FriendFeedのBret Taylorが、スキーマレスなデータ（スキーマ（型）に制約されないデータ）をMySQLに格納する方法を紹介している。実際にFriendFeedで使っている方法で、最新のものらしい。 Bret Taylor's blog - How FriendFeed uses MySQL to store schema-less data http://bret.appspot.com/entry/how-friendfeed-uses-mysql MySQLを通常のRDB的な方法でなくストレージ的に使い、JOINを使わないでスケールさせるというもの。CouchDBなどにも近い、最近有力になりつつあるアプローチだ。これを、実績もあり普及しているMySQLを使って実現し、言語はPythonで実装している。 メインのテーブルは次のようなもの。 CREATE TABLE ent
スキーマ不定のデータをRDBに永続化する方法の比較 — ありえるえりあ
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
[ThinkIT] 第10回：メモリ管理で安定稼動 (1/3)
一般に、データベースサーバにおいて、ページキャッシュ（ファイルキャッシュ）を管理することは、性能上あるいはシステム安定稼動の観点から重要です。 今回は、DB2がオンライン処理を実行中に、大規模ファイルアクセス（読み取り、書き込み）を伴う処理が実行される場合のメモリ管理を取り上げます。具体的には、Linuxページキャッシュ（ファイルキャッシュ）が大量に確保され、そのかわりにDB2のメモリがスワップされて、DB2がスローダウンしてしまうようなことを回避する方法について検討します。 DB2が利用するメモリは、そのパラメータ構成により上限のサイズを決めることができます。一方のLinux側におけるページキャッシュの最大利用量は、指定する方法がありませんので（Linuxソースコードを自身で修正することを除き）、一般的な対応方法としては以下のようなものが考えられます。 Linuxカーネルパラメータでの対
スワップサイズをゼロにしてはいけない
先月発売された書籍「Linux-DBシステム構築/運用入門」は、なかなか上々の売れ行きとなっているようです。Amazonではしばらく「1-2ヶ月待ち」の状態が続いてしまっていたのですが、最近になってようやく解消され、容易に入手できるようになっているようです。Amazonの在庫切れ問題がひと段落したところで、これからは書籍のサポート的な情報を書いていくことにします。 まず、本書を購入された皆さまありがとうございました。結構な数の方がBlogやTwitter等で、この本をほめてくださっていることに大変感謝しています。まだ本自体の認知度が低い(存在自体を知らない顧客も多い)ので、普及活動をしつつ、これからも読者の期待に応えられる記事を書いていきたいと思っています。 最初は、よく見かけることの多い「メモリ管理」の話題を取り上げようと思います。第12章では、メモリ管理とスワップ領域に関する解説をして
新書籍「Linux-DBシステム構築/運用入門」
Linux上で「高速で、落ちない」DBサーバーを構築するための技術解説をした書籍を出版します。タイトルはストレートに「Linux-DBシステム構築/運用入門」です。 9月17日発売ですが、ジュンク堂など一部の書店ではすでに入荷しているそうなので、見かけたらぜひ読んでみてください。章構成は以下の通りです。 第1章 論理ボリュームマネージャ(LVM)を活用する 第2章 Heartbeatによるクラスタ環境の構築 第3章 DRBDによるネットワークミラーリング(前編) 第4章 DRBDによるネットワークミラーリング(後編) 第5章 高可用DBサーバーの構築 第6章 現場で使われる高可用構成 第7章 DBサーバーのパフォーマンス概論 第8章 インデックスのチューニング(前編) 第9章 インデックスのチューニング(後編) 第10章 DBサーバーのハードウェア選定 第11章 SSDの効果とアプリケーシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
サービス終了のお知らせ
H2 Database Engine