debiancdn

AWS, Content Delivery Network and Debian

カテゴリーアーカイブ: DB

RDSは1秒未満のスロークエリを記録できない。そこでmin_examined_row_limit

いろんな人に言われることではあるが、RDSは1秒未満のスロークエリを記録できない。

そこで使えるひとつの方法は、 minexaminedrow_limitを使うこと。折角なので超プロのblogから引用。

漢(オトコ)のコンピュータ道: MySQL 5.1のスロークエリログ

min_examined_row_limitという変数が追加されたのも見逃せない。この変数を指定すると、「○○○行以上の行をテーブルから読み込んだクエリをスロークエリログに記録する」という指定ができるようになる。多くの行を読み込むクエリは、潜在的にサーバ全体の性能を劣化させる危険性があるので、long_query_timeを少し大きめにしておいて、このオプションを併用しておくといいだろう。例えばmin_examined_row_limit=10000など。いずれの変数もアプリケーションの特性に合わせて調節して欲しい。

これをRDSで一発でやるなら

$ rds-modify-db-parameter-group sweet-parameter-group --parameters "name=slow_query_log, value=ON, method=immediate" --parameters "name=long_query_time, value=1, method=immediate" --parameters "name=min_examined_row_limit, value=10000, method=immediate"

といった具合になる。

マイクロDBインスタンスのRDSのアレな活用

【AWS発表】Amazon RDS MySQL を月26ドルで! マイクロDBインスタンスが利用可能に! 

ということで、安くRDSを使うことができる。ただし、マイクロインスタンスなのでどうしようもなく遅い。耐えられないくらい正直遅い。

が、それを逆手にとった活用法がある。

それはスロークエリの検出。

MySQL Enterprise EditionとRDS

散々Amazon RDS for MySQLなるMySQLサービスを売っているのだが、それでもMySQL Enterprise Editionはすばらしい製品に見える。

