ホーム > タグ > google

google

GAEのBigtableへのデータのインポートとエクスポートをやってみた

どうも、うしねずみです。

Google App Engineで使えるデータベースはBigtableというのですが、このデータベースへのデータのインポートとエクスポートをやってみました。結論から言うと、日本語を含まないデータのインポートだけしかできませんでした。以下にまとめてみます。

基本的にはGoogleのスタートガイドのページのここに解説されています。だたし、気をつけなければいけないのは、データのインポートおよびエクスポートは英語版のSDKでしかできません(2009年8月3日現在)。どうやらSDKの1.2.1から加わった機能のようです。日本語のダウンロードページで公開されているのは1.2.0なので指示通りのコマンドを入れてもエラーを吐かれます。ですので英語のダウンロードページから最新版(2009年8月3日現在は1.2.3)をダウンロードしてインストールしてください。

これであとは解説ページ通りに行えば行けます。まだローカル環境でしか試してないのですが、1087件のレコードをインポートすることに成功しました。ただしこれは日本語を含まない場合のみで、日本語を含むデータでは

[ERROR   ] Error in worker [Thread-6]: ‘ascii’ codec can’t decode byte 0x82 in p
osition 0: ordinal not in range(128)

というエラーが出てアップロードできませんでした。
また、エクスポート機能についてはGAEのサイトで以下のように言及されています。

2009 年 4 月: Python SDK リリース 1.2.1 には、データのアップロード機能と類似した、データのダウンロード機能の初期バージョンが含まれています。この機能はまだ appcfg.py では使用できませんが、試したい場合は、bulkloader.py をご覧ください。マニュアルを含めたこの機能の完全版を、今後の SDK バージョンでリリース予定です。

さっそくSDKの中からbulkloader.pyというファイルを探して覗いてみました。
【注意】:google_appengineの中には同じ名前のファイルが複数個所にあって分かりにくいですが、ここで言っているのは
\google_appengine\google\appengine\tools
にあるbulkloader.pyです。

この中で定義されているExporterというクラスがLoaderに対応するクラスのようです。さらに見ていくと、appcfg.py(これも上記のbulkloader.pyと同じフォルダ)の中のPerformUploadという関数の近くに(2038行付近)PerformDownloadという関数が定義されています。アップロードには’upload_data’というコマンドが紐付いていますが、ダウンロードには’download_data’が紐づけられているようです(2267行付近)。

つまり、データのアップロードの時に作ったローダクラス(Googleの説明だとalbum_loader.pyになっている)の中のLoaderをExporter、loadersをexportersに書きえてやれば動きそう。
アップロード時のコマンドは(ローカルでテストする場合は)以下でしたが

エクスポートの方では以下のようにすれば動くはず。

ちなみにローカルでテストするときはちゃんとGAEのローカルサーバ(dev_appserver.py)を動かしておいて下さいね。
いや、しかし動かないんだこれが。
 KeyError: ‘Album’
と言われてしまう。「Album」なんて種類のデータは無いんだと。いや、さっきアップロードしましたよっ!データベースから種類「Album」のデータの最初の100件を表示するテストページも問題なく動作してますよ!

なんでだろー。
知ってる方いましたら教えてくださいー。

結局、日本語を含まない場合のインポートだけしかできませんでした。
データのエクスポートができないままでは新規利用者にとって本格導入したい人も二の足を踏みます。もし他のプラットフォームに移行したくなっても、データが取り出せなきゃどうしようもないので。Googleさん、早く正式対応してください。それからドキュメントを…orz

Amazon EC2とGoogle App Engineの比較(それぞれの特徴をまとめてみる)

どうも、うしねずみです。

最近クラウドサービスをちょこちょこ触っています。Amazon EC2とGoogle App Engine(GAE)を両方触ってみたので、それぞれの特徴をまとめてみようかなと思います。

Amazon EC2

【長所】:自由度が高い

