TOP
＞
サーバ構築・運用
＞ 日本語データのバイト数
徹底比較!! PostgreSQL vs MySQLパート2
第３回：実は差があるキャラクターセットの違い
著者：
NTTデータ 藤塚 勤也
2007/5/8
前のページ
1
2
3
日本語データのバイト数
性能測定結果を見ると、UTF-8に変換すると処理時間が大幅に増加する結果となりました。ここで、その原因の1つについて説明します。
まずは表3をみてください。文字「あ」のEUC-JP／Shift-JIS／UTF-8それぞれのキャラクターセットの実際の値を示しています。
キャラクターセット
値（16進数
EUC-JP
A4A2
Shift-JIS
82A0
UTF-8
E38182
表3：文字「あ」の値
このように、EUC-JPやShift-JISでは2バイトのデータであった文字「あ」は、UTF-8に変換すると3バイトのデータに変換されます。よってUTF-8に変換して抽出する場合、サーバからクライアントに転送するデータ量が増加することになります。
単純にいって、同じ文字列でもEUC-JPおよびShift-JISのデータよりUTF-8のデータの場合、1.5倍のデータ量をサーバからクライアントに転送しなければならないということです。
当然ながら、UTF-8の方が処理に必要な時間が多くなります。特に今回の性能測定試験では、抽出したデータをファイルに書き出していますので、抽出データ量が増加すればその分だけファイルに書き出すための処理時間も増加します。
これらの要因から、UTF-8の場合の処理時間が極めて大きく増加したと思われます。
最後に
今回の性能測定では、極力処理時間の差をだすために、あえて10万件ものデータを一気にSELECTする処理で測定しました。通常のアプリケーションでは、1回の処理で複数件のデータしかSELECTしないと思います。よって、キャラクターセットの変換を行っても今回の性能測定結果のような大きな処理時間の差が発生することはないと思います。
データベース内に日本語データを格納する際は、PostgreSQLとMySQLともにサーバとクライアント間の変換機能を活用すると便利です。
一度に大量のデータを扱う処理を行う場合や、限界まで転送量負荷を抑えなければならない場合、多少なりとも影響がでることを頭の片隅に入れて、扱うデータのキャラクターセットを選択していただければと思います。
前のページ
1
2
3
著者プロフィール
株式会社NTTデータ 藤塚 勤也
基盤システム事業本部 オープンソース開発センタ シニアスペシャリスト。
日本タンデムコンピューターズ（現日本HP）を経て、2003年よりNTTデータにてOSS分野に参画。日頃はオリジナルOSSの開発や、OSSを用いたシステム構築への技術支援に従事。「RDBMS解剖学」（翔泳社）を共著。
INDEX
第3回：実は差があるキャラクターセットの違い
日本語データの取り扱い
キャラクターセットの変換性能
日本語データのバイト数
