読者です 読者をやめる 読者になる 読者になる

7つのデータベース7つの世界

7つのデータベース7つの世界

7つのデータベース 7つの世界

7つのデータベース 7つの世界

NoSQLを使う場面とは?ということに悩んだので、読んでみた。 正直、PostgreSQLさえあればなんでも出来そうって気になってきた。 第6章まで。

第1章 イントロダクション

  • リレーショナルデータベース
  • キーバリューストア
    • Raik
    • Redis
  • 列指向データベース
    • HBase
  • ドキュメント指向データベース
  • グラフデータベース
    • Neo4j
  • ポリグロット(混合型)
    • 複数のデータベースの長所を組み合わせてエコシステムを構築

第2章 PostgreSQL

  • 普及の要因
    • データの安全性(ACID準拠)
    • マインドシェア
    • クエリの柔軟性
    • 正規化による柔軟な問い合わせ
  • PostgreSQL
    • 自然言語のパース
    • 多次元インデックス
    • 地理空間クエリ
    • 高度なトランザクション
    • ストアドプロシージャ
    • ユニコード
    • シーケンス
    • テーブル継承
    • 副問い合わせ
    • ANSI SQL に最も準拠したRDB
    • 高速
    • 信頼性が高い
    • テラバイト単位のデータも扱える
    • Skype、CNAF、FAAでも実運用されている
  • 数学的リレーション
    • リレーション(テーブル)
    • 属性(列)
    • タプル(行)
  • CRUD
    • Create
    • Read
    • Update
    • Delete
  • インデックスで高速検索
    • Bツリーインデックス
    • ハッシュインデックス
  • 集約関数
  • グループ化
  • ウィンドウ関数
    • 複数の行に対して集約関数を実行
    • 行をグループ化することなく集約関数を使える
  • トランザクション
    • ACID 準拠
      • Atomic(原子性: 操作はすべて実行されるか、すべて実行されない)
      • Consistent(整合性: データは常に正しい状態にあり、不整合な状態はない)
      • Isolated(隔離性: トランザクションは他から邪魔されない)
      • Durable(永続性: コミットされたトランザクションはサーバがクラッシュ後も安全である)
    • ACID の整合性は CAP定理 の整合性とは違う
  • ストアドプロシージャ
  • 恐怖のベンダーロックイン
  • コードはアプリケーションに依存するのか?データベースに依存するのか?
  • トリガー
  • ビュー
  • ルール
  • クロス集計
  • あいまい検索
    • LIKE、ILIKE
  • 正規表現
  • レーベンシュタイン
  • トリグラム
  • TSVevtor, TSQuery
  • 汎用転置インデックス GIN
  • メタフォン
  • 多次元ハイパーキューブ
  • PostgreSQL の強み
    • リレーショナルモデルと同じく膨大
    • 長年の研究
    • あらゆる計算分野における利用実績
    • 柔軟なクエリ
    • 高い整合性と永続性
    • 実践で使い込まれた各言語用のPostgres用のドライバ
  • PostgreSQL の弱み
    • 分割がうまくできない
      • スケールアップ、スケールアウト
    • データが柔軟過ぎる場合

第3章 Raik

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 の弱み
    • RDB のようなデータのスライシングはできない
    • レプリケーションのやり方が常に正しい選択というわけではない
      • オールオアナッシング
    • データセンターに分散するシャーディングはない