3

取引プラットフォーム (低遅延環境) のオーダーブックでは、少なくともすべての注文が一意であることを確認するために、すべての注文 ID を保存する必要があります。取引日に受け取ることができる注文 ID の数は無制限です。履歴データ分析を使用する以外に、データ構造を事前に割り当てるために適切に「推測」できる数はありません。日中のオーダー ID コンテナーの再割り当てを回避するために、どのようなスキームが存在しますか?

4

1 に答える 1

3

取引プラットフォーム (低遅延環境) のオーダーブックでは、少なくともすべての注文が一意であることを確認するために、すべての注文 ID を保存する必要があります。取引日に受け取ることができる注文 ID の数は無制限です。履歴データ分析を使用する以外に、データ構造を事前に割り当てるために適切に「推測」できる数はありません。日中のオーダー ID コンテナーの再割り当てを回避するために、どのようなスキームが存在しますか?

良い質問。1 つの解決策は、各ブランチが個別のヒープ割り当てであるツリー データ構造を使用することです。これは、最も純粋に機能的なデータ構造 (OCaml や F# など) がどのように機能するかでSetありMap、それらをインクリメンタルにするため、挿入と削除は常に O(log n ) の最悪のケースです。

于 2013-07-09T19:01:07.063 に答える