株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。

深夜番組のようなノリで、Twitter・KVSもろもろについて考える

»

 前から、発展するかと書きためていたメモから、1本分には発展しそうもない探偵ナイトスクープ風小ネタ集(雑感)です(探偵ナイトスクープって関西の人しか分からんネタかな)。

◇    ◇    ◇    ◇

■Twitter

 何カ月かやってみて何となく分かりました。これって、英語圏より日本語(漢字)圏の方があってる気がします。昔からチャット特有の英語のスラングがあるけれど、それでも、英語では140文字では厳しそう。

 Twitterは本音が出てしまうというのはそのとおりだと思います。ブログは多少いい格好はしてしまいますからね。

 基本的にはチャットの拡張版と見てしまう。チャットといえば Niftyで卒業したわたしですが、当時は、Windows3.1の時代。上海からもやっていて、ホテルで電話線の接続ポイントを外し強引にモジューラジャックに改造して、インターネット → CompuServe → Nifty とつないでいた。ノートPCは14.4Kbps、デスクトップは28.8Kbpsのモデムだった。

 電話線を壊しているのを見て、中国の人に、「あなたはZビザを持った外国人なのですから、そんなことしてバレたら大変なことになりますよ」って注意されたけど、まぁ、わたしみたいなガキンチョは誰も相手にしないだろうと思っていた。しかし、中国国営のプロバイダと契約していて身元がバレているし、今の中国のインターネットの規制を見るとホントはヤバかったのかな?

 従量課金でつなぎながら寝てしまう人とか、定額制のテレホーダイとかができたり、テレホタイムにはビジーでつながらなかったり、そんなチャット時代を思い出しつつ何となく参加しています。ちなみに、わたしは朝、家を出る前に見ることが多いのですが、Twitterはその頃ビジーになることが多い、アメリカが混む時間なのでしょうね。

 「かとぉぉぉぉぉきちぃぃぃぃ」か、オリンピックのフィギア辺りで二番煎じをやる人が出るのだろうけれど、二番煎じぐらいまでかな?そういうものはすぐ飽きるから、「何度も」は通用しないだろうし……。個人的には、ビジネス上の利用方法があんまり思いつかない。

 無料だから、テーブルマーク(加ト吉)のような利用方法はありだけれど、どう考えても、Twitter(利用者じゃない方)のビジネスって広告以外にやっぱりないと思う。どうやって儲けるのだろう。頭が固くなってるな~。

 それよりも、仮に Twitter と全く同じモノがもっと早く日本から発信していたとしても、金も人も集まってないだろうと、マーケティングやベンチャー市場についてなど、そんなところばかり気になります。

◇    ◇    ◇    ◇

