IaaSプロバイダはどうやってマーケットを広げるのか？ PaaSレイヤを提供するのは簡単だが、そうすると顧客にはロックインされるという懸念が持ち上がる。顧客が管理の主導権を持てるというIaaSの利点でを維持したまま、どうやってPaaSの利点である、熟練を要する運用業務を顧客から不要にする、ということを提供できるだろうか

その答えは運用を容易にするツールの提供だ。それはIaaS上に用意された、優れた（ベストプラクティスな）インフラで、可用性とスケールを実現するものだ。

これがまさにAWS Elastic BeanstalkがTomcatを用いて行ったことである。

IaaSとPaaSの違いはなくなろうとしている － Publickey

個人的にはベンダロックインよりも、運用がどれだけ容易になるかが最大の関心事だったりする。
運用にもスケールするかどうかが含まれていると考えています。

昨今のWEBサービス開発は、php等のスクリプト言語で作るのがあたりまえです。
初期の開発者の単価が抑えられ、ホスティングサービス等を利用しやすいから。

で、幸運にもWEBサービスが流行ったら、フロントエンドのWEBアプリケーションも色々と性能改善をしつつ機能追加とかするのも大事ですけれど、ある程度の規模を超えるとストレージのレイヤ（データベース側）でがんばってスケールさせる必要が出てくる訳で、ミドルウェア含むインフラ層にもエンジニアを惜しみなく投入して、あの手この手で分散化する必要が出てきます。

最近は知りませんが少なくとも私の知る限り、php は Apache等のhttpデーモン のプロセスまたはスレッドにくっついて動く訳でして、永続的接続とかいう仕組みは有っても、アプリケーション全体でDBコネクションの数を制御したり、プーリングしたり、使いまわしたり、データベースアクセス専門のオブジェクト(DAO)をこさえて使いまわす、なんて事が簡単には出来ない訳でして、そこはもう Java Servlet の方が1階層タンデムな分そこのへんの作りこみが楽だから、ある程度の規模までならデータベースアクセスの観点からパフォーマンス面で有利だと思う訳でして、私がWEBアプリケーションとしてはマイナーな Java を選ぶ理由の1つです。

TCP/IPのコネクションを張るのはそこそこリソースを消費する訳だから、php でApacheのプロセス（スレッド）上減数に合せてコネクションを貼りっぱなし、なんて構成を最初はとったりする訳ですが、RDBMSサーバ側のリソースも結構ふんだんに用意する必要がありますし、規模が大きくなってくると、最近は安くなったとはいえスケールアップさせるのはソコソコ金がかかるんで、水平に垂直に分割したりレプリケートさせたりキャッシュしたりインフラ層でイロイロやらないといけないんで、安定させて性能を出すにはそれなりのコツというか、DBAなんていう職業が成立してしまう位イロイロな匠の技がある訳ですし、24時間365日運用するには、やはり訓練もドキュメンテーションもそれなりに必要になってきます。

で、最初の「運用がどれだけ容易になるか」の話ですが、こういう「インフラ系エンジニア」の下働きは、それなりに優秀な人材を集めなければいけないしコストがかかります。WEBサービスもマネタイズできないと単なるボランティアですからやはり収益性は大事な訳です。

誤解を恐れずに言うならば、インフラ系エンジニアは「システムの能力を最大限に引き出し（必要に応じて向上させて）たり、セキュリティ含むITをとりまくあらゆるリスクを軽減する為にイロイロとがんばる」訳ですが、それで収入が増えるとか言う事は無い、と考えられる事が多いわけです。特に経営層に。

これらはだんだんとコモディティ化してきているから、もし外注できるなら、どうせ金かけるなら優秀なソフトウェアエンジニアを中に雇いたい訳です。サービスをより良くするスピードこそ、競争力であり、収入を増やす為に必要だからです。

こういう事を書くと世の中のインフラ系のエンジニアの方を敵に回しそうなんで一応書いておきますが、価値を生むとか生まんとか以前に情報システムは運用してナンボ、作るだけじゃダメな訳で、運用管理も誰でも簡単に出来る訳じゃないです。Salesforceの様に、運用こそ差別化の最大要因だと言い切ってしまいたい所です。

さらにさまざまな問題を回避する事で、問題が発生した場合に損失しうる企業価値を損なわずにすむという面もありますんで、一概に要らないと言っている訳では無くて、AmazonやGoogleとかが、規模の原理を活かして、自社の優秀なエンジニアと運用のベストプラクティスを、IaaSやPaaSで提供しはじめている訳ですから、少なくともWEBサービスにおいては、ストレージ層も含めて「スケールする」インフラがセットで提供されはじめた今、「事業」として考えた場合、「外注」されやすい分野である事は間違いないでしょう。

