2011年1月12日水曜日

MySQL:VIEWを利用する際の注意点


MySQLのVIEW機能は複数のクエリ結果を1つのテーブルとして扱え、毎回複雑なクエリを打たなくても詳細な結果が得られるのでとても便利な機能です。



無駄にかっこよく言いましたが、複雑なクエリのエイリアスを作れるということです。



いきさつ


DBはレプリケーションが有効な通常の冗長構成です。


VIEW作ったのにスレーブ側にSELECTができないという現象に遭遇し該当のテーブルを調べたところwarinigがでていました。


さらに、毎日DBのバックアップを取っていたのですがAccess denied when using LOCK TABLESのエラーも発生しました。


実際に該当のテーブルにSELECTすると1044: Access denied for userと表示されSELECTできないことを確認しました。


rootなのになぜかアクセス権がないようです。



VIEW構文


VIEWを使うには以下のクエリを使います。



利用方法は今回の記事では割愛させていただきますがこちらの記事などが詳細に解説されております。



CREATE


[OR REPLACE]


[ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]


[DEFINER = { user | CURRENT_USER }]


[SQL SECURITY { DEFINER | INVOKER }]


VIEW view_name [(column_list)]


AS select_statement


[WITH [CASCADED | LOCAL] CHECK OPTION]



CREATE VIEW 構文



SQL SECURITY


VIEWにはVIEWを作成するたびにアクセス権を設定することができます。


デフォルトでは、CREATE VIEWを実行したユーザになります。


前述したAccess denied for userはこのアクセス権に引っかかっていたようです。


先に解決策としてはSQL SECURITY DEFINER ではなく SQL SECURITY INVOKERにする事です。


この影響でバックアップ時にテーブルロックが拒否されバックアップもできてなかったようです。



なぜおきたのか


実は各DBのユーザを厳密化するために、mysql.userテーブルはレプリケーションにより同期されない仕組みにしていました。


その結果マスターでCREATE VIEWが実行され、各スレーブにも同様のクエリが流れるがスレーブにも伝わりますがユーザがいないためSELECTした際にエラーがでるということです。


A5ERなどのツールを用いてDBを管理している場合はSQL SECURITY INVOKERが使えないことがあるので注意してください。


突然Access denied for useが出た場合はVIEWを疑ってみるといいかもしれません。




2011年1月4日火曜日

初心に戻るエンジニア


今は神戸の実家に帰省中ですが、東京に行って半年がたちました。



今年はとにかく就職し徹夜のグループワークをこなしたり、技術研修をしたり、配属先でなかなかミスの許されないエキサイティングな仕事をしています。



リリースが間近なため仕事を納めたのは夜中の2時になっていましたが、最後の方は開発者と今回の企画について気さくに話せたのでよかったと思います。



今私が働いている会社は主に3つの役に分かれます。企画・開発・インフラとありそれぞれ個別でサービス開発に携わっています。



この分別はある程度の人数を抱えた企業であると一般的で部分最適化と言われるシステムです。



大きな母集団を最適化するのはそれぞれ役割の違いや理念の違いなどで難しいとされています。しかし、母集団を小さな集合に切り分け部分集合にし、部分集合内を最適化することに注力すれば全体最適化につながるという仕組みです。



残念ながら私は、今の会社が現在のシステムになった経緯は知らないのですがこの部分最適化がうまく機能しないのがIT企業です。



発案者(つまり企画)が売れそうなサービスを考案します。それを、開発に実現可能なのか、工数、予算などをインフラを巻き込んで検討します。



そこから、部分最適化にのっとって企画、開発、インフラと別々に行動するわけですが、それぞれ別々で行動しているため思い込みや、勘違いなどで細かい修正や細かい仕様の決定でMTGを繰り返すことになります。



規模の大きいプロジェクトほどこの過程が頻繁に繰り返されるため、全体の工程の中でMTGが大部分を占めてしまいます。



その結果できあがった物やプロトタイプが企画が考案した物が異なったりして、再開発をしたり仕様の変更を検討したりする必要があったりします。



このように、部分最適化するにあたって切り離してはいけない部分があるため切り離し作業は慎重にやるべきです。




やるリスクよりやらないリスク



IT企業のようなネットを軸にしたサービスを展開している場合は、よく言われる言葉です。



ネットサービスはドッグイヤーと言われています。犬は人間の7倍歳をとるのが早く、ネットもそれぐらいのスピードで様々なサービスが作られています。



このスピードの波に乗り、ついて行くには進化するサービスに敏感に反応しスピーディに開発する必要があります。



なぜなら、ユーザはいち早く今よりもよりよりサービスを求めており、できるだけ早く使いたいからです



そして、ドッグイヤーの影響で時は金なりがよりシビアに利益として響いてきます。



その結果、やるかやらないか決めることに時間を割くよりも、とにかくやる事が重要になります。



豊富な機能より使いやすいサービス



開発したものすべてはユーザのために作った物です。使うのもユーザです。全てにおいてユーザ重視である必要があります。



しかし、最近ユーザビリティが軽視されユーザの事が考慮されておらず利益を中心とした設計が多く見られ残念です。



ユーザインタフェースは、アクセスログから解析するのが一般的です。



どのようにリンクがクリックされページにたどり着いたのか、その経路は設計通りか。設計外の場合、ボタンを大きくしたり、色を変えたり、場所を変えるなどの工夫が必要です。



これらを解析するツールもあるので利用するといいでしょう。



とにかく出してみる


ネットサービスの強みはなんと言っても、スピードです。不具合があればネットを通じてすぐに解決することができます。



日本人は完璧主義で、これまでに高い品質ですばらしいサービスを作り上げてきました。



しかし、その結果リリースが遅れ対抗サービスとして作り直すためにリリースを延期しては元も子もないですよね。



またネットは世界中とつながっているため個人、企業問わずにいつでもインターネットを介してサービスを展開することが可能です。



実際ネットの世界にはベータ版が溢れており、Googleに至ってはサービス前であるlabなんてのもあります。



もちろんセキュリティ的な面は最善を尽くす必要はありますが、その他機能的に未熟な部分に関してはユーザレビューを受けながら開発する事でよりユーザの希望に添う物を開発でき、無駄な工数を減らし次の追加機能の開発を同時進行で進めることもできるでしょう。



視点を変える、視点を加える


企画、開発、インフラ全てにおいて客観的に物事を分析する必要があります。これは、殆どの人が注意していることだと思います。



しかし、視点を加えるというのは意外と抜けていたりします。視点を加えるには、本を読んだり人の話を聞くのが一番いいと言われています。




今年やること


私は漫画を含めて技術書ぐらいしか本を読まなかったのですが、今年は月に1冊は読んでいきたいと思います。



また今年も、技術的に色々挑戦できたらいいなと思っています。特にネットワーク関連中心にやっていこうと思います。


では、今年も読みにくい記事ですがよろしくお願いします!


私はうさぎ年です。