TimesTen適用事例

TimesTen適用事例

　性能検証を行うことで、TimesTenがディスク型RDBMSよりも断然速く、さらにCPU使用効率も優れていることがわかりました。それを踏まえてTimesTenがどのような個所に適しているのか、その適用事例を紹介します。

　TimesTenはもともとテレコムや金融業界をターゲットとして開発されてきた製品です。テレコムであれば、携帯キャリアや通信事業など顧客が数千万規模でトランザクションが大量に発生するようなシステム、金融であれば株価やニュースが大量に流れてくるオンライン証券などが適用例としてあげられます。

　そうした中、最近ではWebシステムなどエンタープライズ領域での採用も進んできました。そこで、今回はどの業界のシステムにも代用できるユーザー認証の例をご紹介します。

　まず、図3を参照しながらシステム構成について説明します。Oracle Database 10gにマスタのユーザー情報が格納されています。その中から認証処理に必要なデータをTimesTenへキャッシュしています。

　アプリケーションサーバーからの問い合わせはすべてTimesTenが返すため、Oracle Databaseへの問い合わせは行われません。マスタの更新はOracle Databaseへ直接行います。

　ユーザー認証にどうしてTimesTenが適しているのでしょうか。1つ目の理由が「厳しい性能要件」です。性能要件が数万から数十万TPSの場合、ディスク型RDBMSだけで処理することは困難です。その場合はTimesTenのようなインメモリDBか、独自開発で対応するかの選択となります。ただし独自開発の場合は拡張のたびに改修が必要になることや、アプリケーションの保守・運用面での課題があるため、製品で実現できるものは製品を採用したいという声が強くなっています。

　もう1つの理由が「データ量が小さい」ことです。1ユーザーに必要なデータの量はシステムによって当然異なるため、マスタDBの大きさはさまざまです。しかしユーザー認証に特化して考えた場合、必要な情報はユーザー名やユーザーIDなど一部のデータ（カラム）となります。

　TimesTenは必要なデータ量以上のメモリが必要となりますが、任意のカラムを選択してキャッシュすることが可能なため、たとえユーザー数が数千万といった規模であっても必要なデータ量は少なく済むケースが多いのです。

　導入効果としては、数万TPSの処理をさばくことができるので、性能向上が期待できます。また、Oracle Databaseの負荷軽減も期待できます。ユーザーからの処理はすべてTimesTenまでしか到達しません。Oracle Databaseに発生する負荷はTimesTenと同期をはかるCache Connectの通信と、ユーザー情報を更新するアプリケーションだけになります。そのためOracle Databaseのリソースを別のことに有効活用することができます。

TiemsTen適用のメリットとデメリット

　最後にTiemsTenを適用することのメリットについてまとめます。

　まず、性能検証の結果からもわかる通り、数万TPSや数十万TPSといったディスク型RDBMSでは実現できない高スループットを実現できること、そしてマイクロ秒のレスポンスタイムを実現できることでしょう。

　さらに、ほかのRDBMSと比べて同スループットを実現するために必要なCPUリソースが少なくて済むこともメリットです。TimesTenを配置するマシンのハードウエアスペックを抑えたり、台数削減によるライセンス料を抑えられることが期待でき、結果としてTCOの削減につながります。

　ただこうしたメリットがある一方で、次のようなデメリットがあることも理解しておく必要があります。

　1つ目は、対象となるデータ以上の物理メモリが必要なことです。これは実データのほかに索引や一時領域の分までメモリが必要になるからです。

　2つ目が、性能重視のため監査やセキュリティー機能がないことです。これまで説明してきたようにTiemsTenは速さを重視しているため犠牲になっている機能もあります

　3つ目が、速いのはあくまでも実行部分のみで、SQL解析やフェッチはほかのRDBMSと変わらないことです。よって、不定形のSQLが多いDWHや取得対象行が多いようなシステムでは思ったような効果がでないことがあります。

　このようにTimesTenはどのような処理や要件にも対応できるような汎用的な製品ではありません。ディスク型RDBMSの置き換えとして検討するのではなく、あくまでも向いている処理をTimesTenに抜き出し、それ以外はこれまで紹介してきたRACと連携させることで、信頼性を確保しつつパフォーマンスが期待できるシステムを構築することができます。

　そのためにもアーキテクチャと製品の得手不得手についてよく理解しておく必要があることは頭に入れておいてください。

　「徹底！データベースグリッド」と題し、3回にわたって連載してきました。「第1回：RACが変えるデータベース環境（http://www.thinkit.co.jp/article/96/1/）」では、データベースグリッドとOracle RACの概要について、「第2回：検証！RACの耐障害性と拡張性（http://www.thinkit.co.jp/article/96/2/）」では、検証結果をもとに、RACの耐障害性と拡張性について、そして今回の「第3回：性能検証！インメモリDB」では、少し趣向を変え、RACとインメモリDBの組み合わせについて紹介しました。今回の連載が、皆さまにとって今後のシステム構築の一助になれば幸いです。