ソリッドステートドライブ（SSD）を使用する前後のCUBRIDとMySQLのパフォーマンスのベンチマーク結果

みなさん、こんにちは！



ついにHabrが獲得しました。そして今、私は英語で公開された記事の翻訳をCUBRIDプロジェクトの公式ウェブサイトに投稿することができます。

1.テストについて

次のデータベースシステムのパフォーマンス分析では、CUBRIDとMySQLをテストして、2つの異なる状況でのパフォーマンスを判断します。

1. システムがハードドライブを搭載したサーバーで実行されている場合。
2. ソリッドステートドライブを搭載したサーバーでシステムが実行されている場合。

1.1。 簡単な説明

一般に、データストレージはあらゆるデータベースシステムの主要なタスクであると考えられています。 ハードドライブは、企業が大量のデータを保存するために使用する一般的なメディアです。 ただし、ハードディスク（I / O）のパフォーマンスは、 I / Oバウンド速度によって制限されるワークロードの下で低下することが知られています。 そのため、多くの場合、より効率的なストレージメディアを見つける必要があります。 この記事では、データベースパフォーマンスの向上を実証する、データストレージのメインストレージメディアとして使用される新しいソリッドステートドライブ（SSD）のアプリケーションとテストの結果を紹介します。

1.2。 試験方法

テストを実行するために、各データベースシステム（CUBRIDとMySQL）を2つの別々のサーバーにインストールしました。1つはハードドライブ、もう1つはソリッドステートドライブです。 1秒あたりのトランザクションのパフォーマンスの向上は、実験全体を通じて継続的に記録されました。

1.3。 コンピューター環境をテストする

以下は、ハードドライブとソリッドステートドライブを搭載したコンピューターの仕様です。 ハードドライブとSSDを使用しているときにデータベースのパフォーマンスの違いを正確に判断するには、コンピューターが同じでなければなりません。 内部目的のために同一のコンピューターを使用することは優先事項ではなかったという事実にもかかわらず、このテストでは非常に類似した特性を持つ機器が依然として使用されました。







CUBRIDおよびMySQLデータベースシステムは、ハードドライブとSSDを搭載したコンピューターにインストールされました。 テスト時には、次のデータベースバージョンが使用されました。

• CUBRID 2008 R3.0
• MySQL 5.1.47（innoDB）

以下は、CUBRIDおよびMySQLデータベースシステムのデフォルト構成です。 両方のデータベースサーバーは、4 GBのデータバッファーで構成されました。 他のテスト設定はデフォルトで使用されました。



CUBRID構成（cubrid.conf）



[service]

service=server,broker,manager



[common]

data_buffer_pages=25000

sort_buffer_pages=16

log_buffer_pages=50

lock_escalation=100000

lock_timeout_in_secs=-1

deadlock_detection_interval_in_secs=1

checkpoint_interval_in_mins=720

isolation_level="TRAN_REP_CLASS_UNCOMMIT_INSTANCE"

cubrid_port_id=15097

max_clients=50

auto_restart_server=yes

replication=no

java_stored_procedure=no



checkpoint_every_npages=100000000

data_buffer_pages=262144

error_log_level=notification

communication_histogram=yes

num_LRU_chains=200

async_commit=yes

group_commit_interval_in_msecs=1000







MySQL構成（my.cnf）



[client]

socket = /home1/mysql/mysql/tmp/mysql.sock



[mysqld]

user = mysql

port = 3306

basedir = /home1/mysql/mysql

datadir = /home1/mysql/mysql/data

tmpdir = /home1/mysql/mysql/tmp

socket = /home1/mysql/mysql/tmp/mysql.sock



default-character-set = utf8

default_table_type = InnoDB

skip_name_resolve



back_log = 100

max_connections = 500

max_connect_errors = 999999

max_allowed_packet = 16M

max_heap_table_size = 64M

tmp_table_size = 64M

binlog_cache_size = 1M

thread_cache_size = 128



table_cache = 1024

sort_buffer_size = 8M

join_buffer_size = 8M

read_buffer_size = 2M

read_rnd_buffer_size = 16M

query_cache_size = 64M

query_cache_limit = 2M



# MyISAM options

key_buffer_size = 32M

bulk_insert_buffer_size = 64M

myisam_sort_buffer_size = 128M

myisam_max_sort_file_size = 10G

myisam_max_extra_sort_file_size = 10G

myisam_repair_threads = 1

myisam_recover

ft_min_word_len = 4



# INNODB options

innodb_buffer_pool_size = 4G # 50 ~ 70% of main memory

innodb_log_buffer_size = 8M

innodb_additional_mem_pool_size = 16M

innodb_data_file_path = ibdata1:100M:autoextend