Amazon EC2の特長は何と言ってもその自由度の高さです。EC2ではユーザは「使いたいインスタンスのスペック」、「簡単なセキュリティポリシー」、「使いたいインスタンスの数」を選んで、インスタンスを起動します。例えば、OSがWindows Server 2003、CPUの性能はSmall(SmallとかHighとかで選ぶ)、HTTP(80番ポート)とリモートデスクトップ(3389番ポート)を使えるようにして、1インスタンスを起動、といった感じです。インスタンスというのは、PC1台だと思うとわかりやすいと思います。起動したインスタンスにはリモートデスクトップで接続できて(詳細は以前の日記を)、ソフトのインストールからセキュリティの設定までかなり自由にできます(Linux系OSならSSH接続)。

【短所】:面倒が多い

長所の裏返しですが、アプリケーションを実際に公開するまでの敷居が高いです。最初はWebサーバもメールサーバも何も入っておらず、すべて自分で設定しなくてはならないからです。私のように「Apachの設定はちょっとやりたくない。。。」と言う人にはかなり大変です。

また、負荷が増えた時にスケールすることがGAEに比べると以下の二つの点で面倒です。

  • スケールさせるべきかどうか自分で決めなくてはならない
  • スケールさせる際の追加の作業(とオプションの課金)がある

例えば1つのインスタスでサービスを始めたとします。だんだん人が増えてきて、「どの時点でインスタンスを2つに増やすか」は自分でサーバの負荷などを見ながら決めなくてはいけません。毎日ログを見るとはいえ「もう一台必要かなー?どうかなー?」みたいな判断を自分で行う必要があります(負荷に応じて自動的にインスタンスを追加起動する有料オプションがあったような・・・)。

また、もう1つインスタンスを増やすことにした場合「ロードバランサの設定」という追加作業が生じます。ロードバランサとは、一つのサービスを複数のサーバでこなすための「仕事振り分け」をする機器です。例えばusinezumi.comというドメイン(に紐付いているIPアドレス)でサービスを公開しているとします。2台目のPCにこれと違う新しいIPを割り当てるわけにはいかない(そしたらアドレスは違うけど全く同じ別サイトになる)ので、一つのIPに対して飛んできたリクエストを、それぞれのマシンの負荷を見ながら適当に振り分けていく必要があります。これをやってくれるのがロードバランサです。

EC2でロードバランサの設定が大変かどうかは分かりませんが(おそらくそんなに大変ではない)、追加作業が発生しない方がいいのは明らかです(設定でトラぶったらサービス停止するし)。また、ロードバランサはオプションなのでそれに対して新たな課金が発生するのもあまり喜べません(課金体系は覚えていないのでAmazonのサイトで確認して下さい)。

GAE(Google App Engine)

【長所】:簡単!

GAEの特徴は、公開のまでの簡単さとスケールのしやすさです。GAEでは前回の投稿でも書いたとおりに、非常に公開までが簡単です。もちろんEC2のようにWebサーバの設定など必要ありません。コードをアップロードすればすぐにアプリが公開できます。Webアプリの開発者からすれば、Webアプリ以外のことを特に考えなくてよいのでとても楽だと思います。

また、自分のサービスの人気が出て負荷が増えた時に、自動的にスケールしてくれます。EC2で気にしたような「いつ?何台追加?」みたいなことは全く気にする必要はありません。というかそもそも「何台?」という概念自体がありません。

【短所】:自由度が低い

これも長所裏返しなのですが、自由度が低いです。といってもWebアプリを公開することに関して大概のことはできると思うのですが、「じゃあSubversionをインストールして、開発用のレポジトリサーバにできるの?」っていうとできません。新しいソフトをインストールするとか、どのポートを開放するとか言ったことはできません。できるのは、「コードをアップロードして公開する」だけです。あ、ちなみに静的なファイルのアップロードはできます。

【その他】:データベースの特殊性

これは長所でも短所でもあるのですが、GAEのデータベースはGoogleが使っているものと同じ「Bigtable」というものです。これはリレーショナルデータベースではないという点で、現在使われている多くのデータベースと異なります。これは他のプラットフォームからのGAEへの乗り換えの障害になりかねないのですが、このBigtableの特殊性がGoogleの強力な検索能力を実現していると思えば非常に魅力的に見えてきます。

この件について解説している記事もあると思いますのでここでは詳細は書きません。

まとめ

