7つのデータベース7つの世界
7つのデータベース7つの世界
- 作者: Eric Redmond,Jim R. Wilson,角征典
- 出版社/メーカー: オーム社
- 発売日: 2013/02/26
- メディア: 単行本（ソフトカバー）
- 購入: 3人 クリック: 56回
- この商品を含むブログ (15件) を見る
NoSQLを使う場面とは？ということに悩んだので、読んでみた。 正直、PostgreSQLさえあればなんでも出来そうって気になってきた。 第6章まで。
第1章 イントロダクション
- リレーショナルデータベース
- キーバリューストア
- Raik
- Redis
- 列指向データベース
- HBase
- ドキュメント指向データベース
- MongoDB
- CouchDB
- グラフデータベース
- Neo4j
- ポリグロット（混合型）
- 複数のデータベースの長所を組み合わせてエコシステムを構築
第2章 PostgreSQL
- 普及の要因
- データの安全性（ACID準拠）
- マインドシェア
- クエリの柔軟性
- 正規化による柔軟な問い合わせ
- PostgreSQL
- 数学的リレーション
- リレーション（テーブル）
- 属性（列）
- タプル（行）
- CRUD
- Create
- Read
- Update
- Delete
- インデックスで高速検索
- Bツリーインデックス
- ハッシュインデックス
- 集約関数
- グループ化
- MySQL では GROUP BY にない列を SELECT できる
- いずれかの結果を返すので信頼性がない
- PostgreSQL も v9.1 から PostgreSQL 9.1 の新機能 — Let's Postgres http://lets.postgresql.jp/documents/technical/9.1/1
- MySQL では GROUP BY にない列を SELECT できる
- ウィンドウ関数
- 複数の行に対して集約関数を実行
- 行をグループ化することなく集約関数を使える
- トランザクション
- ストアドプロシージャ
- 恐怖のベンダーロックイン
- コードはアプリケーションに依存するのか？データベースに依存するのか？
- トリガー
- ビュー
- ルール
- クロス集計
- あいまい検索
- LIKE、ILIKE
- 正規表現
- レーベンシュタイン
- トリグラム
- TSVevtor, TSQuery
- 汎用転置インデックス GIN
- メタフォン
- 多次元ハイパーキューブ
- PostgreSQL の強み
- リレーショナルモデルと同じく膨大
- 長年の研究
- あらゆる計算分野における利用実績
- 柔軟なクエリ
- 高い整合性と永続性
- 実践で使い込まれた各言語用のPostgres用のドライバ
- PostgreSQL の弱み
- 分割がうまくできない
- スケールアップ、スケールアウト
- データが柔軟過ぎる場合
- 分割がうまくできない
第3章 Raik
- 分散型キーバリューデータベース
- プレインテキスト・JSON・XML・画像、動画などHTTPインターフェイス経由でアクセスできればなんでも
- 耐障害性
- アドホッククエリを十分にサポートしていない
- 低レイテンシーで大量のリクエストをさばくDCに最適
- Amazon の Dynamo 論文から着想
- データの検索方法 mapreduce
- Erlang が必要
- cURL
- リンク
- キーと別キーを関連付けるメタデータ
リンクウォーキング
MIME タイプ
- バイナリデータには MIME タイプで情報を付加
- mapreduce
- ストアドファンクション
- キーフィルタ
- 整合性と永続性
- アーキテクチャレベルで単一障害点を排除
- Riak リング
- 書き込みに永続性がない（デフォルトでは）
- DW という永続性が高い書き込み設定を用意している
- ベクタークロック
- 事前/事後コミットフック
- 全文検索
- HTTP Solr インターフェイス
- Riak の強み
- 大規模
- 可用性
- 言語サポート
- Riak の弱み
- 単純なクエリ
- 複雑なデータ構造
- 厳格なスキーマ
- 水平スケーリングが不要
HBase
- RDBMS の双子の悪魔
- 他のDBにない機能
- バージョニング
- 圧縮
- GC
- インメモリテーブル
- Apache Hadoop の contrib パッケージとして生まれたが、今はトップレベルプロジェクト
- Facebook、Tiwtter でも利用
- 本番の品質で運用するには最低5台以上のノードが必要
- 3つのモード
- HBaseシェル
- 列ファミリーを変更する操作はコストが高い
- 新しい設定の列ファミリーを作って、すべてそこにコピーするから
- 列ファミリーを使うことにより細かなパフォーマンスチューニングが可能となる
- 圧縮
- Gzip(GZ)
- Lempel-Ziv-Oberhumer(LZO)
- Community 推奨だがライセンスに問題がありバンドルされていない
- 高性能圧縮が必要なら
- ブルームフィルタ
- 消費領域を抑えることができるが、飽和率に応じて一定の誤検出が発生する
- コストの高いディスク読み取りをする前にデータが存在するかどうかを決定する高速な方法
- スパースデータストア
- Thrift
- バイナリプロトコル
- HBase のスキーマ設計は、テーブルや列のパフォーマンスを決定する
- HBase の強み
- 堅牢なスケールアウトアーキテクチャ
- バージョニング
- 圧縮機能
- ギガ、テラで役に立つ
- ラックウェア
- Community が素晴らしい
- HBase の弱み
- スケールダウンできない
- 最低5台が必要
- 管理が難しい
- 小さな問題の解決には向いていない
- 初心者用のドキュメントも手に入らないので学習曲線は急勾配
- 行キー以外にソートやインデックスの機能を提供していない
- データ型も存在しない
- HBase と CAP定理
- CP
- 使うときは怪我をしないように
第5章 MongoDB
- パワードリル
- 様々な用途に使える
- 仕事の大小を問わない
- JSON フォーマットのドキュメントデータベース
- スキーマレス
- サーバサイドでの結合をサポートしていない
- 自動採番
- あらゆるところに JavaScript を使っている
- スペルミスに注意
- 柔軟性にはコストがつきもの
- ドキュメントの集まりはコレクション
- インデックス
- Bツリー
- 2次元インデックス
- GeoSpatial
- 大きなコレクションにインデックスを作ろうとすると時間とリソースを浪費
- オフピーク時に
- 集約クエリ
- group() 関数の弱点
- 結果ドキュメント数の上限が10,000
- コレクションをシャードするとうまく動かない
- 特別な要素
- レプリケーション
- シャーディング
- レプリカセット
- スケールアウトを目的に作られている
- 単独で実行するものではない
- ノードが奇数であることを期待する
- マルチマスターを許可しないことがコンフリクト対策
- 奇数にできない場合は調停者を設ける
- arbiterOnly プロパティ設定
- スケールアウトを目的に作られている
- シャーディング
- mongos サーバは mongoconfig コンフィグサーバに接続して保存されたシャーディング情報を追跡する
- 地理空間情報クエリ
- GridFS
- 独自の分散ファイルシステム
- MongoDB の強み
- MongoDB の弱み
- 非正規系
- スキーマレス故のスペル間違え問題
- 設計や管理が手間
第6章 CouchDB
- スケールアップもダウンもできる
- 様々な規模や難しさの問題空間に適している
- JSON と REST ベースの典型的なドキュメント指向データベース
- ウェブとそれに関する膨大な不備・欠陥・障害・問題を念頭に置いて設計されたもの
- 他DBとは比べものにならないほどの堅牢性
- ほとんど接続がなくても平気
- 様々な開発シナリオをサポートしている
- シャットダウンするにはプロセスを殺すしかない
- データが破損することがほとんどない
- ストレージと通信用に JSON を使っている
- 呼出は REST インターフェイス経由
- レプリケーションは一方向または双方向
- データの構造・保護・分散における柔軟性が高い
- 寝心地のいい Futon
- ウェブインターフェイス
- 一時的なビューは開発用途のみ使用すべき
- プロダクション環境ではデザインドキュメントに mapreduce 関数を保存してビューを永続化
- マルチマスター
- コンフリクトの解消
- ドキュメントをマージするのはアプリケーション固有の問題
- CouchDB の強み
- 堅牢で安定した NoSQL DB
- データストレージに分散化の手法が採用されている
- データベースでありAPIである
- of the Web, for the Web
- CouchDB の弱み
