2015/08/29

吉野弘さんの詩

夕焼けなど

2015/08/20

久しぶりに見直し

ブログにメモをつけていたのを思いだし、久しぶりに見直しました。

メンタル面が不安定だったのだろう記述が、散見されます。
思えば遠くに来たものです。

2010/12/18

RDBからKVS

アプリケーションアーキテクチャのパラダイムはどんどん変化している。
構造化プログラムがオブジェクト指向になったように、規模や複雑さの増加に対応して、新しい考え方がどんどん導入されている。
アプリケーションの適用範囲や期待値が高まる事による自然な流れとも言えるし、マシンパワーの向上や価格低下がそれを可能にしたのだろう。

ただ、最近のJ2EEなどJavaとRDBの組み合わせの進化は、方向性を誤っているように感じる。
いま仕事で携わっているプロジェクトでJBoss Seamを採用しているが、求められている要件からすると、不釣り合いな程に複雑なシステムになり、開発にかなりの労力が必要になっている。
ドメイン分析やエンティティ設計が不十分で適当なために混乱が生じていることも、原因の大きな部分を占めているが、エンティティ設計にそれ程のスキルや才能を必要とすること自体、正統な進化を遂げているとは言い難い。

エンティティの変更は、処理ロジックの変更に比べて影響度が大きく、気軽にできるものでは無いため、開発初期の段階である程度しっかりしたものが出来ている必要がある。それは確かなのだけれど、アジャイルやFDDのような、小さくて動くものを積み上げる形式の方法論では、最初にすべてのエンティティを決めることには無理があり、後から見直しが必要になってしまう。

アジャイルやFDDは、要件ずれのリスクを小さくするための方法論だから、要件が複雑化している現状からすると、ウォーターフォール型開発の正統な後継に思える。けれど、エンティティの揺れによって大きな手戻りが発生しやすく、トータルの開発コストは膨れ上がりやすい。要件品質と開発コストのトレードオフと見ることが出きるけれど、それって進化とは言えないだろう。(選択肢が多様になるので価値はあるけれど)

プログラム言語が、JavaやRubyのようなオブジェクト指向言語だろうと、Cのような手続き型言語だろうと、エンティティ設計の困難さはあまり変わりが無い。処理言語の問題ではなく、RDBというデータ構造の限界なのだろうと思う。

ということで、DBMSの新たなパラダイムとして、KVSに期待している。
Google App EngineのBigTableもKVSだけれど、試すには敷居が高いと思っていたらApacheのプロジェクトにもKVS的なものがあった。
CouchDB プロジェクト
手軽に試してみるにはこちらの方が良さそう。(@ITに解説記事があるので手始めに全部読んでみたい)

JavaとBigTableの組み合わせで行くなら、Slim3(非公式日本語サイト)をつかうのもありだけど、KVSにスケーラビリティよりも柔軟性を期待しているので、言語も別のものを探したい所。
もちろんプログラムで処理するには、ある程度の型情報が定義されている必要があるから、KVSと型情報を保持させる仕組みを組み合わせれば、次世代の主流になれるのではないかと思う。

ちなみに、KVSを含むRDBでないDBMSはNoSQLと呼ばれているみたい。(Wikipediaの記事)

2010/12/17

Web型オンラインストレージ

Evernoteという名前を所々で見かけたので、ググってみた。

以下が日本語サイトのURL。
http://www.evernote.com/about/intl/jp/

どうやら、オンラインストレージサービスみたい。
無料会員でも、月々60Mバイトアップロードできて、検索もあるので
ちょっとしたメモの保存/共有には重宝しそう。

同系のサービスに、Zoho NotebookやGoogle Notebook があるので、多分使い勝手が良いんだろう。
「多分」なのは、クライアントがWindowsとMacしか用意されてないから試していないため。
wine経由で頑張って見るほど必要性を感じないし。

ちなみに、大容量データを保存したいならDropboxが人気の模様。
こちらはLinuxkクライアントもあるし、使ってみたらローカルフォルダ並の手軽さ。
これは、いいサービスだ。

で、同系のサービスにGoogle Storageがあって、
有料版のバイト単価はこっちの方が安いみたいだけど、、、
どうもGoogleさんはユーザビリティが苦手らしい。

2010/10/24

Redis

オープンソースのKVSにRedisとういのがあるらしい。
「Redis 2.0.0」が2010年9月5日にリリースされたとのこと。
ハッシュ以外のデータ構造もサポートし、リスト型、集合型、順序付き集合型などのデータ構造が扱える。
サーバ側でコレクションに対するpush/pop、コレクション同士のunion/intersection、数値のincr、decrなどの操作もアトミックに行える。

RDBと役割を分担しつつも、今後のメインのデータストレージになりそう。
トランザクションの必要性がなくなることは無いだろうけれど、
必要な部分を可能な限り小さくする設計を考える必要が出てくるかも。