GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Sebastien Auvray , 翻訳者 編集部 投稿日 2008年11月19日
ActiveRecordはRailsの事実上のORM(O/Rマッピング)である。Sequel(リンク)(v2.7.1)はActiveRecordに代わるORMだが、それ以外にもRubyの包括的なツールキットとなり、データベースオペレーションを行う。
- Sequelはデータベースクエリとテーブルスキーマの構築を目的に、スレッドの安全性、接続プーリング、簡潔なDSLを提供する。
- Sequalはまた、Rubyオブジェクトへのレコードのマッピングと関連レコードの処理を目的として、軽量ながら包括的なORMレイヤーを備えている。
- Sequelは、プリペアード・ステートメントや束縛変項(リンク)、マスター/スレイブ設定、データベース・シャーディングといった(リンク)高度のデータベース機能をサポートする。
- SQL.Sequelを使えば、SQLを習得し始める必要なく、複数レコードの処理が容易にできる。
- Sequelには現在、ADO、DB2、DBI、Informix、JDBC、MySQL、ODBC、OpenBase、Oracle、PostgreSQL、SQLite3用のアダプタが揃っている。
Sequel DSLの例:
DB[:countries].filter(:region => 'Middle East').reverse_order(:area).
SQLには以下のように翻訳される:
SELECT avg(GDP) FROM countries WHERE region = 'Middle East' ORDER BY area DESC LIMIT 5
changelog(リンク)(変更ログ)を一見すればプロジェクトの活動がわかり、新リリースが定期的に発表されている。
InfoQでは、Sequelの進捗状況やActiveRecordとの比較について、Jeremy Evans氏と情報交換する機会を得た。
InfoQ - 前回のインタビューでSharon Rosner氏はSequelを始めた理由として、Railsにマルチスレッディングと接続プールが欠如していたことを挙げていました。Rails 2.2では両方ともサポートされていますが、Sequelを選択する理由として、この点は相変わらず有効でしょうか。
Evans氏 - ActiveRecordの新しい接続プーリング機能をまだ使っていないので、Sequelと比較してどの程度優れているのか分かりません。Sequalの接続プーリング機能は私がメンテナンスを引き継ぐずっと前から存在しますが、同機能に対する苦情は聞いたことがないので、Sequalの実装の堅牢性を確信しています。ActiveRecordの実装が同じように優れているか否かは、時間が経てばわかるでしょう。
他の理由はどうですか。大きなデータセットや複数レコードの処理では、Sequelは相変わらずActiveRecordよりもアジャイルでしょうか。可能な限り生のSQLを回避できるようにしているSequelは、現在のActiveRecord よりも依然としてRuby的でしょうか。SequelがActiveRecordより優れた能力を発揮する分野がほかにありますか。その逆はどうでしょうか。
SequelはSQLを受け取って、Rubyのレベルで公開します。ActiveRecordではSQL文字列の断片を使ってクエリを組み立てますが、Sequelで使用するのはプレーンなRubyオブジェクトです。Sequelは確かに、よりRuby的なデータベースライブラリであり、SequelではSQL文字列をひとつも使わないで、結構大がかりなアプリケーションを書けます。
両フレームワークとも、他方には相当するものが存在しない分野があります。たとえばSequelには、マスター/スレイブ・データベース、データベースシャーディング、束縛変項、プリペアード・ステートメントに対するビルトインサポートがあります。ActiveRecordでは(少なくともプラグインなしでは)こうしたものに対するサポートはありませんが、ActiveRecordのスキーマパーサーは現在のところ、Sequelより機能数が多く、ActiveRecordにはSequelと複製可能な関連の型(たとえばポリモーフィック関連)に対するビルトインサポートもありますが、Sequelほど簡単に使えません。ActiveRecordよりもSequel(あるいはSequelよりもActiveRecord)を使う理由にパフォーマンスがなり得るかどうかは、定かではありません。ActiveRecordが優れた能力を発揮する分野の1つに、使っていない多数の列を選択している場合があります。Sequelはデータベースからデータが回収されるときに、そのデータをタイプキャストしますが、ActiveRecordは使用する時までタイプキャストしません。Rubyの日付クラスはインスタンス化が非常に遅いので、日付を使っていない限り、この件は大きな問題にはなりません。使用中の列を選ぶだけなら、Sequelの方が速いはずです。これを一言で単純に言うなら、最適化しない場合はSequelのパフォーマンスの方が劣り、最適化すればSequelの方が優れている、ということになるでしょう。
Sequelは多数のデータベースをサポートしますが、PostgreSQLやMySQLをターゲットとして多数のパフォーマンス改善が行われています。他のデータベースとのパフォーマンスについて、自信がありますか。
私はプロダクションアプリケーションではPostgreSQLしか使わないので、私が行うデータベース特異的な最適化は、その大部分がPostgreSQL関連となる傾向にありますが、その理由は、そうすれば私のアプリケーションに最も利益をもたらすからです。アプリケーションのテストでSQLiteを使うこともありますが、MySQLを使うのはSequelをテストする時だけです。Sequelを使えるその他すべてのデータベースについては、私の手でテストはしていません。
率直にあなたの質問に答えるとすれば、答えはノーで、私には自信がありません。なぜなら、Sequelと他のデータベースを一緒に使った経験がないからです。しかし私の記憶では、パフォーマンス関連の苦情はきていません。
このSharon Rosner氏とのインタビューは (リンク)10ヵ月前のもので、Sequelは当時バージョン0.5でした。それ以来、あなたがこのプロジェクトの指揮をとるようになりました。v2.7.1までに導入された新機能で、あなたにとってもっとも意義深い機能はどれでしょうか。ロードマップでは、すばらしい新機能がすでに決まっているのでしょうか。Sequelを使ってRails/Merbをうまく実装できた、というフィードバックはたくさんありますか。
私がSequelを使い始めたのは1.2からですから、それ以前の変更については知りません。1.2以降の最も意義深い変更と新機能は以下のとおりです。
1) Magic Removal(マジックリムーバル):2.0以前はSequelの実装はたくさんのマジックに依存していました。1.5から2.0にいく間に、重要な内部変更を多数行い、さらにクリーンなコードにして、容易に作業できるようにしました。
2) ドキュメンテーション:私がメンテナンスを引き継いだとき、Sequelの大部分が文書化されていませんでした。今では一部のアダプタを除き、Sequel全体としては少なくとも基本的なドキュメンテーションが揃っています。
3) 関連づけ:どのRuby ORMと比較しても、Sequelの関連づけは最強です。ActiveRecordを使えば特定の関連の型(たとえばポリモーフィック関連)を実装する際の手間が減りますが、Sequelではユーザーに公開する内部の仕組みを増やし、より細かい粒度の制御を可能にすることにより、ActiveRecordでは不可能な関連の実装が可能になります。
4) データセットのグラフ作成:任意のデータセット(テーブル)2つを一緒にグラフ化し、結果をコンポーネントテーブルにスプリットできます。ユースケースとしては、同一名の列をもつ2つのテーブルを結合したいけれども、列に別名を与えて結果を手作業でコンポーネントテーブルにスプリットしたくない場合です。グラフ作成があなたに代わってすべてを処理してくれます。
5) Expression Filter DSL:高度なフィルタリングを行う場合、以前SequalはParseTreeを使用していましたが、ParseTreeのパフォーマンスは最適とは言えず、JRubyやRuby 1.9には使えませんでした。Expression Filter DSLの使用法は非常にシンプルで、パフォーマンスも良く、そして人気の高いすべてのRuby実装で使えます。このDSLでは、「dataset.filter(:number > 2)」のようなコードが機能します。
6) JRubyとRuby 1.9のサポート:Rubyの三大人気実装のすべてが、今ではSequelをサポートしています。
7) プリペアード・ステートメント/束縛変項:Sequelでは、実際のデータベースのプリペアード・ステートメントと束縛変項を使用できるデータベースもあり、それ以外のすべてのデータベース上では、エミュレートしたサポートを利用できます。使用中のデータベースにもよりますが、プリペアード・ステートメントは通常のクエリと比べてきわめて高速になり得ます。
8) マスター/スレイブ・データベースとシャーディング:Sequalには、マスター/スレイブ(読み取り専用)データベースとデータベース・シャーディングの両方に対するビルトインサポートが備わっています。
将来のロードマップについてですが、計画は大してありません。何か意見があれば聞きますが、現在のSequelで私のニーズのすべてが満たされているのです。現在はコーナーケースの修正に取り組んでいますが、予定している機能はありません。
RailsやMerb、Ramaze、Sinatraなど、Sequelを使用した実装がかなりの数存在することを知っています。個人的には、自分のアプリケーションでSequelと一緒に使うのはRailsかRamazeです。
原文はこちらです:http://www.infoq.com/news/2008/11/sequel-ruby-db-toolkit
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信