要るとか要らないとか言う以前に、土俵というか、世の中のルールというかが変わって来たぞ、と。

そういう観点で、Google App Engine と AWS Elastic Beanstalk を比べると、App Engineの方が楽そうなんだよなぁ。
でも、既存システムの移行の難易度で言うと、格段にBeanstalkの方が楽そうだなぁ。
App Engineの方がスケールしそうだしなぁ。でもAWSの方が自由度高いしなぁ。

と、これからは、クラウドをコーディネートする力が求められそうですね。
纏まりなくてすいません。

WWW SQL Designer

phpなサーバがあれば、ダウンロードしたzipを展開して置くだけ。
成果物はXMLでExport/Importできる。

今まで紙とペンでやってましたけど、こりゃあ良いです。
がっつり作りたい時はちゃんとしたのんが欲しくなりますが、分析フェーズとかちょこっとER図を書きたい時にはめちゃめちゃ便利です。
ブラウザにブックマークしとくだけですし。

参考サイト

ER図作成ツールを2つ紹介 | アイビースター

ウノウラボ Unoh Labs: ブラウザでER図が描ける「WWW SQL Designer」紹介

floatingdays: WWW SQL Designerのインストール＆設定

まず、Entity (エンティティ) と聞くと、Codd博士のERモデルや、IDEF1Xとかの拡張ERモデルを思い浮かべてしまいます。
いわゆるリレーショナル・データモデリングにおける「実態」を表すEntityは、RDB上のスキーマの設計の元になるもの、と刷り込まれているんです。

ですが、app engine の話をするとき、Entityという言葉は文字通り実体のほう、RDBにストアされた個々のインスタンス、つまり行、タプルをイメージするべきの様です。

私だけでしょうか。微妙に混乱します。

このへんの微妙な言葉のニュアンスから、Entity Group と リレーションを混同してしまうという弊害があるんじゃないでしょうか。
実は私もそうでしたので。

Entity Group は Entity (＝オブジェクト、≒タプル) を保存するときに決まる(決める)もの。
リレーションはデータクラスで定義し、Entityに保存する時に決めるもの。

エンティティグループはリレーションではない

祖先とか親とか子とかいう単語が出てくるので誤解しがちだけど、エンティティグループは、１：多のようなリレーションを表現するものではない。

トランザクションによりACID特性を保障したいときに設定するもの。

リレーションはkeyをコレクションで持ったり、Slim3のModelRefなどを使って表現する。
app engineのエンティティグループ – 理系のためのTIPS集

あとkindという言葉も、これからGAEを学ぼうとする人には鬼門になるかもしれません。

Google App Engineの本とか記事とかを読んでいると良く出てくるんですけど、日本語のGoogle Codeのドキュメントを見ても、kindの説明はありません。原文で読むとなんとなく判ってきます。

整理しておきます。

Entity (エンティティ)
	App Engine データストア内のデータ オブジェクト。
	key と プロパティ がセットされる。
	リレーショナルデータモデルで言うところのタプル。
	RDBMSで言うところの行、レコード。
	Javaでデータモデルを定義し、そのモデルのインスタンスを生成してDatastoreに
	保存したら、それがエンティティ。

プロパティ
	名前のついた値。Entityには1つ以上のプロパティがある。
	そのデータ型は整数、浮動小数点値、文字列、日付、バイナリ データなど。
	Jデータクラスのフィールドと(ほぼ)同義。

データクラス
	Javaでデータモデルを定義たクラス。

kind
	正確にはEntity's kindでしょう。
	Datastoreに保存されたエンティティのデータクラスの種類。
	リレーショナルモデルで言うところのスキーマ。
	RDBMSで言うところのテーブル。

ブログサービスの概念モデリングは、[ブログ] – [記事] – [コメント] の 3階層で Header-Detailになる事が多いと思います。

今までRDBMSばっかりやってたのですが、過去は3層で考えた概念スキーマをそのまま論理スキーマにしちゃって問題無かったです。

と言うか今でも私は正規化バンザイ派、概念スキーマをそのまま論理スキーマにしちゃえ派です。このへんは佐藤正美さんのT字形ER手法に強く影響されました。

で、App Engineで作ろうとするじゃないですか。
時間が作れ次第おっかなびっくりやっているので遅々として進まない訳ですが。

まずは記事のCRUDを作ってみて、それは上手くいきました。
で、最近やっと後回しにしていたリレーションシップとトランザクションに取り掛かっているわけです。

