タグ「gae」を含む新着エントリー - はてなブックマーク
すぐに始められる方法が紹介されていたので、さっそくやってみた。
Google App Engineを使って無料でサイトを立ち上げる方法 - EC studio 技術ブログ
このサイトの説明通りにやったら、静的なHTMLページを設置することができた。
Google App Engineで、Pythonで動くwikiを設置したいと思っていた。
bellbindさんのブログで紹介されていた１ファイルで動くwikiスクリプトを設置してみた。
遅ればせながらGoogle AppEngine(python版)でプログラムを書いてみた - ラシウラ
このサイトの説明通りにやったら、簡易wikiを設置することができた。
●app.yamlの修正
サイトの設定情報は、app.yamlというファイルに記載されている。
静的（スタティック）なページと動的（ダイナミック）なページを混在させるときに、エラーが出たので注意が必要だ。
application: myapp
version: 1
runtime: python
api_version: 1
handlers:
- url: /wiki(?:/.*)?
script: wiki.py
- url: /admin/.*
script: $PYTHON_LIB/google/appengine/ext/admin
login: admin
- url: /
static_files: htdocs/index.html
upload: /
- url: /
static_dir: htdocs
handlers: の部分の順番を逆にするとダメだった。
・赤字の部分＝動的なページへのルーティングを先に書く。
・青字の部分＝静的なページへのルーティングを後に書く。
上記の内容だと、先に青字の部分を持ってきてしまうと、「/」＝ルートディレクトリに設定したフォルダ（上記の例だと「myapp/htdocs」）の直下を見に行ってしまうので、他の場所（上記の例だと「myapp」内に配置したwiki.py）にあるファイルが呼び出されなくなってしまう、ということだろう。
とりあえず、静的ページと動的ページをGoogle App Engineで表示できるようになったから、wiki等のCMSを作っていきたい。
 | 新人プログラマのためのGoogle App Engineクラウド・アプリケーション開発講座―JAVA PYTHON対応 (2009/08) 掌田 津耶乃 商品詳細を見る |
理想としては、MoinMoinやSphinxのようなPython製のwikiを設置したい。
MoinMoin
MoinMoinのインストールと設定、カスタマイズ
Sphinx
渋日記: Pythonって何？という人のためのSphinxインストール入門
●課題
(1) BigTableのデータ構造設計は、従来のRDBとは違う発想で作らないといけない。
RDBのスキーマ、正規化からいったん離れて、MapReduceの作法に慣れる必要がある。
Life is beautiful: Google App Engine上のベスト・プラクティス、その１: Datastore
データの正規化は基本的にはしない → エンド・ユーザーから見て一つの「もの」（たとえば商品、ブログエントリー）があった場合、それに付随する情報（たとえば、タイトル、値段、更新日時、作者）をEntityそのもののプロパティとしてもたせておき、Queryなしに一回のgetですべて取得できるようにしておく。これは、RDBにおける「ベスト・プラクティス」とは正反対の方向を向いたものなので、RDB/SQLに慣れた人こそ気をつけて設計すべきである。
(2) オンプレミスのデータ構造をクラウドに対応させる
Google App Engine用に作ったWebアプリを、クラウドとオンプレミスでシームレスに使うことを考えた場合、オンプレミスのシステムをクラウドに合わせる必要があるのではないか？
オンプレミス － ＠IT情報マネジメント用語事典
on-premise / 自社運用 / 社内設置
情報システムを利用するに当たり、自社管理下にある設備に機材を設置し、ソフトウェアを配備・運用する形態のこと。
クラウドコンピューティング － ＠IT情報マネジメント用語事典
インターネット上にグローバルに拡散したコンピューティングリソースを使って、ユーザーに情報サービスやアプリケーションサービスを提供するという、コンピュータ構成・利用に関するコンセプトのこと。
クラウドかオンプレミスかという二者択一は危険である：栗原潔のテクノロジー時評Ver2：ITmedia オルタナティブ・ブログ
資源所要量が十分に予測可能であれば、マシンを自社で買って外部のデータセンター事業者にハウジングしてもらった方が安上がりでしょう。
他者への依存は極力少なくする方が、慎重で賢明な選択だ。
・基本的には、全て自前で揃える＝オンプレミス。
・コストパフォーンマンスが著しく悪い部分だけアウトソースを検討＝クラウド。
という使い分けを基本にする。
従来、オンプレミスのデータモデルはRDBが主流であった。
O/Rマッパーによって、RDBとオブジェクトモデルのデータ構造の違い＝インピーダンスミスマッチを解消しようとする発想がある。これと同様に、オンプレミス（RDBを採用）とクラウド（MapReduceを採用）の間で、データ構造の違いを変換して利用しようとする発想は、無駄な努力だ。
RDB用のデータスキーマに手を加えて、MapReduce用のデータスキーマに変換して、クラウドにデプロイする、という発想はやめよう。
SQL以外のデータストレージの採用を試してみたい。
NoSQLデータベースを40種類以上リストアップ、キーバリュー型にもいろいろある
key-valueストアの基礎知識
MapReduce → Hadoop
Key-VAlue → kumofs
自前サーバで、Python＋Hadoopを試してみたい。
Happy = Hadoop + Python
→Happy＝HadoopのMapRecudeをPython(Jython)で書くためのフレームワーク
どのみち、シーケンサーを作るときには、NoSQLタイプも利用することになるだろうから、
・PHPを使うときは、RDB
・Pythonを使うときは、MapReduce
と使い分けでみるとか。
- 関連記事
