cloudpackブログ - Spiderってなんじゃ？（SUBPARTITIONで負荷分散しながらストレージ容量を無限追加）
Spiderではパーティションを使ってシャーディングしますが、パーティションの定義によって分散の特性が変わります。 1. サロゲートキーなどのHASHパーティション データは均等に分散 更新負荷は均等に分散 増設はデータ全体の再ハッシュが必要 日付の年月などのHASHパーティション データは順次格納 更新負荷は常に1データノードにのみかかる 増設は新しい年月を追加 サロゲートキーなどのRANGEパーティション データは順次格納 更新負荷は常に1データノードにのみかかる 増設は新しいキー範囲を追加 理想は均等に負荷分散しながら、データ容量を後から増やせるのがベストですが、１，２，３とも負荷分散と容量追加のどちらかにしか親和性がありません。 そこで、作者の斯波さん(@kentokushiba)に伺ったところ、 SpiderでもSUBPARTITIONが使えるとのことでRANGEとHASHを組み
cloudpackブログ - spiderってなんじゃ？（spider自身の冗長化）
いままではSpiderがひとつに対して、データノードが複数ある構成をとってきましたが、実戦ではSpiderが単一障害点になるため好ましくありません。ここではSpider自身の冗長化を行なってみます。 いままでのSpider x 1 + mroonga x 2 の構成に対してデータを入れ込むためのappノードを用意します。 ○SpoderのSPOF ■mroonga CREATE TABLE doc ( id INT PRIMARY KEY AUTO_INCREMENT, created_at datetime, content text, FULLTEXT INDEX (content) ) ENGINE = mroonga; ■spider CREATE TABLE doc ( id BIGINT PRIMARY KEY AUTO_INCREMENT, created_at dateti
cloudpackブログ -mroongaってなんじゃ？（Spiderで分散全文検索）
前回の記事「mroongaってなんじゃ？ (mroongaでmysql全文検索)」でmroongaを使用しましたが、 全文検索のデータは大きくなりがちなので、Spiderを利用して書き込み負荷やストレージ容量を分散してみます。 ○設定 ■mroongaデータノード 前回と同じようにｍroongaテーブルを作りますが、Spiderノードからアクセスするためにユーザー権限を登録します。 今回はホストは特に絞りません。 mysql> GRANT ALL PRIVILEGES ON *.* TO 'memorycraft_user'@localhost IDENTIFIED BY 'memorycraft_pass'; mysql> GRANT ALL PRIVILEGES ON *.* TO 'memorycraft_user'@'%' IDENTIFIED BY 'memorycraft_pa
cloudpackブログ - Spiderってなんじゃ？（tpcc-mysqlでベンチマークをとってみた）
久しぶりにSpiderの話題になります。 今回は、tpcc-mysqlというベンチマークツールを利用してSpiderのベンチマークを取ってみました。 MySQLに限らずDBのベンチマークツールの多くは、TPCという団体の定めたベンチマーク仕様に基いて 実装されています。 また、トランザクションやアクセスなどのDB用途によっていくつかのベンチマークタイプに分かれており、 OLTP向けのTPC-Eや意思決定システム向けのTPC-HやTPC-DSなど色々あるようです。 TPC Benchmarks その中で、TPC-Cというのが複数ユーザーのトランザクションが発生するベンチマーク仕様で、顧客が商品を注文し 在庫チェックと発送などをシミュレートするもののようです。 そして、このTPC-C仕様をmysqlのベンチマークとして実装したものが、tpcc-mysqlです。 このあたりのことは、以下のサイト
cloudpackブログ - 勉強会資料『SPIDERってなんじゃ？（リージョン間でシャーディング）』を公開しました
11月5日（土）に開催されたJapan AWS User Group (JAWS-UG) – Osaka勉強会 第4回で、 cloudpackの職人、三浦（@memorycraft）がLTを行いました。 SPIDERは、シャーディングという、複数のDBにデータを分散して負荷の分散を行うMySQLの ストレージエンジンで、更新処理や参照処理も負荷分散することができます。 このMySQLのストレージエンジンSPIDERについて、概要とリージョン間でシャーディングを 行う際の構成例等を紹介しています。 使用したドキュメントは、SPIDERってなんじゃ？（リージョン間でシャーディング）よりご確認ください。
cloudpackブログ - EC2でMySQL(世界編2 Spiderとレプリケーションで高速負荷分散)
前回のEC2でMySQL(世界編1 Spiderとレプリケーションで世界進出)では、Spiderとレプリケーションで、リージョン間での高速なデータ分散を紹介しました。 前回で少し触れましたが、この構成では例えば、EU側のDBにJPのデータの書き込みには対応することができません。 これを解決し、どちらのリージョンからもすべての商品を投入できるようにしてみたいと思います。 構成は以下の通りになります。 SpiderノードのDBで、書き込みと読み込みでそれぞれ別々のテーブルを用意し、別々のデータノードにそれぞれシャーディングを行います。 データノードの作成とレプリケーションの設定は前回と同じなので割愛します。 ○Spiderノード spider_ja CREATE TABLE item_r ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(25
cloudpackブログ - EC2でMySQL(世界編1 Spiderとレプリケーションで世界進出)
EC2でMySQL(運用編 VP＋Spiderで無停止負荷分散)などを紹介してきましたが、再び、Spiderの話題になります。 WEBアプリを世界展開する際に、要件の1つとして、世界各国のユーザは全てのデータを参照できる必要がありますが、データの登録は各国、地域の担当者が各自のデータを登録したい、というケースが多々あると思います。 例として、商品の販売サイトで、EUと日本にそれぞれ管理者がいるとします。 その場合のユースケースとしては、下記となります。 EUの管理者はEUの商品を登録する 日本の管理者は日本の商品を登録する ユーザーは全ての商品を閲覧できる この時、商品を登録するDBがどのリージョンにあるかによって、ユーザや管理者の間でレスポンススピードに差が出ます。 DBを日本に置くとEUのユーザや管理者には遅いシステムとなってしまい、EUに置くとその逆になります。 そのため、各リージョ
cloudpackブログ - EC2でMySQL(運用編 VP＋Spiderで無停止負荷分散)
前回はEC2でMySQL(運用編 VPで無停止ALTER)を紹介しましたが、同じ様に通常のInnoDBテーブルをSpiderシャーディングに無停止で移行することも可能です。 そこで今回は、この方法を紹介します。 初期テーブルは以下のとおりです。 mysql> create table gift( id int auto_increment, name varchar(255), description text, created_at datetime not null, primary key(id) )engine=InnoDB; Query OK, 0 rows affected (0.02 sec) 上記をSpider化していきますが、今回は定期的にデータを投入しながらSpider化を行ってみます。 まず、以下のようなシェルを実行し、常にデータの投入がされている状態を作ります。 $
cloudpackブログ - EC2でMySQL(Spider編3 Spiderの先にSpider)
EC2はあまり関係なくなってきていますが、引き続きSpiderの話題になります。 Spiderの特性や構成について考えていくと、Spiderで分割するためのパーティショニングにより、さまざまな分割方法を考えることができます。 また、データが増えていくと、分散した先でもさらに負荷軽減が必要になる可能性も考えられます。 EC2でMySQL(Spider編1 Spiderってなんじゃ？)で少し触れましたが、Spiderはストレージエンジンであり、リンク先のテーブルのストレージエンジンに制限はありません。 ここで、Spiderのリンク先にSpiderテーブルを指定したらどうなるか実験してみました。 構成は、下記のようになります。 ここでは、全てTokyoリージョン内とします。 また、IPは仮のものとなります。 SpiderノードA(111.111.0.1) データノードA-1(111.111.0.
cloudpackブログ - EC2でMySQL(Spider編2 リージョン間SpiderでSSL接続)
少し間が空いてしまいましたが、Spiderの続きになります。 EC2でMySQL(Spider編1 Spiderってなんじゃ？)では、Spiderを使用して書き込みの分散を行いました。 今回は、Spiderによる書き込み分散をリージョン間で試してみます。 構成は以下の通りになります。(IPは仮のものです) Spiderノード(Tokyoリージョン、123.123.123.123) データノード1(Tokyoリージョン、111.111.111.111) データノード2(EUリージョン、222.222.222.222) また、リージョン間はインターネット接続になるため、SSLで接続するのが安全です。 インストールやデータベースの作成、セキュリティグループの設定など基本的な部分は前回と同じなので割愛します。 ちなみにこのサンプルで使用している証明書類は自前の証明書になります。 ○データノードの設
cloudpackブログ - EC2でMySQL(Spider編1 Spiderってなんじゃ？)
今回はEC2上での、MySQLとSpiderについての記事になります。 MySQLでの負荷分散となるとレプリケーションが主でしたが、参照系の負荷は分散できても更新処理は分散することが難しく、それがボトルネックになっていましたが、このSpiderを利用すると、更新も参照も負荷分散することができます。 Spiderは斯波健徳さんが開発したMySQLのストレージエンジンで、MySQLでのシャーディングという、データを分散して保存することで負荷を分散する処理を行うことができます。 尚、Spiderには以下の機能と特徴があります。 異なるMySQLインスタンスのテーブルを同一インスタンスのテーブルのように扱うことが可能になります。 XAトランザクションを含むトランザクションをサポートしているため、更新系DBのクラスタリングに 利用することが可能です。 テーブルパーティショニングをサポートしているため
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