「Google App Engine （のKVS）では非正規化を恐れるな」なんて聞いていたものですから、記事Entityの親にあたるブログEntityについては、記事Entityの中に「ブログ名」として繰り返し項目にしちゃえばいいかと、結構簡単に考えていました。

で、いざやってみると、使い物にならない感じなんですね。

まず、記事Entity内で繰り返し項目になっちゃった「ブログ名」を、Distinctして取得したいと思ったんですが、Slim3では（App Engineでは）出来ません。

ならばGroup By で、とも思ったんですが、それもありません。

マニュアルは一度読んでるし、GAEの本も2冊ばかり読んだんですが・・・なんとなく判った気でいるのと、実際に手を動かして困ってみるのとでは、頭に入り方が大違いですね。

ならばと、Slim3の機能を使ってブログEntityと記事Entityを双方向1対多関連にしました。

これで目出度く ブログの一覧は取得出来る様になりました。当たり前ですが。

仕様として、記事Entityは、親であるブログEntity（カテゴリ）の変更というか、付け替えが出来ます。

普通にトランザクションでこれをやろうとすると、com.google.apphosting.api.ApiProxy$ApplicationException がスローされました。

これは自分のコードの書き方が悪いだけでして、異なるEntity Group での更新をしようとした事が原因、という事まではすぐに判りました。

本題はココからでして・・・

ブログEntityはオーナーだけが変更できます。
記事もオーナーだけが書けます。

RDBMS脳では、[ブログ] – [記事] – [コメント] の 3階層 の外側に、[オーナー]Entityがいて、[ブログ]の外部キーになっているか、[オーナー・ブログ]連関テーブルがあるか、そんな感じです。

App Engineでは同一Entityグループでしかトランザクションが使えない。
Entityグループが同一なら物理的な格納位置が近くなる（らしい）。

もしかして、[オーナー]でEntityグループをくくった方が良いのか？？？？

[オーナー] – [ブログ] – [記事] – [コメント] の 4階層？？？

Hibernate的に考えると、オーナークラスのプロパティでブログをSetとかのコレクションクラスで持たせてlazy loadingさせて、あとは記事、コメントと・・・そんな感じ？

それでスケールするのか・・・・？

この4階層の論理スキーマで良いのか、自信が持てないです。 <- イマココ

幸い、Slim3には「グローバル・トランザクション」なるものがあり、異なるEntity Group間での更新も出来る筈です。（まだ試していない）

一貫性を重視するか、スケーラビリティを重視するかで、論理スキーマが変わってきそうな気がします。

もうしばらく悩みそうです。

マイクロソフトのAccess 2010では、ODBCを通じてクラウド上のリレーショナルデータベースであるSQL Azureに直接接続可能だと、MS Officeチームのブログのエントリ「Access 2010 and SQL Azure」で紹介されています。
Access 2010 and SQL Azure – Microsoft Access – Site Home – MSDN Blogs

この機能を使えば、社内でSQL Serverの運用をすることなく、Access 2010から大規模なリレーショナルデータベースの機能を利用することができるようになります。」

Access 2010からODBCでクラウドのSQL Azureに接続可能。そのメリットは？

JetエンジンのままAccessを多人数で使うのは、排他制御の面でも、性能の面でも、あまり宜しくないんですけど、現場によっては結構重宝されていますよね。

自動でシュリンクしないからファイルがどんどん肥大化するし、しょっちゅう壊れるし。
せめてMSDE、今で言うとSQL Server Express Editionですかね、を使って欲しい訳です。

データベース管理者にとっては、SQL Serverのデータメンテナンスなど管理業務をAccessから行うことでずっと便利になるという指摘もいただきました。たしかに、それもぐっと楽になりそうです。

ODBCドライバさえあれば、OracleでもDB2でもデータ管理は出来ますね。
SQL大好きな私にとってAccessのクエリを使うのは苦痛なんですけど、エンドユーザにはGUIで操作できるAccessは結構使いやすいみたいですね。

RDMBSはコモディティ化した感があります。
今後のデータストアのプラットフォームは、完全にクラウド上での覇権争いになってきました。
KVSで無くRDBMSじゃ無いと駄目な案件を、SQL Azure と VM Forceが受け皿になっていきそうな予感。

どうするOracle陣営。

ニッチと言えばニッチなジャンルの雑誌だっただけに仕方ないですが、良く読んでた雑誌が消えていくのは、なんだか寂しいです。

一応RDBMS屋のつもりだった昔、データベーススペシャリストの試験に受かるまで、1、2年くらい定期購読してたんですが、だんだんとWEBな人になってから、最近は読んでませんでした。

