読者です 読者をやめる 読者になる 読者になる

データベース処理の高速化を図る。-Insert編-

皆さん、お久しぶりです。

サーバーサイドエンジニアの福田です。

前回のブログは第一回のマーケティング、ファンネルに関して書かせて頂いたので、今回は技術的なお話を書きたいと思います。

 

さて、弊社の運用するサービス、WonderfullはECアプリであり、アプリ内で商品の購入を行うことが出来ます。

こちらのサービスの根底となるのがECオープンプラットフォームであるEC-CUBEであり、弊社Wonderfullアプリもサーバー側はEC-CUBEを用いて開発がされています。

縁の下の力持ちであるEC-CUBEですが、ECサービスを提供する為、非常にデータベースとの関連性が深いです。

アプリ上で掲載する商品情報の管理。受注情報の管理。各サプライヤーさんの情報管理。商品はカテゴリー分けされてるからカテゴリーの管理。。。などなど、多くデータの管理を必要とする為、データベースの扱い一つ変えるだけでサービスの向上、または低下などを招いてしまうことになります。

 

普段は気づきにくいですが、よくお聞きするAmazon楽天、Wonderfullのサービスのように、皆さんの生活の中でもデータベースが深く根付いております。

 

今回、データベースを扱う上で一番処理が重いとされる、Insert処理。データを追加する処理を高速化するにはどうしたらよいか考えてみましょう。

まず、Insertの処理方式を次の3つで考えてみましょう。

①1件ずつのInsert

②1回の発行で複数行のデータをインサート(マルチプルインサート)

③バルクロード(大量のデータを一括ロード)

 

各インサート処理に関して、例として、「データ長約200bytes、100万件(約200Mbytes)のデータ」を投入した場合の比較を行っていきましょう。

インサート処理1インサートの行数MySQL 5.0.79(Innodb)
1件ずつのInsert ※ - 25459(単位:秒)
マルチプルインサート 1000行 78.86
バルクロード - 31.99

※ 遅すぎたので1000件分を計測し×1000で算出

 

上記の結果のようにインサートの形式により、処理にかかる時間が大幅に変わっていきます。

今回の結果は100万件という非常に膨大なデータを扱っていますが、インサート処理の方法一つとっても、処理能力に差があるため、その場その場で適した方法を選択する必要があります。

 

参考:インサート(insert)の処理方式別のパフォーマンスを検証 | 株式会社インターオフィス