introducing spider 20101206(dtt#7)

Spider Storage Engineのご紹介

斯波健徳kentokushiba at gmail dot com

MySQLとは？

MySQLは、オープンソース(ソースコードが公開されている)のリレーショナルデータベースです。

Webサービスと相性がよく、ドワンゴ、Google、Yahoo、楽天、facebook、mixi、gree、DeNAなどで利用されています。

GPLというライセンスに従って、自由に利用、変更、再配布を行うことができます。

ストレージエンジンとは？

MySQLは、プラガブルストレージエンジンアーキテクチャ

というものを採用しており、ストレージエンジンというものを

用途に応じて取り替えることができます。

ストレージエンジンは、データベースの中でデータを

格納したり取り出したりすることを司る部分です。


MySQLサーバ

クライアントクライアント

コネクションプール

perser/optimizer/cache ...etc...

Spider

ストレージエンジンAPI

InnoDBMyISAM

クライアント

MEMORY Blackhole q4m


このようにストレージエンジンが複数あるため、テーブルの

用途に応じて適なストレージエンジンを選択することが

できます。

ストレージエンジンは、テーブル単位で変更可能で、

例えばマスターのテーブルにはMyISAMというストレージ

エンジン、取引情報テーブルにはInnoDBというストレージ

エンジンを使うというようなことが可能です。


ストレージエンジンとその特徴(例)

・MyISAM

トランザクションに対応していないが、その代わり

構造が単純で、参照性能が高い。

並列性が低いが、並列性を必要としないテンポラリ

テーブルなどの用途に向いている。

・InnoDB(InnoDB plugin)

トランザクションに対応している。

OracleやPostgreSQLなどに使い勝手が近い。

現在は主にInnoDB pluginに拡張や改良が

おこなわれている。



・MEMORY

オンメモリで動作するので非常に高速なストレージ

エンジン。トランザクションはサポートしていない。

・BLACKHOLE

どんなにinsertしても、データがたまらないストレージ

エンジン。データはたまらないがレプリケーション用の

ログは残るので、非常に激しいinsertのリクエストを

非同期で反映するために利用される。



・Archive

監査用ログなどひたすらinsertしまくって、

参照(解析)は、あとでじっくり別の場所でやれば

いいような場合に利用されるストレージエンジン。

圧縮されるのでデータサイズがコンパクトで、

高速なinsertが可能。

・CSV

CSV形式のデータを、そのままテーブルとして

利用することを可能にするストレージエンジン。



・q4m

テーブルをキューとして利用するための

ストレージエンジン。

●サイボウズラボ㈱の奥一穂さんが作成。

・Vertical Partitioning

MySQLのテーブルパーティショニングがレコードごとの

分割機能であるのに対し、このストレージエンジンは

カラムごとの分割機能を提供する。

●私が作成。



・mroonga(groongaストレージエンジン)

MySQLで高速かつ並列性の高い全文検索を

可能にするストレージエンジン。

●住商情報システム㈱の池田徹郎さんが作成。

Spiderで分散構成ができるよう、機能拡張を計画中。

・BlitzDB

MySQLのforkであるDrizzle用のストレージエンジン。

Drizzleでトランザクション非対応型のストレージエンジンを

選択する際の、第一の選択肢になっている。

●前坂徹さんが作成。



・Tritonn

MySQL 5.0系のMyISAMを改造して、日本語の全文検索

を可能にしたストレージエンジン。

mroongaはその後継。

●住商情報システム㈱の池田徹郎さんが作成。

・XtraDB

InnoDBのPerconaチューニング版ストレージエンジン。

バックアップツールとして、InnoDB Hot Backupを

改良したXtraBackupがある。

●Percona Inc.の木下靖文さんががっつり関係。

その他のプラグイン・UDF

今回プラグインの話なので、ストレージエンジン以外の

プラグインのご紹介(例)

・handlersocket plugin

MySQLのストレージエンジンにKVS的アクセスを

提供するプラグイン。

PK参照750,000qpsを出したことで、世界に注目される

こととなった。(http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html)

●㈱DeNAの樋口証さんが作成。

Spiderで分散構成ができるよう、機能拡張を計画中。




・MySQL full-text parser plugin collection

MyISAMに全文検索機能のパーサ(bigram,mecab,space,suffix,snowball)を追加提供する

プラグイン。

●Kawai Hiroakiさんが作成。




・mregexp

マルチバイト文字(日本語含む)に対応した正規表現を

利用することができるようになるUDF。

●えとらぼ㈱のひろせまさあきさん作成。




・テーブルに直接アクセスするUDF

実用的に利用されている例は聞いたことはないが、

InnoDBは、直接アクセスすれば非常に高速である

ということを証明するという点で、大きな役割を果たした。

●サイボウズラボ㈱の奥一穂さん作成、

●㈱DeNAの松信嘉範さん作成など

複数タイプが作成されている。




・spider_direct_sql

Spiderストレージエンジンをインストールすると、

おまけで利用できるようになるUDF。

リモートのMySQLサーバに任意のSQLを発行できる。

複数のリモートMySQLサーバで集計した結果を、

ローカルMySQLサーバに集めて２段階で集計する

用途などで利用する。

●私が作成。

Spiderストレージエンジンとは？

Spiderストレージエンジンとは、これらストレージエンジンの

１種で、複数のデータベースサーバにあるテーブルを

束ねて、１つのテーブルとして利用することを可能に

します。

これは、クラウド環境においては、増え続けるデータを、

サーバをどんどん増やしながら分割して管理する

ために利用することができます。

Spiderを利用した構成例

アプリケーションはSpiderの入ったMySQLに

SQL(参照/更新)を実行すると、Spiderが透過的に

後ろにあるデータノードにアクセスして結果を返します。

SQLは、DB１台だったときと同じものでOKです。

AP

DB

DB

AP

DB

DB

LB

Spiderを利用した構成例

トラフィックが増えたり、データが増えたりした場合は、

このようにサーバを追加して、負荷分散を行います。

AP

DB

DB

AP

DB

DB

LB

AP

DB

DB

AP

DB

DB

Spiderでクラウド対応

Spiderを使うと、トラフィックやデータ量に

合わせてサーバを追加(削除)していくことが

できるので、クラウド環境において、

伸縮自在のRDBを構築することができます。

1. Spiderストレージエンジンは、ローカルDBからリモートDBに対してテーブルリンクを生成

2. Spiderは、「database sharding」を実現可能

3. Spiderは、「XAトランザクション」と「テーブルパーティショ

ニング」を利用可能

4. Spiderは、GPLライセンスで公開中

http://spiderformysql.com

「Spider」の主な機能

テーブルリンク

Spiderは、リモートMySQLサーバのテーブルをローカルMySQLサーバのテーブルのように利用することを可能にします。

DB1

Local DBtbl_a

tbl_a

tbl_b

Create table tbl_a (col_a int,col_b int,primary key(col_a)

) engine = SpiderConnection ‘host “DB1”,table “tbl_a”,user “user”,password “pass”‘;

3.Join1.Requestselect tbl_a.col_a,

tbl_b.col_cfrom tbl_a, tbl_bwhere tbl_a.col_a = 1 and

tbl_a.col_b = tbl_b.col_b

2.Get data

4.Response

tbl_a Spider Storage Engine’s table

tbl_a Other Storage Engine’s table



3. Spiderは、「XAトランザクション」と「テーブルパーティショニング」を利用可能



「Spider」とは

SpiderのXAトランザクション

SpiderはDBクラスタリングに利用可能です。

DB2

Local DBtbl_a

tbl_b

1.Requestcommit

2.XA prepare

4.Response

tbl_b tbl_c

DB1tbl_a

DB3tbl_c

2.XA prepare2.XA prepare3.XA commit 3.XA commit 3.XA commit

my.cnf------------------…………spider_internal_xa=1…………

Spiderのテーブルパーティショニング

Spiderは「DB sharding※」をサポートしています。※「DB sharding」とは、データを複数のデータベースサーバに分散させて管理する手法のことを言います。

DB1

Local DBtbl_a

tbl_a

tbl_b

Create table tbl_a (col_a int,col_b int,primary key(col_a)

) engine = SpiderConnection ‘table “tbl_a”,user “user”,password “pass”‘partition by list(mod(col_a, 3)) (partition pt1 values in(0)comment ‘host “DB1”’,partition pt2 values in(1)comment ‘host “DB2”’,partition pt3 values in(2)comment ‘host “DB3”’

);

3.Join

1.Requestselect tbl_a.col_a, tbl_b.col_c from tbl_a, tbl_bwhere tbl_a.col_a = 1 and tbl_a.col_b = tbl_b.col_b

2.Get data

4.Response

DB2tbl_a

DB3tbl_a

col_a%3=2col_a%3=1col_a%3=0



3. Spiderは、「XAトランザクション」と「テーブルパーティショ

ニング」を利用可能



「Spider」とは

Spiderの「DB SHARDING※」

※「DB SHARDING」とは、データを複数のデータベースサーバに分散させて管理する手法のことを言います。

アプリケーションによる「DB sharding」

アプリケーションによる「DB sharding」は、

データの増加や更新リクエストの増加に伴う

パフォーマンスの低下の問題を解決するために

利用されます。


アプリケーションによる「DB sharding」は

データ増加に伴うパフォーマンスの低下問題を解決します。

DB1tbl_a

1.Requesttbl_a.col_a = 1

2.Choose a connection and get data

3.Response

DB2tbl_a

DB3tbl_a


AP1 AP2 AP3


しかし…アプリケーションによる「DB sharding」には、

以下の問題点が挙げられるます。

– 異なるDBサーバのテーブルをjoinできない

– 異なるDBサーバに行われた更新の同期は、アプリケーションで保障しなければならない

– アプリケーションエンジニアは、「database sharding」を実現するために高いDBスキルが必要

– 「database sharding」が実装されていないアプリケーションに、新たに「database sharding」を追加するには、多くの時間と工数が必要になる

Spiderの「DB sharding」

Spiderはこれらの問題を解消します。


Spiderの「DB sharding」は

データ増加に伴うパフォーマンス低下問題を解決します。

DB1tbl_a

1.Requestfrom client

tbl_a.col_a = 1

3.Choose a connection and get data

5.Responseto client

DB2tbl_a

DB3tbl_a


AP1 AP2 AP3

DB

tbl_a

2.Requestfrom application

DB

tbl_a

DB

tbl_a

4.Responseto application


そして…

– 異なるDBサーバのテーブルをjoinできる

– アプリケーションは、異なるDBサーバに行われた更新の同期を保障する必要がない(Spiderが保障する)

– アプリケーションエンジニアは、「DB sharding」を実装する必要がない

– 「DB sharding」が実装されていないアプリケーションでも、アプリケーションを変更しないで「DB sharding」を実現できるため、導入が容易である

導入事例

【導入事例1】 Sagool.tv

Sagool.tvは、

www.youtube.comのような動画サイトです。

ただし、全てのコンテンツはインターネットからクロールされ、

動画は、TVのように流し見することができます。

Sagool.tvは、

【Team Lab Inc. ]

