それは知り合いのご縁でお声かけいただいた最初の相談内容でした。
リリース時から比べると検索スピードが遅くなってしまった
あるECサイトを運営していた会社様でした。
当時はメインである製品を検索する機能があり、その結果をお客様が見て選定し購入するというシンプルな構成でした。
実際に検索すると確かに遅い・・・
ありえないくらい遅い・・・
タイムアウトすることもあり、再現性は100%で特定の検索キーワードで再現するとかではなく、入力したすべてのキーワードで検索スピードが重い状況でした。
テーブル構成はとてもシンプル！
検索対象のカラムにはちゃんとインデックスが貼られていました。
検索方法は前方一致のみのシンプルな検索方法。
検索している対象のテーブルはJOINをしているわけでなく、シンプルにひとつのカラムに対して検索しているだけ。
メモリ容量やディスク容量などのハードウェアも問題ありませんでした。
データ量は問題無し！
データ量は多いときで10万件を超えるくらいで、インデックスも効いていたのでレコード数のボリュームは問題ありませんでした。
データの更新は週に2~3回程度で、全DELETE後に新しいデータをインポートしている運用でした。
ん！？ DELETE・・・ これはなんか怪しい感じがしました。
過去の体験からの予測は・・・
過去にPostgresSQLを使っているシステムで、定期的にテーブルのバキュームをしないと検索スピード等、さまざまな性能が落ちる問題を経験したことがあったのを思いだしました。
これはもしや・・・
断片化か・・・
データ更新時はシステムを止めてOKな運用だったので、入れ替え時にいつも実施していたDELETEはやめてTruncateに切り替えました。
その後はいつも運用通りインポート
DELETE運用を辞めた結果は・・・
データ入れ替えの運用で、DELETEしていた運用からTruncateに変更したことで、無事検索スピードも元のスピードに戻り、受注も増えて無事売り上げに貢献することが出来ました。
ちなみにその当時データベースはOracleでした。
「少なめのデータとシステム規模でなぜこのDBを使っているのだろうか」という疑問が残りつつ・・・
という考えは後のコストダウン対応へのきっかけでした。
最後まで読んでいただきありがとうございました。
コメント