実務で役立つデータベースの活用法

実務で役立つ！データベースの活用法オープンセミナー2015＠香川

What is it?

データベースは何を基準に選んでますか？

What is it?利用するデータベースを

正しく選ぶこと

はプロジェクトの成功にとても大切です

What is it?

しかし、時代は大NOSQL時代

What is it?RDBすら多いのに…

NOSQLって何よ…

どれがいいのよ…







What is it?そう言ったお悩みに

種類別データベースの活用方法

を今日は発表します

What is it?ただし

チューニングやDB設計

の話は今日はしません

What is it?

主にデータベースの選び方の話です

What is it?

正しいDB選択で

未来の自分を助ける

方法を説明します

あじぇんだ

１　自己紹介２　データベースの種類と特徴３　データベースの選び方４　まとめ

あじぇんだ


自己紹介名前：曽根　壮大（そね　たけとも）年齢：３０歳（三人の子供がいます）職業：Webエンジニア

所属：日本PostgreSQLユーザ会

　　　中国支部支部長

　　技術的にはLL系言語とかRDBが好きです

https://dbstudychugoku.github.io/

https://dbstudychugoku.github.io/

あじぇんだ


データベースの種類と特徴

RDBとNOSQL

アーキテクチャーーーーーーーデータモデル

マスタ型 P2P型その他

リレーショナル RDB全般 pgpool2など

キーバリュー Hibari Dynamo Riak

Memcached Redis

カラム指向 Bigtable HBase

Cassandra

ドキュメント指向 MongoDB CouchDB

グラフ指向 Neo4J InfiniteGraph





Memcached Redis


Cassandra



データベースの種類と特徴RDB

リレーショナルデータモデルの理論に基づいたDBMSで現在もっとも広く使われているデータベースシステム

データベースの種類と特徴NOSQL（Not Only SQL）

RDB以外のDBシステムの総称グラフデータモデルなどのリレーショナルモデル以外のサポートなどRDBが不得意な分野に特化している


ACIDとCAP定理とBASE


ACID

データベースの種類と特徴ACID

関連する複数の処理を一つの処理単位にまとめて管理するトランザクション処理に求められる4つの特性


• 原子性（Atomicity） • 一貫性（Consistency） • 独立性（Isolation） • 永続性（Durability）



Atomicity（原子性）とは、トランザクションに含まれる個々の手順が

　　「すべて実行される」か「一つも実行されない」

のどちらかの状態になるという性質



Consistency（一貫性）とは、トランザクションの前後でデータの整合性が保たれ、

矛盾の無い状態が継続される性質



Isolation（独立性）とは、トランザクション実行中の処理過程が外部から隠蔽され、

他の処理などに影響を与えない性質



Durability（永続性）とは、トランザクションが完了したら、

その結果は記録され、失われることがないという性質


CAP定理

データベースの種類と特徴CAP定理

Webサービスを想定して作られた分散化データベースの定理全てを完璧に満たすことができず、いずれかに偏る形でしか出来ない


• 整合性 (Consistency) • 可用性 (Availability) • 分断耐性 (Partitions)



整合性 (Consistency)とは、全てのクライアントが常に同一のデータを見る性質



可用性 (Availability)とは、全てのクライアントが読み出しと書き込みが出来る性質



分断耐性 (Partitions)とは、物理ネットワークが分断されても間違った結果が発生しない性質


A：可用性C：整合性

P：分断耐性



P：分断耐性

CA型

PostgreSQL、MySQLなど（RDB全般）



P：分断耐性

Dynamo、Cassandraなど

AP型



P：分断耐性

MongoDB、Redisなど

CP型


BASE

データベースの種類と特徴BASE

整合性(C)と分断耐性(P)を重視した場合はACIDを満たす必要があるしかし整合性(C)よりも可用性(A)と分断耐性(P)を重視する場合はBASEを満たす必要がある


ACID(CP型)とBASE(AP型)


• Basically Available • Soft-State • Eventual Consistency



どんな時でもアプリケーションが動く



常に整合性を保つ必要がない



結果として整合性が取れる状態に至る


アーキテクチャ


アーキテクチャ ↓

ACIDやBASEをどのように実現するか


アーキテクチャ ↓

マスタ型とP2P型

データベースの種類と特徴マスタ型

マスタ

スレーブスレーブスレーブ

