取引プラットフォーム (低遅延環境) のオーダーブックでは、少なくともすべての注文が一意であることを確認するために、すべての注文 ID を保存する必要があります。取引日に受け取ることができる注文 ID の数は無制限です。履歴データ分析を使用する以外に、データ構造を事前に割り当てるために適切に「推測」できる数はありません。日中のオーダー ID コンテナーの再割り当てを回避するために、どのようなスキームが存在しますか?
1 に答える
3
取引プラットフォーム (低遅延環境) のオーダーブックでは、少なくともすべての注文が一意であることを確認するために、すべての注文 ID を保存する必要があります。取引日に受け取ることができる注文 ID の数は無制限です。履歴データ分析を使用する以外に、データ構造を事前に割り当てるために適切に「推測」できる数はありません。日中のオーダー ID コンテナーの再割り当てを回避するために、どのようなスキームが存在しますか?
良い質問。1 つの解決策は、各ブランチが個別のヒープ割り当てであるツリー データ構造を使用することです。これは、最も純粋に機能的なデータ構造 (OCaml や F# など) がどのように機能するかでSet
ありMap
、それらをインクリメンタルにするため、挿入と削除は常に O(log n ) の最悪のケースです。
于 2013-07-09T19:01:07.063 に答える