CQI: 統一的クエリーインターフェースクラウドコンポーザビリティをサポートする PaaS システム（１）

CQI: 統一的クエリーインターフェースクラウドコンポーザビリティをサポートするPaaSシステム（１）藤田昭人株式会社IIJイノベーションインスティテュート

はじめに 自己紹介今更いらんでしょう・・・詳細は２００８年１０月のSIPROP勉強会の講演資料を見てください Project Gryfon 僕のプロジェクト会社設立を含む事業化のための研究開発プロジェクトこれも詳細は２００８年１０月のSIPROP勉強会の講演資料を見てください Cloudbusting Machine（CBM）「クラウドコンポーザービリティをサポートするPaaSシステム」の名前クラウド向けプログラミング環境を提供するプラットーホーム（Cloud OS）経産省「次世代高信頼・省エネ型ＩＴ基盤技術開発事業」の委託に基づく元ネタは２０１０年４月頃のSIPROP勉強会の講演内容誰ものっかてくれなかったので自力で開発資金を獲得して体制を固める最初の２０１１年７月に最初のリリースを開始 http://www.gryfon.iij-ii.co.jp/ 経産省との約束だったからやむおえず・・・

クラウドコンポーザビリティをサポートするPaaSシステム（１）クラウドコンポーザビリティをサポートするPaaSシステム（１） PaaS サービスを提供するためのシステムウェブ・アプリケーション・フレームワークのスケールアウト拡張 Google AppEngine と同様のアプローチクラウド・アプリケーション向けデバッガアプリケーション・フレームワークに隠蔽された自動スケールアウト機構リソース・ディレクトリ・サービス（クラウド内・クラウド間）クラウドコンポーザビリティの実現

クラウドコンポーザビリティをサポートするPaaSシステム（２）クラウドコンポーザビリティをサポートするPaaSシステム（２）２０１０年７月段階の提案では・・・利用者にはウェブ・アプリケーション・フレームワークに見える Google AppEngine と同じアプローチサポートするスクリプト言語は PHP を想定機能実現はC言語を使用　→　将来の他のスクリプト言語のサポートに配慮リソースディレクトリを介してクラウド間での動的な状態管理を行うクラウドを構成するノードアクティブなサービスとロケーション利用可能なユーザーとアプリケーション・・・etc クラウド・アプリケーション開発を支援する２つのファシリティ自動スケールアウト機能クラウドの稼動状態に応じて自動的にスケールアウトクラウド・デバッガー異常が発生した任意のインスタンスの実行状態を再現今となってはちょっと嘘になっているところも・・・僕は走りながら考える人なので ←　周囲はいい迷惑東日本大震災の影響もあってね ←　大人の事情もあって

統一的クエリーインターフェース ・　は・　性

統一的クエリーインターフェース（CQI）　概要統一的クエリーインターフェース（CQI）　概要様々な KVS/RDB を対象に統一されたアクセス手段を提供する（P7） CBMのクラウドアプリケーションから利用可能 CQI独自のクエリー環境（スキーマ・クエリー言語）を定義同時に複数の KVS/RDB へのアクセスが可能データベースの移行や複数データベースでの連携を想定しているアーキテクチュア Google AppEngine for Python（GAE/P）の GQL の処理系の模倣３種類のコンポーネントから構成される（P8） Query Engine GQL に準拠したクエリー言語を解釈 Datastore Bridge KVS/RDB へのアクセスをディスパッチ Storage Driver KVS/RDB に依存したアクセスを行うサポートしている KVS/RDB Cassandra MongoDB MySQL（ライセンスの問題により非公開）

統一的クエリーインターフェース　コンセプト統一的クエリーインターフェース　コンセプト Storage A Storage B Storage C PHP Execute Environment Storage A Driver CQI API Datastore Bridge User Defined Object Query Engine Storage B Driver User Defined Object User Defined Object Storage C Driver GAE DataStore API

統一的クエリーインターフェース　現在のアーキテクチュア統一的クエリーインターフェース　現在のアーキテクチュア PHP Application Java Application YYY Application ZZZ Application L PHP Interface Java Interface YYY Interface ZZZ Interface PHP-C Binding Java-C Binding YY-C Binding ZZZ-C Binding Query Engine GQL Parser QE DataStore Bridge KVS Driver MongoDB KVS Driver MySQL KVS Driver Cassandra KVS Driver XXX S MongoDB MySQL Cassandra XXX

