2017年データベースの選択は? (第1回)

どんなデータベースがあるの?

2017年のdb tech showcaseでご好評を頂きましたので本ブログでそのセッションの内容について再度ご紹介していきたいと思います。db tech showcaseでは、HadoopやNoSQLさらにGPUデータベース、時系列データベースなどの最新技術をご紹介させて頂きましたが既存のRDBMSが減ってしまっているのか?と言うと、そんなことはありません。私のセッションでもご紹介させて頂きましたがデータベース種別は、適材適所でデータベースが活用される場が広がっています。

上記のランキングは、db-engines.comというサイトでのランキングです(2017年10月)。
どのデータベースに人気があるのかをウェブサイトでの記述数やIT関連のQAサイトにおける質問数と関心のあるユーザ数などから求められています。売上げや利益といった観点でのシェアやランキングは、多く存在しますがOSS系のデータベースは、対象外になってしまいますのでどんなデータベースが良く使われているのかという点では、面白いランキングです。
このランキングでも上位に来ているのは従来から多くのシステムで稼働しているRDBMSですが、やはり代表的なのはOracle、SQL Server、PostgreSQL、MySQLといったところであることは、異論無いと思います。
今回は、OSSデータベースの代表PostgreSQLとMySQLをOracleと様々な観点で比較してみたいと思います。

データベースライセンス比較

Oracleのライセンスは、ご存じのように大きくは、Enterprise Edition(EE)とStandard Edition 2(SE2)に分けられ、SE2は、EEに比較していくつかの機能が限定されています。ライセンス価格は、プロセッサライセンスとユーザ数の2種類の形態があります。ここでは、プロセッサライセンスを元に考えてみます。ライセンス価格を求める場合、EEの場合には、CPUコア数が基準価格に掛けられてライセンス価格が決まります(マルチコアCPUの場合には、「適用係数」が設定されており、ディスカウントされる場合があります)。SE2の場合は、CPUソケット数が基準価格に掛けられるのでコア数は関係ありませんが1インスタンスあたり最大16CPUスレッドに制限されます。どちらにしても数百万円~数千万円レベルになります。
一方、PostgreSQLやMySQLでは、OSSということで「無償」で使用することも可能になりますが、


PostgreSQL は BSD ライセンスというライセンスに基づき公開されています。このライセンスは、元のライセンス条件の記述(COPYRIGHT というファイルに書いてあります)をソースファイルやドキュメント上に残すことだけを再頒布や再利用の条件とするものです。これを守ってさえいれば、PostgreSQL を改良して他のプログラムに組み込むことができ、またその組み込み後のソースコードを非公開にできるため、PostgreSQL をベースにした別の商用製品などを作ることができます。
(https://lets.postgresql.jp/documents/tutorial/pgsql-guidebook/2 より抜粋)


MySQLのライセンスはサーバ/クライアントの区別なく、GPL(GNU General Public License)か、コマーシャルライセンスのいずれかの形態を選択するデュアルライセンス方式。
(https://www.mysql.com/jp/about/legal/licensing/oem/)


とありますので記載されているライセンスに従って使用することが必要です。
但し、MySQLは、Oracle社による年間サブスクリプションが提供されており、サポートを受けたり、エディション毎にオプション機能を使用することが可能です。

また、PostgreSQLとMySQLは、派生したデータベースが多くあり、特にPostgreSQLから派生したデータベースは、広く商用データベースとしても活用されています。

データベース機能比較

Oracle/PostgreSQL/MySQLの機能を比較してみましょう。全ての機能を羅列してしまうと大変なことになってしまうので独断になりますが、自分の経験的に良く使って気になる項目について比較してみました。

基本機能比較

まず、PostgreSQLで他の2つのデータベースと異なるのがストレージの管理方法が追記型であるということです。下図を参照してもらえるとわかりますが、PostgreSQLは追記型であるということです。つまり、既存のデータの書き換えを行うことなく空いている領域を使って更新データを追記しています。これがPostgreSQLでバキューム(VACUUM)処理が定期的に必要とされるわけです。一昔前までは、このバキューム処理が重いだの面倒だなどの話もありましたが最近のバージョンでは、自動バキュームデーモンでバキューム処理させることで、あまり気にする必要は無くなったと言われています。

・データ型やプロシージャーは、多少の差はありますがそれぞれ対応する型は、揃っていますのでどのデータベースを選択しても問題ありません。
・MySQLでは、チェック制約はトリガーで実装する必要があります。
・MySQLには、シーケンスがありませんが自動インクリメント列が定義出来るので、実質的には問題ありません。
基本機能としては、どのデータベースでも(当たり前ですが)大きく不足することはありません。個人的には、よく使うマテリアライズドビューがMySQLに無いくらいがちょっと不便かなと言ったくらいです。

次回は、パーティショニングとパラレル実行処理の観点からの比較をご紹介します。


【2017年データベースの選択は?】連載一覧

2017年データベースの選択は?(第1回)

  • どんなデータベースがあるの?
  • データベースライセンス比較
  • データベース機能比較

2017年データベースの選択は?(第2回)

  • データベース機能比較(続き)
  • Spiderによるスケールアウトパーティショニング

2017年データベースの選択は?(第3回)

  • TPCベンチマークで実行計画と処理時間を比較してみた
  • TPCベンチマークで実行計画と処理時間を比較してみた結果
  • 全体的にみると
  • どのデータベースを使いますか?