Реализация быстрой проверки строки из файла в несколько гб

Гм… А дальше что было я не совсем понял…

Дальше уже вариант переиграть остывшую вселенную, на случай если у ТСа запущенная стадия паранойи.

:)

что бы без большой нагрузки проверять

Без большой нагрузки на что?

Хранение файла в памяти разгрузит ввод-вывод, например.

да

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

уверен что сразу?

уверен что сразу?

заранее считать имел ввиду, ТС не сказал сколько памяти свободно, а 2ГБ это уже мало, пусть считает, нам его память не жалко

да ты оцензурел! 2 гб ради одного файла это очень много

На свете нет ничего быстрее, чем загрузить эти 2Гб в память (не так уж сложно по нынешным временам) и искать там вначале первую букву строки потом всю строку сравнивать.

2 гб ради одного файла это очень много

ТС не сказал - много это ему или мало, быстрее не будет чем из памяти считать

а вот еще один оптимизатор подьехал

а вот еще один оптимизатор подьехал

Дык. Всегда полезно иметь алгоритм самый быстрый из возможных под рукой, пусть для только тестов и сравнения.

начни думать о том, что в 2гб текста (под)стрОки врядли уникальны

начни думать о том, что в 2гб текста (под)стрОки врядли уникальны

не совсем понял мысль

ТС нужно найти в большой строке «2ГБ» малую строку «100 байт» каким то методом типа find() ?
и так 100 раз в секунду ?

Зачем классические бд? Elk и Splunk же прекрасно с этим справятся. Ещё алерты и репорты выдадут.

1. https://docs.python.org/3/library/stdtypes.html#dict Но сожрет много памяти.

2. https://stackoverflow.com/questions/1731971/is-there-a-multimap-implementation-in-python с хешами строк в качестве ключей.

3. sqlite. Но сожрет много памяти.

4. libfpta со вторичным unorderd индексом без ограничений уникальности. Это раз в 5-10 раз быстрее sqlite, но opensource байдингов для питона нет.

5. поставить рядом tarantool.

6. поставить рядом elasticsearch, но прицеп jvm-говна будет больше чем БД.

7. на скриптах, пользовать test --hash-stdin-strings из t1ha и grep.

+еще 33 способа

@foozzi, расскажи чем закончилось.

лучше будет его спарсить

python3

взаимоисключающие параграфы

А потом ТС наконец понял, что он не понял о чём спрашивал.

Читай, оптимизатор)

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B8%D1%81%D0%BA_%D0%BF%D0%BE%D0%B4%D1%81%D1%82%D1%80%D0%BE%D0%BA%D0%B8

Да причём тут это. ТС сказал: файл не будет меняться. Зачем что либо нужно для сканирования более одного раза?

я устал от твоего поноса, перечитай что я писал,а не высирай рандомные предложения.

Я сказал что файл не меняется, но строки генерируются по 20 штук в секунду каждую из которых нужно проверить на существование в файле.

Просто не пытайся что либо ответить, от твоих ответов абсолютно 0 толку

Научись спрашивать в начале и не груби пожалуйста.

Если бы ты умел хорошо предоставлять свою мысль - тебе уже ответили ещё вчера.

Поработай над собой.

И да я тебе уж ответил что БД тебе в помощь.

Успехов тебе в познании как нужно хорошо спрашивать.

Хорошо заданный вопрос - 50% ответа.

Я сказал что файл не меняется, но строки генерируются по 20 штук в секунду каждую из которых нужно проверить на существование в файле.

Это шедевр.

Так все-таки нужна strstr() на питоне или поиск целой строки в файле с разделителями?

А какая в хер разница? Вы все ему в память предлагаете грузить. Сегодня у него этих данных 2 гб, завтра 2тб.

ТС не понимает отличие изменения имени файла от изменения файла.

А дальше вопрос пока не думаю, что нужно ставить сложнее. ТС и так уже запутался.

Так все-таки нужна strstr() на питоне или поиск целой строки в файле с разделителями?

А какая в хер разница? Вы все ему в память предлагаете грузить. Сегодня у него этих данных 2 гб, завтра 2тб.

Разница примерно такая-же как между N и N*N.

Если переформулировать в LOR-терминах, то разница как между жопой и пальцем.

для начала, ты это расписывал три сообщения и так что хер поймёшь.

Сделай для этого файла индекс(хеши строк в какое-нибудь подходящее дерево) и держи его в памяти. поиск быстрый, io не будет, а поскольку файл не меняется, перестраивать индекс можно только на старте, а то и вообще сериализовать рядом, по ситуации.

Вместо того чтобы внятно расписать сразу, хернёй страдаешь.

строки генерируются по 20 штук в секунду каждую из которых нужно проверить на существование в файле

Это не цель, а средство. Ответил бы нормально и рассказал какую задачу решаешь, в чём проблема? Ведя себя как отбитый аутист ты ничего не добьёшься.

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

Да не нужен ему ни файл, ни индекс скорее всего. Готов поставить, что это не более чем порождение больной фантазии и быдлокодерской смекалки. Ну не может такая странная вещь оказаться чем-то полезным, когда её пилит человек, не способный даже задачу сформулировать.

Идём лучше запилим БД на Ардуино для русских шашек, где никто выиграть не сможет.

ТС уже задолбал своей невразумительностью.

Я про шашки серьёзно.

Давай зафигачим!

Ну типа просто как чтобы забава помимо суеты. М?

Так ведь интересно в чём соль была. Заинтриговал и молчит.

Работы так дофига, что я в качалке уже полгода не был. Не хватало мне ещё в отающееся время кодить, я лучше подегродствую.

Реально, только осознал, что скоро полгода уже, благо хоть вес держится, пора возобновлять.

Да он просто пока не понимает что и чего хочет.

Наверняка молодой ишшо. Спе….коз стрельнул в голову, а как с этим справляться пока не понял.

Хз на счёт молодого, он на лоре в 2011 зарегистрировался, лет 20 уж всяко должно быть.

я с 2008 - мне уже 100 должно быть? :)

Идём лучше запилим БД на Ардуино для русских шашек

Ардуино - ок.

Шашки - ок.

Но зачем там БД?

Заинтриговал )

Под тридцатник-то как минимум.

Зачем там ардуино, когда на ESP можно сразу север поднять

Ну обычный перебор и так в моих древних шашках под DOS рубит людей как мясо…

Я вот недавно проанализировал, что можно сделать даже на Arduino Mega полностью не проигрывающие шашки. Признаюсь, что полный анализ не провёл, но по прикидкам 200 килобайт вроде хватит на не полную но без проигрышную базу партий.

Так и подумал. А сколько всего в шашках комбинаций?

Если полный тупой перебор - петабайты.

Но это если по тупому. А так в принципе несколько сот партий по несколько десятков ходов в каждой.

В принципе шахматы не далеко ушли от этого.

Я так с заказчиками общаюсь, не привыкать

Ему прилетают строки и он проверяет их наличие в файле, вместо того, чтобы взять бд и делать по-человечески. Как вариант если ему БД ни на фиг не сдалась, я предложил брать от строк хеши и хранить только их, соответственно и сверяться только с ними, благо они меньше строк произвольной длинны.

Да не парся. ТС так и не написал сути задачи.

grep уже предлагали?

Вообще эти игры сложны только для людей.

У нас мозги совсем никакие по сравнению с гигабайтами и гигагерцами тысячь процессоров у современных мобилок.

В принципе, все игры придуманные людьми в древности типа шахмат, шашек и Го, а тем более карточные - люди даже рядом не валяются с тем как могут их уделать компы.

Иногда просто плохо написаны алгоритмы (по себе знаю).