が運営しています。

http://www.team-lab.com

http://www.team-lab.net

Sagool.tv (検索ページ)

Sagool.tv was created by Team Lab Inc.

Sagool.tv (動画再生ページ)

Sagool.tv was created by Team Lab Inc.

Sagool.tvの変更前構成図

バッチ処理は、毎日全文インデックスを生成する必要があります。

MasterDB

1.Get data

MasterDB

Full-textsearch

replication

AP AP Batch

2.Register

SlaveDB

SlaveDB

…… Full-textsearch

……

…… Batch ……

Crawler Crawler ……

again, again…

当時のSagool.tvの問題点

しかし…

動画のレコードが増加するに従い、DB参照性能が

低下していき、

３０００万レコードを超えた時には、バッチ処理が２４時間で

完了しなくなっていました。

このケースでは、サーバにMySQL clusterを導入するために

十分なメモリがなかったため、 MySQL clusterは導入できませんでした。

そのため、Spiderを使いました。

SPIDER利用後のSagool.tvの構成図

まず、Spiderを利用したスレーブDBと

４つのリモートDBを追加しました。

次に、バッチサーバにSpiderを利用したMySQLを追加しました。

MasterDB

MasterDB

Full-textsearch

replication

AP AP Batch

2.RegisterSlave

DBSlave

