2

IATA SSIM 形式の航空会社のスケジュールを分析する C++ アプリを作成しています。航空業界グループ IATA は、システム間でスケジュールを送信するためのファイル レイアウト標準を指定しており、「SSIM」ファイルには、スケジュールに関する情報と、1 つまたは複数の航空会社の対応するすべてのフライトが含まれています。

Flight オブジェクトのコレクションを含む Schedule オブジェクトを設計しました。通常、入力ファイルには 2,000 ～ 20,000 のフライトがあり、結果のオブジェクトのサイズは最大で約 50MB になります。ここまでは、フラット ファイルを読み込んで、結果の Schedule オブジェクトを作成しました。このオブジェクトは、レポート目的で分析/操作されます。

私の質問は、設計の観点からこれを行うことは問題ありませんか。レポートを作成している間、フライト オブジェクトとスケジュール オブジェクトをすべてメモリに保持しますか? 別の方法として、フライト オブジェクトをディスク上でシリアル化しておき、必要なときにのみメモリ内のアクティブなレコードで作業することもできます。これにより、使用されるメモリのサイズが削減されますが、コーディングの観点からは明らかに面倒です。

これには「標準的な」アプローチがないことは知っていますが、メモリ内の非常に大きなオブジェクトを管理することに対する人々の見方は何なのか疑問に思っています。これはかなり標準的なものですか、それとも次善の設計ですか? 私の好みは、すべてをメモリに保持し、シリアル化に頼らずにオブジェクトで作業することです。

みんなありがとうピート

4

3 に答える 3

2

それらすべてを問題なくメモリに保持できる場合は、それを実行してください。それ以外はすべて、時期尚早の最適化になります。

心に留めておくべき重要なことは、後でアプリケーション ロジックを書き直すことなく別の戦略に切り替えることができるように、アルゴリズムとデータ構造を切り離すことです。アルゴリズムがフライトのリストの反復子で動作する場合、後でアルゴリズムを変更することなく、これらの反復子のロジック (メモリからの読み取り、ディスクからの読み取り) を変更できます。

于 2012-12-17T08:50:49.587 に答える
0

ディスクは地獄のように遅く、絶えずロード/アンロードすることは非常に複雑になります。メモリが不足しておらず、最近のかなりの数のプラットフォームで50MBが確かに多くない場合は、それらすべてをメモリに保持してください。

于 2012-12-17T09:09:22.373 に答える
0

メモリのみを使用する場合の主な問題の 1 つは、システムがクラッシュした場合 (必ずしもコードのバグではない何らかの理由で)、操作したオブジェクトのデータがすべて失われることです。処理が速い場合は、リスクを負う余裕があります。

安定したシステムを提供したい場合は、20K のフライト データがいつ 200 万のフライト データになるかわからないため、スケーラブルである必要があります。アルゴリズムに必要な追加のデータ構造 (より多くのメモリ領域) など. このようなシステムでは、障害後に処理の途中から開始する必要がある場合に備えて、システム状態も保存するためのストレージ メカニズムが推奨されます。

于 2012-12-17T08:57:48.203 に答える