自分の興味の対象がデータそのものからサービスに向かっちゃった事で、面白く読めなくなってきたんですね。

関係者の方々はお疲れ様でした。

CSE(Common SQL Environment)

ワタシにとって手放せない理由は、さくっとExcelでテーブル定義書を出力してくれる所。
全体的にすんごく動作が軽い事もイイし、スプレッドシート感覚でデータ操作もできる。
SQL文の実行もできる。OracleでいうObject Browserの様なもの。

残念ながら、2002年からメンテナンスはされていない様ですが、ODBCドライバのインストールと設定さえしてあれば、今でも使えます。
ODBCでイケるから、MySQLだろうがPostgreSQLだろうが、SQL Serverも、DB2も、勿論Oracleも使えます。

多少ならお金払いますから、是非メンテナンスを継続して頂きたい。

Windowsちょっとイイツール紹介シリーズその1でした。

9iの頃のJDBCドライバ(Thin)では、文字数の制約で色々めんどくさかったけど、
10g以降のJDBCドライバでは、いい感じに変換してくれるのか、CLOBフィールドの参照系ならVARCHAR感覚でコーディングできてた。
でも、更新系では手抜きが通じない。
8000バイト位(多分8192バイト)を超える文字列をInsert/Updagteすると、文字列が一部欠落してしまう。
こっちはいい感じに変換してくれない。

仕方ないから、LobHandlerを使ってちゃんと書いた(つもり)。

Spring は未だに 1.2 を使ってマス。
Sprint 2系でも、いっしょじゃないだろうか。

設定はこんな感じで、lobHanderをインジェクションする。

＜bean id=”lobHandler” class=”org.springframework.jdbc.support.lob.OracleLobHandler”＞
＜property name=”nativeJdbcExtractor” ref=”nativeJdbcExtractor”/＞
＜/bean＞

＜bean id=”nativeJdbcExtractor” class=”org.springframework.jdbc.support.nativejdbc.CommonsDbcpNativeJdbcExtractor”/＞

＜bean id=”abstractDao” abstract=”true”＞
＜property name=”dataSource”＞
＜ref bean=”dataSource” /＞
＜/property＞
＜/bean＞

＜bean id=”hogeDao” parent=”abstractDao”
class=”your.package.dao.HogeDaoImpl” ＞
＜property name=”lobHandler”＞
＜ref bean=”lobHandler” /＞
＜/property＞
＜/bean＞

org.springframework.jdbc.object.SqlUpdate を継承したクラスを作る。
Types は CLOBに。後は特に留意点なし。

package your.package.dao.sql;

import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Types;
import javax.sql.DataSource;

import org.springframework.jdbc.core.SqlParameter;
import org.springframework.jdbc.object.SqlUpdate;

public class Create extends SqlUpdate {

public Create(DataSource ds) {
super(ds, QUERY);
super.declareParameter(new SqlParameter(Types.INTEGER)); // ID
super.declareParameter(new SqlParameter(Types.CLOB)); // Clob Data
compile();
}

private static final String QUERY = “INSERT INTO Table (ID, CLOBFIELD) VALUES ( ?,? )”;

んで、org.springframework.jdbc.core.support.JdbcDaoSupport を継承して、さっきのSqlUpdateクラスを使う。
DIしたlobHandler を使って、 SqlLobValueを生成してあげる。

package your.package.dao.sql;

public class HogeDaoImpl extends JdbcDaoSupport {

public HogeDaoImpl() {
super();
}

private LobHandler lobHandler_;

public void setLobHandler(LobHandler lobHandler) {
lobHandler_ = lobHandler;
}

public void save(Object entityBean) {
BeanOfTable bean = (BeanOfTable) entityBean;
SqlLobValue clobField = new SqlLobValue(bean.getBody(), lobHandler_);
String id = bean.getId();
Create create = new Create(getDataSource());
create.update(new Object[]{ id, clobField });
}

	java.sql.SQLException: 列索引が無効です。

[commons-dbutils] エラー：列索引が無効です。 – メモ！メモ！ – Yahoo!ブログ
によると、

	PreparedStatementのプレースホルダの数と、設定しているパラメータの数が合っていない。

らしい。

が、数は有っている。

散々悩んだ挙句、ResultSetのgetXX の引数が、途中で間違ってた。
こんな感じ。