DB…

Full-textsearch

…

…Batch

…

Crawler Crawler …

DBtbl_a

DB

tbl_a

DBtbl_a

DBtbl_a

DBtbl_a

col_a%4=0

col_a%4=1 col_a%4=2

col_a%4=3Data sharding by Spider

1.Get data

DB DBtbl_atbl_a

again, again…

replication

1.Get data

Sagool.tv: パフォーマンスの改善

結果

1. Spiderを利用したshardingで、各DBサーバのレコードを減らすことにより、パフォーマンスが劇的に改善しました。

– DBのパフォーマンスは約１０倍改善。

– バッチ処理は約５倍改善。

(バッチ処理は8時間で完了するようになりました)

2. Spiderの導入にアプリケーションの変更は不要でした。

3. Spiderは問題が発生している場所にピンポイントで導入できるので、動作確認工数が少なく済みました。

SPIDERの「SHARDING」は簡単です。

【導入事例２】 KADOKAWord.jp

角川グループはメディア、本、商品などの、多くの

ウェブサイトを運営しています。(80以上)

KADOKAWord.jpは

株式会社角川メディアマネジメント

が運営しています。

KADOKAWord.jpは、これらのウェブサイトの

コンテンツを横断的に検索できるサービスです。

KADOKAWord.jpで利用されるSPIDERについて

