Ctrl →

Iskatel · Дек. 16, 2016 21:53:01

В гугле меня похоже забанили, ничего кроме “нужна 64” не нашел.

сделал так, вроде работает:

 def fead_for_re(fl, bufsize, over):
    last =0
    while 1:
        if fl.tell() and not last:
            fl.seek(-over, 1)
        data = fl.read(bufsize + over)
        if len(data) < bufsize + over:
            last = 1
        if not data:
            break
        yield data

использую так:

 with open(os.path.join(path, pt),'rb') as f:
            for chunk in fead_for_re(f, 1024 * 1024, 1024):
                res = proc.findall(chunk)
                for r in res:
                ...

Смысл в том что файл читается на длину “находки” вперед, а потом отматывается назад, и читается снова.
В данном случае я понимаю максимальную длину, того что может найтись.

Но чтото меня в этой логике не устраивает, незнаю что, но такое ощущение, что гдето ошибся…
Поругайте, плиз.

py.user.next · Дек. 17, 2016 02:32:59

Что пытаешься сделать? Опиши задачу.

Iskatel · Дек. 17, 2016 20:51:17

py.user.next
Так то и пытаюсь, в файлах, размером в несколько ГБ найти чтото регекспом.

Пардон, не написал что

 proc = re.compile

Так как файл такого размера невозможно считать, или смапить на 32 системе, то читаю кусками и в них ищу.

А т.к. искомое может находится на стыке кусков, то читаю чуть больше,с запасом, а потом читаю снова, сместясь на этот “запас” назад.

Знаю что искомое не превышает 300 байт.

Все вроде сходится, но паранойя мне подсказывает, что гдето в этом алгоритме ошибка, и не все желаемое так найдется…

ЗЫ. что удивительно: когда изменил размер куска с мегабайта на 32 Мб, то процесс шел медленней.

FishHook · Дек. 17, 2016 20:56:54

Iskatel
Может стоить grep заюзать да и не выдумывать?

Iskatel · Дек. 17, 2016 21:02:01

FishHook

Это часть проги, странно бы было ее разбиваь на куски с заюзыванием некоторых прог, которых в стандартной поставке даже нет…

FishHook · Дек. 17, 2016 21:11:52

Iskatel
не менее странно вкорячивать в программу какие-то наколенные изыскания, когда в любой современной ОС есть встроенные средства поиска оптимизированные до неприличия. Ваша программа, она же не в информационном вакууме будет запускаться, а в некотором окружении. В этом окружении уже давно всё решено и вы лучше не решите точно, даже приблизительно так не решите.

Iskatel · Дек. 17, 2016 23:23:47

FishHook

Есть преложения для винды?

Ну кроме того что “на линуксах пробовал, на макоси не пробовал, а винду хз”

JOHN_16 · Дек. 18, 2016 00:03:46

Вообще есть возможность устанавливать GNU программы в Винде. CygWin, MinGW или еще вот GnuWin32. Где то на форуме кто то уже упоминал о подобных рабочих связках

_________________________________________________________________________________
полезный блог о python john16blog.blogspot.com

py.user.next · Дек. 18, 2016 01:23:02

Iskatel
Пардон, не написал что

Да это понятно из наличия метода .findall().

Iskatel
Так как файл такого размера невозможно считать, или смапить на 32 системе, то читаю кусками и в них ищу.

Так и надо делать, какого бы размера он ни был. Загружать всё в память - последнее дело, потому что сегодня там маленький файл, а завтра большой окажется. А программа должна быть применима к файлам любого размера, в идеале - к бесконечным (так обычно и делают программы вроде той же grep или sed).

Iskatel
А т.к. искомое может находится на стыке кусков, то читаю чуть больше,с запасом, а потом читаю снова, сместясь на этот “запас” назад.

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

[guest@localhost site_18-Feb-2015]$ sqlite3 test.sqlite -line 'select * from ccpview where prof like "%програ%" limit 1'
     prof = Оператор ПК, программист, системный администратор
       id = 37884
  created = 19.01.2015
  updated = 16.02.2015
    views = 61
      age = 30 лет
   gender = мужской
   family = холост
    exper = не указан
   salary = от 26000 р. 
 worktime = не указан
 edugrade = высшее
     city = Южно-Сахалинск
  eduname = 2010-2013 - закончил Закарпатский государственный университет. Программная инженерия.
Форма обучения: заочно.
 workprev = 2005-2013 - Полиграфия ТОВ "Спектраль", монтажист-копировщик.
2013-2014 - "Интерфил", рабочий на складе.
2014 - настоящее время - Типография "Капитал", помощник печатника.
qualities = Знание пользование ПК: выше среднего.
Имеются знания в сфере полиграфии.
Занимаюсь самообучением: html, css, тестирование ПО, английский.
Личные качества: спокойный, пунктуальный, порядочный, целеустремлённый.
     id:1 = 37884
     name = фамилия Алексей Сергеевич
    phone = +798418цифры
    email = alexимя@gmail.com
     id:2 = 37884
   number = 0
[guest@localhost site_18-Feb-2015]$ sqlite3 test.sqlite -line 'select count(*) from ccpview where prof like "%програ%"'
count(*) = 72
[guest@localhost site_18-Feb-2015]$ sqlite3 test.sqlite -line 'select count(*) from ccpview'
count(*) = 17239
[guest@localhost site_18-Feb-2015]$
[guest@localhost site_18-Feb-2015]$ ll test.sqlite 
-rw-r--r--. 1 guest guest 29156352 апр 26  2015 test.sqlite
[guest@localhost site_18-Feb-2015]$

И вот этот сайт я обрабатывал где-то шесть часов без перерыва, можешь себе представить сколько там данных прошло через программу, пока она в них искала все поля и сохраняла в csv (который я потом перегонял в sqlite). Записей всего 17239 получилось, база - 30 метров. Каждая страница должна была скачаться целиком и просмотреться на наличие полей по их регекспам. Естественно, в памяти всё это не разместишь, её просто не хватит на десятки тысяч полных страниц сайта одновременно.

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

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

Иначе ты либо не будешь находить то, что должно быть найдено (логическая ошибка в поиске); либо ты будешь находить, но для этого придётся делать эту глупость с поиском по всему потоку символов, которая по времени очень затратна, и ты просто не дождёшься результата; либо у тебя просто возникнет файл, который не поместится в памяти, и программа просто откажет при размещении его в памяти для поиска. А ещё смешнее будет, когда у тебя получатся все эти вещи одновременно.

Отредактировано py.user.next (Дек. 18, 2016 12:59:44)

FishHook · Дек. 18, 2016 07:46:02

Iskatel
Есть преложения для винды?

Даааавно уже есть

Python-сообщество

Уведомления

#1 Дек. 16, 2016 21:53:01

Поиск в больших файлах на 32 системе

#2 Дек. 17, 2016 02:32:59

Поиск в больших файлах на 32 системе

#3 Дек. 17, 2016 20:51:17

Поиск в больших файлах на 32 системе

#4 Дек. 17, 2016 20:56:54

Поиск в больших файлах на 32 системе

#5 Дек. 17, 2016 21:02:01

Поиск в больших файлах на 32 системе

#6 Дек. 17, 2016 21:11:52

Поиск в больших файлах на 32 системе

#7 Дек. 17, 2016 23:23:47

Поиск в больших файлах на 32 системе

#8 Дек. 18, 2016 00:03:46

Поиск в больших файлах на 32 системе

#9 Дек. 18, 2016 01:23:02

Поиск в больших файлах на 32 системе

#10 Дек. 18, 2016 07:46:02

Поиск в больших файлах на 32 системе

Board footer