Upgrade to Pro — share decks privately, control downloads, hide ads and more …

増え続けるトランザクションデータと向き合う

RyotaNakaya
December 23, 2020

 増え続けるトランザクションデータと向き合う

RDBで増えていくデータについて、事前にどういうことが考えられるか、増えた時にどういう手段が取れるかについて。

RyotaNakaya

December 23, 2020
Tweet

More Decks by RyotaNakaya

Other Decks in Technology

Transcript

  1. 増え続ける
    トランザクションデータと向き
    合う
    By Nakaya Ryota
    2020/12/23

    View full-size slide

  2. 自己紹介
    ギフティ入社:2019年1月
    所属:CC Div. ProductUnit2
    前職:バックオフィス系のパッケージベンダー(上流工程メイン)
    好きなスタバメニュー:スターバックスラテ
    最近は Go より Ruby 書いてる
    インフラも頑張りたい

    View full-size slide

  3. みなさん
    RDBで増えすぎたレコードの管理って
    どうしてますか?

    View full-size slide

  4.  
    (スキーマ変更したいけど、データ多すぎて安全に alter table かけら
    れないな...)
    僕「古いデータ消してもいいですか」
    顧客「物理削除は困っちゃうよねえ、監査とかあればデータ出さな
    いといけないし。論理削除ならいいんじゃない?」
    僕「そうっすよねえ、はは」

    View full-size slide

  5. そもそもデータの削除って
    何を元に意思決定すればいいんだっけ...?

    View full-size slide

  6. トランザクションデータとは
    トランザクションデータとは、企業の情報システムなど
    が扱うデータの種類の一つで、業務に伴って発生した
    出来事の詳細を記録したデータのこと。 (IT用語辞典)

    View full-size slide

  7. データは過去から未来に向かって
    増え続ける(自明の理)

    View full-size slide

  8. データが増えすぎると
    RDBMS では一般的に以下のような問題が起こる
    • パフォーマンス劣化
    • チューニング性劣化する
    • スキーマ変更にかか るコストの増大
    RDBMS 以外でも問題は起こる
    • 記憶媒体(ハードディスク)の限界
    • アプリケーションサーバーでの意図せぬメモリ圧迫
    • select all したら100万行釣れちゃったてへぺろ

    View full-size slide

  9. データが増えすぎると
    データベースのスケーラビリティをあらかじめ検討して
    おかないと、気づいた時にはメンテ不可能になってい
    るかもしれない
    きちんと正規化して index を張ってあっても、大規模
    テーブルのスキーマ変更をダウンタイムなしで行うの
    はハードルが高い

    View full-size slide

  10. じゃあどうすれば...?

    View full-size slide

  11. データが増えすぎる前に
    できることを考える

    View full-size slide

  12. データが増えすぎる前に
    このデータがいつ作られるのかだけでなく
    いつ消されるのか(消してもいいのか)も
    検討した方が良い
    ※ 「消す」というのは無効化のことではなくその名の通り削除を表しています

    View full-size slide

  13. データが増えすぎる前に
    この世の中には大きく二種類のデータがある
    • 法定保存文書を電子化したもの
    • それ以外

    View full-size slide

  14. データが増えすぎる前に
    この世の中には大きく二種類のデータがある
    • 法定保存文書を電子化したもの
    →法律で保存期間が決められている
    • それ以外
     →保存期間に関する公的な制約がない

    View full-size slide

  15. 法定保存文書とは、
    法律で文書の保存が義務付けられており、その保存
    期間も決められた文書のこと
    データが増えすぎる前に

    View full-size slide

  16. データが増えすぎる前に
    法定保存文書の例
    • 株主名簿(永年)
    • 取締役会議事録(10年以上)
    • 取引に関する帳簿(7年以上)
    • 仕訳帳、現金出納帳、売掛帳、買掛帳など
    • 決算に関して作成された書類(7年以上)
    etc
    refs: https://www.storage-channel.jp/blog/legal-document-retention-period.html

    View full-size slide

  17. 以前は必ず紙での保管、提出が義務付けられていた
    が、近年は法定文書を電子化する動きが活発
    データが増えすぎる前に

    View full-size slide

  18. 普段はアクセスされることはないが、
    監査の際に開示することが法律的に求められる
    データが増えすぎる前に
    (注:画像はイメージです)

    View full-size slide

  19. 開示ができなかったりすると最悪捕まります
    データが増えすぎる前に
    (注:画像はイメージです)

    View full-size slide

  20. どのデータが法定文書に当たるのかは、ケースバイ
    ケースなので、事前に法務担当者としっかりチェックし
    ましょう
    ※ 会計システムに連携済みであったとしても、
     raw データを証跡として求められることは全然ある(らしい)
    データが増えすぎる前に

    View full-size slide

  21. 法定文書以外のデータは
    どうすればいいの...??

    View full-size slide

  22. 法定文書以外のデータは保護期間を自由に決められ

    (法律的にはなんの制約もないので、別に保護しなくてもいい)
    データが増えすぎる前に

    View full-size slide

  23. とは言え
    フリーダムだと判断基準がなくて困るので

    View full-size slide

  24. SaaS サービスを提供する場合、
    SLA(Service Level Agreement)、利用規約によって
    データの管理方法を定めるのが一般的
    データが増えすぎる前に

    View full-size slide

  25. データが増えすぎる前に
    経産省が公開している SaaS 向け SLA ガイドライン
    https://www.meti.go.jp/policy/netsecurity/secdoc/contents/downloadfils/080121saasgl.pdf

    View full-size slide

  26. データが増えすぎる前に
    経産省が公開している SaaS 向け SLA ガイドライン
    https://www.meti.go.jp/policy/netsecurity/secdoc/contents/downloadfils/080121saasgl.pdf

    View full-size slide

  27. データが増えすぎる前に
    データ消去の要件として、
    ゴミデータ(古いトランザクション)の取り扱いを定義しておく

    View full-size slide

  28. 要件定義をする際に、非機能要件として
    • 性能要件
    • セキュリティ要件
     みたいなものを定義すると思うんですけど、
     その一項目として議論するイメージ
    データが増えすぎる前に

    View full-size slide

  29. アプリケーションとして必要なデータの定義、不要だと
    みなせるデータの定義ができていれば、
    例えばバッチ処理などで定期的に古いデータを削除/
    退避するなどして、データベースがハイパフォーマンス
    な状態を維持できる(かもしれない)
    データが増えすぎる前に

    View full-size slide

  30. (スキーマ変更したいな、マイグレーション実行や...!!)
    僕「古いデータ消してもいいですか」
    顧客「物理削除は困っちゃうよねえ、監査とかあればデータ出さな
    いといけないし。論理削除ならいいんじゃない?」
    僕「そうっすよねえ、はは」
    そもそもこんな議論が必要ない
    (かもしれない)

    View full-size slide

  31. データが増え過ぎちゃった時に
    できることを考える

    View full-size slide

  32. データは過去から未来に向かって
    増え続ける(2回目)

    View full-size slide

  33. 広がってもせいぜい
    アイビーリーグまでだ
    ろ...
    この設計でヨシッ!
    (注:筆者はマークのことが大好きです)

    View full-size slide

  34. 2019年時点での facebook のユーザー数

    View full-size slide

  35. 設計時点で未来のトランザクションの
    ことなんてわからん
    (っていうか明日何が起こるかもわからんこの御時世 )

    View full-size slide

  36. 未来はわからないけど
    データが増えすぎちゃった時に
    取れる行動を考えておくことはできる

    View full-size slide

  37. 何も考えずに物理的にデータを削除する
    • DELETE クエリを発行して、記憶媒体からデータを削除する
    • 削除する量にもよるが、物理削除してデフラグ、インデックスツ
    リーの更新まで完了すればパフォーマンス的にポジティブな改善
    が見られる可能性が高い
    • 復元不可能なので、選択肢としては現実的ではない
    データが増えすぎちゃった時に

    View full-size slide

  38. 古いデータをアーカイブする
    • ある基準でデータを退避して、アプリケーションからは必要な
    データのみを扱えるようにする
    • 古いかどうかはアプリケーションの要件によって決まる
    • もう参照も更新もしないよ、とか
    • アーカイブのやり方は色々あって、アーカイブテーブルを作って
    退避したり、データベースダンプファイルを作ったり
    • いづれにせよ大元のテーブルからは物理削除する
    データが増えすぎちゃった時に

    View full-size slide

  39. 物理設計を見直す
    • secondary index の設計
    • DBのテーブルを水平分割する(horizontal partitioning)
    • DBのテーブルを垂直分割する(vertical partitioning)
    データが増えすぎちゃった時に(というか設計時に)

    View full-size slide

  40. 水平分割(シャーディング)
    1つのテーブルの各行を別々のテーブルに分散させること
    データが増えすぎちゃった時に(というか設計時に)
    user data

    View full-size slide

  41. 水平分割(シャーディング)
    1つのテーブルの各行を別々のテーブルに分散させること
    データが増えすぎちゃった時に(というか設計時に)
    北海道 user
    東日本 user
    西日本 user
    user data

    View full-size slide

  42. 水平分割(シャーディング)
    1つのテーブルの各行を別々のテーブルに分散させること
    ● 各テーブルの容量は減って取り
    扱いしやすくなる
    ● パーティションキーの設計が難し

    ● データの偏り(ホットスポット)がで
    きる
    ● 一貫性の管理やテーブルをまた
    がるビューが欲しい時に union し
    なければいけないなどの面倒さは
    ある
    ● Cassandara や MongoDb など、
    保存先のノードを意識しなくてもい
    いテクノロジーもある
    データが増えすぎちゃった時に(というか設計時に)
    北海道 user
    東日本 user
    西日本 user
    user data

    View full-size slide

  43. 垂直分割
    テーブルの一部の列だけを抜き出す形で分割を行う
    データが増えすぎちゃった時に(というか設計時に)
    serial_number available_until message balance
    111…. 2020/XX/YY happy birthday 500
    999... 2020/XX/YY happy new year 200

    View full-size slide

  44. 垂直分割
    テーブルの一部の列だけを抜き出す形で分割を行う
    データが増えすぎちゃった時に(というか設計時に)
    serial_number available_until message balance
    111…. 2020/XX/YY happy birthday 500
    999... 2020/XX/YY happy new year 200
    serial_number available_until message
    111…. 2020/XX/YY happy birthday
    999... 2020/XX/YY happy new year
    serial_number balance
    111…. 500
    999... 200

    View full-size slide

  45. 垂直分割
    テーブルの一部の列だけを抜き出す形で分割を行う
    データが増えすぎちゃった時に(というか設計時に)
    serial_number available_until message balance
    111…. 2020/XX/YY happy birthday 500
    999... 2020/XX/YY happy new year 200
    serial_number available_until message
    111…. 2020/XX/YY happy birthday
    999... 2020/XX/YY happy new year
    serial_number balance
    111…. 500
    999... 200
    ● よくあるのは列の内容の利用頻度によって分割するもの
    ● この例だと、balance の更新でテーブルをロックしても、message
    などの表示のための select が待たされることはなくなる
    ● 巨大な可変長カラム(BLOB、VARCHAR、および TEXT )は、脳死し
    て select * すると不要にメモリを圧迫しかねないので、切り出して
    おくというのもあり

    View full-size slide

  46. NoSQLなどスケーラビリティの高いテクノロジーを採用
    する
    • スキーマ変更も容易
    • スキーマレス、列志向
    • データ量が増えても select のパフォーマンスが劣化しづらい
    • KVS なら 1億件あっても釣るのはほぼ一瞬(らしい)
    データが増えすぎちゃった時に(というか設計時に)

    View full-size slide

  47. 安全で楽しいデータライフを

    View full-size slide