データベース入門入門データベース入門入門

奥野 幹也@nippondanjimikiya (dot) okuno (at) gmail (dot) com

@qpstudy 2013.07

ゼロからデータベースをはじめるあなたに。

免責事項

● 本プレゼンテーションにおいて示されている見解は、私自身の見解であって、オラクル・コーポレーションの見解を必ずしも反映したものではありません。ご了承ください。

自己紹介

● MySQLサポートエンジニア– 2000年にサン・マイクロシステムズ入社

● 主にハードウェアのサポートを担当– 2007年にMySQL KKへ転職

● 気付くとまたサン・マイクロシステムズに・・・– 現在は日本オラクルに在席。– サポート一筋 13年

● 日々のしごと– MySQL トラブルシューティング全般– Q&A回答など

自己紹介（つづき）

● ライフワーク– 自由なソフトウェアの普及

● オープンソースではない– GNU大好き

● リチャード・ストールマン氏の教えに従って最近脱Ubuntuしました。

– KDE大好き● ブログ

– 漢のコンピュータ道– http://nippondanji.blogspot.com/

データベースの意義

データベースの必要性

● 大量のデータを安全かつ高速に処理する– 必要なデータを検索する– データを保全する– 素早い応答を得る

● アプリケーションからデータを扱う処理の実装を排除することができる。

– 車輪の再発明の回避– アプリケーションのロジックに集中– 開発効率の向上 すごく

便利です。

インデックス

インデックスは便利！

● 必要なデータだけをピンポイントでゲット！– B+木なら探索の計算オーダーは最悪でも O(logbn)– キャッシュにページが乗ってれば更に高速

● 範囲検索でも使える● ソートでも使える● 多種多様なインデックス

– B+木– ハッシュ– 全文検索– 空間インデックス

大量のデータでもどんと来い！

トランザクション

トランザクションの至上命題

同時実行制御

リカバリ

ACID

Atomicity

Isolation

Consistency

Durability

Atomicity （原始性）● すべての操作は成功または失敗

– Commit– Abort

● アプリケーションは中途半端な状態について考慮する必要がない

– エラー処理は単にトランザクションをやり直すだけ– リトライは必要

Consistency （一貫性）● トランザクションの前後でデータベースの整合性が保たれている。

● ある整合性のとれた状態 Aにおいてトランザクションを実行すると、別の整合性のとれた状態 A’へと遷移する。

● 何をもって整合性がとれているとするかはアプリケーション次第

ATrx

A’

Consistent!Consistent! Consistent!

Isolation （独立性）● あるトランザクションが他の実行中のトランザクションの実行過程へ影響を及ぼさないこと。

● 同時実行制御の課題。● 分離レベル

– Read Uncommitted– Read Committed– Repeatable Read– Serializable

Durability （永続性）● 一度 Commitが成功すれば変更は失われない● リカバリの話。

トランザクションは便利！

● アプリケーションの開発がとても楽に。– データへの排他処理から開放される– クラッシュしてもデータの整合性を気にする必要がない

● Commit/Abortのいずれかの状態– 中途半端な状態について考える必要がない

● 成功してなければリトライ

全部自分で実装しますか？

インデックスやトランザクションだけで満足してませんか？

単なるデータの入れ物として使っていませんか？

残された課題データモデル

RDBMS以前● 利用されていたデータモデル

– 階層型– ネットワーク型

● トランザクションやインデックスは利用可能● クエリの記述が大変

– データの構造に依存したプログラム

優れたデータモデルが必要！

● データベース設計超重要– クエリとデータベース設計はセットで考える

● ⇒クエリ 演算● ⇒データベース データ

– オブジェクト指向のオブジェクトとメソッドのような関係● クラスの設計超重要

「データベース＝単なる入れ物」からの脱却

RDBMS登場！！後半へつづく。

Q&A!!ご静聴ありがとうございました。