いくつかの注文が非常に頻繁に送られてきます。それらを保存し、それらから集約を構築する必要があります。注文には ID があり、それに関連する商品タイプがあります。注文には、追加、更新、削除など、いくつかのイベントを関連付けることもできます。更新イベントの場合、注文に添付された金融商品タイプはありませんが、注文 ID は同じです。例: 注文 ID 100 の商品「xyz」の注文がある場合、後で ID 100 の注文を 20 ドル更新するイベントを取得できますが、そのイベントには商品タイプが存在しません (注文)。
注文を受け取ったら、固有の商品の注文書を作成する必要があります。たとえば、商品「xyz」には、受け取ったすべての注文が注文書に含まれている必要があります。
私の質問は、これをどの程度効率的に保存できるか、またどのようなデータ構造を使用する必要があるかです。
注文は次のようになります。
public class Order
{
public Order(Action add, int id, string instrument, int price)
}
オーダーブック:
public class OrderBook
{
public string Instrument;
public List<Order> AllOrders;
}
オプション1:
Dictionary<int,OrderBook>
注文を受け取ったら、注文 ID としてキーを使用してa を更新し、楽器の注文書を作成します。
問題: これにより、更新イベントが処理されます。注文が既に存在するかどうかを確認してから、注文一覧を更新できます。ただし、インストゥルメント タイプには 1 つのオーダー ブックのみを含める必要があり、この条件はここで違反されています。インストゥルメント「xyz」については、複数の Add 注文が通過する可能性があり、操作も困難になります。
オプション 2:
Dictionary<OrderBook, List<int>>
値を注文 ID として、の辞書を更新します。
問題: これで上記の問題は解決されますが、更新イベントを受け取ると、値のすべてのリスト (注文 ID のリスト) をチェックして、注文が既に存在するかどうかを確認する必要があります。空になり、OrderBook キーで見ることができません。
注文はリアルタイムで減少しており、保存と取得の操作はもう少し効率的にする必要があります (O(1) でない場合は O(logn))。これを構造化するより良い方法はありますか?
注: OrderBook は、金融商品のすべての注文の集約であり、金融商品に対して一意です。注文は特定の価格の楽器に対するものであり、同じ楽器に対する多くの注文があります。私は他の誰か (サード パーティのライブラリ) からイベントと共に注文を受け、オーダーブックを作成する責任があります。