innodb_file_per_table

innodb_log_file_size = 256M

innodb_log_files_in_group = 3

innodb_support_xa=0

innodb_thread_concurrency = 16

innodb_lock_wait_timeout = 60

innodb_flush_log_at_trx_commit = 0 # 0 for slave, 1 for master



# Loging Configuration

log-bin=mysql-bin

expire_logs_days=5

log_warnings

log_slow_queries

log_slow_admin_statements

long_query_time = 2

log_long_format



# Replication setting

server-id = 1

1.4。 テストスクリプト

1.4.1。 テストで使用したテーブルレイアウト

パフォーマンス結果を測定するために、40個のtbl_200〜tbl_239テーブルが下の図で作成されました。

  CREATE TABLE tbl_200;

 ALTER TABLE tbl_200列の追加
	さまざまなID文字（20）NOT NULL、
	 seq integer NOT NULL、
	 col3文字可変（16）NOT NULL、
	 col4文字可変（5）NOT NULL、
	 col5文字可変（50）NOT NULL、
	 col6文字可変（1000）、
	 col7文字可変（300）NOT NULL、
	 col8文字可変（150）、
	 col9タイムスタンプNOT NULL、
	 col10 smallint DEFAULT 0 NOT NULL、
	 col11タイムスタンプNOT NULL、
	 col12文字可変（15）NOT NULL、
	 col13文字（1）NOT NULL、
	 col14文字（1）NOT NULL、
	 col15 timestamp DEFAULT timestamp '04：25：44 PM 07/30/2010 'NOT NULL;

 ALTER TABLE "tbl_200" ADD PRIMARY KEY（ "id"、 "seq"）;
 CREATE UNIQUE INDEX "iuk_tbl" ON "tbl_200"（ "id"、 "col3"、 "col4"、 "col5"）;
 CREATE INDEX "ink1_tbl" ON "tbl_200"（ "id"、 "col9" DESC、 "col14"）; 

テストテーブルの作成に必要な上記のテーブル図を使用して、ハードディスクとソリッドステートドライブを装備したマシンは、3種類のテストに合格しました。

• 40のテーブルに2500万のデータレコードを挿入するデータベースを作成した後、30分間「INSERT FULL」ロードでパフォーマンスを測定します。
• 6400万のデータレコードを40個のテーブルに挿入するデータベースを作成した後、CPUバウンドによって制限される「SELECT」負荷でパフォーマンスを測定します。
• 6400万のデータレコードを40個のテーブルに挿入するデータベースを作成した後、I / Oバウンドによって制限される「SELECT」負荷でパフォーマンスを測定します。

上記の負荷はすべて40スレッドで作成されました。 1つのINSERTロードは1つのINSERTクエリで構成されますが、SELECTロードは、それぞれに主キー 、 一意のインデックス 、および非 一意のインデックスを持つ3つのSELECTクエリで構成されます。

2.テスト結果のレビュー

2.1。 I / O速度によって制限される挿入ワークロードでテストする

各テーブルに約625,000個のデータレコード（合計2500万個）が含まれる40個のテーブルを含むデータベースを作成した後、両方のコンピューター（ハードディスクとSSDを搭載）でFULL INSERT負荷を使用したパフォーマンステストを30分間行いました。 次の表に、パフォーマンステストの結果を示します。







次の図は、1秒あたりのトランザクション数の変化を示しています。







「全挿入」負荷を使用した上記のテストの結果に基づいて、次の結論を導き出すことができます。

• SSDを搭載したコンピューターでのCUBRIDデータベースシステムのパフォーマンスは、ハードドライブを搭載したコンピューターでのパフォーマンスの約5倍です。
• ソリッドステートドライブを搭載したコンピューターでのMySQLデータベースシステムのパフォーマンスは、ハードドライブを搭載したコンピューターでのパフォーマンスの約2.5倍です。 （ 注：ソリッドステートドライブを搭載したコンピューターでは、MySQLはリソースを100％でロードしないため、パフォーマンスをさらに向上させることができます）。

2.2。 CPU機能により制限されたSELECTワークロードでテストする

各テーブルに約1,600,000個のデータレコード（合計6,400万個）が含まれる40個のテーブルを含むデータベースを作成した後、両方のコンピューター（ハードディスクとSSDを搭載）でパフォーマンスをテストし、CPU容量によって10分間負荷を制限しました。 SELECTクエリを使用した特定のロードでは、メモリバッファに必要なページを完全に配置し、目的の100％バッファパフォーマンス値を維持するために、クエリ検索領域を狭める必要があります。 I / O操作はこの負荷では実行されないため、ハードドライブとSSDを搭載したコンピューターのパフォーマンスの違いは、I / Oを除くすべてのコンポーネントで測定されます。 次の表に、パフォーマンステストの結果を示します。







