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

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

nakaryooo
December 23, 2020

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

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

nakaryooo

December 23, 2020
Tweet

More Decks by nakaryooo

Other Decks in Technology

Transcript

  1. データが増えすぎると RDBMS では一般的に以下のような問題が起こる • パフォーマンス劣化 • チューニング性劣化する • スキーマ変更にかか るコストの増大

    RDBMS 以外でも問題は起こる • 記憶媒体(ハードディスク)の限界 • アプリケーションサーバーでの意図せぬメモリ圧迫 • select all したら100万行釣れちゃったてへぺろ
  2. 水平分割(シャーディング) 1つのテーブルの各行を別々のテーブルに分散させること • 各テーブルの容量は減って取り 扱いしやすくなる • パーティションキーの設計が難し い • データの偏り(ホットスポット)がで

    きる • 一貫性の管理やテーブルをまた がるビューが欲しい時に union し なければいけないなどの面倒さは ある • Cassandara や MongoDb など、 保存先のノードを意識しなくてもい いテクノロジーもある データが増えすぎちゃった時に(というか設計時に) 北海道 user 東日本 user 西日本 user user data
  3. 垂直分割 テーブルの一部の列だけを抜き出す形で分割を行う データが増えすぎちゃった時に(というか設計時に) 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
  4. 垂直分割 テーブルの一部の列だけを抜き出す形で分割を行う データが増えすぎちゃった時に(というか設計時に) 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 * すると不要にメモリを圧迫しかねないので、切り出して おくというのもあり