あなたはグーグルではありません

開発者は最も奇妙なことに夢中です。 私たちは皆、超合理的な存在を考えることを好みますが、特定のテクノロジーを選択することになると、ある種の狂気に陥り、HackerNewsのコメントからいくつかのブログの投稿にスキップします。元々探していたものを完全に忘れてしまったので、その前に最も明るい光源に向かって順調に航行しています。

これは、合理的な人々が決定を下す方法ではありません。 しかし、まさにそのため、開発者は、たとえばMapReduceを使用することにしました。

ジョー・ヘラースタインが学士号データベースに関する講義で指摘したように （54分）：

実際、このような野心的なタスクを実行する企業は世界に約5社あります。 他のすべての人と同様に...彼らはシステムの弾力性を確保するために信じられないほどのリソースを費やします。 2000年代には「Google」のようなものがありました。「Googleは世界最大のデータ処理サービスも管理しているため、Googleとまったく同じようにすべてを行います...」[皮肉なことに頭を振って聴衆の笑い声を待つ]

データセンターの建物の何階ですか？ Googleは、少なくともオクラホマ州メイズ郡にあるこの特定のデータセンターでは、4にとどまることにしました。

はい、あなたのシステムはあなたが必要とするよりも回復力がありますが、それが何を犠牲にするか考えてください。 ポイントは、大量のデータを処理する必要があるだけではありません。 おそらく、トランザクション、インデックス、クエリ最適化を備えた完全なシステムを、比較的弱いものと交換しているでしょう。 これは大きな後退です。 何人のHadoopユーザーがこれを意識的に行いますか？ 本当にバランスのとれた決定を下すのは何人ですか？

MapReduce / Hadoopは非常に簡単な例です。 カーゴカルトの信奉者でさえ、飛行機がすべての問題を解決するわけではないことをすでに認識しています。 それにもかかわらず、MapReduceを使用すると、重要な一般化を行うことができます。大企業向けに作成されたテクノロジーを使用し、同時に小さな問題を解決する場合は、軽率に行動している可能性があります。 そうでなくても、GoogleやAmazonのような巨人を模倣するという神秘的なアイデアに導かれる可能性が最も高く、同じ高さに到達します。

はい、この記事はカーゴカルトの反対者です。 しかし、待ってください。私はあなたのために、より多くの情報に基づいた決定を下すために使用できる便利なチェックリストを用意しています。

クールなフレームワーク：UNPHAT

次回、システムを（再）形成するための新しいクールなテクニックをGoogleで検索するときは、停止してUNPHATフレームワークを使用することをお勧めします。

1. （理解）問題を理解する前に、可能な解決策について考えようとさえしないでください。 あなたの主な目標は、ソリューションの観点ではなく、問題の観点から問題を「解決」することです。
2. いくつかの可能なソリューションをリスト（eNumerate）します。 すぐにお気に入りのオプションに指を向ける必要はありません。
3. 別の解決策を検討し、もしあればドキュメント（Paper）を読んでください。
4. このソリューションが作成された履歴コンテキストを定義します 。
5. Flawsと利点を一致させます。 意思決定者が目標を達成するために犠牲にしなければならないものを分析します。
6. 考える（考える） ！ このソリューションがあなたのニーズを満たすのにどれだけ適しているかを落ち着いて静かに考えてください。 心を変えるために何を変える必要があるのでしょうか？ たとえば、Hadoopを使用しないようにするには、データをどれだけ少なくする必要がありますか？

あなたはアマゾンではありません

UNPHATの使用は簡単です。 夜にダウンロードしたデータを集中的に読み取るプロセスにCassandraを使用することに急いで決めた会社との最近の会話を思い出してください。

私はすでにDynamoのドキュメントに精通しており、Cassandraが派生システムであることを知っていたため、これらのデータベースでは主に記録機能に焦点を当てていることに気付きました（Amazonは「カートに追加」アクションを失敗しませんでした）。 また、開発者がデータの整合性を犠牲にしたこと、そして実際、従来のRDBMSに固有のすべての機能を評価したことにも感謝しています。 結局のところ、私が話をした会社では、録音する能力は優先事項ではありませんでした。 正直なところ、このプロジェクトは1日に1つの大きなレコードを作成することを意味していました。

アマゾンはすべてを販売しています。 「バスケットに追加」機能が突然機能しなくなった場合、多くのお金を失います。 同じ順序の問題がありますか？

この会社は、問題のPostgreSQLクエリを完了するのに数分かかったため、Cassandraを使用することを決定し、これらはハードウェアの技術的な制限であると判断しました。 いくつかの点を明確にした後、テーブルはそれぞれ80バイトの約5,000万行で構成されていることがわかりました。 SSDから完全に読み取る必要がある場合、SSDから読み取るのに約5秒かかります。 これは低速ですが、その時点でのクエリ実行速度よりも2桁高速です。

この段階で、私は多くの質問をしました（U =理解し、問題を理解します！）そして、元の問題を解決できる5つの異なる戦略を検討し始めました（N = eNumerate、可能な解決策をいくつか挙げてください！）、しかし、いずれにしてもCassandraを使用することが根本的に間違った決定であることは、現時点ではすでに明らかでした。 彼らが必要としたのは、設定するための少しの忍耐、おそらくデータベースの新しい設計と、おそらく（可能性は低いですが）別のテクノロジーの選択でした...しかし、集中的な記録を備えたキーバリューデータストレージではありませんAmazonがバスケット用に作成したもの！

あなたはLinkedInではありません

ある学生のスタートアップが、Kafkaを中心にそのアーキテクチャを構築することを決めたことに非常に驚きました。 それはすごかった。 私が知る限り、彼らのビジネスは1日に数十件の非常に大規模な業務しか行っていませんでした。 おそらく最も成功した日に数百。 この帯域幅により、メインデータウェアハウスは普通の本の手書き入力になります。

