ソーシャルアプリでNoSQL(あるいはKVS) 〜実践NoSQL〜

  • 2010/07/23(金)
  • オプトさんの例のセミナー
  • GREEのCTOの人
  • ソーシャルアプリでNoSQL(KVS)の話
  • KVSの利用者は少ない? 2/3ぐらい
  • 副題 : 如何にして5キーに耐えるか
  • = Not Only SQL
    • 世にプロダクトはたくさんある
      • それぞれさまざまな特性がある(オンメモリ、分散、性能、実績などなど)
        • デファクトスタンダードがないので乱立?
  • それ (Drizzle) でできるよ
    • それでもいいんじゃないかと思ってます
  • NoSQL と言い出すまでの歴史
    • 1998 年ぐらいから言われ始めたらしい
    • 第一期 : RDBMS でいいよね期
      • 最初はポスギレが多かった
    • 第二期 : memcached も便利だよね期
      • まあセッションとかも使い始めたところ
    • 第三期 : やっぱりスケーラビリティだよね期
      • mixi などでの分散とか
      • sharding
        • JOIN できない><
        • トランザクションできない><
        • 複雑なSQL書いたら怒られた><
      • RDBMS の機能を余り使っていない
        • Relationa じゃないよね
    • 第四期 : 全部 RDBMS じゃなくてもいいよね期
      • たぶんいまここ
  • NoSQLのデータモデル
    • 1 : 1
      • ハッシュテーブル
      • 一番シンプル
        • kumofs / Flare / Voldemort とか
        • パフォーマンス / 安定性 / sharding / replication / Failover
        • サーバを追加すると自動で負荷が分散されたりする
    • メソッドとか
      • set / get / delete
      • add / replace / cas の違いとか
        • add -> INSERT
        • replace -> UPDATE
        • cas -> compare and swap (version 管理して意図しない上書きを抑制できる)
      • incr / decr -> increment / decrement
      • append /prepend
    • vector clock
      • consistency を確保するための仕組みらしい
        • 何かしらの指標によって、replication の失敗を発見して、回復しようとする仕組み?
    • consistency policy
    • serialized object
    • multi get problem
    • disk i/o -> tmpfs
      • sparse file problem
  • 実例
    • 複数のデータを一気にとるときに大変
      • 100パラメータ x 100ユーザ x 100アクセスとか
    • serialize する?
      • get は1回
      • 並列すると conflict -> CAS
        • 更新合戦になると大変 -> ある程度であきらめる
    • 値でのランキングとか
      • 要するに集計したい
      • 全データを dump する
        • あんまりすぎる
      • 適当なタイミングで RDBMS に flush
        • 一番無難
          • 集計系はリアルタイム性がなくても大丈夫だから
            • あとでやってみよう
    • だいたい in memory での運用
      • MMORPG とか
        • オンメモリでいろいろやって、レベルアップとかのタイミングでデータベースに flush するそうな
    • 1 : n
    • Redis
      • 1 : 1
      • List
      • Set (Hash)
      • 便利になるが、パフォーマンスリスクが高い
      • さらに table っぽく
    • Casandra
      • Keyspace.ColumnFamiry.Key.Column
      • 多重Hashのような
      • バイナリログ + メモリテーブルのような感じ
    • m : n
      • Key の prefix search がしたい!
        • 解決法?
          • Index Server
          • Ring w/ Sorted Key
          • Skip Graph ?
    • value で検索したい!
      • DataStore でできてるよ?
        • index をKVSに置いている
        • Power Play っぽい?
          • 各ノードから検索してマージして持ってくる
  • RDBMS との使い分けも考えてみるのがいいと思っているらしい
  • Casandra / Redis の好きじゃないところ
    • 自動分散ができない?
    • master/slaveにはできるがslaveに書き込めたりする
  • GREE では?
    • Flare(1:1)のものだけ
  • serializeに適切なフォーマットは?
    • GREEはPHPなので…
    • 多言語ならMessagePackとかいいんじゃないでしょうか
 
このエントリーを含むはてなブックマークはてなブックマーク - 「ソーシャルアプリでNoSQL(あるいはKVS) 〜実践NoSQL〜」に行ってきた この記事をクリップ!Livedoorクリップ - 「ソーシャルアプリでNoSQL(あるいはKVS) 〜実践NoSQL〜」に行ってきた Googleブックマークに追加 Digg This
Tags: , , , ,
2010/07/22  |  Written by  |  under Blog

と言うわけで初TOEICでした。予想通りリスニングが酷いですね\(^o^)/

さて、どうしようか….

 
このエントリーを含むはてなブックマークはてなブックマーク - TOEICを受けてきたの巻 この記事をクリップ!Livedoorクリップ - TOEICを受けてきたの巻 Googleブックマークに追加 Digg This
Tags: ,
2010/07/12  |  Written by  |  under Blog

まあ単純なことなんですが、営業や企画の人に技術用語を捲し立てる人がわりと多いですよね、と言うこと。