データベースの種類と特徴マスタ型

• RDB • MongoDB • Bigtable • HBase　…など

データベースの種類と特徴P2P型

マスタ

マスタ

マスタ

マスタ

データベースの種類と特徴P2P型

• Cassandra • Dynamo • Riak • Voldemort　…など


データモデル


データモデル ↓

どのようなデータを扱うか

データベースの種類と特徴データモデル

• リレーショナル • キーバリュー • カラム指向 • ドキュメント指向　…など





RDBの元となるデータモデル集合と関連でデータを表現する

データベースの種類と特徴リレーショナル

user_id name1 hoge2 fuga3 bar4 foo

role_id name1 開発部2 営業部3 運用部4 総務部

user_id role_id1 11 33 24 4

データベースの種類と特徴リレーショナル

user_id name1 hoge2 fuga3 bar4 foo

role_id name1 開発部2 営業部3 運用部4 総務部

user_id role_id1 11 33 24 4

集合を定義する

関係を定義する





KeyとValueの組み合わせでデータを表現するシンプルな構造なのでスケールアウトに適している

keyとvalueが1対1

データベースの種類と特徴キーバリューkey value1 hoge2 fuga3 bar4 foo5 test6 花子7 一太郎8 三四郎

データベースの種類と特徴キーバリューkey value1 hoge2 fuga3 bar4 foo5 test6 花子7 一太郎8 三四郎

1:1の関係を保持する





キーバリュー型を拡張して行とカラムの概念を追加 RDBのテーブルに似ているがカラムは事前に定義しない

keyに対してvalue（カラム）が1対多も可能

データベースの種類と特徴カラム指向

key name 所属所属2 年齢1 hoge 開発運用 302 fuga 営業 253 bar 総務運用 224 foo 運用 355 test 開発 426 花子デザイン運用 257 一太郎ドキュメント開発 258 三四郎表計算総務 25

データベースの種類と特徴カラム指向

key name 所属所属2 年齢1 hoge 開発運用 302 fuga 営業 253 bar 総務運用 224 foo 運用 355 test 開発 426 花子デザイン運用 257 一太郎ドキュメント開発 258 三四郎表計算総務 25

1:Nの関係を保持する





階層構造を持たず、ドキュメントそのものを保持するドキュメントにはユニークなIDが振られるスキーマレスなので柔軟な変更が可能

データベースの種類と特徴ドキュメント指向

“name” : “hoge” “role1” : 開発 “role2” : 運用 “age” : 30

“name” : “fuga” “role1” : 営業 “from” : 広島 “age” : 25

“name” : “bar” “role1” : 総務





それぞれが独立したドキュメントドキュメントにはユニークなIDでアクセスが可能





それぞれが独立しているので自由な変更が可能





他にもグラフ型やツリー型など多種多様にある


これらの組み合わせでデータベースの種類と特徴が決まる





Memcached Redis


Cassandra



あじぇんだ


データベースの選び方ドメインに合わせて選ぶ

ACIDの必要性、CAP定理の条件でどれが必要か考えて選択肢を選ぶ

データベースの選び方

RDBは多くのデータに対応している


しかしRDBは万能ではない


NOSQLは目的を絞り込んだDB


まずはRDBで検討する ↓

その後、不足をNOSQLで補う


RDBで問題なければRDBのみ


RDBで問題なければRDBのみ ↓

無理にNOSQLを使わない


RDBも要件によって選ぶ

データベースの選び方SQL Server

