Быстрое считывание произвольной части большого файла

mmap

«считать начиная со смещения» это не считать весь файл до смещения, это сразу перейти к смещению и начать считывать

Не будет mmap быстрее, чем read. Он не для скорости существует.

Я не очень умный, можно немного расширить ответ? Я предполагаю что считывание со смещением это двойная буферизация. Верно ли это?

mmap

А не является ли это той же самой двойной буферизацией?

Откуда инфа ? Раньше утверждалось обратное.

open + seek + read.

двойная буферизация

У вас какая-то каша в голове.

https://ru.wikipedia.org/wiki/Двойная_буферизация

Например от Торвальдса: http://lkml.iu.edu/hypermail/linux/kernel/0802.0/1496.html

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

open + seek + read.

Можно немного шире или ссылку?

open - открываем файл, seek - переходим к нужному смещению (мгновенно), read - читаем нужное количество байт. Всё.

man lseek

man 2 open

man 2 lseek

man 2 read

Спасибо, парни) Seek вроде то, что нужно.

А при чем тут базы данных?

Весь вопрос в том, сколько нам нужно прочитать.

Если меньше странички, то mmap невыгоден.

Польза от mmap проявляется на чтении нескольких страниц.

Но удобство и переносимость у read() лучше чем у mmap().

fseek

pread()

Весь вопрос в том, сколько нам нужно прочитать.

Если произвольное значение? Оно указано в файл-индексе.

Если это произвольное значение не превышает объема доступной физической памяти - то не проблема.

у mmap() есть неудобство - позиция в файле должна быть кратна размеру страницы памяти и размер региона тоже.

для х86 размер страницы 4к

А если размер N[0:6], то остальные 2 запишется нулями?

из-за 6 байт mmap() нет смысла городить.

Я образно. Тут важно чтобы смещение было именно произвольной длины, может и 6 килобайт, а может и 29.73 мегабайт. Размер страницы в чем измеряется (4к)?

Смещение произвольное, но кратное размеру страницы

Размер страницы определяется через getpagesize()

Если тебе нужно получить данные N[5000:9999], то грубо говоря нужно сделать

mmap(NULL,5904,PROT_READ,MAP_PRIVATE, fd, 4096) + 904

при условии, что страничка 4096 байт.

Если произвольное значение? Оно указано в файл-индексе.

На шпиндельных дисках seek() может быть не такой уж и быстрый. Физически seek-и бывают разные, короткие и длинные, в дальнее место диска. Вот здесь есть некоторые цифры https://en.wikipedia.org/wiki/Hard_disk_drive_performance_characteristics

Обычно операционная система делает так называемый read-ahead, т.е. предполагается что данные после позиционирования будут читаться линейно, можно немного прочитать лишнего и подержать в кэше. Это поведение настраивается.

Если файл не очень большой и нужно читать и писать короткие (меньше нескольких килобайт) данные в разные места, mmap()* с большой вероятностью будет эффективнее чем позиционироваться и читать вручную

UPD: * mmap() на весь файл, конечно

будет. следует из практики. от 10 до 25% быстрее при чтении больших объёмов данных на разных носителях. и особенно эффективно, если надо бегать по всему файлу и чтение часто попадает в некоторый регион, который можно весь держать в памяти. для мелких файлов его не применяют.

даже бенчмарк есть в интернетах: https://eklausmeier.wordpress.com/2016/02/03/performance-comparison-mmap-vers...

Ну, можно попробовать open+fadvise+read с одной стороны, и open+mmap+mad vise с другой. Практика показывает, что скорости примерно одинаковые, и понятно почему

можно немного расширить ответ?

из вашего вопроса я понял что вы думаете так: есть у нас файл размером 10 гигабайт, нам нужно считать 10 байт начиная со смещения 5 гигабайт и для этого нам сначала нужно прочитать 5 гигабайт, отбросить их и потом уже прочитать нужные нам 10 байт. так вот это не так. используйте seek или map и считывыйте 10 байт мгновенно с любого смещения. Под «мгновенно» имеется ввиду что скорость чтения никак не зависит от смещения.

Да, спасибо, я это уже понял из предыдущих комментариев форумчан) Осталось понять как строить такие же быстрые индексы к полям.

SQL?

Некую упрощенную версию, где отсутствуют все мощности sql в угоду скорости и сжатию.