1

この風のデータにアクセスする必要があるC++プログラムがあり、6時間ごとに更新されます。サーバーのクライアントがデータを必要とするとき、サーバーはデータベースにクエリを実行し、クライアントにデータを提供します。クライアントは、5つの値を見つけるためのキーとして、lat、lon、およびmbを使用します。

+------------+-------+-----+-----+----------+----------+-------+------+------+
| id         | lat   | lon | mb  | wind_dir | wind_spd | uv    | vv   | ts   |
+------------+-------+-----+-----+----------+----------+-------+------+------+
| 1769584117 | -90.0 | 0.0 | 100 |      125 |        9 | -3.74 | 2.62 | 2112 |
| 1769584118 | -90.0 | 0.5 | 100 |      125 |        9 | -3.76 | 2.59 | 2112 |
| 1769584119 | -90.0 | 1.0 | 100 |      124 |        9 | -3.78 | 2.56 | 2112 |

データはあまり頻繁に変更されないため、サーバーによってデータがキャッシュされるようにしたいので、クライアントが以前にクエリされたデータを必要とする場合は、2番目のSQLクエリは必要ありません。

私は、ストレージ/速度の観点から最も効率的なインメモリデータ構造を決定しようとしていますが、さらに重要なのは、アクセスのしやすさです。

私の最初の考えは、latでキー設定されたマップ、lonでキー設定されたマップ、mbでキー設定されたマップを含み、値がwind_dir、wind_speed、uv、vv、およびtsフィールドを含むマップであるというものでした。

ただし、それはすぐに複雑になります。もちろん、もう1つの考えは、最後の5つのフィールドの構造体を含む3次元配列（lat、lon、mbインデックス）です。

ここに座っているときに、lat、lon、mbを文字列に結合することを思いつきました。これは、lat、lon、およびmbの組み合わせが99％確実であるため、マップのインデックスとして使用できます。 mbは常に一意です。

他にどのようなアイデアが理にかなっていますか？

編集：以下のコメントからの詳細

データに関しては、データセットには3,119,040行あります。これはかなり一定ですが、新しいレポートステーションが追加されるにつれて、何年にもわたってゆっくりと成長する可能性があります。通常、700〜1500のクライアントがデータを要求しています。クライアントはフライトシミュレーターです。デフォルトでは5分ごとにデータを要求しますが、可能な最大頻度は30秒ごとです。追加情報はありません。上に表示されているのは、返したいデータです。

最後に、私が言及するのを忘れたのは、C ++、特にSTLでかなり錆びているので、単純な方が良いということです。

4

3 に答える 3

1

3つの部分からなるキーと適切なlessよりも少ない演算子で使用できますstd::map（これはCrazy Eddieが提案したものであり、数行のコードで拡張されています）

struct key
{
    double mLat;
    double mLon;
    double mMb;
    key(double lat, double lon, double mb) :
        mLat(lat), mLon(lon), mMb(mb) {}
};

bool operator<(const key& a, const key& b)
{
    return (a.lat <  b.lat ||
            a.lat == b.lat && a.lon <  b.lon ||
            a.lat == b.lat && a.lon == b.lon && a.mb < b.mb);
}

マップの定義と挿入は次のようになります。

std::map<key, your_wind_struct> values;
values[key(-90.0, 0.0, 100)] = your_wind_struct(1769584117, 125, ...);
于 2012-05-13T19:48:52.980 に答える
0

ソートされたベクトルも意味があります。3つの部分のキーを比較するより少ない述語をフィードできます。マップまたはセットでも同じことができます。ハッシュ...選択したコンテナの多くの要因によって異なります。

于 2012-05-13T17:02:55.510 に答える
0

もう1つのオプションはc++11 unordered_setです。これは、内部データ構造として赤黒木ではなくハッシュテーブルを使用し、赤黒木に対してO（1）とO（logn）の償却ルックアップ時間を提供します（私は信じています）。 。どのデータ構造を使用するかは、問題のデータの特性（データの数、特定のレコードにアクセスする可能性のある頻度など）によって異なります。構造をキーとして使用することは、いくつかのコメント提供者に同意します。行くための最もきれいな方法。また、将来変更された場合に、一意のキーが何であるかをより簡単に変更することもできます。キー構造にメンバーを追加するだけで、まったく新しいレベルのマップを作成する必要はありません。

于 2012-05-13T17:06:41.127 に答える