Лучший способ хранить много данных о запасах в памяти (переменная)

Question

Я пытаюсь сохранить значительный объем данных котировок фондового рынка в переменной для запроса в памяти. Мне нужно иметь возможность быстро найти самые последние рыночные данные для идентификатора акции и запросить определенную длину истории для конкретной акции.

Например, я мог бы получать данные по биржевому идентификатору 5342 (всегда числовому) каждые несколько секунд ... Моя первоначальная мысль - создать массив SortedDictionary с ключом SortedDictionary, являющимся DateTime цитаты, и его значением, являющимся Моя пользовательская структура рыночных данных. Тогда внешний массив будет идентификаторами акций ... так что я могу позвонить:

RecentPrice = PriceData[StockID].Values.Last();

Или я мог бы перебирать SortedDictionary этой акции в обратном направлении, пока не нажму ключ, который старше требуемого временного диапазона.

Однако я чувствую, что должен быть лучший (более эффективный) метод. Есть идеи?

Редактировать: Вместо массива SortedDictionaries ... словарь SortedDictionaries может быть лучше. Например:

public static Dictionary<int, SortedDictionary<DateTime, StockData>> PriceData = 
    new Dictionary<int, SortedDictionary<DateTime, StockData>>();

, то:

RecentPrice = PriceData[StockID].Values.Last();

Спасибо!

Answer 1

Словари и хеш-таблицы в целом хороши для точных совпадений.Но когда вы хотите «первую дату / время не ранее X», отсортированный список будет работать лучше, потому что поиск - это двоичный поиск.Тем более, что вы только добавляете данные, а не вставляете их.

Answer 2

Если вы можете убедиться, что новые поступающие данные тикера расположены во временном порядке, SortedList - лучший выбор. Он потребляет меньше памяти и быстрее для вставки и удаления заказанных данных.

Также, если вам нужны различные запросы данных. База данных в памяти - лучший выбор. Я использую SqlLite для выполнения аналогичной функции в одном из моих проектов, и она отлично справляется с различными требованиями, потому что я могу использовать sql.

Answer 3

Вы думали об использовании стека вместо SortedDictionary?Некоторая пользовательская реализация может работать хорошо, если ваши данные всегда вставляются в правильном порядке.Возможно связанный список.

Если ваши данные поступают последовательно, почему бы просто не сохранить их в массиве?Таким образом, вы можете использовать двоичный поиск, чтобы быстро сходиться в желаемом диапазоне дат, и операция вставки также очень быстрая.Хотя это тратит немного памяти ...

Answer 4

Если ваши значения StockID являются смежными и начинаются с нуля, вероятно, будет достаточно массива.В реальном мире, я думаю, что они, вероятно, нет, поэтому словарь словарей хорош.Я часто использовал их для решения подобных проблем.