トップ  > メモ一覧  > カテゴリ「DB一般知識」の絞り込み結果 : 4件

4件中 1 〜 4 表示  1 

No.1811【引用】高度に進化した分散データストアはRDBMSと見分けがつかない?(shibuya.pm#12スライド)

高度に進化した分散データストアは RDBMS と見分けがつかない? (shibuya.pm #12 スライド)

 昨日開催された shibuya.pm #12 - NoSQL特集 で使用したスライドを slideshare にアップロードしました。
高度に進化した分散データストアについて

View more documents from kazuho .

 開発しているシャーディングミドルウェアである Incline と Pacific については YAPC::Asia 2009 を始めいろいろな所で話をする機会をいただいてきたので、今回は、 なぜ RDBMS ベースのア...

引用元

更新:2009/12/03 10:10 カテゴリ: MySQL  > DB一般知識 ▲トップ

No.1434 MySQL5.1は次のストレージエンジンをサポートします。

MySQL 5.1は次のストレージエンジンをサポートします。

  • MyISAM —デフォルトのMySQLストレージエンジンと、ウェブ、データウェアハウス、そしてその他のアプリケーション環境で一番利用されるストレージエンジンです。MyISAMは全てのMySQLコンフィギュレーションの中でサポートされています。そして、MySQLに他のストレージエンジンを設定しない限り、これがデフォルトとして利用されます。

  • InnoDB — トランザクションプロセスアプリケーションに利用され、ACIDトランザクションサポートや外部キーなどを含む、複数の特徴をサポートします。InnoDB は全てのMySQL 5.1 バイナリディストリビューションの中にデフォルトとして含まれています。ソースディストリビューションの中では、好きなようにMySQLを設定する事によって、エンジンを有効にも無効にもできます。

  • Memory — 参照事項や迅速なデータ検索を必要とする環境で、きわめて高速なアクセスで全てのデータをRAMの中に格納します。このエンジンは以前は HEAP エンジンとして知られていました。

  • Merge — MySQL DBAや開発者が、一連の同一 MyISAM テーブルを論理的にグループ化し、それらを1つのオブジェクトとして参照付ける事を可能にします。 VLDB データウェアハウスと同じで、VLDBに効果的です。

  • アーカイブ — サイズが大きいほとんど参照されない履歴、アーカイブ、セキュリティ監査情報を格納したり、検索する為の完璧な解決法を提供します。

  • Federated — いくつもの物理的サーバーから、別々のMySQLサーバーをリンクさせて1つの論理データベースを作成する能力を提供します。 分散、またはデータマート環境に大変効果的です。

  • NDB — 高い検索機能と、できるだけ長い稼働時間を必要とするアプリケーションにぴったりな、クラスタ化されたデータベースエンジンです。

  • CSV — ストレージエンジンはコンマ区切りの値を使ったフォーマットでデータをテキストファイルに保存します。CSV エンジンは、 CSVフォーマットにインポート・エクスポートする事ができる他のソフトやアプリケーション間でデータを簡単に交換する為に利用する事ができます。

  • Blackhole — ブラックホールストレージエンジンはデータの受け入れはしますが、格納はせず、検索しても結果は得られません。 この機能性は、データが自動的に複製される分散型のデータベースデザインの中で利用できますが,局所的に格納はされません。

  • Example — このストレージエンジンは 「スタブ」 エンジンで実装されており、何の機能も持ちません。このエンジンを利用してテーブルを作成できますが、データの格納も検索もできません。このエンジンの目的は、MySQL ソースコードの中で新しいストレージエンジンを作成する方法を説明する為の、見本の役割を果たす事です。それ自体は、ソフトウェア開発者向のものです。

引用元

更新:2009/09/04 08:32 カテゴリ: MySQL  > DB一般知識 ▲トップ

No.1395 米大統領選でMySQLはどのように使われたのか

米大統領選でMySQLはどのように使われたのか

 日本の衆議院選挙が間近に迫っていますが、昨年米国で行われた大統領選において、オバマ陣営がIT技術を駆使したという話はよく知られています。 MySQLももちろん使われていました。今年4月にサンタクララで開催されたMySQL Conference & Expo 2009というイベントでは、最終日のキーノートにおいて、Obama Tech Teamの方々より、大統領選においてMySQLがいかに使われたかという発表が行われました。
本当はカンファレンス終了後にすぐちゃんとしたレポートを書いて公開する予定だったのですが、その週に起こった草なぎ剛逮捕とか、そのほかの出来事にすっ かり気を取られて放置していました。Blogを始めた契機にTwitterの中で興味を持っている方がいるかどうか聞いたところ、そこそこの方が興味を示 したので、ここで簡単にまとめたメモを公開することにします。


●チームメンバー
発表者は以下の5人で、ほか何名かでチームを構成。
Chuck Hagenbuch (Blue State Digital)
Leigh Heyman (Blue State Digital)
Stephen Gunn (Google)
Mikey Dickerson (Google)
Ian Gulliver (Google)
(Google社内のメーリングリストなどでボランティアの公募があって、それに乗る形で参加されたそうです)

●主なミッション
▲Fundraising(資金調達)
・インターネット経由で資金調達できる仕組みの整備
・当初の目標は$290Mの調達
・実際には$500M以上(当時の為替レートで550億円くらい)を調達することができた

▲大量のeメールの送信(購読者に応じて内容を変える)
・当初の目標は500-600万人の購読者に対して計2億5000万通程度のメール送信をすること
・実際には購読者は1300万人に達し、計20億通のメールを送信
(日本だと公職選挙法で選挙期間中のメール配信とかは違法になると思うのですが、米国ではセーフらしいです)

▲Webサイトの整備
・当初の目標は秒間800PVをさばくこと
・実際には最高で秒間4300に達した(2008年10月29日)

●インフラ設計
▲ハードウェア
・Dell 2950 w/ Disk Array (x2)
・Amazon EC2も併用したが、大事なところでは使わなかった。選挙日に2時間止まったりしたらどうしようもないので
(今のEC2のサービスレベルを見ると99.95%保証のようです。大統領選のような「特定の時間帯は絶対に動いている必要がある」というタイプのサービスではまだ厳しいのではないでしょうか)

▲MySQL
・最初はMyISAMのみ。レプリケーション使用、mysqldumpでバックアップ。
・データ量の増加に対してバックアップが追いつかなくなった。
・データ量は5TBを超えた。論理バックアップでは新規レプリカの作成にも数日単位でかかった。
・物理バックアップに移行(ファイルシステムスナップショット。おそらくflush tables with read lock + tar)。
・テーブルロックによって夜間バッチジョブが動かなかった
・結局ロックが深刻になりすぎたので、中心的なトランザクショナルなテーブルをInnoDBにした


●テーブル/データ設計

▲有権者の行動をトレースするための仕組み
・有権者がどこで何をしたかという情報を蓄積して選挙活動に活かす
・キャンペーンのe-mailは、全員に同じ内容が届くわけではない。有権者が過去に何をしたかによってグループ分けをしていて、グループごとに内容が違う。(過去に1回でもオバマ陣営のボランティアをしたか、まったくしていないかとか)
・「AとBをした人にメールを送りたい」という要求があったときに
行動Aに関するテーブル
行動Bに関するテーブル
を管理して、それぞれで1300万人の購読者を保持したらレコード数が膨大になってしまう。
・ 「デフォルト行動」を定義して、デフォルトでない行動をした人の情報だけをテーブルで持つようにした。例えばAをした人よりもしていない人の方が圧倒的に 多ければ、Aをしていない人のレコードだけを格納する(Bも同様)。「Aをした人 and Bをした人」は、全体から「Aをしていない人 or Bをしていない人」を引いたものと同じだが、この場合は後者の方が処理効率が良い
・これでレコード件数を減らすことができ、パフォーマンスが上がった

▲有権者情報の検索処理
・MyISAMではロック競合が深刻だったのでInnoDBにした。
・InnoDBにしたことでCOUNT(*)に時間がかかるようになった
・AUTO_INCREMENT列に対してMAX関数を使うことで、最大値を取るようにした。最大値=件数という想定
・誰か(開発者)がテスト用に巨大な値をセットしたら、値が本来の値(件数)ではなくなってしまった。
・AUTO_INCREMENTは再起動かALTER TABLEをしないと戻らないのでmaxは使えなくなった(ダウンタイムを設けることができない状況)
・サマリーテーブルに件数情報を書くようにした。ある一定のタイミングで、最新の件数をサマリーテーブルに書き出すようにして、高速に件数を取れるようにした
・MyISAM→InnoDBによってデータ量が増えたので、広範囲にまたがる集計系処理にかなりの時間がかかるようになった
・リアルタイム性の求められない処理だったので、同一テーブルのコピーをMyISAMで作成し、そのMyISAMテーブルに対して集計処理を行うことで高速化した

▲大量のeメールの送信履歴管理
・メールの送受信情報を記録する要求がある
・1時間に200万通を送る必要があり、その履歴も管理
・MyISAMテーブルを使用
・テスト環境では100万件の登録に2分だったが、本番環境では1時間かかった
・テスト環境では空だったのが、本番環境では既存のレコードが多いのが原因
・できるだけ空のテーブルにINSERTさせるように設計変更した
・MyISAMテーブルを複数用意して、日付で分割、空のMyISAMテーブルにINSERTさせる
・これらをMERGEテーブルとして結合
(本番環境でINSERTに長時間を要したのは、インデックスの影響と考えられます)


▲重いバッチ処理によってマスターがスローダウンする
・バッチ処理の中で、重たいSELECTをスレーブで行って、最終結果をマスターに書くようにした


▲Early Vote (期日前投票)推進
・有権者の行動をいち早く分析して、支持者に早期に期日前投票に行くように促す仕組み
・「どの日に、どの週で、どの政党に、どの性別の人が、何秒投票し、平均年齢は何歳で...」といった情報を解析したい
・もともとは各テーブルに行動情報を蓄積して、7テーブルくらいをジョインして結果を返していた
・4000秒以上かかっていた
・日ごとに集計するのが分かっていたので、日を切り口にしたサマリーテーブルを導入。秒単位で結果を返せるようになった




●感想
発表者たちの主な活動期間は、2008年9月中旬頃から11月までだったそうです。極めて限られた期間の中では、事前に練りに練ったMySQLアーキテク チャ構成を元に型にはめていくというアプローチが難しかったようで、かなりの試行錯誤を繰り返しながらそれでもなんとかなった、という感じで生々しい話で した。Early Voteを強力に推進したことが大統領選勝利の大きなポイントだったというニュースは日本にも伝わってきましたが、それを裏方で支えていたのは、必要な情 報を正しく迅速に取れるための仕組みであり、そのためのデータモデルであったということを強く感じました。個々のテクニックはよく知られたものばかりです が、それを適切に組み合わせられるのは経験と技術あってのものですし、適切なスキルがあればOSSでもこうした重要なシステムを安定稼動できる(逆に無け れば商用製品でも困難)、ということを示す良いキーノートだったと思います。
このエントリーを含むはてなブックマーク

引用元

更新:2009/08/28 08:21 カテゴリ: MySQL  > DB一般知識 ▲トップ

No.1344 分離レベル

分離レベル

分離レベルとは、データの一貫性を保つために、データベー スシステムに組み込む特別なロックの仕組みです。分離レベルが高いほど、そのロック方法も複雑になります。データベースで使用される分離レベルによって、 データの一貫性に関連する次の事象がトランザクションで発生するかどうかが決まります。

表 B-1
データ読み取りの行為
Dirty reads
(ダーティー リード)
ユーザー 1 が、行を変更します。ユーザー1 がコミットする前に、ユーザー 2 が同じ行を読み取ります。ユーザー 1 がロールバックします。ユーザー 2 は、実際にはデータベースに存在しない行を読み取ったことになります。これによって ユーザー 2 は誤ったデータに対して判断を下すことになるかもしれません。
Non-repeatable reads
(反復不可能な読み取り)
ユーザー 1 が行を読み取りましたがコミットしません。ユーザー 2 がその同じ行を修正または削除し、それをコミットします。ユーザー 1 がもう一度同じ行を読み取ったときは、その行が変更または削除されています。
Phantom reads
(ファントム リード)
ユーザー 1 は、検索条件を使用して複数行のセットを読み取りましたがコミットはしません。ユーザー2 がこの検索条件を満たす行を挿入し、コミットします。ユーザー 1 が検索条件を使ってもう一度読み取ったときには、前になかった行が存在することになります。

 

分離レベルとは、データベース システムで、上記の事象が発生するのを防げるかどうかを示すレベルです。ANSI(American National Standards:米国規格協会)によって、次の 4 つの分離レベルが定められています

      • Read uncommitted (0) (コミットされていない読み取り)
      • Read committed (1) (コミットされた読み取り)
      • Repeatable read (2) (反復可能な読み取り)
      • Serializable (3) (直列化可能)

0 から 3 へとレベルが高くなるほど、トランザクションのデータの一貫性も高くなります。一番低いレベルでは、上の 3 つの事象がすべて発生する可能性があります。一番高いレベルでは、どの事象も発生しません。このような事象が発生するのを防げるかどうかは、各レベルで使 う、次のようなロックの仕組みによって決まります。

表 B-2
分離レベル
Read uncommitted (0)
(コミットされていない読み取り)
データベースを変更するときにロックがかかり、トランザクションの終わり(EOT)まで維持されます。データベースの読み取りには、ロックがかかりません。
Read committed (1)
(コミットされた読み取り)
データベースの読み取りと変更時にロックがかかります。読み取り後にロックは解除されますが、変更されたオブジェクトのロックは EOT まで維持されます。
Repeatable read (2)
(反復可能な読み取り)
データベースの読み取りと変更時にロックがかかります。変更されたすべてのオブジェクトのロックは EOT まで維持されます。データの読み取りロックは、EOT まで維持されます。変更不可能なアクセス構造(インデックスおよびハッシュ構造など)のロックは読み取り後に解除されます。
Serializable (3)
(直列化可能)
DataSet の影響を受ける行に、EOT までロックがかかります。変更されたアクセス構造、およびクエリで使われた構造がすべて EOTまでロックされます。

 

B-3 では各分離レベルにおいて発生するデータ一貫性の事象を示します。

表 B-3
分離レベルとデータの一貫性 

レベル
Dirty Read
(ダーティー リード)
Nonrepeatable Read
(反復不可能な読み取り)
Phantom Read
(ファントム リード)
0, Read uncommitted
(コミットされていない読み取り)
1, Read committed
(コミットされた読み取り)
不可
2, Repeatable read
(反復可能な読み取り)
不可
不可
3, Serializable
(直列化可能)
不可
不可
不可

 

分離レベルが高いほど、データの一貫性が高くなりますが、逆に、個々のユーザーの同時処理性は低くなります。同時処理とは、複数のユーザーが同時にデータにアクセスして変更することです。分離レベルが上がるに従って、使用されるロック制御が原因で、同時処理上の問題が発生する確率が高くなります。

検討事項分離レベルが高くなるほどロック制御が厳 しくなり、ユーザーが、別のユーザーによってかけられたロックが解除されるのを待つ時間が長くなります。分離レベルと同時処理性には、このような逆比例的 な関係があるので、分離レベルを選択する前にユーザーがデータベースをどのように使用するか検討しておく必要があります。データの一貫性と同時処理性のど ちらがより重要かを考慮して、使用する分離レベルを決めてください。

引用元

更新:2009/08/20 09:35 カテゴリ: MySQL  > DB一般知識 ▲トップ
4件中 1 〜 4 表示  1 

FuelPHP

Mac

フロントエンド開発

web開発

プロマネ

マネタイズ

プレゼン

webサービス運用

webサービス

Linux

サーバ管理

MySQL

ソース・開発

svn・git

PHP

HTML・CSS

JavaScript

ツール, ライブラリ

ビジネス

テンプレート

負荷・チューニング

Windows

メール

メール・手紙文例

CodeIgniter

オブジェクト指向

UI・フロントエンド

cloud

マークアップ・テキスト

Flash

デザイン

DBその他

Ruby

PostgreSQL

ユーティリティ・ソフト

Firefox

ハードウェア

Google

symfony

OpenPNE全般

OpenPNE2

Hack(賢コツ)

OpenPNE3

リンク

個人開発

その他

未確認

KVS

ubuntu

Android

負荷試験

オープンソース

社会

便利ツール

マネー

Twig

食品宅配

WEB設計

オーディオ

一般常識

アプリ開発

Python

サイトマップ

うずら技術ブログ

たませんSNS

rss2.0