違いをメモってみるか。ちなみにRDSはMySQL community edition.

  • MySQL Enterprise Backup: これはRDSはバックアップの仕組み(snapshot)もあるしポイントインタイムリカバリもあるからいいか
  • MySQL Enterprise Monitor: MySQL Query Analyzerいいなあ。RDSにないし。
  • MySQL Workbench: 管理ツールはまあRDSにはいらないのかもしれない。
  • MySQL Enterprise Security: LDAPやAD連携なんかはいいよね。RDSにもあっていいね。
  • MySQL Enterprise Scalability: スレッドプールは圧倒的だよね。。
  • MySQL Premier Support: @nippondanjiのサポートうけてみたいよね。。(#やっているかは知りません)

そんなわけで、欲しいものはまだまだあるのであった。

NHNテクノロジーカンファレンスで見たDeNAのMySQL運用の話とAmazon RDSの比較など。

NHNテクノロジーカンファレンスにいってきた。

DeNAでのMySQL運用の話。岩永さんが話をしてくれたおかげでこれから外で話せますありがとうございます! という具合。

実に実直で正直で手間をかけた運用で、なおかつその手間をなくすためのツールの開発、アプリケーションも一体となったとりくみのすばらしい実例だと思う。

このセッションではAWSならばの話は当然いっさいなかったのだが、AWSのMySQLサービスであるRDSならどうするのかを書いてみる。

サービスが縮小するときの話。スケールバック(スケールイン)時に2つあったマスターDBの数を減らす。その際にはosの上に二つ目のMySQLをたちあげる方法をとっている。二つ目のMySQLは違うIPアドレスで立ちあげて、それをbind-addressを指定している。

RDSを使っているならば、サービスを縮小するならば、大きなインスタンスから、小さなインスタンスに設定を変更する。詳細はFAQの#20を参照

「バックアップ」サーバ。マスタおちたときのレプリ昇格用。デイリーのバックアップ用。サービスからは参照されていないただのスレーブ。デイリーバックアップは人のすくない朝3時とかにmysqldump

RDSの場合は、http://aws.amazon.com/jp/rds/faqs/#23 にあるように、デイリーの自動化バックアップと、任意のタイミングでのデータベース スナップショットを提供している。

MHAでは、データの整合性をたもち、スプリットブレインがおこらないように、マスタ切り替え。IPのきりかえまでもやってくれる。夜中におちても切り替え時間だけの停止。計画的に使うこともできる。

RDSであれば、可用性向上のためにさらにMulti-AZオプションが使える。http://aws.amazon.com/jp/rds/faqs/#36 にあるように、Amazon RDS は別の Availability Zone において同期する、「スタンバイ」レプリカを自動的に設定して管理します。DBインスタンスに対する更新は、複数の Availability Zone 全体において、スタンバイに対して同時にレプリケーションされます。

フェイルオーバー時、Amazon RDS は単純に DB インスタンスの正規名レコード(CNAME)を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。DBサイズにもよりますが、3分以内で復旧します。

ここまでいいことを書いたけど、RDSでは絶対にできないことは、お客様側のアプリで対応しないといけないこと。そしてInnodb以外を使うこと。というわけで、次の2つはさすがのDeNAの総合力といったところだろうか。

UPDATEの最近の命題。ロックをどれだけ短かくするか。ソシャゲは綺麗なもんばかりじゃないのでデッドロックはおこる。そこでロックの順番をアプリで管理させる(理想) or バージョンをつかって楽観ロック 

プライマリキーでのSELECTの機会は多い。そこでHandler socketの登場。SQLパーサをはぶけるので速くなる解説。

 

ScalebaseによるMySQLのホワイトペーパ

http://www.scalebase.com/downloads/MySQL%20Scaling%20Strategies.pdf

MySQLのシャーディングやHA化とは人類の夢。あわせて低価格化も。それでいてサポートをほしいとなれば選択肢は多くない。

MySQLのシャーディングといえば、http://spiderformysql.com/ がすぐに浮かぶ日本人でも、それ以外を網羅的に書いているのでぜひ一読をおすすめする。

ネーミングセンスが光る? DBの名前のつけかた。

最近知ったオソDBの名前の由来

名前についつい時間をかけてしまったり、会議の時間が潰れてしまったりすることはよくある。

そうそう。なまえといえばCouchDBがマッタリ系でいいですよね。。

いまさらながらMySQLのドキュメントはあじわい深いしサービス精神にあふれているDBの本。

なんといっても、余すところなく書いてやろうという意気込みを感じる執筆人がおさえて書いた感じがつたわるあの内容!

DBに必要になることはたいていMySQLに実装されていることもあって、たいへんよい仕上り。

そして http://dev.mysql.com/doc/ で配っている形式の多さ。どれをとっても一級品だろう。

と、ここまで書いて、他にもあるんじゃね? と思ったら、https://www.lpi.or.jp/ossdb/ossdbtext/text.php オープンソースデータベース標準教科書 -PostgreSQL- (Ver1.0.1) というepubでも配っているすばらしげなものもあるようです。

mysql5.1にupgradeしたらmysql5.0でつかえてたテーブルが使えなくなったので,結局dumpしなおした.

結論を言うと

mysql5.1にupgradeしたらmysql5.0でつかえてたテーブルが使えなくなったので,結局dumpしなおした.

ということなのでした.

なんかmysqlがうごかんので,show databasesをしてみたら"#mysql50"という表示が出る.

mysql> show databases
    -> ;
+-------------------------------------+
| Database                            |
+-------------------------------------+
| information_schema                  |
| #mysql50#donrails-trunk_development |
| #mysql50#donrails-trunk_production  |
| #mysql50#donrails-trunk_test        |
| mlabcms                             |
| mysql                               |
| snf_development                     |
| test                                |
+-------------------------------------+

どうやら,"#mysql50#"という表示は,

http://dev.mysql.com/doc/refman/5.1/ja/identifiers.html

MySQL 5.1.6より、データベース名とテーブル名内の特殊文字は項8.2.3. 「ファイル名への識別子のマッピング」で記述されているとおり、対応するファイルシステム名にコード化されています。旧バージョンのMySQLを使用していて、で特殊文字を含むデータベース名やテーブル名が新しいエンコーディングに対応するようアップデートされていない場合、#mysql50#が接頭に表示されます。そういった名称を検索、もしくはそれらを新しいエンコーディングに変換するには、そのセクションを参照してください。

ということで

特殊な接頭辞を使用する必要を無くすため、旧名をアップデートするには、mysqlcheckで再エンコードしてください。次のコマンドは全ての名前を新エンコーディングにアップデートします。

 shell> mysqlcheck --check-upgrade --all-databases

をかませばいいらしい.

出力

#mysql50#donrails-trunk_development.authors
error    : Table upgrade required. Please do "REPAIR TABLE `authors`" or dump/reload to fix it!

こんなのが出た.

–auto-repair

チェックされたテーブルが破壊されていた場合、自動的に修復します。必要な修復は全てのテーブルがチェックされた後に実行されます。

なるものがあるので試してみた.

Repairing tables
#mysql50#donrails-trunk_development.authors
note     : The storage engine for the table doesn't support repair

あれれ,

 show create table テーブル名;

で,ストレージエンジン確認.

 ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8

とでてるな.InnoDBは対応してないのか?

AUTO_INCREMENTが悪さをしてるんだろうか.まあdumpして復帰.

何をもってフェアかという話はあるが30msecを問題とされてしまうと俺らの職がなくなるので困るんです

米金融、市場情報先取りで巨額利益…米紙報道(読売新聞) – Yahoo!ニュース

 【ニューヨーク=池松洋】米ニューヨーク・タイムズ紙(電子版)は24日、米金融大手ゴールドマン・サックスや一部のヘッジファンドが、他の市場参加者よりも100分の3秒早く情報を入手できる大口投資家の立場を利用し、高速コンピューターを駆使して大きな利益を上げていると報じた。

 米証券取引委員会(SEC)もこの「抜け道」を問題視しており、新たな取引規制を今秋にも導入する見込みという。

 同紙によると、ゴールドマンなどは、100分の3秒の時差の間に取引情報を分析して自動的に取引を行うコンピューターを導入し、自己勘定で巨額の利益を得ている。

こんな話はあるけれど,30msecってけっこうな時間であって,現在のストリームDBをつかったアルゴリズム取引は2,3msecの違いで左右される世界.
ここで金融ITは2月ころはどん底で,なんだか最近求人も増えてきたようなのに,こんなnewsがあると暗い気分になる.
で,ちょっとどうなるのかを考えてみる.

  • 完全に抜け道をふさぐようなひどい規制がかかったら,金融ITイヨイヨオワタってことになる.これが最悪のシナリオ.
  • NYSEやNASDAQの取引周辺にはECNがその数倍の規模であって,その速度を競っているので,そっちに逃げる.それで形骸化するシナリオ.
  • 大手には規制がかかって,個人やらヘッジファンドには規制がかからない意味わからんことになるシナリオ

SOX法のように,USは完全にふさぐことにする法律をつくって,日本にも無理矢理従わせることにして,しかしいつのまにかUSでは規制緩和になって,日本の金融IT根刮ぎ終了,というのを考えたんだけど,日本じゃECNもでかくないし,東証はのろいのでそんな問題はないのか.

DEIMでの筑波というか北川研というか川島先生らでやってる研究

続いてDEIM2009での筑波大学北川研.私のコメントが一部まじっているので注意

p123, データストリーム処理へのベイジアンネットワークの導入

佐藤亮† 川島英之† ,†† 北川博之† ,††

センサデバイスから得られるデータを解析した後に生成される,イベントストリームを対象に確率計算を実行する.

筑波大 北川研の主題の話.まずこれ.

p130, ストリーム処理エンジンにおける効率的な来歴管理

川島英之† ,†† 北川博之† ,†† 寺島裕貴†††

ストリーム処理エンジンの出力を受け取ったアプリケーションからの根拠を問い合せる要求に応えるため,ストリーム処理エンジンに到着したタプルストリームの内,その出力の全来歴を永続化する実験の結果,来歴タプル永続化処理には多大な時間を要すること,およびその原因はディスクアクセス回数であることを示した.

オービスで実験しているようだ.

p54, XML データに対するファセットナビゲーションのためのフレームワーク FoX の提案

駒水孝裕† 天笠俊之†† 北川博之††

近年, ファセット検索は膨大なデータを対象に効率的な検索 を行う手法として注目を集めている.データはあらかじめファ セットと呼ばれる独立したカテゴリごとにグルーピングされて いる.ファセット検索とは,表示されているファセットとその 値(キー)を選択し検索対象データを絞り込む,という動作を 繰り返し行いデータの検索を行う手法である.ファセット検索 は以下のような特徴を持つ.

  • 現在の検索結果とそれに関連したファセットとキーを表 示する.
  • ファセットとその値を選択したときに結果が何もないよ うなファセットは除外される.
  • ファセットの値にはその値によって検索できるデータ数 も同時に表示する. ファセット検索の例としては DBLP Bibliography [7] や Fla- menco Search(図 1)[8],mSpace などがある.

p56, 分散ストリーム処理における対象情報源の動的変化を考慮した問合せ最適化手法の評価

大喜恒甫† 渡辺陽介†† 北川博之† ,††† 川島英之† ,†††

StreamSpinnerの利用.センサと分散したDB間のネットワーク使用量の最適化

Intriggerをつかって構築したようだ.https://www.logos.ic.i.u-tokyo.ac.jp/intrigger/registration/

喜連川研とかにある分散ノード.クラウドというよりはグリッドっぽい.

p223, センサノード上で動作する汎用データ管理基盤の開発

山口卓郎† 渡辺陽介†† 北川博之† ,†††

センサノード上でも処理して不要なnetwork利用を防ぐはなし.やってること

  • StreamSpinnerをSunSPOTにのせる
  • 分散問い合わせ言語も考えている.
    • LIFETIME 節というのがキモ

関連研究との比較がわりとためになるかんじ.

  • Aurora[1], STREAM[3], TelegraphCQ[2]:1 台のマシン で動作する集中型のストリーム処理エンジンであり、分散スト リーム処理は考慮されていない。
  • Coral8[10]:商用ストリーム処理エンジンであり、単位時 間当たりの処理可能データ数が多く、高速処理が可能と謳われ ている。株式トレーディングなどに利用することを想定して いる。
  • Borealis[4]:分散型ストリーム処理エンジンであるが、分 散環境中にアプリケーションを組み込むための明確な枠組みは ない。またセンサノード上で稼働していない。
  • TinyDB[6]:センサネットワークを 1 つの大きなリレー ションとしてみなすことができる。しかし分散ストリーム処理 のためにノード毎に異なる演算を配置することはできない。ま た下流から上がってくる不要な子機データを上流の親機で集約 する際に処理するのに対して、本研究では、データを持つ子機 上で選択演算して余分なデータはその子機から送信しないな ど、不要データ処理に関するアプローチが異なっている
  • Abadi らは Borealis と TinyDB を組み合わせた枠組み を提案している [5]。ただし、Borealis の分散問合せ最適化で はセンサノードは対象にされておらず、センサネットワーク内 のデータ収集方法は、全て TinyDB に依存している。彼らの枠 組みでは、センサネットワークからデータを収集する要求の定 義を QoS によって設定できる。この仕組みにより、バッテリ 寿命を気にせずサンプリング収集間隔を狭めてデータを収集し たり、サンプリング収集間隔を広げてバッテリ寿命を延ばしな がらデータを収集したり、といった指定が可能である。収集は power、latency、quality の各条件を、ユーザやアプリが設定 する lifetime という寿命を満たすように設定して行われる。こ れに対し本研究では、PC とセンサノードの両方に同種のシス テムを搭載することで、それぞれの特性を考慮した問合せ最適 化を実現している。問合せに基づいて、生成された処理木の演 算を LIFETIME 節の条件を満たすノードの中で最もコストが かからないプランを選んで配置している。