統一的クエリーインターフェース　API Cによる API を規定している ${PREFIX}/include/cqi.h CQI 構造体の生成・破壊 CQI_t *cqi_new(char *driver, char *user, char *passwd, char *host, int port); void cqi_free(CQI_t *cqi); GQL によるクエリーの解釈 query_t *cqi_analyze(CQI_t *cqi, char *gqlstr); ストレージへの接続・解除 int cqi_attach(CQI_t *cqi, char *aux); Int cqi_detach(CQI_t *cqi); ストレージへのアクセス Int cqi_put(CQI_t *cqi, entity_t *ep); Int cqi_delete(CQI_t *cqi, entity_t *ep); entity_t *cqi_fetch(CQI_t *cqi, query_t *qp, int *count); Int cqi_count(CQI_t *cqi, query_t *qp);

統一的クエリーインターフェース　Cによるサンプル統一的クエリーインターフェース　Cによるサンプル int main(int argc, char *argv[]) { CQI_t *cqi; query_t *qp; entity_t *ep; char *gqlstr = "SELECT * FROM xzip"; int i, n; cqi = cqi_new(“Cassandra", // driver "root", // user "root", // passwd "127.0.0.1", // host 9160); // port cqi_attach(cqi, "xzipcode.xzip"); // connect datastore qp = cqi_analyze(cqi, gqlstr); cqi_query_show(qp); n = cqi_count(cqi, qp); printf("\n# %d entries\n", n); if (n > 0) { ep = cqi_fetch(cqi, qp, &n); if (ep != NULL) { for (i = 0; i < n; i++) { printf("\n# %d\n", i); cqi_entity_show(&ep[i]); } } cqi_entity_free(ep); } cqi_query_free(qp); cqi_detach(cqi); // disconnect datastore cqi_free(cqi); exit(0); }

統一的クエリーインターフェース　PHPによるサンプル統一的クエリーインターフェース　PHPによるサンプル <?php if(!extension_loaded('cqi_php')) { dl('cqi_php.' . PHP_SHLIB_SUFFIX); } $query_string = 'SELECT * FROM xzip'; $queryArray = array(); $gql = array('main_sentence' => $query_string, 'param_count' => count($queryArray), 'param' => $queryArray); $result = cqi_analyze($gql); $qarray = $result['query']; $query = $qarray[0]; $driver = array('driver' => 'cassandra', 'user' => 'root', 'passwd' => 'root', 'host' => '127.0.0.1', 'port' => 9160, 'aux' => 'xzipcode.xzip'); $result = cqi_count($driver, $query); $result = cqi_fetch($driver, $query); ?>

統一的クエリーインターフェース　ZipBench CQIがサポートするストレージの性能評価を行うベンチマーク RDBの性能評価でよく使われる郵便番号データによる日本郵便が公開する郵便番号データを利用したデータベース総データ数は123,004件※詳細は日本郵便のホームページを参照http://www.post.japanpost.jp/zipcode/dl/oogaki.html ベンチマークの内容郵便番号データベースを対象に４種類の条件によるクエリーを実行し、その実行時間を１クエリーごとに計測するあらかじめデータベース等を作成しておく必要がある PHP版、C版の2種類を用意コードリリースに収録しているソースコード: ${PREFIX}/src/zipbench ビルド環境： ${PREFIX}/build/cpp/zipbench 現在進行中の作業データ登録に関するベンチマークテストドキュメント

統一的クエリーインターフェース　性能（１）統一的クエリーインターフェース　性能（１）

統一的クエリーインターフェース　性能（２）統一的クエリーインターフェース　性能（２）

統一的クエリーインターフェース　APIの内幕 GAE/P の db extension が提供している機能はそれなりに網羅一応 Analyze/Put/Delete/Fetch/Count が使える GQLはSELECTのみをサポートするクエリー言語 SELECT文を解釈してConditionとOrderingの情報のみを抽出 ANCESTORは取り合えず無視データーモデルは Datastore API を参照 Entity と Property による Db extension の Model クラスに対応するモデルはないプログラミングスタイルはGAE/Pから大きくかけ離れている PHPからの呼び出し方法で悶絶したから拡張モジュールからPHPのクラスにバインドする方法が当初わからなくて PHPで Model クラスの再現を試みるも効率悪すぎクエリー結果を拡張モジュールとPHPのデータ領域でコピーするから将来の1000エントリ制限撤廃を考えると致命的

統一的クエリーインターフェース　開発の現状統一的クエリーインターフェース　開発の現状現在リリースしているのは第１プロトタイプ当初はGAE/PからC++へのコンバージョンを企図するも挫折 Python って LISP だったんだねぇやむなく方針変更をして同等機能を C で実装ちょっと力ずく感もあるが・・・APIは爺感に溢れてるしまぁコンセプトの検証を優先しましたひと通り作ってみていろいろわかってきた拡張モジュール経由で PHP とのデータ引渡しをする方法だとか何でもかんでも連想配列に突っ込めばよいというわけではなさそう Cassandraでクエリーを実行する方法だとかひと通り作ったところで中村君がMyCassandraをやっていることを聞いて絶句上限1000エントリーってCQIに意味はあるの？ GAE/Pはサービスだからリソース占有を避ける必要があるけど・・・これらの反省を元に現在第２バージョンの作成を急いでます第１プロトタイプはデザイン的に課題多し基本的には GAE/P の該当コードをよく読んで意訳で解釈しつつ xQL パーサーは大きな課題

CQI 第２バージョン　課題 第１プロトタイプからの積み残し課題はGQLとの整合性 GAE/P では db extension が良く知られているが、取り合えずその下位に位置する Datastore API と整合を取ることで作業中データモデルは Entity と Property のみを定義各種スクリプトにはオブジェクトとしてバインディング Datastore API はスレディングによる非同期通信でBigTableと通信しているように見えるのだが・・・各 KVS/RDB との通信は各システムがサポートするクライアントライブラリを利用これがまたまたいろいろあって・・・悶絶もっとも厄介なのはインデックス問題 KVSのなかには検索の制限から独自にインデックスを設けないとGQLによるクエリーができない事例があるが、最近ではKVSもインデックスをサポートしている事例もあって・・・現在はCassandra用ドライバーでSecondary Indexと独自インデックスを組み合わせたGQL対応を行っているが・・・整理が必要。

GAE/P DataStore API の内部構造 api/datastore.py Query Class Count Run Get Get Put Delete datastore/datastore_query.py Query Class datastore/datastore_index.py YAML datastore/datastore_rpc.py

GQLのクエリー 構文制限不等式フィルタが使用できるのは、1つのプロパティに限られる。等号を先に指定しなければならない。フィルタで使用されているプロパティの順序付けを先に指定しなければならない。 SELECT * FROM <kind> [WHERE <condition> [AND <condition> ...]] [ORDER BY <property> [ASC | DESC] [, <property> [ASC | DESC] ...]] [LIMIT [<offset>,]<count>] [OFFSET <offset>] <condition> := <property> {< | <= | > | >= | = | != } <value> <condition> := <property> IN <list> <condition> := ANCESTOR IS <entity or key>

CQL Cassandraのバージョン0.8よりサポートされたNoSQL http://www.datastax.com/docs/0.8/api/cql_ref Command USE SELECT INSERT UPDATE DELETE BATCH TRUNCATE CREATE KEYSPACE CREATECOLUMNFAMILY CREATEINDEX（Secoudary Indexを作成するため） DROP COMMON Idioms

CQLのクエリー 構文 [FIRST N] 行ごとに返される列数の制限 [REVERSED] 結果のソート順が逆になる [USING <CONSISTENCY>] 整合性レベルのオプション制限プロパティ値に対するクエリは、インデックスが張っていないと使用できない。 ORDER BY句に相当するものはない。 SELECT [FIRST N] [REVERSED] <SELECT EXPR> FROM <COLUMN FAMILY> [USING <CONSISTENCY>] [WHERE <CLAUSE>] [LIMIT N];

HQL HyperTableにて使用されるNoSQL http://hypertable.org/hql/index.html Command ALTER TABLE CREATE NAMESPACE CREATE TABLE DELETE DESCRIBE TABLE DROP NAMESPACE DROP TABLE DUMP TABLE GET LISTING INSERT LOAD DATA INFILE RENAME TABLE SELECT SELECT CELLS SHOW CREATE TABLE SHOW TABLES USE

HQLのクエリー 構文 column_predicate や where_predicate では直接値を指定する他に正規表現を用いることもできる。制限制限ではないが「行キー以外に対する検索のクエリは効率的ではない」とある。 ORDER BY句に相当するものはない。 SELECT [CELLS] ('*' | (column_predicate [',' column_predicate]*)) FROM table_name [where_clause] [options_spec] SELECT CELLS col1:/^w[^a-zA-Z]*$/ from RegexpTest WHERE ROW REGEXP \"^\\D+\" AND VALUE REGEXP \"l.*e\";",

クエリとインデックスの関係 ※　等式を含む条件の場合のみ、複数プロパティに対してのクエリが実行できる。 ※※　明記されている制限はないが、行キー以外の検索条件はパフォーマンスが悪い。　　　（また、「Access Groups」と「BloomFilter」にてパフォーマンスの向上を図っている？？？）上図では、カスタムインデックスとは、ストレージが持つ機能のみを使用した場合のインデックスとする。

SELECTフレーズのまとめ SELECT <A> FROM <B> WHERE <C>=<D><E> <C>=<D>

CQI: 統一的クエリーインターフェースクラウドコンポーザビリティをサポートする PaaS システム（１）