Oracle TimesTenを高速化させるも永続化させるも設定次第であると前回の記事で軽く触れました。とはいっても、やはりOracle TimesTenを導入されるお客様の多くはパフォーマンスを最重要視するケースが多いので、まずはOracle TimesTenをより高速化させるための設計ポイントについて解説します。
Oracle TimesTenを高速化させる極意
最初に整理しなくてはいけないのは、Oracle TimesTenで速くしたいのはどんな処理なのか？という点です。更新も参照もなんでもかんでも速くしたいという要件であればそれも実現可能ですが、参照だけ高速化できればよいのであれば読取専用データベースとして使用させることが最もシンプルで速い構成になります。
更新や削除も含めて高速化したいという場合は、以下のようなチューニングポイントがあります。
極意1：DurableCommitsは無効化すべし。
DurableCommitsパラメータを無効化し、コミット時にログをディスクまで書かせない設定にします。これによってコミット処理にかかる時間が短縮されるため、レスポンスが速くなります。
DurableCommitsパラメータはデフォルトで無効化されているので、明示的に有効化しない限りはコミットの度にディスクまでログが書き込まれることはありません。
極意2：ログバッファは潤沢に用意すべし。
ログバッファ(LogBufMBパラメータで指定)に充分なサイズを設定することで、ログバッファがあふれてディスク上のログファイルに頻繁にフラッシュされることを防ぎます。
ログのディスクへの書き込みが頻発し、ログファイルへの書き込みがまだ終わらないうちにログバッファがいっぱいになると、ログバッファ待機が発生し、処理の遅延につながります。
極意3：チェックポイントは必要最低限に留めるべし。
Oracle TimesTenではチェックポイントの間隔を明示的に調節できるので、この運用をどう設計するかが重要です。
パフォーマンス重視なら、チェックポイント頻度を極力少なくして、チェックポイントで発生するI/O負荷やCPU負荷を抑えた方がよいです。
しかし、だからといってチェックポイント頻度が少なすぎると、ディスク上のログファイルがどんどん増え続けてしまうことになります。
ログファイルを格納する領域が枯渇し、ログがそれ以上書き込めなくなると更新処理が行えなくなりますので、必要最低限のチェックポイントは行わなければいけません。
チェックポイントのチューニングはそのシステムの更新頻度や更新量に依存するので、まずはデフォルトの自動チェックポイント設定(600秒)のままで負荷テストを行い、パフォーマンスやログファイルの増加傾向を確認しながら必要に応じて変更することをおすすめしています。
極意4：とにかくデータ連携は非同期にすべし。
レプリケーションも、Oracle Databaseとのデータ連携も非同期にした方がパフォーマンスはよいです。
もちろん、なんでもかんでも非同期にしてしまうと永続性が弱くなってしまうので、ここの落としどころについては後でまたご説明します。とにかく、今は「パフォーマンスが最優先なら非同期がいいのね」と理解しておいてください。
極意5：SQLはシンプルに書くべし。
Oracle TimesTenにもいろいろな実行計画がありますが、Oracle Databaseほどのバリエーションはありません。したがって、副参照の多いSQLや結合するテーブルの多いSQLは高速化のメリットを享受できないケースもあります。
Oracle TimesTenはインデックスを使用したシンプルなSQLが得意であり、いかにインデックス・スキャンで処理させるかが肝といえます。
また、Oracle Databaseと同様にバインド変数を使用して解析回数を減らすことも重要なポイントです。
極意6：CPUを枯渇させるなかれ。
Oracle TimesTenはメモリ上で全ての処理を行うため、CPUリソースを消費しながら高性能を実現する製品であることを忘れないでください。
Oracle TimesTenという名前は「CPUを10倍効率的に使用する」という意味であり、基本的にはCPUを効率的に使用しますが、それでもCPUが枯渇するような状況ではパフォーマンスはなかなか伸びません。
まずは、簡単なPOC（Proof Of Concept）を実施していただき、どの程度のCPUスペックがあれば問題ないのか見積もっていただくことをおすすめします。
極意7：クライアントサーバ接続よりもダイレクト接続にすべし。
Oracle TimesTenはアプリケーションサーバ内にインストールしてダイレクト接続させることも可能ですが、別サーバにインストールしてクライアントサーバ接続させることも可能です。
イン・プロセス動作し、ネットワークのオーバーヘッドがない分、ダイレクト接続の方が断然速いので、パフォーマンスを追求するならダイレクト接続です。
