py.user.nextКстати чтение файла частями и поиск границы запрашиваемого периода в сырых данных занимает меньше времени. Т.к. я могу по одной записи понять, есть ли в этих 8 Кб нужные мне события и откинуть весь кусок, если он мне не подходит.
Это и замедляет скорость, и даёт неточность, и усложняет код через усложнение алгоритма анализа. Не надо искать в файлах. Это сырые данные. Надо их привести к очищенным данным и искать в очищенных то, что нужно найти.
doza_andСпасибо, почитаю на досуге
Для логов нужны не совсем базы данных. Это даже скорее не базы данных.
SergeyChmutovЯ про это и говорю. Если ты откинешь весь кусок, да даже если не откинешь, то у него в конце может оказатся день из даты. При этом месяц из этой же даты будет в следующем куске. Так ты пропустишь одну запись, которая может вполне подходить под критерий нужной, и даже не узнаешь об этом. Поэтому-то и нужно сначала гарантировать получение целостных записей, а уже потом с целостными записями работать. И вот для этого нужен уровень преобразования сырых данных с поблочным чтением в последовательность точно отделённых друг от друга записей.
Т.к. я могу по одной записи понять, есть ли в этих 8 Кб нужные мне события и откинуть весь кусок, если он мне не подходит.
py.user.nextНу я просто не до конца описывал логику работы. Там да, я вычитываю часть файла, с конца беру целую строку, высчитываю длинну “битой” строки. И потомделаю смещение с учетом битой строки
Я про это и говорю. Если ты откинешь весь кусок, да даже если не откинешь, то у него в конце может оказатся день из даты. При этом месяц из этой же даты будет в следующем куске. Так ты пропустишь одну запись, которая может вполне подходить под критерий нужной, и даже не узнаешь об этом. Поэтому-то и нужно сначала гарантировать получение целостных записей, а уже потом с целостными записями работать. И вот для этого нужен уровень преобразования сырых данных с поблочным чтением в последовательность точно отделённых друг от друга записей.