転載リンク：https://www.infoq.cn/article/2017/06/U-no-Google
最初に完全に盲目的にそれらの巨大企業を崇拝するのではなく、問題自体を理解しなければならない問題の解決策を探していたとき。アマゾン、LinkedInにGoogleにオザンOnayは、例えば、自分の感覚に来る人のためにアラームを鳴らし。以下の内容は、元のテキストを表示する権限著者が翻訳されています：あなたはグーグルではありません。
ソフトウェアエンジニアは常に奇妙な事に魅了されています。我々は常に狂気に巻き込まれ、非常に合理的なようだが、技術選択の顔に - ハッカーのニュースからブログのすべての種類に、蛾のように、前後に投げのように、最終的に消耗し、無力明るい光のボールを飛ぶ、彼はその前に彼の膝に落ちた - それは我々が探していたものです。
本当の理由の人々は、このような意思決定をされていません。しかし、このようなMapReduceのを使用するかどうかを決定するなど、常にエンジニアの場合、。
ジョーHellersteinは、彼のビデオチュートリアルデータベース大学で述べています：
世界で唯一の約5社は、このような大規模な操作を実行する必要があります。他の会社については......彼らは、フォールトトレランスを実現するために必要なすべてのIOを使用しています。2000年代には、人々は熱狂的にグーグルで追いかけて：「私たちはまた、世界最大のインターネット・データ・サービスを実行するため、Googleは、私たちがしなければならないすべてのものを行っています。」
何の問題もなく、耐障害性の実際のニーズを超えて、私たちは中に重い代償を支払っ：システムの本来の成熟のためのIOを増加させ、同様に可能ではないだけで - ビジネス、インデックス作成とクエリオプティマイザが含まれています - 壊れなります耐え難いです。歴史のどのような深刻な逆転！どのように多くのHadoopユーザーが意識的な決定を下しますか？どのように多くの人が最終的に彼らの決定は賢明ではありません知っていますか？
MapReduceのは、国民の批判の対象となっている、それらの偶像崇拝者も、何かが間違っていた実現しました。あなたが大規模なテクノロジー企業を使用していますが、しかし、あなたの状況は彼らとはかなり異なっている、そして、あなたの決定はよく考え抜かれていない、あなただけの模倣巨大企業もすることができなければならないことを信じるように慣れて：しかし、このような状況が広まっていますあなたは同じ富をもたらすために。
はい、これはあなたが、記事を「盲目的崇拝しないでください」アドバイスです。しかし、この時間は、私はあなたがより良い意思決定を支援する便利なチェックリストの長いリストを持っていました。
クールな技術？UNPHAT
あなたはまだあなたのソフトウェアアーキテクチャを再構築するために、Googleの検索技術を使用している場合、私はあなたが再びそれをしない示唆しています。代わりに、アプリケーションUNPHATの原則を考慮することができます。
十分な理解（理解）あなたの質問の前に、解決策を見つけるために急いではありません。あなたの目標ではなく、プログラムの分野で問題を解決する、問題を「解決」問題領域にする必要があります。
一覧（列挙）の様々なプログラムは、ちょうどあなたのお気に入りのプログラムに目を固定されていません。
候補を選択して、書類（紙）をお読みください。
背景候補（歴史的文脈）の理解。
比較の利点（効果）と欠点、短所。
（考えて）考えてみて！冷静に候補者があなたの問題を解決するために適しているかどうかを熟考。どのようにあなたの心を変更できるようになる異常事態が表示されますか？例えば、どの程度の少ないデータでは、Hadoopのを使用してのアイデアをあきらめるようになりますか？
あなたはアマゾンじゃありません
UNPHAT原理は非常に簡単です。最近、私は会社との会話を持っていた、同社は、読み取り集中型のシステムでカサンドラを使用しようとする、そのデータは内部の夜の間にシステムにロードされます。
彼らは、ダイナモに関連する論文を読み、そしてカサンドラは、最も近いダイナモの製品であることを知っています。私たちは、書かれたの可用性を確保するために、これらの分散データベースの優先順位は、（Amazonは「カートに入れる」この操作は失敗せて表示されない）ことを知っています。あまりにも、この目的を達成するために、彼らは一貫性に妥協を作り、伝統的なRDBMSのほぼすべての特性に表示されます。彼らは1日1回のみ、しかし、大量のデータを書き込むので、しかし、同社は実際に、可用性を書くために優先権を与える必要はありません。
PostgreSQLのクエリは数分かかりますので、彼らは、カサンドラの使用を検討した理由。彼らは、ハードウェアの問題は、調査の後、我々は5000万データ・テーブル・データ、データの80のバイトまで、それぞれがあることがわかったと信じています。あなたは一枚からSSD上のすべてのデータを読み込む場合は約5秒かかり、これは高速ではありませんが、実際のクエリに比べて、それはより速く二桁です。
彼らのために私は本当に（！列挙された複数の候補）私は彼らのために5つのプログラムを用意し、問題はさらに深刻になると、（問題を理解するために！）彼らにいくつかの質問をお願いしたいと思います、しかし、それは明らかである、カサンドラそれは完全に間違ったアプローチです。彼らはただ、特定のその他の技術（もちろん、そこではないかもしれない）を使用することも考えられる、そのようなデータの一部を改造として、いくつかのチューニングを行うには患者である必要はあり......が、これは非常に可能なキーと値のストア書き込みシステムではありません、Amazonはカサンドラを作成していました彼らのカートの問題を解決するために使用されます！
あなたはLinkedInのいません
私は実際に彼らのシステムにカフカを使用し、学生によって設立された小規模な会社を見つけ、それは私は非常に驚い感じさせます。状況の最高の日に、わずか数百 - 私の知る限りでは、彼らはあなたが毎日必要とする少数のものを持っています。このようなほぼ確実には、直接ノートに記録すること。
カフカは、LinkedInの内部にある特定の処理するように設計され、それは天文学的です。でも、数年前に、この数字は、毎日、数兆円に達している毎秒はピーク時千万のメッセージを処理する必要があります。しかし、カフカも10桁で、おそらく再び低いスループットを処理負荷のために使用することができますか？
意思決定を行うおそらくエンジニアは確かに彼らの期待ニーズに基づいて、また、該当シーンカフカをよく知っていますさ。しかし、私は、彼らはカフカのコミュニティの追求に耐えることができなかった、と慎重にカフカが彼らのために右であることについて考えていなかったと思います。あなたが知っている、それは大きさのギャップの10件の受注です！
ここでも、あなたはアマゾンじゃありません
Amazonの分散データベースよりもっと有名な、それは、サービス指向アーキテクチャでスケーラブルなアーキテクチャモデル、ということです。2006年のインタビューでワーナー・ボーゲルズは、サービス指向アーキテクチャーは彼らがフロントストレッチを達成するのに役立ちますしながら、Amazonは2001年に、スケールアウトするためのフロントエンドを自分の必要性を実現し、指摘しました。エンジニアは互いに顔を見合わせ、そして最終的にはわずか数のエンジニアは、このことを行うために始めたが、ほとんど誰が小さなサービスに自分の静的なWebページを分割していく所存です。
しかし、Amazonはその後、彼らは7800人の従業員と売上は$ 30億持って、SOAへの移行を決めました。
もちろん、従業員がSOAを回すことができたとき、あなたは7800まで待たなければならないわけ......しかし、あなたはそれについて考える必要はありません、それは本当にあなたの問題を解決することができますか？あなたの問題の原因があるとは何ですか？彼らは、他の方法でそれを解決することができますか？
まだ彼はモジュラーアプリケーションが音楽で大規模な単一使用していないのはなぜこれほど多くの大企業がありません：あなたは、同社の50の個々のSOAをオンにするつもりと言った場合、私は助けることはできませんが、不思議は？
でも、Googleアカウントではありません
Hadoopを使用して、そのような大規模なデータフローエンジンをスパーク非常に興味深いものになるが、多くの場合、伝統的なDBMSは、時として少量のデータをメモリに直接あることが、現在の負荷に適しています。あなたは、メモリの1TBを買うために$ 10,000費やすことをいといませんか？あなたは10億人のユーザーがいる場合は、あなたの投資が十分ではありませんので、各ユーザーは、メモリの1キロバイトを使用することができます。
おそらく、あなたがディスクに書き込まれた大規模なデータをロードする必要があります。だから、どのように多くのディスクが必要ですか？あなたは最終的に持っているどのくらいの量のデータの？GoogleのGFSやMapReduceのを作成する理由は、そのような全体のウェブ検索インデックスの再構築など、Web全体に計算問題を、解決することです。
おそらく、あなたはGFSとMapReduceの論文を読んだことが、問題の一部ではなく、容量よりもそのGoogleのスループット、バイトの読み取りストリームがディスクからあまりにも多くの時間を費やすので、彼らは、分散ストレージを必要とする理由です。その後、2017年に多くの機器のスループットを必要としますか？あなたがより良い機器を使用して検討するかもしれないので、あなたは確かに、Googleのスループットのようなので、多くを必要としません。あなたが使用している場合は、両方のSSDはあなたのコスト上昇の量を与えるのだろうか？
おそらく、あなたはまた、スケーラビリティをしたいです。あなたは慎重にそれを数えている。しかし、あなたのデータレートが行うSSDの価格の速度よりも速く増加しますか？あなたのデータ内のすべてのマシンを爆発する前に、あなたのビジネスは非常に成長のだろうか？2億要求に対処するために2016年の時点で、スタック交換の日、彼らは唯一のバックアップレプリカとして4 SQL Serverの、スタックオーバーフロー、他の目的のための1のための1つ、他の二つを取りました。
おそらく、あなたはUNPHAT原理を適用した後、まだのHadoopやスパークを使用することを決定しました。おそらく、あなたの決断は正しいですが、キーを使用すると、ツールを使用することです。GoogleはMapReduceのはもはやインデックスを構築するために適していることに気づいていないとき、彼らはそれを使用することはありません、この真理をよく知っています。
まず、あなたの質問を理解します
私は話しています新しいアイデアではありませんが、おそらくあなたのためのUNPHATで十分です。あなたは十分ではないと思われる場合は、「ハンモック駆動開発」リッチヒッキーの演説を聞くことができたり、「それを解決する方法」、または「科学とエンジニアリングを行うのアート」コースをハミングについて学ぶポリアの本を参照してください。私は詳細を考える必要があるように頼みます！彼らの前に完全な理解の問題を解決しようとする前に。最後に、有名なポリアの詩を送信します。
あなたが質問に対する答えは愚かであるかわからない、あなたは所望の終点が悲しいです達していません。