下手な専門用語を使うことで自分の首を絞める

そういう時に限って、聞いてた人が拡大解釈してしまい、あとでいろいろ大変な目にあうことは少なくありません。「いや、そういう意味じゃなくてですね…」「でも、もうお客さんに言っちゃったよ?」なんで言う、ありがちな会話が繰り広げられたりするわけです。こうなってはいくら口論しても取り返しがつかないことが多いので、仕方なく作業することを強いられます。でもどうしてこうなってしまうのか。

本質を理解していないと説明できない

私自身もそうですが、用語の本質を理解していないと人に説明することはできません。大学・大学院とお世話になった先生に、「絵を描いて説明して。絵を描けないということは、ちゃんと理解していないということ」とよく言われました。自分が理解していればそれを図示して、つまり本質をわかりやすく絵に描けるはずだというのです。最初はよくわかってなかったのですが、博士課程あたりでその重要性を理解できた気がしています。物事の本質を理解せずに話をしようとしてもうまく伝わらないだけでなく、間違った認識を与えてしまうこともあります。

ちゃんと説明するのは難しい

では、本質を理解した上で話せばいいのかというと、そうでもありません。今度は何が必要とされているのかを認識しないと、的外れな内容を説明してしまいかねません。つまり聞き手の状況や認識を考慮して説明する必要があるのです。仕事であればその全容を把握して、何が問題となっているのかを理解しないと大変なことになります。的外れな回答になってしまって、やったこと全てを巻き直しなんてことになりかねません。

相手の立場になって考える

そう言う意味で簡単なようで意外にできないのが、相手の立場で物事を考えるということ。「俺はそうは思わない」と決め付けずに、何故その結論になったのかを考えないと、いつまでも状況は変わりません。とは言え、どうしても理解できない時もあるでしょう。その時は新天地を目指せばいいだけです。

「できないこと」じゃなく、「できること」をまず言おう

また「それじゃ無理ですよ、だって・・・」といきなり言うのではなく、「これではどうですか」と提案することも重要です。一見当たり前のことですが、意外にできないものです。面倒な実装になりそうだったり、手間がかかったりと、ネガティブなイメージが先行してしまうことが多いからでしょうか。でも結局「無理ですよ」といって別の大きな手間がかかってしまうことって多くないですか?そう言うのから脱却するためにも、否定から入るのではなく肯定から行くべきだと感じています。

扱いにくい人にならないように

また仕事が増えるだけなら、まあそれもよくないのですが、まだましですが、社内の信用を失うことになる可能性があります。「あの人何言ってるかわかんないよ」や「あの人話しにくいし扱いにくい」と言われるようになってはおしまいです。私自身は、難しいことや不可能そうなことを、自分のアイデアや技術力でなんとかしてこそ、技術者の本領発揮なわけですから、「そんなの無理ですよ」という前に一つでもアイデアを出して見たいと思っています。

 
このエントリーを含むはてなブックマークはてなブックマーク - 技術者はもっと説明責任を果たすべき この記事をクリップ!Livedoorクリップ - 技術者はもっと説明責任を果たすべき Googleブックマークに追加 Digg This
Tags: , ,
2010/07/11  |  Written by  |  under Blog

まあ会社の愚痴なんてよく言うと思います。私自身も以前はよく言っていましたし、twitterでつぶやきもしてたと思います。でも仙台Ruby会議02で親方たちと話をしたり、情熱プログラマーを読んでみて、愚痴を言う前にやるべきことがあるんじゃないかと考えるようになりました。

情熱プログラマー ソフトウェア開発者の幸せな生き方

  • 著者/訳者:Chad Fowler
  • 出版社:オーム社( 2010-02-26 )
  • 単行本(ソフトカバー):200 ページ

いやならやめてもいいんじゃよ by Maat

じゃあ社畜になって働くのかというとそうではなく、その前に自分にできることをできる限りやっているかどうかと考えるようになったからです。情熱プログラマーの第3章にある、「バケツ一杯の水の中の小石一つ」や「8時間燃焼」を読んだときに、「あぁ、このままじゃダメだな。」と思いました。そして仙台Ruby会議02で親方の話を聞いてみて、「今のまま止まるって決めてるのは自分なんだ。だからこそ愚痴を言って逃げてるんじゃないか。」と強く思うようになり、仕事や会社の愚痴を言う前に自分がやるべきこと・できることはきちんとやらないといけないと考え出したのです。まだやりきれてないんじゃないか。まだまだやれることはあるはずだと。

まだ転職しない理由

