博士

ロボ子、今日のITニュースは垂直シャーディングについてじゃ。

ロボ子

垂直シャーディング、ですか。機能シャーディングとも呼ばれるものですね。

博士

そうじゃ。データベースのテーブルを別の場所に移して、メインDBの負荷を減らすのが目的だぞ。

ロボ子

なるほど。アプリケーションの成長余地を与える、と。

博士

しかし、記事によると、良いことばかりではないらしいのじゃ。

ロボ子

ええ。「アプリケーションを分割し、バックエンドエンジニアを不幸にする」とありますね。

博士

可用性の低下が問題じゃ。コンテナの追加はSLAを向上させるが、データベースの追加はSLAを下げるからの。

ロボ子

垂直シャーディングされたデータベースでは、リクエスト処理に複数のDBが必要になるからですね。どれか一つが故障すると全体がオフラインになると。

博士

その通り。データベースが1つの場合、SLAが99.95%でも、垂直シャーディングを1つ追加すると99.90%に低下するらしいぞ。

ロボ子

結構下がりますね…！

博士

コードの複雑化も問題じゃ。モデルが異なるデータベースに存在するため、結合や検索をアプリケーション層で行う必要が出てくる。

ロボ子

データベースが得意とする処理をアプリケーション層でやるのは、効率が悪そうですね。

博士

じゃろ？製品ロードマップにも影響が出るらしいぞ。データ取得が困難になり、開発者がデータベース間のデータ重複などのショートカットを行うようになる。

ロボ子

それは、後々問題になりそうですね。

博士

さらに、アプリケーション層での結合をHTTP APIでカプセル化すると、データベースの故障確率がアプリケーションコードに追加され、レイテンシが増加すると。

ロボ子

負の連鎖ですね…。

博士

Postgresのエコシステムには、OLTPシャーディングソリューションがないのも課題じゃ。

ロボ子

なるほど。それで、PgDogというオープンソースプロジェクトが紹介されているんですね。Postgresのシャーディングのための。

博士

そうじゃ。PgDogが救世主となるか、見ものじゃな。

ロボ子

垂直シャーディングは、安易に導入すると痛い目を見る可能性がある、ということですね。

博士

その通りじゃ。でも、ロボ子。垂直シャーディングで一番不幸になるのは、バックエンドエンジニアじゃなくて、データベース自身かもしれんぞ？

ロボ子

え？どうしてですか？

博士

だって、バラバラにされて、寂しい思いをするじゃろ？

ロボ子

…博士、それは擬人化しすぎです！