前回の続きです。
前回は、業務システムの検索画面が遅い理由を３つ挙げました。今回は、これらの対策を、業務システムの全体設計を担うアーキテクトの立場から考えてみます。
最小限の手戻りで、テーブル設計を見直したい
検索画面の遅さは、テーブル設計を見直すことで解決できます。とはいえ、前回も触れましたが、開発終盤に手戻りの大きい見直しをかけるのは現実的ではありません。なんとか最小限の手戻りで、テーブル設計を見直すことができないものでしょうか？
非正規化テーブルを追加する
こういう場合、大抵は「非正規化テーブルを追加する」ことになります。非正規化テーブルとは、他テーブルが保持しているデータを、性能上のメリットが得られる形（予め集計しておく等）に変換した上で、重複して保持するテーブルのことです。非正規化テーブルの追加であれば、既存テーブルの設計には一切手を入れる必要がなく、性能アップしたい機能のみをテコ入れできます。
例えば、検索時にオプティマイザが使うインデックスを間違えてしまうのは、１つのテーブルに多くのインデックスが割り当てられていることが原因です。この場合、検索に特化した非正規化テーブルを追加することで、インデックスを分散させる事ができます。
同期処理がネック
この手法を導入する際に避けて通れないのが、重複データの「同期処理」です。同じデータを複数テーブルに重複して保持している為、データ更新時には、それらのテーブルを同時に更新しなければならないのです。
この同期処理は、業務システムの更新機能に組み込む必要がある為、手戻りが発生します。この手戻りをどこまで限定的にできるかが、「非正規化テーブルを追加する」案の良し悪しを決めると言っても良いでしょう。
更新処理をAPI化すべし
私は、この同期処理による手戻りを限定的にする為に、「更新処理を始めからAPI化しておく」ことが必要と考えています。
大半の業務システムは、テーブルそのものが、画面間を繋ぐAPIと位置付けられてています。そして、テーブルを読み書きするデータアクセスは、各画面が個別にSQLを設計しています。
このような構造だと、今回のような同期処理が必要となった時に、各画面の手戻りが必ず発生してしまいます。更新処理をAPI化しておけば、同期処理はそのAPIの中で吸収できる為、各画面まで手戻りが及ぶことはありません。加えて、業務寄りのロジックとシステム寄りのロジックを綺麗に分離できる為、コードの見通しも良くなり、保守しやすくなります。
加えて、RDBを使っている大抵の業務システムは、更新処理が単純です。（逆に、参照処理は複雑なことが多い）単純なので、更新処理をAPI化する開発コストも、さして大きくありません。
おわりに
私は、アーキテクトとして、今までに大小様々なシステムの全体設計に携わってきました。その都度、ああすれば良かったとか、凝り過ぎたなぁとかいろいろ反省させられます。
今回は、そんな試行錯誤の中で見つけた解決策について、書かせて頂きました。