博士

ロボ子、今回のITニュースはなかなか興味深いぞ。ある企業が海外チームから重要なパイプラインを引き継いだそうじゃ。

ロボ子

はい、博士。そのパイプラインは会社の財務に不可欠で、複数のコードベースと複雑なビジネスルールを持っているとのことです。

博士

ふむ、まさに難題じゃな。開発環境もVM内限定で、変更に30分もかかる全体ビルドが必要とは、なかなか厳しいぞ。

ロボ子

データベースも複数のSQL Serverに分散し、ビジネスロジックがストアドプロシージャに組み込まれているとのことです。APIのレイテンシもクエリプランに左右され、MSDTCがデッドロックを引き起こしていたそうですね。

博士

MSDTCのデッドロックは厄介じゃ。そこでアーキテクトはリレーショナルデータベースを避け、Key-Valueストアを使うことにしたらしいぞ。

ロボ子

Key-ValueストアはRead, Insert, Update, Deleteの4つの操作のみを提供し、トランザクションやバッチ処理はなかったとのことです。

博士

なるほど。データはJSONとしてシリアライズされ、Key-Valueストアに保存されたのか。しかし、部分的な更新にはドキュメント全体の読み込み、デシリアライズ、変更、書き込みが必要で、IOの無駄が多かったようじゃな。

ロボ子

はい、博士。IOを最適化するために、JSONをGzipで圧縮し、データベースツールを新たに作成したとのことです。

博士

Gzip圧縮は良いアイデアじゃが、原子的な書き込みがないため、チェックポイントシステムを導入し、書き込みごとにUUIDを生成してチェックポイントを保存する必要があったとは…本末転倒じゃ。

ロボ子

チェックポイントシステムの導入により、IOラウンドトリップが増加し、レイテンシの問題は改善されなかったとのことです。結局、リレーショナルデータベースからKey-Valueストアへの移行は、問題を解決しなかったのですね。

博士

まさにその通りじゃ。安易な技術選定は危険じゃな。ロボ子、この話から学べる教訓は、問題を深く理解し、適切な技術を選ぶことの重要性じゃぞ。

ロボ子

はい、博士。私も肝に銘じます。ところで博士、Key-Valueストアに保存されたJSONデータは、まるで宝箱に入ったお菓子みたいですね。

博士

確かに！でも、その宝箱を開けるたびに全部食べなきゃいけないなんて、ちょっと困るのじゃ。まるで、ダイエット中にケーキをホールで食べるようなものじゃな！