主要データベースの増え続けるdisk容量の対応事例

こんにちは、SRE の @masartzです。 今回は最近取り組んだ、メルカリの主要データベースの容量削減のお話をしようと思います。 TL;DR 主要データベースの容量を20%以上削減しました どういう状況だったか？ 何をしたか？ メルカリでは2017年11月現在、出品数は1日100万件を超えています。 なので、単純に日々多くのデータが増えていっています。 そのためデータベースのスケーリングは常に検討し、取り組まなければならない課題です。 今回扱ったデータベースはいくつかあるデータベースの中で商品テーブルを持つ、メルカリの主要データベースになります。 増え続けるデータに対応するための、テーブル分割を変則的な形で対応したのでその過程を紹介します。 前提：データベース分割方法 メルカリのデータベースには 会員情報や商品情報など、基本要素となるデータから、通知やお知らせメッセージなど付加的な機能

[juve534]

DBリファクタリングは、何度もアプリケーションの修正が入るし、大変な作業だな。それでも、やらないと行けないんだけどな。

[pattyhama]

面白い

[yarumato]

“主要DB容量を20%以上削減。テーブル単位で物理DBを住み分ける、いわゆる垂直分散方式。部分情報のみを持つ別テーブルを別DBに作成し、カラム単位による分割の変形方式で移行する”

[Peranikov]

DBリファクタリングは切り戻しも考慮しながらデプロイを何度も積まなきゃいけないから本当に大変

[hoppie]

こういう話好き

[masudaK]

淡々と書かれてるけど、この規模で普通にやっててすごい。

[naopr]

アプリケーション側のコード修正の一部を担当したけど、影響範囲の洗い出しと書き換えはそれなりに大変だったなー。分割お疲れさまでした！

[at_grandpa]

とても参考になる！

[skit_n]

尊い

[wata88]

移行中の考慮ポイントがすごく勉強になった

[katzchang]

DBリファクタリングだ

[yatta47]

メルカリほどの大きい規模の事例はめちゃ参考になる。

[tofu-kun]

100段階右折みたいな感じで大変だったろうな