あとよく「転職フラグか」とかつぶやかれたりするわけですが、そのときは「いまはまだ転職しない」と思うのです。じゃあなぜ「まだ」なのかと考えたとき、やり残していることがあるのもそうなんです、やっぱり「怖いこと(転職)から逃げてる」ことは否定できません。なんだかんだで居心地のいい場所だと、そこから脱出できない、脱出するのが怖いと感じるのは普通じゃないでしょうか。でもそれって「逃げ」なんですよね。じゃあ転職すればいいのかというと、それもある意味「逃げる」ことになる。どちらにしても、そう言う考えだと「逃げ」にしかならない。心のバイブルである逆境ナインによると、「男たるもの進むべき」だとあります。じゃあどうやって「進め」ばいいのか。もう全力でやるしかないわけですよ、いまの仕事を。

自分と戦って負けないために

では全力を出してやるのはいいとして、何を目標に据えるか。越えるべきは自分なので、いままでやったことのないことをやるべきだろうと思ってます。また自分に負けないようにしないといけないと。というわけで、男の戦いに終わりはないとバイブルにも書いてあるので、このままで突き進みたいと思っています。

 
このエントリーを含むはてなブックマークはてなブックマーク - 自分に負けないために この記事をクリップ!Livedoorクリップ - 自分に負けないために Googleブックマークに追加 Digg This
Tags: , ,

前にも書いたのですが、どうにも学生のときにやり残した感が拭えないので、やはり勉強会やりたいと思ってます。内容的には学部レベルの数学・物理から初めて、計算科学や量子コンピュータ付近まで行ければなぁと軽く考えています。また数学・物理どちらかと言うわけではなく、両方やることにしたいと思ってます。実験物理でもない限り数学は絶対に必要だし、先端物理の方が数学っぽいところがあったりもするので、片方だけと言うわけにはいかないからです。

内容的には、物理はファインマン物理学シリーズからでいいかなと思うのですが、数学がそれに類するものが見あたりません。なんかいいのないですかね。「数学:物理を学び楽しむために」は知ってるんですが、他になんかあれば教えてください><

とすぐにでも動きたいのですが、RubyKaigi 2010が終わるまではなかなか動けないので、9月以降かなとか思ってます。まあほんとは誰か主催しくれたらいいのになーとか思ってたりするわけですが。とりあえず、自分へのプレッシャーのために、ここで告知しておきます。

 
このエントリーを含むはてなブックマークはてなブックマーク - 「エンジニアのための数学・物理勉強会」など開催したい この記事をクリップ!Livedoorクリップ - 「エンジニアのための数学・物理勉強会」など開催したい Googleブックマークに追加 Digg This
Tags: , ,
2010/07/08  |  Written by  |  under Blog

最近は朝に一人もくもく会やってたりするんですが、iPhoneでなにかしら音楽を聞きながらやってます。音楽を聞きながらの作業が効率的かどうかはわかりませんが、曲調やジャンルによってテンションが変わることに異論はないと思います。

で、普段の作業中は何を聞いているかというと、最近はほとんどThe ProdigyChemical Brothersだったりします。アップビートなテクノだと、何故かキータッチが速くなったような気がします。でも毎日だといろいろ辛いので、最近は徳永英明榊いずみECHOESとか鬼束ちひろとかも聞いていたりします。気分が変わって違う視点で進行するのもいいものですね。
しかし曲によって心理状態も変わるようで、鬼束ちひろとか聞くとなんか落ち着いた気分になります。焦ってたりイライラしてたりするときは、そういう曲を聞くのがいいようです。

そう言えば、むかし実家でいろいろあったときや博士論文書いてた時にはさすがにストレスがたまり、精神的に脆くなる時がありました。そう言う時によく聞いていたのが榊いずみ(橘いずみ)で、「太陽が見てるから」「こぼれおちるもの」「ごらん、あれがオリオン座だよ」は何度聞いたか覚えてません。おかげで何とか書き上げて学位を取得できたわけですが、この曲がなかったらどうなっていたかは定かではありません。特に「26-Dec.11th.1968」はかなりやばく、自宅で胸を熱くしながら何度も聞いていました。

と言うわけで、最近いろいろあるので久しぶりに鈴木彩子が聞きたくなりました。唐突ですねが。最初に聞いたのは大学生の頃かな。例によってアニメ(サイレントメビウス2の主題歌「旅立つ朝に」)だったりするわけですが、アルバム買ってみて聞いた「葛藤」にはかなり影響された記憶があります。「お前らには社会に出る資格がない」とか当時は強烈なインパクトがありました。

特にオチもないのですが、音楽とともに日々作業をすることで、安定した作業効率を得られるんじゃないかなと思ってます。ちなみに見る音楽はDCIですが、流石にこれを知ってる人は少ないかな?ドラムコー・スタイルのマーチングバンドやってたという過去があるので、Madison ScoutsMalagueñaとか見るとアドレナリン分泌されまくるわけです。まあそんなわけで、音楽聞きながらやってみるのもいいんんじゃないでしょうか。

 
このエントリーを含むはてなブックマークはてなブックマーク - 音楽で気分を変えてみる この記事をクリップ!Livedoorクリップ - 音楽で気分を変えてみる Googleブックマークに追加 Digg This
Tags: ,