Amazon EC2とGAEはある程度は競合相手であり、ある程度は競合になりえないと思います。なぜなら「できること」の範囲が違うからです。Amazon EC2ではその自由度の高さゆえ、Webサーバ以外の用途にも使えます。例えばメールサーバや、シミュレーションなどの一時的な計算リソースとして使えたり、何か新しいことを試すためのテスト環境として使うようなこともできるでしょう。一方でGAEでは、アプリ開発以外のことができない代わりに、アプリ開発以外のことはほとんど気にしなくてよいという強みがあります。

同じクラウドというラベルを張られていてもかなり違ったサービスなので、自分が必要としているサービスはどちらなのかをしっかり見極めてから使う必要があるようです。

wordpressで「重複するメタデータ(descriptions)のあるページ」の対策をする ~wp.Vicuna Ext. Customをカスタマイズ~

どうも、うしねずみです。

ブログを始めてから、Googleのウェブマスターツールにお世話になっています。Googleアカウントがあれば利用できて、自分のサイトがGoolgeからどのように見られているかが分かるのでとても役立ちます。例えば自分のサイトがどんな検索クエリで上位に来るのかとか、Googleのボットがクロールしに来た時のクロールエラーとか、サイトの作り方について参考になる情報が得られます。

私のブログではウェブマスターツールの「HTMLの候補」のタブで以下の二つの問題を指摘されていました。

  • タイトルタグの重複
  • 重複するメタデータ(descriptions)

つまり、「違うページなのに同じタイトルタグ(メタデータ)がついてるよ」ってことです。違うページにはちゃんと違うタイトル(メタデータ)をつけなさいってこと。タイトルタグの重複については、WordpressのプラグインであるAll in one SEO packが役に立ちます。このプラグインの設定で「Rewrite title」にチェックを入れてタイトルのテンプレートを指定しておけば、記事ごとに違ったタイトルを自動的につけてくれます。私もこれを使っていましたが、最近使い始めたwordpressのテーマであるwp.Vicunaでは最初からページごとに違うタイトルタグを付けるようになっていました(さすがです)。

ところが、もうひとつのdescriptionメタタグに関しては、wp.Vicunaでも対応していません。wp.Vicunaではdescriptionのメタタグは“header.php”で吐き出していますが、header.phpはどのページにも共通に読み込まれるので、記事ごとに違ったメタタグを付けることができません。ですのでここは自分で改造することにしました(違うテーマを使っている人は参考にならないかもしれませんが)。

まずheader.phpのdescriptionメタタグ部分をコメントアウトします。header.phpの26行目の以下の部分をコメントアウトして

次のようになります。

このままだと全てのページでdescriptionメタタグが表示されない(コメントアウトしたから)ので、以下の7つのphpファイルにメタタグを出力する部分を書き加えていきます。

  1. 404.php
  2. archive.php
  3. category.php
  4. index.php
  5. page.php
  6. single.php
  7. tag.php

それぞれのファイルの先頭付近にタイトルタグを出力している部分がありますので、その直前にdescriptionメタタグを付け加えていきます。別に直前じゃなくてもいいですが</head>よりは前に書く必要があります。

これはtag.phpの例ですが、付け加えるとこうなります↓

wp.Vicunaではもともと各ページに違ったタイトルタグを付けるので、descriptionメタタグも同じものにしました。テーマによっては複数のページに同じタイトルタグをやdescriptionメタタグを付けるものもあるので、その場合は各ページで違ったものになるようにしてください。(記事のタイトルを含めるとか、「archive」、「category」といった文字を含めるとか)

これで無事、各ページに違うdescriptionメタタグが付くようになりました。
ところでGoogleに指摘されたからやってみたものの、SEO的にはどれぐらい効果があるんだろうか。。。

↓ぽちっと押してください。
人気ブログランキングへ

クラウド導入日記(1) ~Google App Engineに登録してみる~

どうも、うしねずみです。

最近趣味で走らせているプロジェクトがありましてそこでWebサービスを作ろうという話になっています。試算してみるとかなりサーバーのリソースが必要だということが分かりましてさらにユーザ数とその増加のペースが読めないということになりました。
共用じゃないレンタルサーバー借りると高いし急速なユーザ増加に対応するのは骨が折れそう。

これはもうね。
世の流行りのね。
クラウド使うしかないよね。
っていうか使ってみたいだけかも。