次の図は、1秒あたりのトランザクション数の変化を示しています。







I / O操作がない場合、ソリッドステートメディアを使用したCUBRIDのパフォーマンスはハードドライブと比較して約17％低下し、MySQLのパフォーマンスは約6％向上します。 両方のコンピューターのI / Oを除くすべてのコンポーネントのパフォーマンスの違いは上記のとおりです。

2.3。 I / Oレートによって制限されたSELECTワークロードでテストする

各テーブルに約1,600,000個のデータレコード（合計64百万個）を含む40個のテーブルを含むデータベースを作成した後、両方のコンピューター（ハードディスクとSSD）でパフォーマンステストを実施し、負荷はI / O速度によって制限されました10分 必要なページをメモリバッファに完全に配置せず、ページの頻繁な置き換えを防ぐために、このロードのSELECTクエリの検索領域を拡張する必要があります。 ワークロードが非常に激しいため、I / O操作の数が増加しています。 次の表に、両方のシステムのパフォーマンステスト結果を示します。







次の図は、1秒あたりのトランザクション数の変化を示しています。







入出力の速度によって制限される負荷 "SELECT"を使用した上記のテストの結果によれば、次の結論を導き出すことができます。

• SSDを搭載したコンピューターでのCUBRIDのパフォーマンス（1秒あたりのトランザクション数）は、ハードドライブを搭載したコンピューターと比較して約4.2倍向上します。
• ソリッドステートドライブを搭載したコンピューターでの1秒あたりのトランザクション数におけるMySQLのパフォーマンスは、ハードドライブを搭載したコンピューターと比較して約2.8倍向上します。

したがって、速度とI / Oが制限されている状況では、両方のデータベースシステムのパフォーマンスは、ソリッドステートドライブを使用すると向上します。

2.4。 SELECTテスト結果の体系化

次の表は、上記の2つのテストの結果をまとめたものです。







下の図では、CPU能力によって制限されたテストの結果が左の列に表示され、I / O速度によって制限されたテストの結果が2番目の列に表示されています。 すべての場合において、CPU能力によって制限されるテスト中のパフォーマンスレベル（1秒あたりのトランザクション数）は、I / O速度によって制限されるテスト中よりも高くなります。 したがって、I / O操作は、データベースシステムのパフォーマンスが低下する主な理由と考えることができます。 実験中に見つかった最も興味深い特性は、ソリッドステートドライブを搭載したコンピューターでCPUの能力によって制限される操作とI / O速度によって制限される操作を実行するときのCUBRIDパフォーマンスのわずかな違いです。 つまり、CUBRIDはおそらくSSDを搭載したコンピューターでの作業を最大限に活用します。 （このテストで使用されるソリッドステートドライブコンピューターのランダムアクセス速度は非常に高いと見なされます）。

3.結論

この実験により、ソリッドステートドライブを搭載したコンピューターでCUBRIDおよびMySQLデータベースシステムのパフォーマンスレベルが向上することが確認されました。 I / O速度によって制限される負荷の下では、CUBRIDのパフォーマンスは4.2倍、MySQLのパフォーマンスは2.8倍になります。 この実験では、CUBRIDおよびMySQLデータベースシステムはSSDコンピューターで構成されていません。 したがって、この実験では、特定のデータベースシステムに対するSSDコンピューターの適合性については説明しません。 それでも、CUBRIDとMySQLはどちらもソリッドステートドライブを搭載したコンピューターで動作するため、I / O速度によって制限される操作のパフォーマンスをさらに向上させることができると結論付けることができます。 将来、同じハードウェア仕様とオペレーティングシステム（他のハードドライブとSSDをインストールすること）で、CUBRIDとMySQLデータベースシステムの最適化された設定でさまざまなテストを行うことで、より興味深い結果を得ることができます。

4.注釈

このテストは、したがって、NO EVENTに同社は、行動の研究は、いかなる直接的、間接的、偶発的、特別、懲罰的、または必然的な損害、本体のみの媒体としてのソリッドステートドライブを使用する場合のパフォーマンスの違いを見つけるために内部で使用するために行われます。データの損失と利益または事業の中断を含む。 このテストの結果は、1つのデータベースが他のデータベースより優れていることを意味するものではありません。 ハードディスクとソリッドドライブを使用した場合のデータベースの生産性の違いを正確に判断するには、コンピューターを使用する必要があります。 内部目的のために同一のコンピューターを使用することは優先事項ではなかったという事実にもかかわらず、このテストでは機器を非常に慎重に使用しました（を参照 ）。 したがって、このテストの結果は、一般的な教育目的にのみ使用する必要があります。