• 開発環境(VS,C#など)の連携が強力 • 標準的な機能の多くをサポート • GUIツールが便利

データベースの選び方Oracle

• Active - Activeな構成が可能(RAC) • 独自・標準的な多くの機能 • GUIやサードパーティが充実 • 強力なOracleサポートチーム(有償)

データベースの選び方MySQL

• レプリケーションが柔軟で強力 • 自動フェイルオーバー完備 • 高速なコネクション(multi Thread) • OSSなサードパーティが充実 • SSDと相性が良い

データベースの選び方PostgreSQL

• Oracleにも負けない豊富な機能 • 企業に属さない中立なOSS • コミュニティを含めたサポート • OSSなサードパーティが充実


デメリットも見る

データベースの選び方SQL Server

• 商用なので有償 • スケールアウトが苦手 • MS以外の環境でメリットが少ない • CUIの連携が少ない

データベースの選び方Oracle

• 商用なので有償(しかも高い) • 行連鎖や行移行など設計が難しい • サードパーティが有償(しかも高い) • ORA-00600のトラウマ

データベースの選び方MySQL

• 実装されてない機能がある Window関数が無いマテビューがない等 • ギャップロック • 相関サブクエリが苦手(遅い)

データベースの選び方PostgreSQL

• 追記型の制約(VACUUM、HOT等) • SSDにしても劇的な高速化はしない • GUIが弱い(設定を含め、CUIベース) • デフォルトがdataチェックサム無効そもそも9.3以上の機能


RDBで解決できない問題


RDBで解決できない問題 ↓

それをNOSQLで解決する

データベースの選び方RDB全般の問題

• 大量のデータを処理(ビックデータ) • DBの水平拡張(スケールアウト) • 多種多様なデータモデル対応



データベースの選び方大量のデータを処理

• テラやペタ級を処理 • それを高速に処理 • 結果を高速に表示　…など




キーバリュー HibariDynamo Riak

Memcached Redis

カラム指向 Bigtable HBase Cassandra







Memcached Redis




大量のデータから高速に結果を場合





Memcached Redis




結果のみを高速に返す場合





Memcached Redis




大量のデータを集計する場合

データベースの選び方大量のデータを処理

PaaS(クラウド)がマッチしやすい・BigQuery ・RedShift ・TreasureData

データベースの選び方高速に処理

キャッシュのようにKVSを使う・Memcached ・DynamoDB ・Redis



データベースの選び方DBの水平拡張(スケールアウト)

• 参照の負荷分散 • 更新の負荷分散 • 可用性の確保　…など





Memcached Redis


Cassandra



RDBでも出来るが高速ではなかったり、

サードパーティが必要だったりする





Memcached Redis


Cassandra



Dataは分散するが偏ったアクセスなどは分散しない場合も多い





Memcached Redis


Cassandra



MongoDBはマスタ型だか自動フェイルオーバーするので要件によってはマッチする


• RDBでも可能シャーディングやレプリケーション・負荷の予測と分散化が難しい・RDBよりも簡単にNOSQLで行う


• NOSQLは弱い整合性が多い(AP型) • データにリアルタイム性が不要な場合がにマッチする(履歴ログなど）

• データの一貫性が不要な場合もマッチする(ブログなど)







Memcached Redis








Memcached Redis




JSONなど非構造化データを格納最近、PostgreSQLやMySQLも対応してきた領域





Memcached Redis




グラフ型はRDBが苦手なデータモデルの最たる例 RDBでは難しいデータ構造の表現を可能にする

データベースの選び方多種多様なデータモデル対応

• リレーショナルモデルで表現出来ないデータ構造は無理しない無理に表現すると問題の原因になる • データモデルが違う場合、お互いのデータ利用にインターフェイスが必要多くの場合はプログラムが結合する

あじぇんだ


まとめ

データの寿命はコードより長い

まとめ

一度作ったデータは変更が難しい

まとめ

一度作ったデータは変更が難しい ↓

ソフトウェアの選択が大事

まとめ

長所と短所を把握する

まとめ

長所と短所を把握する ↓

苦手なことをさせない

まとめ

ACIDとCAP定理で比較する＋

データモデルと要件を比較する

まとめ

データモデルとソフトウェアの特性を理解する

まとめ

リレーショナル・データベース

まとめ

リレーショナル・データベース ↓

グラフやツリーを表現させない

まとめ

ACIDを担保してないNOSQL

まとめ

ACIDを担保してないNOSQL ↓

お金の管理や集計をさせない

まとめ

インフラをデザインする ||

得意分野を組み合わせる

まとめ

適切な設計は適切な拡張を生む

まとめ

適切な設計は適切な拡張を生む ↓

Scale UpやScale Outを可能にする

まとめ

データの寿命はコードより長い

大事なことなので二回（ｒｙ

まとめ

オススメの書籍

まとめ

まとめ

まとめ

まとめ

“もし現在のアプリケーションがRDBで上手く動いているのであれば、

それをNOSQLに置換する理由は無いし、それを勧めたりはしない”

Nate McCall(@zznate)

ご静聴ありがとうございました。

Technology

実務で役立つデータベースの活用法