まあ何はともあれやってみようということでしばらくクラウド導入の話を書いていこうかと思います。かなりスローペースで進むとは思いますが気長に見守ってください。

 初回は「Google App Engine(GAE)への登録」です。

 1、まずは、何はともあれGAEのサイトにアクセスしましょう!
そして右上の「スタートガイド」のところからログインを選択します。
すると「Googleアカウントでログインしてくださいよー」と言われるので、ログイン。
(Googleアカウント持ってない人はそれを作るのが先です)
すると次のような画面に飛びます。

google app engine 1

2、Create an Applicationボタンをクリック
「Getting Started Guide」とか「FAQ」とか「Developer’s Guide」とか読んで勉強してくださいねって書いてある。後で勉強することにして、Create an Applicationボタンをクリック。 

3、携帯メールを使って個人認証
GAEのアプリケーションを作るには確認コードが必要です。国と携帯のキャリア(ドコモとかauとか)を選んで携帯の番号を入れてください。SMSを使って確認コードを送ります。(確認コードで)認証するのは(最初の)一回だけです。
って書いてある。
google app engine 2

「携帯の番号入れろ」って言われているのに「Username」と書いてあって何を入れたらいいか迷う。
とりあえず自分の名前をローマ字表記で入れてみた。
すると
「Mobile NumberかUsernameを入れなきゃだめでしょ!」
って怒られる。
google app engine 3

いや、Usernameって何すか。。。って思いながら携帯の番号を入れてみる。
すると
「携帯の番号@ezweb.ne.jpにメール送りました。確認してください。数分しても届かなかったらもう一度トライ!」
的なことを言われる。
google app engine 4

いや、「携帯の番号@ezweb.ne.jp」に送っても届かんだろ、と思ったので再トライ。
つまり、携帯のメールアドレスの@より前の部分(@は含まない)を入れるのが正解のようです。

4、確認コードを入力
そしたら一瞬で携帯にメールが来たのでそれに書いてある確認コードを前の図の「Enter Accout Code:」ところに入れてsendボタンを押す。

5、Application ID とApplication Titleを決める
好きなIDを入れてみてCheck Availabilityボタンを押して空きIDかどうかをチェック。空いてたらApplication Titleも入力して、規約を読んで「I accept these terms」をチェックしてSaveボタンを押す。
google app engine 5

6、無事完了!
以下のような画面が出れば無事完了。
google app engine 6
dashboadを押すと自分のダッシュボードに飛びます。

今回はこんなぐらいで。
次はAmazon EC2の方も登録してみたいと思います。

人気ブログランキングへ

Google Chromeの「要素を検証」が便利

どうも、うしねずみです。

最近ブログを始めたこともあって、適当にテーマファイルやサイトの構成なんかをいじったりして試行錯誤しているのですが、Goolgeのブラウザ、Chromeの「要素を検証」という機能がとても役に立つ。
Chromeで目的のページを表示して右クリックすると「要素の検証」が選べる(下図)。
右クリックして要素を検証を選択

すると別ウインドウが立ちあがり、HTMLソースが階層化されて表示される(下図)。
要素を検証のウィンドウ

するとこのソース上でオンマウスした要素が実際のサイト中のどの部分に対応するのかがブラウザの方に表示される(下図)。
ブラウザ上の表示

 これの何が便利かと言うと、例えば実際に自分のサイトを見ながら「この部分をもっとこうしたい」と思ったとする。慣れている人はいいのかもしれないが私のように不慣れだとHTMLと実際のレンダリングされたページの対応を探すのは面倒なのです。そうした時にビジュアル的に対応する要素を探せるのが私にはとっても便利なのである。

WordPressは動的にページを生成するので、実際に修正を加えるときにはテーマファイルのphpソースの中から該当する要素を吐き出してそうな部分を検索してそれを直接いじって確かめてみるしかない。 

試行錯誤していると自分のPCからのアクセスでページビューが増えていって悲しい。しかし、いつかきっと自分のページビューなんて誤差の範囲になるくらい人が来てくれたら嬉しいなー。

↓同情していただけたら、ぽちっと押してください。
人気ブログランキングへ

Home > Tags > google

Search
Feeds

Return to page top