昨今Oracleを含むEnterpriseのDatabaseからOSS系のDatabaseへの移行を望む声をよく聞きます。私もOracleからAzure Database（PostgreSQLベースのAzureのPaaSサービス）への移行を考える機会がありました。ので、この時に様々調査したことなどを何回かに分けて投稿したいと思います。
脱Oracleのニーズを考える
昨今では「脱Oracle」というキーワードをよく耳にします。一昔前ではありとあらゆるシステムで使われていたOracle Databaseですが、なぜその「Oracle」からユーザは今離れようとしているのでしょうか？私もデータベースエンジニアとして活動をしていますが、Oracle Databaseは非常に使いやすく、高速で、痒い所にも手が届く、RDBMSの中でも抜群に優れているデータベースだと思います。
一方、昨今よく耳にする「Oracleやめたい」の声。まずはこのあたりから考察してみました。
変更され続けるOracle Databaseのライセンス
一つ目の理由はOracle Databaseのライセンスの改定がユーザになかなか受け入れられてないのではないかと言う点です。以下直近の数年での行われたOracle Databaseのライセンスの改定を示します。
※細かい内容については記載しませんのでご注意ください。
| 年 | 内容 |
|---|---|
| 2009年 | 冗長化構成における待機系を課金対象に変更 |
| 2013年 | Oracle Advanced Securityの価格を30%アップ |
| 2014年 | Oracle Diagnosticks Packの価格を50%アップ |
| 2015年 | Oracleの全製品を対象に10％アップ |
| 2015年 | Oracle Database SE Oneを廃止しSE2に統合 |
| 2017年 | Oracle Databaseの他社クラウド向けライセンス内容の変更 |
| 2019年 | Oracle DatabaseのSE RACの事実上の廃止 |
一つ一つを紐解くと、単純な値上げではなく、機能の拡張だったり、機能統合による物だったりすると思いますが、ユーザから見ると「単純な値上げ」と印象づいてしまったのかもしれません。
このようにOracle Databaseのライセンスや価格が変更され続けてしまった、あるいは単純な値上げであると印象づいてしまった背景がユーザがOracle Database離れに走る要因となったのかもしれません。
難しいライセンスの考え方
Oracle Databaseのライセンスに関してはユーザにとって少しややこしい部分があります。こういった部分も影響しているかもしれません。
更新時調整率の導入
2011年11月以降に更新されるサポート契約は、前年度料金をベースとした変動制の導入となり、実質的に毎年保守料の値上げされます。仮想化ポリシー
Oracle製品がインストールされる（又は稼働する）物理サーバーの全プロセッサがライセンスカウントの対象となります。仮想化環境の設定を変更することで、物理サーバー間で仮想マシンが移動可能な場合には、Oracle製品の移動元/移動先の両方にライセンスが必要となります。サービスレベルの一致
サポートサービスのレベルの一致が必須。テクニカル・サポートを購入する場合、どのライセンス・セットにおいても、全てのライセンスが同じテクニカル・サポート・サービスのレベルでサポートされていなければならない。
ライセンス料、保守料が高額だと感じている？！
これはOracle Databaseだけの話ではなく、エンタープライズ向けRDBMS製品全般に関してですが、ユーザはRDBMSの「ライセンス料」、「保守料」が高額であると感じているのかもしれません。
一方でOSS系のDatabaseは昨今すごい進化を遂げてきており、機能も非常に充実してきました。エンタープライズ向けのRDBMSと遜色ないレベルまで進化してきています。「OSSの進化」を背景にエンタープライズ向けのRDBMSが高額であるとユーザは考え出したのかもしれません。
なぜPostgreSQLなのか？
OSS系のRDBMSで代表的なデータベースはMySQLとPostgreSQLだと思います。一方で、Oracle Databaseの移行先としてはPostgreSQLを選定することが多くあります。なぜOracleの移行先としてPostgreSQLが人気であるのか？このあたりを見ていきます。
PostgreSQLの機能の豊富さ
1つ名はPostgreSQLの機能の豊富さです。以下に代表的な機能をOracle EE、PostgreSQL、MySQL(InnoDB)で表記します。
| Oracle EE | PostgreSQL | MySQL | |
|---|---|---|---|
| JOIN方式 | 〇 | 〇 | △ (一部未対応) |
| 行ロック | 〇 | 〇 | 〇 |
| トランザクション処理 | 〇 | 〇 | 〇 |
| 読み取り一貫性 | 〇 | 〇 | 〇 |
| ストアドプロシージャ | 〇 | 〇 | 〇 |
| トリガー | 〇 | 〇 | 〇 |
| マテリアライズドビュー | 〇 | 〇 | 〇 |
| 全文検索 | 〇 | 〇 | 〇 |
| オンラインバックアップ | 〇 | 〇 | 〇 |
| Point In Time Recovery | 〇 | 〇 | 〇 |
| パーティショニング | 有償オプション | 〇 | 〇 |
| テーブルスペース | 〇 | 〇 | 〇 |
| レプリケーション | 有償オプション | 〇 | 〇 |
| クラスタリング | 〇 （一部有償オプション） |
〇 | 〇 |
この中でもJOINの形式が特に重要となります。Oracle Databaseの場合、複数のテーブルと結合したりする処理が多かったりしますが、MySQLよりもPostgreSQLの方がJOINの方式の豊富だったりします。すなわち、複雑なSQLになると、JOIN方式が豊富にある方が高速であり、Oracle Databaseの場合、複雑なSQLで実行されているケースが多いので、この点において、MySQLよりも優れているという事になります。
技術者の技術転換のしやすさ
その他の理由としては、技術者において技術の転換が容易であるという点です。
Oracle DatabaseとPostgreSQLの構造を図で表していますが、見ていただいてもわかるように、Oracle DatabaseとPostgreSQLの内部構造が非常に似通っている点がわかっていただけると思います。
メモリではOracle DatabaseのSGAに相当するところが、PostgreSQLでは共有メモリです。Oracle Databaseでは専用サーバプロセスをセッションごとに立ち上げて利用することが多いですが、PostgreSQLでもバックエンドプロセスをマスタプロセスからホークして、すなわちCOPYして起動し利用することになります。Oracle DatabaseのデータファイルはPostgreSQLではデータベースにあたり、REDOログファイルはWALファイルになります。
このように、Oracle Databaseと比較的、内部構造が似ているので、Oracle Databaseのエンジニアの技術の転換がしやすいと言われております。ココが大きな理由の２つ目です。
PostgreSQLの進化
最後はPostgreSQLの進化です。近年ではコミュニティも活発になっており、コアの部分のバージョンアップも積極的にされています。PostgreSQLは商用RDBMSと遜色ないレベルにまで進化してきたのが、３つ目の理由となります。
| バージョン | リリース日 | 主な変更点 |
|---|---|---|
| 9.6 | 2016/09/29 | パラレルクエリ、複数の同期スタンバイが可能、postgres_fdwの機能改善 |
| 10.0 | 2017/10/05 | ロジカルレプリケーション、宣言的パーティション、SCRAM認証の追加 |
| 11.0 | 2018/10/18 | パーティショニングの強化、ストアドプロシージャでのトランザクション、クエリの並列処理の高性能化、JITコンパイラ、ユーザエクスペリエンスの改良 |
| 12.0 | 2019/10/03 | JSON Path、生成列（式で計算される列）に対応、各種インデックスの機能追加/性能改善、パーティションニングの機能追加/性能改善、テーブルアクセスメソッドに対応 |
最後に
このように、Oracle Databaseのライセンスの改定や、OSSの進化を背景にユーザは「OracleからOSSへの移行」を考えるようになったと考察します。その以降先はPostgreSQLです。機能も豊富で技術の転換も容易である。Oracleの移行先としてPostgreSQLが注目を集める理由です。
次回は
今回は「脱Oracle」の背景に関する考察や、「Why PostgreSQL」に関して記載しました。次回以降はテクニカルな話にを記載します。