昔々、John という開発者が、大きなテーブルの name カラムを VARCHAR(20) から VARCHAR(512) に変更しようとしていました。これは、国際展開を進めるプロダクトチームから上がってきた要望で、より多様な名前の長さに対応するためのものです。実際の SQL はこちらです。
ALTER TABLE person MODIFY name VARCHAR(512);DBA の Bob が John のマイグレーションスクリプトをレビューしました。表面的には素直な変更で、これまでに何度も見たり承認したりしてきた類のものです。Bob はゴーサインを出しました。
Bob の承認を受けて、John はマイグレーションを実行しました。デプロイした瞬間、社内のアラームが一斉に鳴り響きました。
根本原因は微妙です。MySQL 8.0 で Online DDL のカバー範囲は広がりましたが、この文はまだカバーされていません。公式ドキュメントに書かれているとおり、文がサイズ値をエンコードするバイト数を 1 から 2 へ広げるためです。
結果、他のすべてのトランザクションはこの DDL の完了を待ってブロックされました。大きなテーブルでは、これは数時間に及び得ます。
業界は非難無きカルチャーを推奨していますが、誰かが説明責任を負う必要はあります。さもないとプロセス改善の旗振り役が現れず、同じことが繰り返される確率が高くなります。
書き手の John の責任か？ そうかもしれません。ただ、特定のデータベースの、特定のバージョンにおける、特定の文の実行計画を知っていることは、平均的な開発者にはやや高い要求です。
レビュワーの Bob の責任か？ もっともらしい。Bob はより多くの知識を持ち、まさにこういう誤りを捕まえるために雇われています。とはいえ Bob がすべて被ると、開発者の DB 知識を伸ばす動機が薄れます。
幸いなことに、こうしたジレンマは今では少なくなってきました。
- 企業は DB の責任をより開発者へ移しつつあります。DB 担当者やプラットフォームチームが DB インフラを面倒見つつ、日々の DB 開発タスクは開発チームが完結して扱う、という形が増えています。
- 企業は Vettabase、Percona、Enterprise DB のような外部 DBA コンサルティングサービスから専門助言を得られます。
- 企業は Bytebase のようなデータベース開発ツールを採用し、開発者と DB チームの連携を改善できます。
データベース DevOps の時代へようこそ。