りず・じぇいぴー

PHPを中心とした技術情報を徒然と書いてます。

開発進捗的にお見苦しいブログですみません。

2010-06-13 20:35:41 PHP データベース Comments: 0

NoSQLという挑発的な名称と、ハッシュしか扱えないという貧弱ぶりが嫌いで、
「どうせこんなもんただのバズワードだろう。memcachedに顧客情報を記録するのは馬鹿のすることだ」と思っていたが、
NoSQLをNot Only SQLと読ませようという活動や、Tokyo Cabinetがテーブルモデルに対応している事を知り、
もともとmysqlがあまり好きではない身としては、かなり惹かれるものがあるのではないかと思い直した。

mysqlとTokyo Tyrant(TT)を比較して、前者の優位点を列挙してみる。

• JOINが使える。つまり、リレーションする。
• サブクエリーが使える。
• GROUP BY句が使える。
• SQL関数が使える。
• 1つのサービスで複数のデータベースとテーブルを扱える。

つまり、「考えることが出来る」というのが、RDBMSの相対的な利点だと思う。

しかし、そんな利点は本当に必要なのだろうか？
ビューやストアドプロシージャががんがん回るDBサーバがあって、フロントエンドの負荷を軽減しているというなら良いが、普通そんな仕事はmysqlにはやらせない。PostgreSQLの出番だ。

それに、レプリケーション済みmysqldなんてものは、データの読み込みにしか使わないのだ。どうせ読んでくる内容は決まっているというのに、そのためにデータベース接続を随時発生させるなど愚の骨頂である。データはローカルのメモリにおいておけばいいし、それがデータベースの体裁を保っている必要など全くないのだ。
その要件においては、NoSQLを使うと冗長性と耐負荷性能はあがるので、一概にmysqlのほうが堅牢安全であるとは言い難い。

そして、たいていはmysqlを使ったアプリでも、複雑なSQLは発行しない。そしてそれが必要の無いような設計をする。
ORMが糞みたいなSQLをはき出して仕方ないからそこだけ手でチューニングしたとか、その程度である。
しかし、パフォーマンスならTTのほうがmysqlより数段良いのだ。mysqlにしがみつく理由にはならない。

そして何より我々はPHPerである。ロジックはすべてPHPで書いてしまえばいいのだ。

• サブクエリーの目的は何だ？ WHERE句の条件指定のために内側のクエリを書くくらいなら、そのクエリだけを実行して条件を作ってしまえばいい。2回クエリを投げるとデータベース接続コストがかさむって？ TTならその心配は無い！
• GROUP BY句とSQL関数はPHP関数で代替してしまえ。DBサーバのかわりにWebサーバが計算コストを支払えば良いだけだ。WebサーバとDBサーバが同居しているなら、尚更DBサーバにやらせる意味は薄い。
• あとはJOINだけなんとかすればいいんだー！

というわけで、最終的にこんな事が出来ないかと夢想している。

before

1号機　Webサーバ #1
2号機　Webサーバ #2
3号機　mysqld マスタ(読み書き)
4号機　mysqld スレーブ #1(読み込み)
5号機　mysqld スレーブ #2(読み込み)

もしくは、上記構成よりパフォーマンスが発揮できるmysqlの導入事例として

1号機　mysqldマスタ(読み書き)
2号機　Webサーバ #1 mysqld スレーブ #1(読み込み)
3号機　Webサーバ #2 mysqld スレーブ #2(読み込み)

after

1号機　Webサーバ #1 TTマルチマスタ #1(読み書き)
2号機　Webサーバ #2 TTマルチマスタ #2(読み書き)
3号機　PostgreSQL(読み書き)


長々と書いて自分が導き出したい結論が、mysqldレプリケーションへの否定だという事に今気がついた。
つづく。

2010-06-07 03:27:34 Mobile Comments: 0

日本全国、いつでもどこでもPCでネットに繋がるようにしたい。
スマートフォンはPCほど利便性が高くないので除外する。少なくともテキストエディタとsshが使いにくい。

まず最初に、非常に残念だが、willcomとe-mobileを候補から除外しなければならない。
この2キャリアはケータイと比べると格段に電波のとどくエリアが少ないので、
「どこでも」使いたいという要望を満たせないのだ。
せめて、携帯電話が繋がる場所では通信したい。willcomは実際に使っていてそれが満たせない。
e-mobileは自分の周囲ではもっと電波が悪かった経験がある。

64k通信を検討したが、世の中の流れが大容量通信に志向しており、
「パケ代を節約する」という概念が非常に希薄である。
極論を言えばシンクライアントが満足に動作すれば、他には何もいらないのだが、
残念ながらRDP 7.0の実力をもってしても、64k通信でまともに遠隔作業をすることはできない。
せめて384k通信であれば、もうちょっとなんとかなるのかも知れない。

