KL system

DB哲学

by 唐草 [2024/04/02]

　数年前から契約先のサーバで動いている業務管理アプリが遅いと感じていた。表示件数が増えると耐え難い遅さになる。ぼくは5件くらいしか表示されないので、待ち時間は1秒程度。もっとも表示件数の多い人は50件ぐらいになり、待ち時間は10秒を超える。
　10秒待ちなんてフリーズを疑うレベル。2024年のアプリとは思えない。早急な対策が必要なのだが、システム開発者は退職済み。ブラックボックス化していて手を出せない状況だった。そこでボトルネックを洗い出すために、ぼくはほぼ互換の仕組みを用意した。
　ぼくが用意した互換システムは50件を0.05秒で表示した。約200倍の速度を実現した。
　ボトルネックはハッキリした。データベースへのアクセスに無駄が多いのだ。1件1件データベースに問い合わせているようだし、処理の大半をデータベース任せている。つまり、難しいことを何度も問い合わせる丸投げに近いやり方だった。
　一方、ぼくが用意した方法は全件を一気に取得して、アプリケーション側で処理をする。これは受け取った情報を自分で取捨選択する方法だ。
　今回は、処理をデータベースに任せて逐次アクセスする従来のやり方は不適当だったようだ。それは足の遅い人に一品ずつ買い物を頼むようなもの。今回は自分の足でまとめ買いに走ったほうがずっと速かった。
　データベースと処理の関係は奥深い問題だ。常に良い結果を生むベストな方法は存在しない。今回は偶然にも古いやり方が不適当で、ぼくの新しいやり方が当たっただけ。
　だから、データベース関連のコミュニティーは常に荒れている。ロジックと呼ばれる計算や検索をデータベースに任せるのか、それともアプリケーションに任せるのかで激しい対立が起きている。
　ぼくはデータベースは情報の貯蔵庫であって処理機ではないという考え。だから、複雑な処理は全部アプリケーションに任せたいと考えている。こう考えている人も多いが、同じ考えの人々でさえ団結できていない。「複雑な処理」の基準を巡って多くの血が流れているのだ。
　今日もサブクエリ派とインナージョイン派で不毛な争いが繰り広げられる。

• <<前の記事を読む　
• 　次の記事を読む>>