RDBMSかNoSQLか
- MongoDBとRDBMSの使い分けについて Open database life: ムック「データベース徹底攻略」 - MySQL/Redis/MongoDB/Redshift
- 「先に楽をして後で苦労するか、先に苦労して後で楽をするか」
- 大多数のサービスは成功せずに死ぬので、MongoDB採用による技術的負債は顕在化しにくい。旨みの部分(設計コストを抑えられる)だけ使える(けどサービスが死んでるので旨みとか言ってる場合じゃない)
PostgreSQLのJSONサポート
RDBMSでKVSの旨みがとれる?
BLOBは別のテーブルへ
TEXTやBLOBなど、データ量の大きな列は別のテーブルに移したほうがいい。そもそもバイナリデータはどうしてもDBに入れないといけないかよく検討すべき。
- バックアップ/レストア時の時間短縮
-
SELECT *
したときに余計にスクロールしたりしないので、運用時に少し幸せになる
定型のカラムたちって持つべきなの?
- 更新者 update_user
- 更新日時 updated_at
- 作成者 create_user
- 作成日時 created_at
みたいなやつら
論理削除は悪なのか
ユーザーは論理削除などという言葉を使わない。
ユーザーは削除が論理なのか物理なのかなんて気にしない。
エンジニアは内部事情を語りすぎる。
論理削除したくなったとき、ユーザーがそのシステムでなにをしたいのかを見つける。それは"退会"や"絶版"などだったりするかもしれない。それらの言葉のほうがデータやユースケース、ドメインを正しく表現できる。
論理削除はおうおうにしてデータモデルをじゅうぶん考えられてないケースで現れてくる。
けっきょく削除フラグじゃん?そうかもね。でもよりわかりやすい言葉のほうが良くない?
大規模データだから削除コスト重いから論理削除?そういうケースならいいんじゃないの?考えたうえでの選択であることが大切。
- RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita
- 論理削除が云々について - mike-neckのブログ
- 論理削除フラグという名の死亡フラグ - @ledsun blog
- Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か
- Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
オペレーションミス対策/データの復旧
たまにオペミス対策としての論理削除という話があるが、それでは不十分。UPDATE
でほかのカラムが更新されたらどうするの?それも対策しときたくない?
バックアップ/レストアの基本として必ず事前に検証しておくこと。
- 基本として適切なgrantを管理する
- そもそもオペミスが起こらないようにする
- MySQL 遅延レプリケーション?
- ストリーミングレプリケーションしつつ遅延レプリケーション?富豪的だけどそれもいいか
- Oracle FLASHBACK TABLE
- DDL変更すると対応できなくなるので注意
- PostgreSQL PITR?
- 復旧に停止が必要だからしんどい
このへん本気でやるなら、商用DB使ったほうが幸せになれそう。コストかけてもそれでも欲しいかを考えたい。
データのライフタイム
古いデータはアーカイブに残す?いつ?どれくらいの頻度で参照する?
アーカイブから戻すのにかかる時間は?