Geekly Articles each Day

ソリッドステートドライブ（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および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スレッドで作成されました。 1つのINSERTロードは1つのINSERTクエリで構成されますが、SELECTロードは、それぞれに主キー 、 一意のインデックス 、および非 一意のインデックスを持つ3つのSELECTクエリで構成されます。

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


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

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

I / O速度によって制限される\ "Insert \"ワークロードのパフォーマンステスト結果。

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

1秒あたりのトランザクション数を変更する

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

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

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

CPU機能により制限される\ "SELECT \"ワークロードのパフォーマンステスト結果

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

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操作の数が増加しています。 次の表に、両方のシステムのパフォーマンステスト結果を示します。

I / O速度によって制限される\ "SELECT \"ワークロードでのパフォーマンステスト結果

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

1秒あたりのトランザクション数を変更する

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

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

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

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

テスト結果\ "SELECT \"

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

CPU機能とI / O機能が制限されている場合の1秒あたりのトランザクションのパフォーマンスの違い

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つのデータベースが他のデータベースより優れていることを意味するものではありません。 ハードディスクとソリッドドライブを使用した場合のデータベースの生産性の違いを正確に判断するには、コンピューターを使用する必要があります。 内部目的のために同一のコンピューターを使用することは優先事項ではなかったという事実にもかかわらず、このテストでは機器を非常に慎重に使用しました（を参照 ）。 したがって、このテストの結果は、一般的な教育目的にのみ使用する必要があります。

Source: https://habr.com/ru/post/J118074/

More articles:


All Articles