Непоследовательный доступ к массиву данных.

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

Вам же, если у вас измерения имеют разную длину, можно хранить отдельно смещение и номер.

Такое решение первым пришло в голову. Но надеялся, что есть способ проще (считать, что есть готовая реализция. :) ).

> Но надеялся, что есть способ проще

Berkeley DB, например.

SQL + кэширующая прослойка. Или BerkleyDB, оно само умеет кэшировать записи.

mmap?

Есть и называется системный swap. Быстрее получить доступ будет сложно, не зря его уже доооолго пилят.

Вам же говорят: памяти мало, mmap'ить не получится. Хотя, например, файл кэша, если его размеры будут небольшими, можно и mmap'нуть.

man mmap: mmap() creates a new mapping in the VIRTUAL!!! address space of the calling process.

Мало физической, а виртуальной можно сделать сколько угодно. Делайте свап на 3 ГБ и пользуйтесь.

>Делайте свап на 3 ГБ и пользуйтесь.

Своп здесь не нужен

Кто лучше кеширует, чем ОС?

тут mmap надо делать

получится

mmap можно спокойно заюзать.

попробуй еще posix_fadvise