kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

カテゴリーアーカイブ: Cloud Computing

Azure Table 用のエンティティデザイナ(書きかけ)


DSL Tools で表題のものを書きましたのでおすそ分け。スクリーンレコーディングを Expression のスクリーンキャプチャで取ったのですが、さすがにFullHDでのスクリーンキャプチャはマシン性能が厳しいですな。SkyDriveへあげるつもりだったんだけど、1ファイル50MBまでって事であがんね(w

 うげ、SkyDrive にあげた物の埋め込みタグが貼り付けられずに切られるんですが、これってアリなんでしょうか、同じ所が提供してるサービスとしてどうよな感じ。

←のバーに出している SkyDrive のパブリック配下に AzureTableEntityDesigner.zip がございますのでご自由にお持ちください。

 Spacesもう駄目か?

バッチかリアルタイムか


世間的にはHadoopみたいなバッチソリューションでの分析や集計がこれからはやるって方向なんですが、ちっと異議ありーってところ。
 
確かにKVSだとテーブルにキーは一個だけ、あってもたかが知れてる個数しかないのはご存知のとおり。
これじゃ多様な分析ニーズを満たすなんてことはぜんぜんありえナスな事。
 
でも1テーブルしか更新しないって前提であればそうだったりするだけで、分析のニーズに応じて複数テーブルをInsert/Updateすればいいじゃないって話。RDBMSのサーバがINSERT/UPDATEで物理テーブルと同時にいくつものINDEXを更新するのは周知の事実でそれをプログラムコードでやればすむって話。
 
このときにテーブルのキー構造とインデックスのキーは必ずしも一致する必要はないし、分析側のニーズで必要なINDEXがあるならそれを別々のINDEXテーブルに持てば良いわけで、これでwhereで使えるキーが制約されるとか、そんなのお構いナッシング。Hadoopとかに代表されるMapReduceを使うとかの以前に DAL からビジネスレイヤよりの場所で見れば複数インデックスが付いたテーブルに見え、DAL以降では複数のKVSテーブルに分散格納された構造を作るのは決して不可能なこっちゃなく。
 
フロントの負荷?インスタンス増やして分散しれ!なんのためのクラウドじゃって話だったりするし。
 
確かにこれまでのBIは OLTP からバッチ的にETLしてキューブ作ってという手順踏んできたしそれが効率の良い方法っていうか、必要とされる処理効率に対しての解がそうだっただけで、それを延々とやるわけにはいかんだろーし、「データが見えるまでのラグタイムが発生する」事をいつまで顧客が納得して受け入れ続けるか、リアルタイム更新での分析データを競合が出せると言ったらどうなるか。
 
KVSではキーに制約があって…、既存の OLAP の流れで バッチによるETLで… そこでMapReduceですよHadoopですよって、流れは普通なんだがあからさまに普通ですねー感もしないでもなく。
とりあえずKVSはどの層に属するもんなんだという点で考えれば「トラック番号、セクター番号」でIOするディスクより何ぼかマシ程度の物理層なんじゃねーかとしてみる方向もないわけじゃないっすよと。