  |
はてなキーワード: HADOOPとは
今日、牛丼を食べながらふと気がついたのですが、もしかして我々の業界は異常なのではないでしょうか？
サービス名、技術名はスキあらば3文字って感じだし (AWS, EC2, EKS, GCP, GAE, GKE k8s, C2C, CPU, GPU, SPU...)
会社名もソフトウェア名も連想できるってものじゃないし (PostgreSQL, MySQL, Redis, etcd, Consul, HashiCorp, Vagrant, GitHub, CircleCI, FreeBSD, CentOS, Ubuntu, Linux, Couchbase, Hive, Hadoop, Vagrant...)
みんな普通にPOSIX互換なコマンドをペシペシしているし (cd, cp, mv, pwd, mkdir, ls, vi を更に謎の数文字のオプションも含めて覚えているわけで)
それも特に覚えようとして覚えてきたわけでもないじゃないですか。
気がついたら覚えているわけで、手に身についているわけで。まるでポケモン151匹を勝手に覚えてしまったあの頃と同じようなノリで謎の英単語や謎の羅列を身に着けてしまっている訳ですよ。
何ら疑問に感じてなかったんだけど、普通に好きじゃないとできないよね。
で、思ったんだけど、インターネット小話で聞く「全然興味はないけどSEになっちゃいました」みたいな人ってガチで苦痛なんじゃないだろうか…
(未だにそんな人を見たことが無いから都市伝説だと信じてるけど)
別に周りにそんな人が居るわけじゃないけど、新卒が入社してくる季節ってことでふと気になりました。
おしまい。
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドでVBAから、Rやら自社製品の解析用環境の割と珍しいタイプのスクリプト言語など（特定されそうだからぼかすけど。）
とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手に作ってみたりして提案していた。
物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。
この辺で気付いたことだが、製造業のITリテラシーは驚くほど低い。製造業と一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。
なんせまともにプログラムを書いたことが無い新人が半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。
ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。
（そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。）
2年目に気付いたのは、弊社エンジニアのITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。
製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。
無骨だが使いやすいイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。
だから逆に言えば下々の人間はコピペでなんとか恰好を整えられるのだった。
彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。
私はそれに感動した。なんせWebスクレイピングみたいな方法で他人が社内プラットフォームや社内WIKIに上げた報告をまとめたり、製造時データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。
それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。
何にせよそういったものを一気通貫、自動化できるポテンシャルがあると感じられた。
SQLもjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しかも管理はIT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。
ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。（あとで聞いた話、外部コンサルで外れを引いたらしい）
自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし（有難迷惑だった可能性は否定できないが）、もう少し待てばモノになると信じていたし、実際そうなった。
具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。
残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。
そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。
もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社（厳密にはその親会社に）に買われることになった。
そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。
つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。ITも例外ではない。（ITインフラ部署の無い会社はさすがに無いはずだ）
一方で製造業の本懐である「製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存の顧客への説明が必要だからだ。
そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか。
（ここで簡単のために旧弊社を（旧）A社、買収した側の競合他社を（旧）B社と呼ぶことにする。）
今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である。
旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフが簡単に表示され、A社側のお偉いさんからも好評を得ていた。
だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。
そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉だ
「増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ？」
もちろんhtmlもjavascriptもphpもRoRも一行も書いたことが無いのが当時の私である。
果たして旧A社のプラットフォームはB社のプラットフォームのデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。
そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。
クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベルで筆舌に尽くしがたいものがあるが、
反面教師だと思って耐える日々だ。
最近分かったことは旧B社のバックエンドスクリプトがデータを引っ張るついでに意図的に旧A社のプラットフォームを攻撃しているということだ。DDoSとまでは言わないが、悪意100%である。
いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。（つまり旧A社プラットフォームが不安定かつ重くなることを意図しているらしい）
旧A社から継続されてる業務はまだそこ使ってるんですけど・・・
それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。
旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える（私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える）
そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。
さっき、テック系ブログのRSSと一緒にホットエントリのRSSを外して、アプリを削除したよ。何年の付き合いだろう？サービス開始からだから・・・悲しくなるから確認せずに行くよ。
最初はダイアリーに書いて、反応なんて全然なくて、広告コメントばかりだったな。いまでもはてなの知り合いはいないんじゃないかな。
ネットコミュ障なんだ。Twitterとか色々やってるけどやりとりする相手なんて誰もいないよ。
僕は君になにもできなかったね。本当に君の事が好きだったのかな？本当に村民になりたかったのかな？多分、違う。本当はブクマされて、スターつけられて、承認欲求を満たしたかったんだ。
意識高い系を笑えないよね。何年も異性にお金を注ぎ込む人を笑えないね。僕もずっとホットエントリを見て、色んなものを買ったりしたんだ。
====
どうしてこうなったか？聞きたくもないだろうけど、最後だから言わせてくれよ。
初めて君を見たとき、天国に見えたよ。最新の技術トレンドがここにあってさ。自分の理想郷はここなんだって。技術力をつけて、認められる人間になって、ここの住人になる事が幸せなんだって思ったんだ。
そうやってさ、次々流れてくるトレンドに耳だけが年増になっていって、それを知らない周りの人たちをバカにしてたな。
でもさ、肝心の技術力は全然つかなくてさ、大学生になれば、就職すれば、東京に出れば、新しいマシンがあれば、お金があれば、時間があれば、やる気があればって制約条件がなくなる度に新しい言い訳を考えてたな。
結局、生半可な知識じゃ参加できないってチンケなプライドのせいで勉強会に参加せず、ブログも書かず、なれたのは一番軽蔑するExcelとにらめっこしてるSIer。おいおい、Web系のベンチャーでテックブログ書くんじゃなかったのかよ(笑)
耳年増で、周りをバカにしてたクセに仕事が全然できない自分とのギャップに10年耐えてきたけど、年末に休職したんだ。自律神経失調症。
眠れるんだよ？ごはん食べられるんだよ？ただ、会社の人みんなが怖くなってさ、朝だるくってさ、すげー疲れてさ。苦しくて。仕方ないから受け入れて。っていうか、甘やかして。つまるところ、ズル休みなんだよ。
時間が出来たから、ずっと積ん読になってた技術に正面きって立ち向かってみたんだ。すぐ投げ出したね。理由は分からないけどただ苦痛だった。
作りたいものなんかなかったし。多分、技術を使いこなしてスゴいって言われたかったんだね。
部屋にはPerlやRoR、SQLite、jQuery、node.js、AWS、Haskell、Hadoop、Docker、Raspberry Pi、R、Reactのホコリを被った本がある。彼らはブックオフ行きかな。
最近は時間はあるからさ、はてブばっかやってたんだ。見るのがホットエントリから新着エントリーになったな。いつもみたいに100文字制限ギリギリのコメントだけじゃなくて、10文字くらいの一言コメントも書くようになったんだ。その10文字コメントのうちひとつが100スターくらいもらえてさ。
そのとき分かったんだ、これはずっと片思いなんだって。叶わない恋なんだって。自分が住める世界じゃないんだって。おかしいよね、小学校の頃のプロ野球選手の夢だって、中学生の頃の小説家の夢だって、高校の頃のパンクロックスターの夢だってすぐ諦められたのに、この夢は35歳の今だって諦めきれないんだ。
応用情報取った時も、ネスペ取ったときも、オラクルブロンズ取った時もLPIC 2取った時も全く達成感なかったよ。コレ取るのに何年かかってんだってさ。村民は1ヶ月あれば取れるぞ。同期のアイツだって3ヶ月で取ってるぞ。何が言えるんだってさ。
銃・病原菌・鉄読んだ時もそうだった。で、お前はそこから何かアウトプット出来るのか？ってさ。読むだけなら幼女でも出来るんですけどwって。
伝わる？伝わらないだろうな。みんな高IQですぐに色んな技術を理解出来るじゃない？すごいよ。自分は二浪で駅弁大学しか行けないくらいのバカで、リアルでもネットでも知り合いを作れないコミュ障で自己承認が全然出来ないんだ。
ADHDって言葉を知った時、これだーって思ったけど違ったね。ITの勉強してても過集中が全然ないんだ。
話が逸れたね。認知療法してて、気づいたんだよ。何をしてても自分を認められないんだよ。はてなに受け入れられる事を成し遂げられてないからね。
だから、自分を認めるために、君のことを自分から切り離さなきゃいけない。自分の世界を作らないと。一方的になっちゃうけど、さようなら。勝手だけど、今にも泣きそうだよ。
これからどうしようかな。匿名で好きな事書けるのはココだけなんだ。自信のない間違ってるかもしれない事を書いてもいいのはココだけなんだよね。ここなら見たくないコメントを見なくてすむんだ。
でも、前に進まなきゃ。夢の世界への憧れは終わりだ。目の前の現実世界に適応しなきゃ。また逃げ戻ってくるかもしれないけど、いまはさようならしなきゃ。
最後に何か残せるとしたら・・・スタバのハチミツ、あれ何に使うと思う？あれ、ワッフルを食べるときに使うんだよ。
・・・スベったね。
さようなら。このエントリも2時間すれば次のページ行きだ。そうすると、誰かの目にも触れなくなる。単なるはてなの磁気データになる。
最後にブコメとかつくんじゃないかって浅はかな期待を持ちながらこの内容を登録するボタンを押します。じゃあね。
P.S. 認知療法について書いてくれたこの増田には本当に感謝しています。まだまだ自分について書く事が苦しいけど、正しい道を向いてると信じています。
技術屋ぶって偉そうにしているが、まるっきり分かっていなかった。
でも、そんなことに怒ってはいないよ。
なによりも、今月末で顔を見なくてよくなるのが嬉しい。
とにかく、この一年の作業は、君が転職活動するためのことで振り回された一年だった。
AWSとかHadoopとか履歴書に書くためだけに色々頑張ったね。
退職すると報告があった時、
『転職先決まって良かったね。』
と、心のそこから思ってたよ。
辞めてくれてありがとう。
転職先は上場企業らしいけど、引き取ってくれた会社に感謝したい。
すぐにボロを出すのか、3年ぐらい我慢するのか分からないけど、年齢的にもこの先転職するのは厳しいだろうから転職先で末永く働けると良いね。
> Githubにアクセス出来ないと言ってもイマドキのエンジニアは誰も信じないだろう
え、事業部は数年前からはてダアクセス禁止だったし、yumやapt-getとかもっての他でパッケージ一つ毎に上司の承認が必要でしたが？
横浜研究所がなんなのかあんま把握してない(元シ研かな？)けど、Linuxとストレージ関係の部門とは・・
自分は優秀じゃなくて落ちこぼれで外に出ていきましたが、ほんと所員に外見てきてほしいとは思う。
ところで自分がやめるとき周りの人全然Hadoopとか知らなかったんだけど、ビッグデータ周りの推進は研究所主体ということで合ってます？
(高速独自DBの可能性もあるけど)
2005年に突如現れたRailsによって国内でRuby利用者が急増したのがPerl滅亡への第一歩となった。書きやすさに作者がとことんこだわって作られたRubyの魅力を一度知ってしまうとPerlの古くさく読み辛く書き辛い文法に誰もがうんざりし始める。
Ajaxで再発見されたJavaScriptのブームもPerl終焉に若干ながら貢献している。ブラウザというPerlが全く手を出せないジャンルの王者JavaScriptの持つ華やかさに誰もが憧れ、そして手元のPerlの古くささに反吐が出始める。不器用で不細工なところも含めて愛していた女房とつつましく送っていた人生に、突然ぴちぴちのボイン女子大生が転がり込んで来たようなものである。
iPhone市場が本格的に立ち上がり、Perlとは全くの無関係であるスマホアプリ全盛期がやってきていよいよPerl滅亡へのカウントダウンが始まった。そして極めつけはソーシャルゲームバブルである。ここでもPerlとかいう言語は全くの蚊帳の外で大絶賛凋落中。
Perlなんぞ全くお呼びでない世界の話。段々とwebテクノロジーの世界に高度な数学的知識を持ったアカデミック層が跋扈しはじめ、専門学校でプログラミング言語を学んだだけの人間がハッカーなどと名乗ると恥ずかしい時代になってきてきた。
遂にPerlにとどめを刺したのはPythonである。守備範囲は当然ながらPerlと駄々被りで読みやすく書きやすく世界的なシェアもうなぎ上り。完全にPerlが不必要な世の中になってしまった。
2005年までのPerlはまさに我が世の春を謳歌していたが今や目も当てられない惨状でプログラミング言語のシーラーカンス・COBOLとすら比較され出す始末。昔Perlの人として売り出していたハッカーも、いつのまにかPythonの人になっているケースも海外では多い。10年でここまで時代は変わる。今のメインテクノロジーも明日は我が身だ。小手先の技術に乗っかってモダンだのハッカーだの聞こえのいい言葉を汚い口でまき散らして消えて行ったPerlエンジニア達の死を無駄にしてはいけない。変化の速い時代に生きる我々に必要なのは本質を学ぶ事だ。コードの書き方とかどうでもいいんだ。もっと10年20年たっても色あせない情報工学を身につけなければならない。
これを読んで思ったこと、またはその反応に対して思ったこと。
http://d.hatena.ne.jp/yomoyomo/20130228/bigdataisdead
Web2.0からクラウド、ビッグデータまで、様々なバズワードが生まれ、おっさんたちを虜にし、また一部からは揶揄される状況が繰り返されている。当然ビジネスの上でも、これらのバズワードは多用され、一部では本質的に意味のある事業が進んでおり、また一部では知的ゴロツキの餌となっているのが現状だろう。
このようなバズワードに対し、一般的な反応は大きく分けて2つだ。「我が社もビッグデータ事業だ。その方が時代に乗っていて格好いいだろう、ぐはははは」と「またバズワードか。食傷気味だ…一年で何回聞くことになるんだろう…」である。
ここで、問題にしたいのはバズワードの対象自体が有用か有用でないかではない。基本的に正しく捉えればクラウドもビッグデータも有用だ(だからこそ、バズっているともいえる)。では、なぜこれらのバズワードが飛び交う時に、嫌な気分になったり、攻撃的になったりする人たち(自分含む)がいるのだろうか。
考えてみたのだが、バズワードは言葉自体がもつ情報量が圧倒的に少ないことに起因するのではないか？ということだ。これはバズワードの定義が曖昧ということとは異なる。そうではなくて単語が発言されるときにその単語がもつ情報量の問題だ。通常の会話ではある単語が発言されたときに、その人の知識量やバックグラウンドを示す単語があればその人の能力をある程度推測することができる。
卑近な例だが「Excelだと100万行以上あると開けないですよね」という発言があると少なくともこの人は100万行のデータを扱ったことはあるんだなという情報が受け手は得られる。技術的会話とは本来そういうもので、その人の発言する技術用語である程度の技術力を推測するものだろう。いや、コード書かせてみないとわからないだろ、というツッコミはおいてください。あくまで最低限の推測、例えばこれまで付き合いのない企業間での打ち合わせのような場合でのスクリーニングの状況を想定してほしい。
このとき、バズワードによって、なんかよくわかってない人も「ハドゥープでノーエスキューエルでアレですよ」みたいな発言をするようになると、これまでどちらかというとマイナーで技術者かどうかを識別する単語につかえていたHadoopや統計手法名をまた一から考え直さなきゃいけなくなる。一番最初のスクリーニングの仕方をこちらが変える必要がある。それが激しくめんどい。だから、バズワードは嫌いだ、という思考を自分がしていることに気がついた。
というわけで、ビッグデータうんぬんにイライラしている方々、この仮説は如何でしょうか？
蛇足だが、なんでこの思考に辿り着いたのかというと、あまり親しくない他社との打ち合わせ時に相手がビッグデータ、ビッグデータと連呼するので、ほんとに技術力があるのか(またはほんとにビッグデータに関心があるのか）よくわからなかった。そこで、関心あるならそれなりにビッグデータに関する情報もフォローしているはずだという仮説のもとでユバタスについて話題を振ってみたところ、ユバタスどころかPFIも知らなかった。世の中そんなもんである。
シェル操作課題 (cut, sort, uniq などで集計を行う) 設問編 - Yamashiro0217の日記の解答例です。MySQL 5.5です。
mysql＞ CREATE TABLE log ( -＞ id BIGINT PRIMARY KEY AUTO_INCREMENT, -＞ server_host VARCHAR(30), -＞ access_time DATETIME, -＞ user_id INT, -＞ access_url VARCHAR(191) -＞ ); Query OK, 0 rows affected (0.00 sec) mysql＞ LOAD DATA LOCAL INFILE 'log.csv' -＞ INTO TABLE log -＞ FIELDS TERMINATED BY ',' -＞ (server_host, @unixtime, user_id, access_url) -＞ SET access_time = FROM_UNIXTIME(@unixtime); Query OK, 9 rows affected (0.01 sec) Records: 9 Deleted: 0 Skipped: 0 Warnings: 0
mysql＞ SELECT server_host, access_time, user_id, access_url -＞ FROM log; +-------------+---------------------+---------+--------------+ | server_host | access_time | user_id | access_url | +-------------+---------------------+---------+--------------+ | server1 | 2012-07-27 13:25:24 | 30 | /video.php | | server2 | 2012-07-27 13:25:10 | 20 | /profile.php | | server3 | 2012-07-27 13:25:15 | 7 | /login.php | | server1 | 2012-07-27 13:25:05 | 8 | /profile.php | | server2 | 2012-07-27 13:26:45 | 35 | /profile.php | | server2 | 2012-07-27 13:25:10 | 20 | /profile.php | | server3 | 2012-07-27 13:26:45 | 30 | /login.php | | server4 | 2012-07-27 13:27:05 | 12 | /video.php | | server1 | 2012-07-27 13:27:45 | 7 | /video.php | +-------------+---------------------+---------+--------------+ 9 rows in set (0.00 sec)
mysql＞ SELECT server_host, access_url -＞ FROM log; +-------------+--------------+ | server_host | access_url | +-------------+--------------+ | server1 | /video.php | | server2 | /profile.php | | server3 | /login.php | | server1 | /profile.php | | server2 | /profile.php | | server2 | /profile.php | | server3 | /login.php | | server4 | /video.php | | server1 | /video.php | +-------------+--------------+ 9 rows in set (0.00 sec)
mysql＞ CREATE INDEX log_ix1 ON log (server_host); Query OK, 0 rows affected (0.01 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql＞ SELECT server_host, access_time, user_id, access_url -＞ FROM log -＞ WHERE server_host = 'server4'; +-------------+---------------------+---------+------------+ | server_host | access_time | user_id | access_url | +-------------+---------------------+---------+------------+ | server4 | 2012-07-27 13:27:05 | 12 | /video.php | +-------------+---------------------+---------+------------+ 1 row in set (0.00 sec)
mysql＞ SELECT COUNT(*) -＞ FROM log; +----------+ | COUNT(*) | +----------+ | 9 | +----------+ 1 row in set (0.00 sec)
mysql＞ SELECT server_host, access_time, user_id, access_url -＞ FROM log -＞ ORDER BY server_host, user_id -＞ LIMIT 5; +-------------+---------------------+---------+--------------+ | server_host | access_time | user_id | access_url | +-------------+---------------------+---------+--------------+ | server1 | 2012-07-27 13:27:45 | 7 | /video.php | | server1 | 2012-07-27 13:25:05 | 8 | /profile.php | | server1 | 2012-07-27 13:25:24 | 30 | /video.php | | server2 | 2012-07-27 13:25:10 | 20 | /profile.php | | server2 | 2012-07-27 13:25:10 | 20 | /profile.php | +-------------+---------------------+---------+--------------+ 5 rows in set (0.00 sec)
mysql＞ SELECT COUNT(DISTINCT server_host, access_time, user_id, access_url) -＞ FROM log; +---------------------------------------------------------------+ | COUNT(DISTINCT server_host, access_time, user_id, access_url) | +---------------------------------------------------------------+ | 8 | +---------------------------------------------------------------+ 1 row in set (0.00 sec)
COUNT関数の中にDISTINCTを書けるのは覚えておくと便利です。
mysql＞ SELECT COUNT(DISTINCT user_id) -＞ FROM log; +-------------------------+ | COUNT(DISTINCT user_id) | +-------------------------+ | 6 | +-------------------------+ 1 row in set (0.00 sec)
mysql＞ SELECT access_url, COUNT(*) -＞ FROM log -＞ GROUP BY access_url -＞ ORDER BY COUNT(*) DESC -＞ LIMIT 1; +--------------+----------+ | access_url | COUNT(*) | +--------------+----------+ | /profile.php | 4 | +--------------+----------+ 1 row in set (0.00 sec)
mysql＞ SELECT REPLACE(server_host, 'server', 'xxx'), COUNT(*) -＞ FROM log -＞ GROUP BY server_host; +---------------------------------------+----------+ | REPLACE(server_host, 'server', 'xxx') | COUNT(*) | +---------------------------------------+----------+ | xxx1 | 3 | | xxx2 | 3 | | xxx3 | 2 | | xxx4 | 1 | +---------------------------------------+----------+ 4 rows in set (0.00 sec)
mysql＞ SELECT DISTINCT user_id -＞ FROM log -＞ WHERE user_id ＞= 10 -＞ ORDER BY user_id; +---------+ | user_id | +---------+ | 12 | | 20 | | 30 | | 35 | +---------+ 4 rows in set (0.00 sec)
これは規模じゃなくて難易度の話だろ
難易度の話をするならCで言うポインタの理解なりの例えがあるんじゃないか？
javaだとなんだ、、、オブジェクト指向なコード書けることか？
元増田に話しとくとjavaで開発するにもHadoop、strutsやらのフレームワークや
jspなどなど色々ある
Androidアプリはその中じゃそんなに難しい部類ではないと思う
別の言語使ってもAPIやらフレームワークやらOSやら言語以外の知識と理解は山ほど必要だ
別の稼ぎ口があってプログラマが向いていないと思うなら、今なら遅くないから
引き返したほうがいいな
似たように苦しむ事が多いが腹をくくってる
元記事にも100人1000人のユーザーならSQLでも問題ないって話をしたと思うが 1万人ユーザーって簡単なの？そもそも。って話だよね。
そしてその時のサービスは本当にツイッターみたいな大量データーサービスなの？と。（それってツイッターのコンペでサービスとして成り立たなそう。違えばいいけど）
ORACLでハイエンドサーバーのグリッド使うのと 自分でMYSQL分散書くのと HADOOPにするのと どれが得かはやってみないと分からん。
ダウンタイムを短くしようとすると、2011年現在では組めるならばオラクルな気はする。すくなくとも簡易的にベンチとらないとわからん。
Hadoopの怖いところは所詮Apache.orgということで、Apache.httpdのように急激な開発が流行から外れて止まってるかのようになることがあることなんだよねぇ。
Apache.httpdって、MPMがいまだpreforkとか あってWorkerで event とかって、しばらく前は、いまだ不安定とかそういう開発状況だと思ってるんだけど。
event MPMってもう安定化したの？event MPMのコア概念である
『Workerですら遅いから カーネルコールバックを使おうっていう流れ』自体はもう10年近く昔の概念だと思ってるんだけど・・・
今現在 一番イケてるのはHADOOPだとは思うけど。 Rubyが一時期ほどには勢いがないのと一緒で（いちおうRoR前から知っているみとしては、RoRによる隆盛が奇跡のようなものだが）
まだ、怖いよね。 障害復旧の実装もまだ、弱いし。個人的にはZookeeperがもっとちゃんとなったら、もう1度 調査する！ という感じで塩漬け状態なのがHadoop.
少なくとも単一障害点のフェールーバー周りが本家でどうなるかとかだねー。
どうでもいいけどPHPの方が好きなので PHP for apache event MPMを安定化希望・・・ まぁ、Perlもいいよね。
だがRubyとPASCAL だけは無理だ。BEGINとか書いてあるソースを高速に読みこむのは無理。（）ぐらいならいけるけど、BEGINってなんだよ。図形認識できないから読みづらいよ。
