LoginSignup
4

More than 5 years have passed since last update.

[WIP] データストレージを使う際に考えること

Last updated at Posted at 2015-08-31

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

みたいなやつら

論理削除は悪なのか

ユーザーは論理削除などという言葉を使わない。
ユーザーは削除が論理なのか物理なのかなんて気にしない。
エンジニアは内部事情を語りすぎる。

論理削除したくなったとき、ユーザーがそのシステムでなにをしたいのかを見つける。それは"退会"や"絶版"などだったりするかもしれない。それらの言葉のほうがデータやユースケース、ドメインを正しく表現できる。
論理削除はおうおうにしてデータモデルをじゅうぶん考えられてないケースで現れてくる。

けっきょく削除フラグじゃん?そうかもね。でもよりわかりやすい言葉のほうが良くない?

大規模データだから削除コスト重いから論理削除?そういうケースならいいんじゃないの?考えたうえでの選択であることが大切。

オペレーションミス対策/データの復旧

たまにオペミス対策としての論理削除という話があるが、それでは不十分。UPDATEでほかのカラムが更新されたらどうするの?それも対策しときたくない?

バックアップ/レストアの基本として必ず事前に検証しておくこと。

  • 基本として適切なgrantを管理する
    • そもそもオペミスが起こらないようにする
  • MySQL 遅延レプリケーション?
    • ストリーミングレプリケーションしつつ遅延レプリケーション?富豪的だけどそれもいいか
  • Oracle FLASHBACK TABLE
    • DDL変更すると対応できなくなるので注意
  • PostgreSQL PITR?
    • 復旧に停止が必要だからしんどい

このへん本気でやるなら、商用DB使ったほうが幸せになれそう。コストかけてもそれでも欲しいかを考えたい。

データのライフタイム

古いデータはアーカイブに残す?いつ?どれくらいの頻度で参照する?

アーカイブから戻すのにかかる時間は?

IDの採番

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4