DjangoBB LoFi version

Полная версия: Помогите с чтением файла python

Начало » Python для новичков » Помогите с чтением файла python

FLX

Апрель 1, 2017 14:34:51

Ребят, я создал некий список с md5 хэшами весом 9ГБ на каждой строке по 1 хэшу. Написал программу для поиска нужного мне хэша, но вот в чем проблема программа загружает файл по одной строке и сравнивает с тем что я дал и из-за этого как я думаю процесс проверки всего файла занимает 2 м 50с . Для меня это слишком медленно хотелось бы 30 сек-1минуты. Я подумал что если загружать файла частями и считывать среди них то будет быстрее. Вот код

 from __future__ import print_function
import io
import time
print('Give Me Your HashRound Please')
word = input()
with io.open('baseWD.txt', encoding='utf-8') as file:
    for line in file:
        if word in line:
            print(line, end='')
time.sleep(5)

Надеюсь на вашу помощь

JOHN_16

Апрель 1, 2017 18:31:01

FLX
использовать базу данных с индексом по хешу

FLX

Апрель 1, 2017 22:43:59

JOHN_16
FLXиспользовать базу данных с индексом по хешу

Ты имеешь ввиду в sql перегнать? Если да то подскажи как

JOHN_16

Апрель 1, 2017 23:13:44

ну раз 9Гб, то брать к примеру PostrgeSql и туда гнать. Как? ну материалов немерено. Написали этот код - напишите другой. Это настолько тривиально, что не составит труда

4kpt_V

Апрель 2, 2017 00:00:09

FLX
Да там реально не составит труда. Одномерная таблица, ведь. В новый postgresql привалило фишек по параллельной обработке, так что можно надеяться на “нехилый” прирост.

FLX

Апрель 2, 2017 01:02:19

4kpt_V
FLXДа там реально не составит труда. Одномерная таблица, ведь. В новый postgresql привалило фишек по параллельной обработке, так что можно надеяться на “нехилый” прирост.

А в коде надо будет менять что-либо кроме разрешения файла?

doza_and

Апрель 2, 2017 01:33:06

FLX
А в коде надо будет менять что-либо кроме разрешения файла?

Вы прикалываетесь? Ни одной строчки не совпадет. Будет три страницы полностью нового текста :)

Вы прикалываетесь? Три минуты на чтение 9 Гигов вам долго? Прикидываем, скорость очень хорошего винчестера 100 Мб в секунду у вас 10**11 Байт. Делим. Для вашего объема полное чтение никак не быстрее 15 минут На реальном железе в 2-3 раза дольше. И это без учета обработки питоном. Как у вас 2 минуты получилось?

Вы прикалываетесь? Если вам известен Хеш то зачем его вообще искать? Если там есть доп инфа то непонятно почему вы сделали так что Хеш встречается в произвольном месте строки (судя по оператору in).

Так что извините я похоже не очень въехал в постановку задачи, или вы нас успешно потролили первого апреля.

FLX

Апрель 2, 2017 09:54:37

doza_and

Я сгенерировал базу хэшей, каждый хэш в порядке возростания числа числа на новой строке например
1 –> c4ca4238a0b923820dcc509a6f75849b
2–>c81e728d9d4c2f636f067f89cc14862c
3–>eccbc87e4b5ce2fe28308fd9f2a7baf3
4–>a87ff679a2f3e71d9181a67b7542122c
5 –>e4da3b7fbbce2345d7772b0674a318d5
и так далее. Изначально я создавал базы такого типа ,но позже оказалось что мне числа не особо важны важно лишь то есть они в этом базе или нет. Я их убрал. Что касается скорости у меня 300000000 строк, на каждой строке 32 символа, весит 9ГБ, и программа считывает с первой по последнюю строку за время равное 2 минуты 50 секунд. Я видел приватные программы других людей с весами файлов еще больше,но у них находился хэш 2-3 секунды.

doza_and

Апрель 2, 2017 12:46:39

Да чет я ночью плохо делю.
Посмотрел сейчас. У меня на чтение получается порядка 82 Мб/c те на вашем файле около 110 секунд.
Это минимум что нужно для чтения всех ваших данных.

FLX
людей с весами файлов еще больше,но у них находился хэш 2-3 секунды.

Потому что алгоритм не такой дубовый как у вас.
Полезно прочитать про алгоритмы. Кнут Д. Искусство программирования. Том 1-3.
Думаю в вашем случае можно сделать проверку принадлежности где-то за пол секунды может даже и существенно лучше.

Ну например вы скромно хотите примерно удвоить быстродействие (1 минута вместо 3). Зачем вы файл до конца читаете когда нашли ХЭШ? поставьте break внутри if. При высокой вероятности принадлежности это удвоит скорость проверки.

ziro

Апрель 2, 2017 17:01:27

На Вашем месте я бы подумал об оптимизации вашей системы хранения данных. На мой взгляд тут главная проблема не скорость считывания файла с диска, а скорость поиска. Ее можно существенно ускорить, но необходимо переделать структуру данных.

Например, я бы поступил таким образом. Во-первых, в качестве хранилища данных выбрал бы не один файл, а каталог, например “basewd”

Во-вторых, если бы мне надо было бы сохранить хэш “c4ca4238a0b923820dcc509a6f75849b” из Вашего примера, то я бы

1. В каталоге хранилища создал папку “c4” (первый байт хэша), если она еще не существует.
2. Внутри этой папки создал текстовый файл “ca.txt” (второй байт хэша), если он не существует
3. В этот файл записал бы хэш “c4ca4238a0b923820dcc509a6f75849b” в том же виде как и было раньше.

В этом случае поиск по хранилищу конечно-же усложнится и станет двухэтапным. На первом этапе Вам нужно будет проверить существование файла “basewd/c4/ca.txt”. И, если он существует, то на втором этапе, внутри этого файла осуществить поиск так же как и раньше.

Но, и это главное, прямой поиск Вы будете осуществлять не на всем первоначальном массиве 300000000 записей, а только на выборке примерно в 300000000 /(255*255) ~= 4614 записей. Здесь в знаменателе количество возможных комбинаций подкаталогов и файлов (первый и второй байт хэша).

Ну это так, если не отказываться от текстового хранилища данных, а делать все по быстрому и не со зла.