AuroraMySQL 負荷試験報告 〜結局のところスキーマ分離のDB設計ってどうなの？〜 その１ - MNTSQ Techブログ

はじめに スキーマ分離と行分離 目的と結論 目的 結論のサマリ 試験内容 試験環境とツール 負荷の設計 本番環境でのクエリ傾向の分析 QPSの測定 進め方 試験結果 スキーマ分離のボトルネック スキーマ数を固定して負荷をあげてみる 結果まとめ なんとか延命したい はじめに 弊社が採用しているDB設計は、テナントごとに独立したスキーマを持つ「スキーマ分離」 のデータ構造に基づいています。このアーキテクチャは、高いデータ分離性とセキュリティを確保できる一方で、「スキーマ数の増加に伴ってパフォーマンスが劣化する」という性質が指摘されます。 サービスのスケールにおいてこの「性能劣化」が、いつ、どのように顕在化するのかは、設計上の大きな課題でした。この漠然としたリスクを定量的に評価し、将来的な「行分離」アーキテクチャへの移行の是非を判断することを目的に、負荷試験を実施しました。 本記事では、この試験

[taruhachi]

スキーマ分離のメリットは、将来の物理DBクラスターの分離が容易で論理的には無限スケールが可能だと思ってるんだけど、私の想定するユースケースとは全く異なるものなんだろうな。

[strawberryhunter]

Auroraの接続数には制限があるから、DB数をそんなに増やすことは想定しないわ。行分離は手動運用が面倒で危険で大量レコードに悩まされる。PostgreSQLのRow Level Securityのオーバーヘッド問題はどの程度解決済みなんだろうか。

[ebo-c]

宗教上の理由 is 何

[ST0RM]

“採用しているDB設計は、テナントごとに独立したスキーマを持つ「スキーマ分離」 のデータ構造に基づいています。”

[tofu-kun]

PostgreSQLのschema分割の場合だと、どれくらいのパフォーマンスになるのか気になる。チューニング結果の次回も期待。