У меня следующая проблемная ситуация. Куча данных разбита на 10 тыс. Небольших файлов (около 8-16 кб каждый). В зависимости от пользовательского ввода, я должен загрузить их как можно быстрее и обработать их. Точнее, каждый пакет данных может быть разбит на 100-100 тыс. Файлов, и существует приблизительно 1 тыс. Пакетов данных. Хотя большинство из них поменьше.
Сейчас я использую пул потоков, и при каждом доступе к файлу следующий свободный поток открывает файл, читает его и возвращает данные, подготовленные для отображения. Поскольку в будущем число файлов будет расти, я не очень доволен этим подходом, особенно если он может в конечном итоге получить что-то около 100 тыс. Или более файлов (развертывание этого будет, безусловно, забавным;)).
Итак, идея состоит в том, чтобы объединить все эти крошечные файлы для одного пакета данных в один большой и прочитать из него. Я могу гарантировать, что он будет только для чтения, но я не знаю количество потоков, которые будут одновременно обращаться к одному файлу (я знаю максимальное количество). Это дало бы мне около 1000 файлов хорошего размера, и я могу легко добавлять новые пакеты данных.
Вопрос заключается в следующем: как можно разрешить потокам 1..N эффективно читать из одного файла в этом сценарии? Я могу использовать асинхронный ввод-вывод в Windows, но он должен стать синхронным для операций чтения менее 64 КБ. Отображение памяти в файле не вариант, так как ожидаемый размер составляет> 1,6 ГБ, и мне все еще нужно иметь возможность работать на x86 (если я не могу эффективно отобразить какую-то крошечную часть, прочитать ее, снова отобразить ее - мой опыт работы с отображение памяти состояло в том, что оно приносит довольно много накладных расходов по сравнению с одним чтением).
Я думал об открытии каждого из пакетов данных N раз и предоставляю каждому потоку дескриптор циклическим образом, но проблема в том, что он может в конечном итоге иметь (количество файлов данных) x (максимальное количество потоков) ) открытые дескрипторы (может легко стать 8-16k), и мне пришлось бы синхронизироваться при каждом доступе к пакету данных или использовать магию без блокировки, чтобы получить следующий бесплатный дескриптор файла.
Поскольку это не кажется оригинальной проблемой (я полагаю, что любой движок базы данных имеет подобную, где вы можете иметь M таблиц (пакетов данных) с N строками (файлы в моем случае), и вы хотите разрешить как можно больше потоков для одновременного чтения строк). Так какова рекомендуемая практика здесь? Кстати, он должен работать в Windows и Linux, поэтому приветствуются переносимые подходы (или, по крайней мере, подходы, которые работают на обеих платформах, даже если они используют разные базовые API - до тех пор, пока они могут быть упакованы, я счастлив).
[ РЕДАКТИРОВАТЬ ] Дело не в скорости, а в сокрытии задержки. То есть я читаю около 100 таких крошечных файлов в секунду, может быть, я не больше 1 Мбит / с. Моя главная проблема - время поиска (поскольку моя схема доступа не предсказуема), и я хочу скрыть их, запуская показания при отображении старых данных пользователю. Вопрос в том, как разрешить нескольким потокам отправлять запросы ввода-вывода для нескольких файлов, возможно,> 1 поток обращается к одному файлу.
Это действительно не проблема, если один из вызовов занимает около 70 мс или около того, чтобы завершить, но я не могу себе позволить, если вызов вызова чтения блокируется.