■Key-Value Store(KVS)

 「これからはKey-Value Store(KVS)だ!」という意見が多いのでそれについて。

 先に断っておくと、わたしが関わっている分野でKVSを使わねばならない案件というのはほとんどなく、少し試しただけなので認識が間違っているのかも知れない。間違っていればご指摘いただければ幸いです。

 まずはそもそも論。

 KVSはRDBにあらず、RDBと取って変わるものでもありません。今、RDBを使っていてKVSの方が使いやすいと思うなら、そもそもRDBを使うべきでないところにRDBを適用しているだけの話です。KVSはその名の通り、データストア(保存)を目的にしたもので、RDBはリレーショナルデータベースですから、根本的に別物なので同列に並べることがまず間違っている。

 そもそも、KVSではデータの整合性が保証しにくいという点で、業務システムには不向きです。というか使えません。逆にTwitterのようなシステムや、オンラインゲームなど、最終的なデータ量、ユーザ数が読みにくく、整合性がなくても何とかなるシステムに向くでしょう。

 業務システムでも使う局面はあるかも知れませんが、基本的にRDBとの組み合わせで使うのじゃないかな?

 例えば、RDBを使ってファックスシステムを作ったとします。ファックスシステムでは受送信した画像をどこかに保存しないといけません。そのとき、RDB内に保存することもあるでしょうが、大抵はスケールアウトできるように画像をファイルサーバに保存し、RDBにはファイルサーバのパス・ファイル名のみを保存するという方法になるでしょう。

 つまり、一種のKVSですよね。

 RDBとファイルサーバ(いにしえよりのFTPでしようが、Sambaにしようが、Windows共有サービスを使おうが)+DNSサーバの組合せというのは、別に新しいシステムの構造とか、新しいテクノロジーでは全くない。KVSも同じように、「必要になったら使うよ」ってスタンスで十分だと思っています。イヤ、KVSを作る人は新しいテクノロジーにチェレンジしている部分はあるのですけれど、KVSを扱うことは新しくも何ともないわけです。

 大差ないというのはわたしの感覚で、Windows共有サービスをFTP、Sambaにするということが大変という人もいる(もちろん、サーバの物理的な引っ越しはデータ量によって大変ですけど)。という点で考えると、現状で、KVSも様々な種類が出ていますが、KVSに対してSQLのような汎用的なアクセス手段があるのでしょうか?

 SQLはちょっとした方言で、「こんなモノ使えね~」っていわれてしまうのですが、そういった人が、「これからはKVS」っていっているように思うのです。しかし、KVSに対するアクセスは、もはや方言というレベルでないほど大きな差があるように……(調査してない)。

 少なくともSQLなら単純な標準SQLのみで記述していたら、そのまま移植できるけれどKVSは無理よね。KVSは単純ですから、標準化はSQLに比べ容易ですが、Googleのように高機能を目指している向きもある。高機能になればアクセス手順も変わるから、ベンダー毎に振り回されるんじゃないですかね?

 KVSを作る方は「アクセス方法を標準化しよう!」とか、「最低限必要な機能を標準化しよう!」とか、そんな話も含めて楽しそうだし、機会があればやってみたいと思いますけれど、KVSを扱う方で「早くしないと遅れてしまう」とか、「そんな大層な話かな?」と思う。必要であれば使えばいいし、そもそもRDBと別物なのに同列にして、「SQLのような変なモノを使わなくてすむ」みたいな論調のブログなどを最近よく読むので、変な話だと思うのです。

 「新しいことは正しいことだ」みたいな風潮はよくない。例えば、Vistaを発売日の夜中に(1月30日で寒かったらしい)並んで買ってしまう人もいたらしいけれど、その行為を、今、冷静に考えてどう思いますか?わたしには、なんかの罰ゲームとしか思えない……。

 とにかく、何かを選ぶのに「新しいから」というファクタは、できるだけ小さなウェートで見た方がよいと思います。

 結局は、業務システムをメインでやっているわたしは、KVSを「RDBと併用しないで単体で使う」という局面はないと判断していますし、必要になっても大して困らない。

◇    ◇    ◇    ◇