SoftBankの定額データ通信の仕組みは、e-mobileの回線を使う事で実現しているらしい。
SB回線は従量で、イーモバ回線は定額なのだそうな。つまりイーモバ契約するのと何も変わらん。
よって却下。ちなみにこの情報はソフトバンクショップ店員さんに聞いたのでガチなはず。ここにも書いてあるね。
http://mb.softbank.jp/mb/data_com/price_plan/bonus_pack/

DoCoMoは最も魅力的な選択肢である。カバー範囲の広いFOMAが使える。
2年縛りとなる「定額データプラン　スタンダード　バリュー」で、月々5,985円＋プロバイダ525円。
ところが通信量と通信プロトコルに制限があるらしい。
http://www.nttdocomo.co.jp/service/data/foma/flat_rate/function/index.html
意外に制限が少ない。実際に困るのはSkypeくらいだと思う。でも、やろうと思えば出来るらしい。
http://p15.jp/2009/02/23/225152
http://p15.jp/2009/07/13/000448
携帯電話の定額パケットで無料通話をされると困るという理屈はわかるので遠慮してもいいんだけど、
とりあえず文字チャットだけでも出来るのはありがたい。これなら実用の範囲内かも。

auは月額5,460円＋プロバイダ900円。DoCoMoと大差ない。
「WINシングル定額 (シンプル)WINシングルセット割または誰でも割シングル適用後」の金額。わけわからん。
上り回線も早いことが特徴だと思う。そしてカバーエリアがDoCoMoと結構違う。
http://www.the-hikaku.com/internet/hikaku3.html
そして規制が厳しい。月間300万パケット(384MB)で速度規制がかかるらしい。
理論値に近い通信を15分やっただけで制限されるとか、どんだけひどいサービスだ。
DoCoMoは「3日で300万パケット」という規制があるといううわさがある。

結論としては、DoCoMoが良さげ。
なので予算を獲得したら契約してみるつもり。

念のためRDPの通信量を調べてみた。
http://blogs.technet.com/b/askcorejp/archive/2009/12/29/3302885.aspx
余裕を見て4KB/秒と考えればよさそう。64k通信でも意外となんとかなるのだろうか。
実際に試した感じだと、やはり応答速度は大きくローカルとの差を感じてしまうのだが。
384MBに達するのは26時間後。つまり、だいたい1日8時間使用可能ということになる。
FTPは当然として、Firefoxとかも全部リモートで動作させることが前提になる。微妙だ。

2010-05-21 02:55:31 PHP Framework Comments: 0

とりあえず適当にハードウェア用意して、開発進めて、納品直前にパフォーマンスが出ない事に気がついて、
お客さんが急に不満を言ってきたり性能要件のハードルを上げようとしてきたりして、
もう納期直前なのにどうするんですかこれ状態になるのを避けるための方策を考えてみた。

まともなロードバランサを導入する

ぶっちゃけ、これに尽きる。
だいたいハードウェア構成を提案しようとしても、既にロードバランサだけは準備されてて、それを使用しろと言われて、
しかもスティッキーセッションに対応しないような軟弱なブツだったりするもんだから、
Webサーバのほうでセッションを記録する先の確保に困って、nfsに置いたらデータは消えるし、
DBに置いたら過負荷でダウンするしで、ひどい目にしか遭わないって事になるわけです。
そんな風になるくらいなら mod_proxy_balancer でも使ったほうが一万倍はマシだろうにね。

メモリを最低4GBは積む

いまどきのフレームワークを使って開発したPHPアプリケーションは、1アクセスあたり32MBくらいメモリ食います。
同時100アクセスさせたかったら3.2GB用意しろってことです。そこまでさばくのは他の要因ゆえ困難だけどね。
言い換えると、8GBあっても使い切れないんじゃないかと思う。CPUやストレージが豪華ならその限りではないけど。

PostgreSQLを使う

mysqlはUNIX Socket(localhost)で使うもの。
DBサーバを立てるなら、使うRDBMSはPostgresであるべきです。
というかmysql使ってもなんもいいことないから、いっそのこと全面的にやめてしまってもいいと思う。
あ、でも、まともなロードバランサがあるんなら、localhostに置いたmysqlを活用するのは賛成です。

APCを導入する

まさか導入しないなんて事はありえないだろうからここに書くまでもないが。

きちんとチューニングする

osとかapacheとかphpとかdbとか、それぞれいじるのよ。方法論はネットに腐るほどあるから割愛。

きちんとプログラミングする

そこで異臭を放っている腐ったスパゲッティを投げ捨ててまともなロジックに書き直すべき。
フレームワークの重さに悪態をつきはじめるのもこのあたりから。
動的に生成しているファイルを静的にしはじめるのもここから。

