Spider Storage Engineのご紹介
MySQLとは?
MySQLは、世界で も普及しているオープンソースのリレーショナルデータベースです。
Webサービス、モバイルコンテンツサービスと相性がよく、Google、Yahoo、Facebookをはじめ、多くのWeb、モバイルサービス関連企業で利用されています。もちろん、DeNAさんでも利用されています。
GPLというライセンスに従って、自由に利用、変更、再配布を行うことができます。
ストレージエンジンとは?
MySQLは、プラガブルストレージエンジンアーキテクチャ
というものを採用しており、ストレージエンジンというものを
用途に応じて取り替えることができます。
ストレージエンジンは、データベースの中でデータを
格納したり取り出したりすることを司る部分です。
ストレージエンジンとは?
MySQLサーバ
クライアント クライアント
コネクションプール
perser/optimizer/cache ...etc...
Spider
ストレージエンジンAPI
InnoDBMyISAM
クライアント
MEMORY Blackhole q4m
ストレージエンジンとは?
このようにストレージエンジンが複数あるため、テーブルの
用途に応じて 適なストレージエンジンを選択することが
できます。
ストレージエンジンは、テーブル単位で変更可能で、
例えばマスターのテーブルにはMyISAMというストレージ
エンジン、取引情報テーブルにはInnoDBというストレージ
エンジンを使うというようなことが可能です。
Spiderストレージエンジンとは?
Spiderストレージエンジンとは、ストレージエンジンの
1種で、複数のデータベースサーバにあるテーブルを
束ねて、1つのテーブルとして利用することを可能に
します。
これは、クラウド環境においては、増え続けるデータを、
サーバをどんどん増やしながら分割して管理する
ために利用することができます。
MySQLと同じく、GPLライセンスで公開しています。
Spiderを利用した構成例
アプリケーションはSpiderの入ったMySQLに
SQL(参照/更新)を実行すると、Spiderが透過的に
後ろにあるデータノードにアクセスして結果を返します。
SQLは、DB1台だったときと同じもので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を構築することができます。
「Spider」の主な機能
1. Spiderストレージエンジンは、ローカルDBからリモートDBに対してテーブルリンクを生成
2. Spiderは、「database sharding」を実現可能
3. Spiderは、「XAトランザクション」と「テーブルパーティショ
ニング」を利用可能
「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
1. Spiderストレージエンジンは、ローカルDBからリモートDBに対してテーブルリンクを生成
2. Spiderは、「database sharding」を実現可能
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
Spiderの「DB SHARDING※」
※「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
col_a%3=2col_a%3=1col_a%3=0
AP1 AP2 AP3
アプリケーションによる「DB sharding」
しかし…アプリケーションによる「DB sharding」には、
以下の問題点が挙げられるます。
– 異なるDBサーバのテーブルをjoinできない
– 異なるDBサーバに行われた更新の同期は、アプリケーションで保障しなければならない
– アプリケーションエンジニアは、「database sharding」を実現するために高いDBスキルが必要
– 「database sharding」 が実装されていないアプリケーションに、新たに「database sharding」を追加するには、多くの時間と工数が必要になる
Spiderの「DB sharding」
Spiderはこれらの問題を解消します。
Spiderの「DB sharding」
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
col_a%3=2col_a%3=1col_a%3=0
AP1 AP2 AP3
DB
tbl_a
2.Requestfrom application
DB
tbl_a
DB
tbl_a
4.Responseto application
Spiderの「DB sharding」
そして…
– 異なる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参照性能が
低下していき、
3000万レコードを超えた時には、バッチ処理が24時間で
完了しなくなっていました。
このケースでは、サーバにMySQL clusterを導入するために
十分なメモリがなかったため、 MySQL clusterは導入できませんでした。
そのため、Spiderを使いました。
SPIDER利用後のSagool.tvの構成図
まず、Spiderを利用したスレーブDBと
4つのリモート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 shardingby Spider
1.Get data
DB DBtbl_atbl_a
again, again…
replication
1.Get data
Sagool.tv: パフォーマンスの改善
結果
1. Spiderを利用したshardingで、各DBサーバのレコードを減らすことにより、パフォーマンスが劇的に改善しました。
– DBのパフォーマンスは約10倍改善。
– バッチ処理は約5倍改善。
(バッチ処理は8時間で完了するようになりました)
2. Spiderの導入にアプリケーションの変更は不要でした。
3. Spiderは問題が発生している場所にピンポイントで導入できるので、動作確認工数が少なく済みました。
SPIDERの「SHARDING」は簡単です。
【導入事例2】 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
【導入事例3】株式会社マイクロアド
株式会社マイクロアドは行動ターゲティングというテクノロジーで、
配信する広告を 適化できる広告配信サービスを提供している企業です。
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
改善結果
その結果、彼らは、毎日1億レコードの更新という目標を達成し、
参照性能の向上にも成功しました。
また、データベース分割のためのアプリケーションの
修正は、ほとんど不要でした。
彼らは現在、事業の更なる拡大のため、データベース
の再拡張(re-sharding)を計画しています。
Spider Storage Engine
まとめ
Spider Storage Engineは ・・・・・
1. 他のストレージエンジンと連携することで、その機能を強化・拡張することができる。
2. リモートのMySQLサーバにあるテーブルを、ローカルのMySQLサーバにあるテーブルとして利用する事ができる。
3. XAトランザクションで、複数のサーバに行われた更新を同期することができる。
4. MySQL 5.1から利用可能となったテーブルパーティションをサポートしており、テーブルの各パーティションはそれぞれ別のサーバを利用することができる。
これら4つの機能により ・・・・・
Spiderはトランザクション機能付で「DB sharding」を実現できる。Spiderはアプリケーションの機能性を損なうことなく「Sharding」を実現できる。
(このあたりがクラウド対応RDB構築用)Spiderの導入に、アプリケーションは変更の必要がない。Spiderは必要なところだけにピンポイントで利用できる。
まとめ
「Spider」の 近の動き
1. MariaDB対応
2. BKA対応
3. レプリケーションリトライパッチ
4. 可用性対応
「Spider」の 近の動き
MariaDB対応
MariaDBにバンドルしてもらえるお話を頂きまして、現在
鋭意対応中です。
MariaDBとは、MySQLの生みの親であるMontyとその
会社の社員が開発を行っているMySQLのフォークです。
なお、SpiderはMySQLでも、引き続き利用が可能です。
1. MariaDB対応
2. BKA対応
3. レプリケーションリトライパッチ
4. 可用性対応
「Spider」の 近の動き
BKA対応
BKAとは、大きなテーブル同士のjoinを高速化するための
機能で、現在はMariaDB 5.3で利用可能です。
対応は奥野さんのアドバイスを頂きつつ、このほど完了
しました。(パーティション機能とBKAを組み合わせて
利用するためのパッチも完成しております)
簡単にパフォーマンスを測定した結果では、約35倍の
性能向上となっております。
1. MariaDB対応
2. BKA対応
3. レプリケーションリトライパッチ
4. 可用性対応
「Spider」の 近の動き
レプリケーションリトライパッチ
レプリケーションスレーブでSpiderを利用した際に、
リモートのサーバとの接続がネットワークの瞬断などで
途切れてしまうとレプリケーションがエラーで
停止してしまい、運用上不都合が発生します。
このため、MySQLに「slave_transaction_retry_errors」
というパラメータを追加し、「slave_transaction_retry_errors=1158,1159,2013,12701」
のように、エラー番号をコンフィグファイルに指定することで、
指定したエラーはトランザクションを再実行するパッチを
作成しました。
1. MariaDB対応
2. BKA対応
3. レプリケーションリトライパッチ
4. 可用性対応
「Spider」の 近の動き
可用性対応
Spiderを利用した際の可用性の担保は、現在リモート
サーバ側でDRBDなどを利用して行っていただいて
いると思いますが、現在Spider側でも可用性が担保
できるよう8月末完成を目標に機能開発中です。
この機能は、
・テーブル(パーティション)単位で冗長化の多重度を変更可能。
・ラウンドロビンの参照負荷分散。
という特徴をもつため、よく参照される 近の情報のみ多重度を
高くして、トラフィックをさばくというような使い方も可能です。
おわりに
これからも精力的に
開発を続けていきますので、
よろしくお願いします!!
http://wild-growth-ja.blogspot.com/http://spiderformysql.com
Kentoku SHIBA ([email protected])
Any Questions?
Thank you for taking
your time!!
Top Related