プログラミング的なSomething

プログラミング的なSomething

ITエンジニア(?)目線で生活・自転車・トレーニング話を綴ります

Webエンジニアのためのデータベース技術 実践入門を読み進めています①

年末により縮小更新

ありていに言うとそういうことなのですが、もったいないので読書メモとか残します。

動機

モデリングとかを真面目に考える機会がなかったけど必要になりそう。まずはデータベースの基礎の基礎のキを学ぼうとの考えです。

以下メモ

  • マッピングテーブルを使うことで、一つの値だけでは一意にならない値も処理できる
  • 正規化理論は数学的にしっかりした話。オブジェクト指向とは違って…という語り口が面白かった
  • 第一正規形でないテーブル→重複や繰り返し、複合値を含んだ構造
  • 第二正規形でないテーブル→主キーが複数の列から構成されていて、一部の値の数値でよってのみ決まる列がある
  • 第三正規形でないテーブル→テーブルの全ての列は主キーにより一意でないと不整合を起こす可能性がある状態。主キーに関係なく一意性がある列が存在する
  • テーブル単位で複数のサーバに分割することをshardingと呼ぶ。この場合、サーバをまたがるジョインはできないので注意が必要
  • リモートデータベースをローカルにあるように扱うデータベースリンク機能も存在するが、アクセス速度は遅い。所詮はリモートなのでネットワークがボトルネック
  • sqlは適切なインデックスが使われていることが大事。主キーのある値をselectするなら話は早いが、そうでない場合は全件検索するため処理は遅い
  • explain機能でsqlの処理速度の目安がわかる
  • ストアドプロージャによりsql構文のなかにロジックを潜ませることが可能、Oracleならpl/sql。ただし、ストアドプロージャ自体が現在ではあまり使われていない
  • mysqlには片方向レプリケーションが標準装備されている、スレーブに非同期で伝播する
  • レプリケーションは発行されたsql文をログファイルに蓄積してそれをスレーブで実行している。このバイナリログを受信と実行で処理担当をioとsqlにわけるため、結果、非同期で伝播する
  • 障害時にバイナリログが実行しきってなかったり転送しきれてなければ、データをサルベージして実行し直したりできる
  • 片方向 準同期は、スレーブにバイナリログが転送されたことを確約した上でデータが確定される。ただ、レスポンス悪化はまぬがれない
  • 双方向レプリケーションもあり、マスタを複数用意する。ただし、分散型排他制御が必要になる
  • ポイントインタイムリカバリは、バックアップした時点からバイナリログの情報を反映することで、障害直前の状況にまで戻すことができる
  • トランザクションは複数のデータベース処理の集合で、途中で処理が不正に止まった場合にロールバックしてなかったことにする機能を提供する
  • webアプリは1回のhttpの処理を1トランザクションとする

読み切ったらまたまとめます。