■ユーザインターフェース

 イロイロ書きたいことはあるのですけれど少しだけ。

 わたしの俺様ルールの中に「キーイベントやチェンジイベントを極力使わない!」というのがあります。もちろん、矢印やタブキーの制御は必要なのですけれど、数値や日付のエリアの制御です。

 なんで、数値だけとかの制御をキーイベントでするのか?

 例えば、日付エリアで、2010/02/20 と入力するとする。

 このとき、スラッシュを入力しなくても4桁入力した時点で、スラッシュを足すとかそういう仕様が嫌いなのです。

 なぜかというと、わたしは古い世代の人間なので達人のオペレータさんをたくさん見てきたからでしょう。達人は自分がミスタッチしたとき、画面も見ずにミスタッチしたと判断しているし、画面を見ずにミスタッチした回数だけバックスペース叩けます。しかし、スラッシュ区切りで必ずゼロを入れないといけないとか、入力中にゼロやスラッシュを補完するような仕様だと、入力時に叩いたキーの数と、バックスペースを叩くキーの数が違うことになるので、逆に混乱するのです。

 で試しに、エクセルのセルで書式設定を日付タイプにして、システム日付が2010/02/15のときに、2010/02/20と入力するのを試してみてください。(日付は現在時間に合わせて適当に変えて読んでくださいね)

    H22.2.20
    H22.02.20
    H22-2-20
    H22/2/20
    平成22年2月20日
    feb 20
    20feb
    2/20
    2-20
    2010/2/20 ……

 などなど、上どの入力を行ってもエクセルが日付と判断し、『年』は省略してもシステム日付の年を自動で補完し、セルに設定した書式で表示されます。(漢字は他システムからの値コピーのときに便利)

 ただし、エクセルは基本的にセルに何でも入力(制限はできるけれど)できる仕様上、

    2.20 → これは数値と見なされてNG
    2010.2.20 → これは文字列と見なされてNG
    0220 → これは数値と見なされてNG
    20100220 → これは数値と見なされてNG

 などの入力はできません。

 これらは、少なくとも、エクセル95(2000年問題はあったけど)からあった機能ですが、わたしは業界に入った頃から、「カスタムのシステムを作ってパッケージのエクセル以下じゃあマズイ」と思っていました。ですから、わたしが細かい仕様を決めるときは、年月まで補完し、補完のモードを3つ(直近の未来日付か、直近の過去日付か、当年当月か)を作ります。

 エクセルでは『日』だけで『年月』を補完しては、数字が入力できなくなりますから、『月』までは補完しませんが、業務システムでは日付エリアは日付しか入らない(ことの方が圧倒的に多い)ために、普通は『年月』を補完しても何の問題もないわけです。もちろん、漢字まで入力するパターンは現実的に不要なので作りませんが、エクセルよりは使いやすくなりますね。

 もっとも、達人は数十分もあればどんな入力方式でも慣れるのですけどね。

 実際のコーディングや仕様書はモードの指定だけしかしませんから、大した作業でも難しい話でもない。

 今はオペレータという仕事が少なくなっているのかも知りませんけど、昔は本当に達人のオペレータさんが派遣であちこちの会社を渡り歩いていた。会社毎に入力方法が違うので、見た目が洗練された入力方法を考えるより、あらゆる入力をサポートする方がメリットがある。つまり、エクセルと同じように、入力中は入力されたままを表示しておき、入力が確定するときに、補完、エラーチェック、表示の整形を行えばいい。つまり、キーイベントなど使う必要はないのです。

 年月まで補完したり、違う入力方法をサポートしたりしたら混乱する。って批判されることはあります。

 がしかし、デファクトスタンダードのエクセルで「混乱して日付入力ができない」っていう人をわたしは見たことがないですし、会話で日付を話すとき、いちいち年月をつけて話すような人とも会ったことがない。もちろん、わたしのお客様ではそのような機能を入れたことはありますけれど、混乱して入力できないというのは聞いたことがない。

 例えば、今が2010年2月25日として、「3日に飲みに行きましょう」って言われれば、2010年3月3日しかないですし、「これいつの売上伝票?」「3日のです」って言われれば、常識的には2010年2月3日のことです。(先付けで売上を立てることはなくはないけれど、そういうイレギュラーなときには、会話でも月を付けて話さないと話は通りませんね)普通の人は、会話では判断できるでしょう。あくまでも、「省略しなければならない」ではなく、「省略できる」ですから、省略したくない人はフル桁入力すればよい。会話でできるレベルは自動で判断すりゃいいのです。

 共通部品にするのでコーディング量は変わらない。それでも、文句をいうのは、技術者か、情報システム部の人です。情報システム部は、問い合わせがあったときにいろんな方法があるのは生理的にイヤらしいのですが、「そんなところ誰も質問してけーへん!」って。

 ですから、何もいわれなくても、「それぐらい共通仕様に盛り込めよ」って思うのです。

 逆に、アニメーションなどの懲り方には納得できないのね。エクセル97(95だったかな?)をインストールしてイルカが出たときには激しい怒りを覚えたモンだ。「こんな下らんリソース食うだけの糞機能削って安くしろ!」って冗談抜きでディスプレイ割りかけたモンね、CRTで良かったよ(鳴き声が入っていることを後から知って、もう一回……)。

 多分、わたしの考え方が古いんだろう。つまり、達人のオペレータさんというのは、昔は手書きの伝票が回ってきてそれを入力していたような人達で、入力機能はそういうオペレータさんに最適化した考え方が染みついているわけです。最近は専属のオペレータさんがいないことの方が多いので、「まぁ、見た目でもイイか」と極力いわなくしている(ウソ、多分、ぶつくさ言ってる)。

◇    ◇    ◇    ◇

 雑感でした。

Comment(9)

コメント

ども、いつも読ませていただいております。

オフィスアシスタントのイルカですよね。
自分も最初はなんじゃこりゃ!!って速攻消してました。
が、今は、実は便利な使い方ができるんじゃないかと思って逆に常に出してみてます。
最初から完全否定では無く、使ってみたら初心者とかの気持ちがわかって良いかも…って考えてます。
今は、PCの資産も十分にある時代ですからね〜。

flatline

こんばんは。

KVS については、業務システムには使えないというものではないと思います。
実際に小さい業務システムですが、RDBMS使わずに、Tokyo Cabinet + Tokyo Tyrant だけで構築して、稼働してます。数百万レコードでも、全く遅くならないところがすごい。レプリケーションやフェイルオーバーも簡単だし。

RDBMS(postgreSQL)でも、ほとんどkey とデータだけのテーブル1つで、業務システム作ってますよ。全文検索用(senna + ludia)には別にテーブル作りますが。