どのサーバが何台あればいいの？

まず、WebサーバでもDBサーバでもないものは別のハードウェアに載せましょう。
あと、テストサーバと本番サーバは分けましょう。development、staging(testing)、productionに分けるとベター。

その上で、WebサーバとDBサーバがそれぞれ何台にするべきかわからないときは、
とりあえずすべてのサーバに両方ともインストールしてしまいましょう。

DBサーバがすかすかでWebサーバが過負荷だから、
ORMだったものをストアドプロシージャに全部変更する羽目になった、とか、
逆にDBサーバが接続出来なくなりすぎるから、Webサーバにデータベースの複製を置くことにした、
という、やや悲惨な事例もそれなりにあったりします。

結局大規模サイトを作るにはどうしたらいいの？

縦割り行政じゃなくて横割りにするといいと思う。
用途の違ったサーバが別々にあるのではなく、同じ構成のサーバがいくらでも増やせるようにする。
あとは・・・まあ個別にご相談で。

2010-04-26 16:36:49 贅肉的知識 Comments: 0

紛らわしい用語シリーズ。

用語	Win2k	WinXP	Win7/Vista	MacOSX
サスペンドとレジューム	挙動A	-	-	-
スタンバイ	-	挙動A	-	-
休止状態/ハイバネーション	挙動B	挙動B	挙動B	挙動B
スリープ	-	-	挙動A+B	挙動A
セーフスリープ	-	-	-	挙動A+B

• 挙動A・・・CPUとメモリに通電したままハードディスクとモニタの電源を切る。
• 挙動B・・・メモリの内容をハードディスクに書き出してPCの電源を切る。起動時に待避した内容をメモリに読み込む。
• 挙動A+B・・・メモリの内容をハードディスクに書き出すがCPUとメモリに通電したままにする。もし電源が切れていなければ挙動Aで復活し、電源が切れていたら挙動Bで復活する。

ちなみにMacOSXでは、デスクトップ機ではハイバネーション、ノート機ではセーフスリープを行うように設定されているが、どちらの挙動も「スリープ」という名称で表記されており、「スリープモードの違い」として扱われているらしい。

2010-04-24 10:21:42 PHP Framework Comments: 0

機会があってAkelosというフレームワークを触ることが出来た。
「CakePHPよりもRuby on Railsに近い」と言われて引き継いだが、おおむね納得している。
この重さはRoR譲りに違いない。

詳細なベンチは結局取らなかったので証拠として出せるものは無いが、
ActiveRecordsでRDBのクエリが不必要に発行されているなら、それは必ず積もり積もってシステムを苦しめる。
countBySql() findBySql() という抜け道を使いつつ、リレーションを神経質に減らせばある程度はマシになる。
それでも手元の環境では、フレームワーク自体の起動コストが1.7秒くらいかかっていてだいぶ重い。

平行して、Smarty2を研究している。
枯れたテンプレートエンジンなので今更「研究」というほどの事では無いのだが、
各種フレームワークが持つ(もしくはsymfon 1.0が持っていた)ヘルパーはSmartyのヘルパーにとても似ている。
今となってはかなり使い勝手が悪いが、次世代のテンプレートフレームワークはSmartyを超える必要がある。
PHPカンファでも「PHPはそれ自体がテンプレートエンジンである」と言う人が居たが、
short_open_tagの廃止をはじめとして、テンプレートエンジンとしては退化している部分も少なくない。
処理速度も大事だが、「まともな文法でテンプレートを書く」という意識がPHPerには希薄なのが悲しいところだ。

フォームフレームワークは、それはそれでどこも似通っているし、
結局のところ「フォームはヘルパーで処理するかフレームワーク化するか二択」になっていると言える。
8年前に愛用していた HTML_QuickForm はあまり使いやすいと言えなかったが、モダンなものもあれに劣るとも勝らない出来だ。

ちなみにAkelosにはSintagsというテンプレートエンジンが搭載されているが、これはSmartyをさらに手抜きしたような文法を持っていて、なじみやすくはある。
templateディレクトリにtplファイルが入っていて、隣にtemplate_cディレクトリがあるあたりで、お察しである。

これらを「改善」するつもりなら、パラダイムシフトを起こさなければいけないのだろうし、
そこまでする気が無いのなら、枯れた技術で妥協するのもアリなのかも知れない。
PHPerの大多数は保守的で新しいもの嫌いな傾向があるし、
そうじゃないPHPerが積極的に新時代の標準を頑張って構築していく必要があるのではないかと思うのだが如何か。

前へ 1 2 3 4 5 次へ 175 件中 11 ～ 15 件目