[Database] How fast is Oracle TimesTen Velocity Scale?

原文はこちら。
https://blogs.oracle.com/timesten/how-fast-is-oracle-timesten-velocity-scale

---

Oracle TimesTen Velocity Scaleは、TimesTen In-Memory Databaseの基盤をベースにしています。TimesTenでは、マイクロ秒の単位という非常に低レイテンシのSQL操作を実現しています。

非常に多くの変動要素があるため、データベース間でApple to Appleでの比較を行うことは困難です。DBベンダーが互いの製品をベンチマークする際、競合他社のDBが最適に調整されていないという疑いが常にあります。以下は、Apple to AppleのDBベンチマークの例です。
2016年8月、Googleは、Sysbench DBの読み取り/書き込みワークロードを使用して、2つのアベイラビリティゾーン間での高可用性構成のOLTP DBベンチマークを公開しました。

Cloud SQL Second Generation performance and feature deep dive 
https://cloudplatform.googleblog.com/2016/08/Cloud-SQL-Second-Generation-performance-and-feature-deep-dive.html
Sysbench : Scriptable database and system performance benchmark 
https://github.com/akopytov/sysbench

Google Cloudに最適化されたGoogle Cloud SQL Second GenerationとGoogleはAWS上でAmazon RDS MySQLとAuroraを実行しましたが、コンサルティング会社（2ndWatch.com）はすぐにベンチマークを再実行し、Amazon Auroraが最適に調整されていないことを示しました。（Amazonからのコンサルティングを受けた）2ndWatchは、AWS AuroraがGoogle Cloud SQL Second Generationより優れた性能を発揮したことを証明できました。

Benchmarking Amazon Aurora
http://2ndwatch.com/blog/benchmarking-amazon-aurora/

これは、OracleではなくDBベンダーが、このベンチマークに対してデータベースが最適に調整されていることを確認したことを意味していました。
このSysbench read/write DBは、2個のアベイラビリティゾーン（データセンター）間での同期レプリケーションを実施しているため、ネットワークのラウンドトリップタイムがTimesTen Velocity Scaleの支配的な要因でした。

上記のスループットベンチマークでの変動要素は、RDBMSとパブリッククラウドです。下図は同じSysbenchベンチマークでのレイテンシ（小さいほどよい）の結果です。

見ておわかりのように、TimesTen Velocity Scaleは最低のレイテンシならびに最高のスループットを叩き出しています。Google Cloud SQL Second GenerationやAmazon RDS MySQLおよびAmazon Auroraは全てactive-standbyレプリケーション構成を使っています。もっと読み取りのスケールのために読み取り専用のレプリカを追加することができるとしても、書き込みのスループットはアクティブなデータベースが一つであるために制限をうけます。Oracle TimesTen Velocity Scaleはactive-activeレプリケーションを使っているため、 Velocity Scaleデータベースにマシンを追加することにより、書き込みのスループットもスケールすることができます。
下図のOLTPベンチマークでは、TPTBMベンチマークを使いread/writeのスケールの様子を示しています。このワークロードは80％が読み取り、20％が書き込みです。

このベンチマークでは、Oracle Bare Metal Cloud（現Oracle Cloud Infrastructure）上の32個のSun X5-2 Linux x86-64マシンを使いTPTBM read/writeワークロードがリニアにスケールすることを示すものです。

Oracle Server X5-2
http://www.oracle.com/us/products/servers/x5-2-datasheet-2312923.pdf 

コミットされた書き込みトランザクションの永続化がボトルネックだったため、マシンごとにVelocity Scaleの2つのインスタンスを使用しました。そのため、32台のマシンで64のVelocity Scaleノードが実行されていました。
書き込みI/Oのボトルネックが発生した場合に、100％読取りワークロードでテストを再実行しました。その結果、64台のマシンを使用して、毎秒120億PKのSQLのSelectという結果になりました。


この100％読取り専用ワークロードでは、Oracle Bare Metal Cloudの64台のSun X5-2 Linuxマシンでリニアにスケールすることがわかります。より高速なマシンでこれらのテストを繰り返すことができればと考えています。
詳細は、Oracle Open World 2017のセッションでご紹介します。

TimesTen and Velocity Scale at Oracle Open World 2017
https://blogs.oracle.com/timesten/timesten-and-velocity-scale-at-oracle-open-world-2017

免責事項：これは私の個人的な考えであり、いかなる形であれ、オラクルの公式見解を表すものではありません。