KVSマンセーなつもりはなく、普通にRDBMSで構築した方がいいケースもあるのはもちろんですが、一概に「向いてない」「使えない」ってのはどうかと思います。

もっとも、ろくに調査も勉強もしないで、既得権益(SQL)を守るために「使えねえ」って言ってる人も、同僚ではないですが、実際に知ってますが。

(株)ポチ

噛み付くつもりはなく、単なる興味なのですが
キーと値だけで成り立つ業務システムってどの
ようなシステムなのでしょうか?

よほど簡易な業務システムですか?

私の経験上想像もつかないので・・。
(会計とか生産管理とか受発注とかまず無理ですよね)

Cypher

KVSは出たばかりの技術ですから、ほとんどのシステムでまだ「一枚目」
なんじゃないかと思いますが、これから業務が移り変わって二枚目、三枚目
が出てくるとした場合、その移行作業ってどうなるのかな、と考えています。

似た業務なら微修正で移行できてしまうのかもしれないですが、違う業務に
流用するとなると、ドメイン分析から始めて正規化し、一旦RDBに放り込んで
から、JOINしてKVSにする、みたいな手順になるんでしょうか?
(データクレンジングも、KVSではやりにくいかも)

oumi

>キーと値だけで成り立つ業務システムってどの
>ようなシステムなのでしょうか?

全てのデータ、つまり、行と列で表せるデータは、KEYとVALUEの組み合わせ(の多様性)と同じ事ですから、なんの問題も無いと思いますよ。

>会計とか生産管理とか受発注とかまず無理ですよね
理屈上は、問題無いと思います。

むしろ、ストアそのものでは無い部分(要件)、管理ツール、リカバリ運用ツール(方法)、クエリー方法といったような物に左右されている現実があるだけではないでしょうか。

物量にしても、耐えうるだけのファイル構成をいかにして作れるか?とか、並行クエリーの仕組みをどこまで理解して使えるかとか、それこそ技術者の腕にかかる部分も多いと思います。もちろん、DBMSのさらなる進化も必要ですけどー。

会計システムなどにしても、日・月・半期・決算・年度切り替えなどの時期で、必要なDIKSサイズが数テラ単位で変動するようなケースだと、KVS型のDBMS欲しいですね。スケールのし易さと言う観点で。
RDBMSなんか具合悪くなりますもの・・・・

flatline

ポチさん、こんばんは。

>キーと値だけで成り立つ業務システムってどの
>ようなシステムなのでしょうか?

詳しくは省略しますが、ある種のCRMです。
エンドユーザが追加/編集/削除する項目がたくさんあって、テーブル定義が面倒だったので。まあ、実験的な意味もあります。

世の中の事象のほとんどは、keyとvalueで表現できるので、会計や生産管理とかも理論上はできなくはないと思います。実際にやるかどうかは、また別問題ですが。

AC/DC

ひとつ聞きたいんだけどさ、
もし、顧客が「スラッシュを入力しなくても4桁入力した時点で、スラッシュを足す仕様にしてくれ」と言ってきたとしたら、
生島さんは断るわけ?

Buzzsaw

Twitterに対してなぜか嫌悪感を抱いてしまいます。
「所詮、チャットの延長戦上でしょ?」という、なんというか、「技術者としての上から目線的なモノ」がムクムクと湧いきてしまうのです。
もちろん、勝間さん(私は彼女ぐらいしか知らないw)のようにTwitterを使いこなしている方にとってはシステム的なことよりも「ゆるくつながる」といったヒューマニズム(?)的な部分をアピールしているとは思うのですが、実際には
「今Twitterが大流行!」ってコピーを見た人はそれこそ、SQLやRDBが最初に登場した時ぐらいの技術革命(があったかどうかは知りませんが)を想像してしまうのでは?と思います。で、そのアピールする側とキャッチコピーを見る側の視点がずれているのに、とりあえずそのまま進んでしまっている状況が、嫌悪感の原因かもしれません。プラス、「ゆるくつながる」そんな「キーワード」が「おっしゃれ~」というような勝間的胡散臭さ(いや、彼女のことは嫌いじゃないですよ)が嫌悪感をさらにプンプン香ばしくするのかも知れません。

コラムと無関係な愚痴、失礼しました。

皆様、おはようございます。

コメントを書こうと思ったのですが、時間が空いてしまったので、一本書きました。
これで許して下さい。

コメントを投稿する