これは、map & reduce でスケールを実現する唯一の方法ですか?
これについて私が嫌いなのは、永続性の無知がすべてジャッキアップされていることです。HDFS はインターフェイスを介して自身を公開する必要があります。それがどの言語で記述されているか、またはその理由を気にする必要はありません。ODBC を記述して、Oracle、Sql Server、およびどのオペレーティング システムでも実行されていないものにプラグインする方法と同じように。
Hive は知っていますが、行列操作やガウス分析などの重い計算には適していないと思います。
もう 1 つの問題は、複雑な命令セットとそれに伴う依存関係を作成することです。つまり、コードを移植し、依存関係と共にサーバー自体にインストールする方法を理解する必要があります。これは多くのインフラコストです！また、(Platform as a Service) Paas クラウド内で行うことも困難です。
たとえば、Hadoop ストリーミングを使用した例。バイナリがターゲット サーバー カーネルに対してコンパイルされていることを確認する必要があります。例えば。Linux と Windows など。また、すべてのプロジェクトが同じバージョンの依存関係を参照していることを確認する必要があります。繰り返しますが、これは雄牛です。複数のチームがある場合、これは多くの調整とオーバーヘッドになります。私たちは、これらのいくつかから逃れるために SOA に移行しました。
データはコードよりも重いことは理解しています。データ自体の隣にコードを配置する方がはるかに効率的ですが、これがスケールを実現する唯一の方法ですか? Hadoop が対処することになっているデータの量を扱う場合、懸念の分離を絶対に犠牲にする必要がありますか。
たとえば、はい、CLR を Sql サーバーに埋め込むことができますが、実際には、これは他の方法では解決できない真に深刻なボトルネックに対してのみ予約されています。別名-それを呼びたい場合、それはハックまたはアンチパターンです。これをやりすぎると、製品が Microsoft Sql Server と強く結びついてしまいます。ビジネスのニーズの変化に応じて、Oracleやその他のものと交換することはできません。良くない。
また、すべてのコンピューティングの歴史において、私たちは常にデータをコードに持ち込んできましたが、その逆ではありません。例えば。データベースから Orm、サービス、メモリ、キャッシュ、そして命令セットにデータをロードします。これには、SOCという理由がありました
私の質問は、 map & reduce + no sql は、命令セットに必要に応じてデータをロードするのではなく、データの隣にコードを配置するだけでよいケースの 1 つであるかどうかです (たとえば、負荷分散されたサービスのどこか)クラウド）。