比較のために、KafkaはLinkedInのすべての分析イベントを処理するために作成されたことを思い出してください。 これは膨大な量のデータです。 数年前でさえ、それは1日に約1兆イベントであり、ピーク負荷は1秒あたり1,000万メッセージでした。 もちろん、Kafkaを使用してより低い負荷で作業できることを理解していますが、10オーダー少ないですか？

太陽は非常に大きな物体であり、地球よりも6桁重いだけです。

おそらく、開発者は、予想されるニーズとKafkaの目的の十分な理解に基づいて、慎重な決定を下したこともあります。 しかし、彼らはカフカに対する（通常は正当化された）コミュニティの熱意によってむしろ活気づけられ、これが本当に彼らが必要とするツールであるかどうかほとんど疑問に思わなかったと思います。 想像してみてください... 10注文！

すでに言った？ あなたはアマゾンではありません

Amazonの分散データウェアハウスよりもさらに人気があるのは、スケーラビリティを提供するアーキテクチャ設計アプローチ、つまりサービス指向アーキテクチャです。 2006年のジムグレイとのインタビューで Werner Vogelsが指摘したように、Amazonは2001年にインターフェース（フロントエンド）のスケーリングが困難であり、サービス指向アーキテクチャが役立つ可能性があることに気付きました。 このアイデアは次々と開発者に感染しましたが、ほんの数人の開発者でクライアントがほとんどいないスタートアップは、ソフトウェアをナノサービスに分割し始めませんでした。

AmazonがSOA（サービス指向アーキテクチャ）に切り替えることを決定するまでに、 約7,800人の従業員がおり、売り上げは30億ドルを超えていました 。

サンフランシスコのコンサートホールビルグラハムオーディトリアムには7,000人が席を構えています。 Amazonには、SOAに切り替えたときに約7,800人の従業員がいました。

これは、会社が従業員7800人のレベルに達するまでSOAへの移行を延期する必要があるという意味ではありません... 常に自分の頭で考えてください 。 これは本当にあなたのタスクに最適なソリューションですか？ あなたの前の仕事は正確に何ですか？それを解決する他の方法はありますか？

50人の開発者で構成される組織の作業がSOAなしで単純に上昇することを教えてくれた場合、なぜ多くの大企業が単一の、よく組織されたアプリケーションを使用して素晴らしく機能するのか疑問に思いました。

GoogleでさえGoogleではありません。

負荷の高いデータストリーム（HadoopまたはSpark）を処理するためのシステムの使用例は、本当に戸惑う可能性があります。 非常に多くの場合、従来のDBMSは負荷により適しています。また、データ量が非常に少ないため、 使用可能なメモリでも十分な場合があります。 どこかで1TBのRAMを10,000ドルで購入できることをご存知ですか？ 10億人のユーザーがいたとしても、各ユーザーに1 KBのRAMを提供できます。

ディスクへの読み取りと書き込みが必要になるため、おそらくこれは負荷に対して十分ではありません。 しかし、実際に読み書きするのに数千のディスクが必要ですか？ 実際にどのくらいのデータを持っていますか？ GFSとMapReduceは、インターネット全体のコンピューティングの問題を解決するために作成されました。たとえば、 インターネット全体で検索インデックスを再計算します。

ハードドライブの価格は、GFSのドキュメントが発行された2003年よりもはるかに低くなりました。

GFSとMapReduceのドキュメントを読んで、Googleの問題の1つはデータ量ではなく帯域幅（処理速度）であることに気付きました。ディスクからバイトを転送するのに時間がかかりすぎたため、分散ストレージを使用していました。 しかし、今年使用するデバイスの帯域幅はどうなりますか？ Googleが必要とするほど多くのデバイスを必要としないことを考えると、おそらくより新しいドライブを購入する方が良いでしょうか？ SSDを使用するにはどれくらいの費用がかかりますか？

事前にスケーラビリティを検討したい場合があります。 必要な計算はすべて完了していますか？ SSDの価格が下がるよりも早くデータを蓄積しますか？ すべての利用可能なデータが1つのデバイスに収まらないように、ビジネスを何回成長させる必要がありますか？ 2016年の時点で、Stack Exchangeは1日あたり2億件のクエリを処理し、4台のSQLサーバーのみをサポートしていました。メインはStack Overflow、もう1つはすべて、もう2つはコピーです。

繰り返しますが、UNPHATに頼っても、HadoopまたはSparkを使用することを決定できます。 そして、決定は正しいかもしれません。 主なことは、あなたが本当にあなたの問題を解決するために正しい技術を使うということです。 ちなみに、これはGoogleでよく知られています。MapReduceがインデックスに適していないと判断したため、使用を中止しました。

まず最初に、問題を理解する

私のメッセージは新しいものではないかもしれませんが、その形であなたに返事をするかもしれませんし、UNPHATを覚えて生活に適用するのは簡単かもしれません。 そうでない場合は、 ハンモック駆動開発に関するリッチヒッキーのスピーチ、またはポールの本、それを解決する方法 、またはハミングのコース、科学と工学の実践の講座を見ることができます。 なぜなら私たち全員が尋ねる主なことは考えることだからです！

そして、あなたが解決しようとしている問題を本当に理解してください。 パウロの心に強く訴える言葉で：

「 理解できない質問に答えるのは愚かです。 達成したくない目標を目指して努力するのは悲しいことです。」

---

ロシア語翻訳

翻訳： アレクサンダー・トレグボフ

アレクセイ・イワノフ 編集 （@ponchiknews）

コミュニティ： @ponchiknews

図： LucidChartコンテンツチーム