失敗から学ぶRDBの正しい歩き方読書会(4)に参加

書いたままほったらかしでブログに投稿するの忘れてました。

9章「強すぎる制約」から読みました次回は11章「見られないエラーログ」からです

強すぎる制約

• RFCに準拠した制約
  • RFCに準拠しないアドレスが多いので危険
• ドメインは使わない派
  • WEB系の会社では外部キー制約も使わないことが多い
    • フレームワークに任せってきり？
• ドメインは使う派
  • ER studioなどでER図を作るのに便利
  • 巨大なシステムの膨大なテーブル郡に一気に適用できる
• 小ネタ
  • postgresの\Dは何か⇨　多分describe
    • 降順のdescとかぶる？

外部キーでデッドロック

• 小テーブル更新時に親テーブルに共有ロックがかかる
• id昇順でinsert + 降順でinsertがconcurrentに動くとdeadlock?
  • multiversionでSerializableなスケジュール云々*1みたいなこと考えたけど、特定の実装でデッドロックになる・ならないと、あるスケジュールがSerializableかどうかは全く別の話

DOMAINに似たENUM型

• ENUM型は標準SQLではない

状態をもつCHECK制約

ALTER TABLE emails ADD COLUMN updated_at timestamp without time zone CHECK (updated_at >= now());

• この制約は動くのか？
  • now()はいつ評価されるか？
  • now()はpostgresqlだとトランザクションの開始時点の時刻を入れるのでbegin以降にアプリ・SQLで呼び出したnowなどで作った日付のデータはinsert可能
  • now()が制約実行時に評価されるDBMSだと動かない。
    • まさか制約定義時に評価されてるDBなんてないよなぁ
• MySQLはSET FOREIGN_KEY_CHECKS=0で外部キー制約を無視できる
  • MySQLのバックアップが単純なinsert文の集まりなので、これを使う
  • これは遅延制約ではなく、FOREIGN_KEY制約を無効化する

バックアップ

• バックアップの種類
  • 論理バックアップ
    • 商用DBMSだと論理バックアップは使われないことが多い
      • postgresqlやmysqlで使われる
    • テキストデータなのでデータサイズが大きくなる
  • 物理バックアップ
  • Point in time Recovery
    • これはバックアップではなくリカバリ方法
    • 増分バックアップ
• 指標・目標
  • RPO:復旧できるデータ
    • バックアップにかかる時間も重要
  • RTO:復旧までにかかる時間
  • RLO:復旧したいデータ

• MySQLのバックアップ(バイナリログ)は遅い

• 文字化けを戻せない可能性がある

  • 昔のsjis,eucなどのデータをUTF8でバックアップした時に戻せない可能性がある?□など
• 運用チームは日々非常時のリストア練習が必要
  • 正しくバックアップ・リストアできるか
    • バックアップ対象は正しいか

レプリケーション

• 遅延レプリケーション
  • 30分だけ遅延してレプリケーション:MySQL発?
    • DB2が真似した？

クラウドサービス

• 運用の手軽さ
  • 導入の殺し文句

クラウドサービスを使うメリットは、構築がお手軽だからというだけではなく、フルマネージドしてもらうことで、運用を正しく維持できることにもあります。 　もしクラウドサービスを検討しているときに、上長に「クラウドサービスは心配」と言われて足踏みしているなら、運用面のメリットも併せて提案してみてはいかがでしょうか。

• クラウドサービス=必ずしも安心ではない
  • ファーストサーバーの例
  • クラウドベンダがファイルをぶっ飛ばす可能性がある
• マルチクラウド
  • どのベンダーでも使える言語で作る必要がある
    • Google App Engineなどは使えない

失敗から学ぶRDBの正しい歩き方 (Software Design plus)

余談

ブログデザインのサムネ切り取りが素敵だね。

*1:w-wはno conflict