KADOKAWord.jpでは、

BlackholeとSpiderを利用しています。

なぜなら・・・

グループサイトからの急激なログトラフィックが

あるためです。

KADOKAWord.jp: ログサーバ構成図

現在、

急激なログトラフィックがあっても、問題は発生していません。

AP

…

replication

StatisticalDB

DB

AP

DB

tbl_a

DB

tbl_aDB

tbl_a…

tbl_a tbl_a

1.Write log

2.Replication3.Log data collecting

using Spider

Blackhole

【導入事例３】株式会社マイクロアド

株式会社マイクロアドは行動ターゲティングというテクノロジーで、

配信する広告を適化できる広告配信サービスを提供している企業です。

http://www.microad.jp/【MicroAd, Inc.]

Spider導入前構成

このシステムでは、バッチ処理が毎日新しい統計結果で、

広告配信のルールを更新する必要があります。

MasterDB

replication

AP AP

Batch

Register new statistical rules from batch server

SlaveDB

SlaveDB

…… AP AP ……

LVS

事業拡大に伴う課題

・更新負荷の増大これまで1日につき、2000万レコードの更新が限界だったものを、事業拡大に伴い1億レコードを更新できるようにする必要があった。

・参照負荷の増大基本的にはレプリケーションスレーブを追加することで対応するが、1台あたりの更新が減らないと、スレーブ追加のメリットが薄れる。

・アプリケーション修正データベース分割の為に、大幅なアプリケーションの修正は避けたい。

そのために、Spiderが選択されました。

Spider導入後構成

彼らは、データベースの分割の単位で

レプリケーションを構成するという手法を

採用しました。

MasterDBreplication

APwith Spider

APwith Spider

Batch

Register newstatistical rules from batch server

SlaveDB SlaveDB

…… APwith Spider

APwith Spider

……

LVS

SlaveDB SlaveDB

LVS

SlaveDB SlaveDB

LVS

MasterDBreplication

MasterDBreplication

SpiderDB(MySQL with Spider)

Spider sharding

Spider sharding

改善結果

その結果、彼らは、毎日１億レコードの更新という目標を達成し、

参照性能の向上にも成功しました。

また、データベース分割のためのアプリケーションの

修正は、ほとんど不要でした。

彼らは現在、事業の更なる拡大のため、データベース

の再拡張(re-sharding)を計画しています。

Spider Storage Engine

まとめ

Spider Storage Engineは・・・・・

1. 他のストレージエンジンと連携することで、その機能を強化・拡張することができる。

2. リモートのMySQLサーバにあるテーブルを、ローカルのMySQLサーバにあるテーブルとして利用する事ができる。

3. XAトランザクションで、複数のサーバに行われた更新を同期することができる。

4. MySQL 5.1から利用可能となったテーブルパーティションをサポートしており、テーブルの各パーティションはそれぞれ別のサーバを利用することができる。

これら４つの機能により・・・・・

Spiderはトランザクション機能付で「DB sharding」を実現できる。Spiderはアプリケーションの機能性を損なうことなく「Sharding」を実現できる。

(このあたりがクラウド対応RDB構築用)Spiderの導入に、アプリケーションは変更の必要がない。Spiderは必要なところだけにピンポイントで利用できる。

まとめ

http://wild-growth.blogspot.com/http://spiderformysql.com

Kentoku SHIBA (kentokushiba at gmail dot com)

Any Questions?

Thank you for taking

your time!!

introducing spider 20101206(dtt#7)

Documents