	bean.setValue1(rs.getString(1));
	bean.setValue2(rs.getString(2));
	bean.setValue8(rs.getString(8));
	bean.setValue4(rs.getString(4));
	bean.setValue5(rs.getString(5));
	bean.setValue6(rs.getString(6));

実際は、列の数が200以上ある様なケースだったので、なかなか判らなかったのだ。

自戒の意味を込めて、書いておこう。

ロックの自動エスカレーション

SQL Server 2000のロックは、動的にロック方法を自動判断して行われる。

行ロック・ページロック・DBロック

上記のチューニングとしてMS SQLでは”分離レベル”の設定 が4つある。
下に行くほどデータの整合性が上がるが、デッドロックが起こりやすくなる。
OLTPの場合、余程大勢でInsert、Updateをしない限り、デフォルトでいいんじゃないかと思う。
トランザクションを使用する場合は、明示的に 3) を選択 (後述) する場合もあるかも知れない。
但し、トランザクションは短めに。

1) READ UNCOMMIITTED
ユルユル。ダーティリード可能

2) READ COMMITTED
コミット済み読み取り (SQL Server の既定の分離レベル)

3) REPEATABLE READ

4) SERIALIZABLE
直列化 (各トランザクションが完全に分離される最高の分離レベル)

明示的なロック

ロックは明示的にもできる。ロックヒントと呼ばれるモノをSQLステートメントに挿入ればいい。

   SELECT * FROM TABLE_NAME  WITH (ROWLOCK) WHERE FIELD_NAME = 'hoge'

WITHのとこのロック種類はこんなにある。

• FASTFIRSTROW
• HOLDLOCK
• NOLOCK
• PAGLOCK
• READCOMMITTED
• READPAST
• READUNCOMMITTED
• REPEATABLEREAD
• ROWLOCKSERIALIZABLE
• TABLOCK
• TABLOCKX
• UPDLOCK

ロック競合

ロックが競合した時のタイムアウト設定があるらしい。

    SET LOCK_TIMEOUT [timeout_period(ミリ秒単位)]デフォルト0ミリ秒

と言う事は、トランザクションが失敗した時の処理をキチンと実装しなければ(ロールバック->コネクトクローズ)、タイムアウトまで待ちっぱなしになると言う事になると言う事だろうか。

ロックの状況は、エンタープライズマネージャで確認できる。ストアドプロシージャ(sp_lock)、master.syslockinfoテーブルでも確認できる。

参考サイト
ZDNet SQL Serverのデットロックを防ぎ同時実行性を向上させよう

トランザクション分離レベルの選択とデッドロックの問題～ SQL Server 2000 における Web アプリケーション開発 ～

テーブル増時のパフォーマンスは？インデックス vs DB分割

RDBMSをスケールさせる為に、データを垂直分割したいときがある。
それに備えて、DB設計時から垂直分割するのは是か非か。
SQL Serverは1つのインスタンスに複数のデータベースが作れる。
貧乏なウチは、1つの物理サーバかつインスタンスで、複数のデータベースを作って、データを垂直分割し、アプリケーション側で何の工夫もせずに、SQLだけで検索できなくもない。
例えば、2億レコードの単一DB と、 10万レコードの200個のデータベースとで、どれ位のパフォーマンスの差がでるだろう。
一般的に、テーブルが分かれると発行するSQL文が増える為、パフォーマンスが低下するのだけど、設計とSQLの作りにもよるし、実際に検証しなければわからない。
時間があれば一度検証してみたい。

物理ディスク構成

最低でも、データベースファイルとトランザクションログファイルは物理的に分けたい。
SANにデータベースファイル、ローカルHDDにトランザクションログファイルとか。

APIはあるの

ある。BOL参照。インストール時にカスタムを選択し、開発ツールを選択すると、スクリプトのサンプルもインストールされる。

phpからデータベースサーバへの接続方法(ミドルウェア)

MS SQL Serverの接続方法には色々あるが、PHPでの使用となると、ODBC関数の使用もしくはMS SQL関数の使用の2つが用意されている。

下記2つのパフォーマンスの善し悪しは、比較検証して見ないと分からない。

1)MS SQL関数
MS SQL関数は、MS SQLクライアントツール”ntwdblib.dll”を必要とする。
このモジュールは、DB-Libraryと呼ばれる呼び出しインターフェースで、MS SQL Server6.5の頃の古いAPIである。下位互換の為に用意されているようで、MS SQL Server2000で用意された新機能を使う事が出来ないらしい。Unicodeにも非対応である(非対応の意味が良く分からないが)。

2)ODBC関数
ODBC3.7以上では、Unicodeをサポートするようだ。(要検証)
正確には、MDAC 2.1以上 または SQL Server ODBC ドライバ (バージョン 3.70.0623 以降) または OLEDB プロバイダ (バージョン 7.01.0623 以降(MS KB JP234748)。
MS SQL Serverをインストールすると、MDAC2.6がインストールされるようだ。