私の会社では、ETL プロセスの手段として Web サービスを使用することを検討しています。ただし、いくつかの理由から、Web サービスはこの目的に適合しないと思います。1. Web サービスは、大きな xml を生成するときに大量のメモリを消費する可能性があります。2. xml は肥大化した形式です。3. サーバーがデータを生成するのに膨大な時間がかかる場合、タイムアウトになる可能性があります。 4. ファイル サイズの制限はありますか? （Windowsの場合、私の記憶が正しければ2Gbです）
私はウェブサービスの専門家ではないので、あなたの意見が必要です。:)
ありがとう。
Web サービス ツール シェッドには、あなたが詳細に説明したすべての問題を回避するテクノロジがたくさんあります。ストリーム指向の XML シュレッディング、配信用の XML 圧縮形式、断片化と公平性を処理するプロトコル、およびテラバイト単位のデータを保持できる多くのストレージ システムがあります。
Web サービスによって、2 GB のシリアル化されたテーブルを含む単一の glop 引数を受け入れるインターフェイスの大学新入生の宿題の調合を想像すると、すべての引数が有効になります。しかし、 WS-ReliableMessagingとWS-Transactionに関連する概念の知識を持つ経験豊富なチームに要件を与える場合、 Web サービスに関する ETL プロセスを持たない理由はありません。SOAP プロトコル自体を支持するわけではありませんが、関連する概念の知識と理解を支持することに注意してください。
そうは言っても、Web サービス指向の ETL プロセスがあなたにとって意味があるかどうかは、他のすべての理由に依存します。ただし、Web サービス技術に対するあなたの反論には根拠がありません。
なぜあなたの会社は、 duffymoが彼の回答で言及したような本物のETLツール、またはオープンソースがオプションの場合はTalendやCloverETLの使用を検討していないのか疑問に思っています。
私はETL製品の専門家ではなく、すべてをチェックしたわけではありませんが、これは考慮すべきことであると確信しています。
私は ETL タスクに Web サービスを使用しません。そのタスクに適した専用ツール (Ab Initio、Informatica など) があります。
大量のデータがある場合、ネットワークがもたらす余分な遅延の代償は法外なものになると思います.
それは実際にあなたが何をしているか、そしてそれをどのように達成しようとしているかに依存します. 一般に、Web サービスは、通常 ETL プロセスに投入するよりも多くの注意と供給を必要としますが、タスクにおいても驚くほど効果的です。あなたのシナリオがうまくいくかどうかを言うのに十分な詳細が得られませんでした.
私は、100 MB 以上のドキュメントを送受信する Web サービスに取り組んできました。一部は XML でエンコードされ、一部は XML でエンコードされていないものもあり、(閉じたローカル ネットワーク上で) 数秒で実行できます。これらのサービスにはかなりの調整と計画が必要でしたが、私たちのシナリオではうまく機能し、さまざまなクライアントがかなり標準的なインターフェイスを介してさまざまな量のデータを接続および送信できるようになりました。これは、ジョブが各クライアントに固有であり、クライアントごとにセットアップおよび保守する必要があるという点で、私たちが持っていた他の ETL ジョブとは異なりました。
それはすべて、あなたが何をしているか、そしてあなたの制約が何であるかに依存します.
このルートを追求する場合は、クライアントに接続する方法を含め、プロセスを最初から最後まで座って下書きし、データが受信されたことを確認し、ジョブが終了したことを確認します。いくつかのシナリオ、クライアント、および送信されるデータの種類を検討してから、何が必要かを判断してください。それを、他のツールですでに利用可能なものと比較し、それを完了するのにどれだけの時間が必要か.
まず、任意の非 XML データを Web サービスでストリーミングできるようにする MTOM を検索します。
Web サービスは ETL タスクに最適です。各タスクは独自のスレッドで無料で処理され、リクエスト間の適切なクリーンアップが保証されることに注意してください。Tomcat などの内部で Web サービスを使用しても、思ったほど重くはありません。
XML の肥大化が懸念される場合は、JSON 形式を検討してください。