Теоретическая проблема большого объема, нельзя использовать коллекцию для сортировки в .NET

Question

Извините за заголовок этого поста, но я не могу придумать более креативное название.

Я звоню в стороннюю веб-службу, где авторы заказывают результаты транзакций из последних. Общее количество транзакций превышает 100 000. Чтобы сделать вещи более интересными, веб-служба отправляет сложные объекты, представляющие каждую транзакцию, поэтому, если я запрашиваю все 100 000 одновременно, произойдет тайм-аут. Таким образом, вызовы этого веб-сервиса должны быть пакетными, чтобы возвращать только 1000 записей одновременно. Это означает 100 индивидуальных звонков на этот веб-сервис.

Пока все хорошо, за исключением того, что транзакции нужно обрабатывать от самых старых до самых новых, поэтому мне нужно место для временного хранения просто ПРОСТО идентификаторов этих транзакций, чтобы позже я мог вспомнить идентификаторы в правильном порядке (самые старые до самого нового) после того как я их отсортировал.

В этом решении мне не хватает СУБД, я думаю об использовании текстового файла для хранения значений.

Извините за длинное вступление, если вы еще не спите, вот некоторые соображения:

(1) * * +1011

1. Если я просто сохраню значения в текстовом файле, я получу более 100 000 строк в текстовом файле в неправильном порядке, то есть мне придется реализовать способ чтения файла снизу вверх
2. Я не уверен, но может быть добавление в начало существующего текстового файла без каких-либо потерь производительности, таким образом, после создания файла я мог бы использовать встроенный .net, чтобы прочитать файл сверху вниз -> вниз ,
3. Я мог бы подключить текстовый драйвер odbc и, возможно, использовать некоторый SQL-порядок по выражению, но я никогда не делал этого раньше, и я не хочу добавлять больше шагов по развертыванию в свое приложение.
4. Возможно, использование текстового файла - не самый лучший способ, может быть, есть лучшее решение этой проблемы, о котором я не знаю.

Это вопрос архитектуры / логистики, любая помощь будет признательна, спасибо

Answer 1

Если вы работаете на обычном компьютере класса ПК / Сервер, память для хранения 100 000 идентификаторов и связанных временных меток не считается большим объемом. Рассмотрите возможность использования отсортированного списка в памяти.

Если вы действительно хотите записать в файл, вы можете использовать File.ReadAllLines и перебирать полученный массив строк в обратном порядке.

Answer 2

Если это просто идентификаторы, вам обязательно нужно использовать файл?

Предположим, это 32-байтовые идентификаторы ... 100 000 из них по-прежнему составляют чуть более 3 МБ. Ты действительно так стремился к памяти?

Я бы определенно попытался начать с решения в памяти - убедитесь, что оно будет в порядке в наихудшем возможном случае (например, удвоить ожидаемый объем), но затем сделайте это.

Основная мораль не в том, чтобы слишком бояться цифр, которые кажутся большими: 100 000 предметов могут быть значительными с человеческой точки зрения, но если данных не достаточно много, это арахис для современного компьютера.

Answer 3

Вы можете попытаться сохранить информацию в комбинации DataSet / DataTable и использовать DataView, присоединенный к DataSet, для изменения порядка сортировки, когда вы получаете из него свои данные.

В зависимости от структуры XML, который вы получаете от веб-службы, вы можете прочитать его непосредственно в DataSet и разрешить ему анализировать его в DataTables для вас (если это сработает, я бы пошел на это для фактора простоты).

Этот метод будет включать наименьшее количество кода, но вам придется оценивать производительность DataSet с 100 000 элементов в нем.

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

У меня сложилось впечатление, что вы изначально собирались просто сохранить идентификаторы, отсортировать их, а затем повторно запросить веб-службу для каждого идентификатора в вашем отсортированном порядке, но это означало бы двойное обращение к службе для тех же данных. Я бы избежал этого, если это возможно.