Sly32

И кстати, JOIN еще одной таблицы, например, если я хочу добавить еще  описание, хранящееся отдельно - не сильно увеличивает скорость

Результат выполнения такого кода 

    @timer
    def get_id(self, ipid):
        stmt = (
            select(BlockedID.ip_id, Description.url)
            .join(Description, Description.blocked_id == BlockedID.id, isouter=True)
            .where(BlockedID.ip_id == ipid))
        with Session() as session:

            print("="*120)
            print(stmt)
            result = session.execute(stmt).all()
            print("-" * 120)
            print(result)

что генерит запрос типа

========================================================================================================================
SELECT blocked_id.ip_id, description.url 
FROM blocked_id LEFT OUTER JOIN description ON description.blocked_id = blocked_id.id 
WHERE blocked_id.ip_id = :ip_id_1
------------------------------------------------------------------------------------------------------------------------
[('1234456', 'http://tut')]
Execution time: 0.006269931793212891

Для миллиона записей совсем некритично. Сам HTTP запрос будет занимать намного больше времени,  Получение результата - малая часть в процентном отношении ко всему времени. 

В итоге получаю очень простой код,  хорошую надежность, простой бэкап данных, чем в случае работы с файлами

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

Start script
Found file 40000 for checking ip 49342
Count of records: 433209
This ip(49342) was blocked for download
Execution time: 0.04430103302001953

Подытоживая, нашел время проверить поиск по аналогичной БД на этой же машине. Стэк - Postrgesql 14, проиндексированная таблица, коннект с помощью SQLAlchemy. Скорость поиска в таблице с 1100000 строковых записей длиной 30 символов:

Start finder
[(Id(id=1000201, ip='mIiVBR23U2dooVjRzmCn0eC8a4XMcg'),)]
Execution time: 0.0586090087890625
[(Id(id=5, ip='wHx0pgTK4kOoI9nc7dp9b9NV7uBqnn'),)]
Execution time: 0.004904031753540039
[]
Execution time: 0.004606962203979492

То есть в худшем случае результат сопоставим, в лучшем - на порядок быстрее при количестве записей в 2 раза большем 

Все-таки база побеждает) Да и кода там меньше получается.

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

DGPT заменит и  "вебмастера" и верстальщика.  Для пользователя пропадет  ненужный посредник в виде тебя.

Разбираюсь настолько, чтобы никогда не использовать такие поделки в работе. Для фронта мне достаточно работать с React/Bootstrap как минимум.  Хотя я давно занимаюсь немножко более интересными вещам, чем клепать сайтики под рекламку)

Ты уже попробовал? Можешь привести примеры "грязного" кода, в сравнении с тем что пишешь ты? С удовольствием бы посмотрел)

5 страниц обсуждений и никто не удосужился выяснить что это за система. А это не про сверстать сайтик. Ну понятно, откуда тут 16 баксов на посмотреть, когда мечта - найти хостинг за доллар)))

Именно поэтому я в названии написал "вебмастер" - в кавычках))) И они стройными рядами побежали отмечаться в теме и доказывать... а непонятно что даже. Не попытавшись даже понять, про что этот новый продукт)

Ты забыл еще что-нибудь про джуна вкренчить

Ваше право. В любом случае, спасибо за интересную дискуссию и что пошарили свой опыт. Лично мне было интересно и полезно. 

Еще раз - это ВООБЩЕ не оптимальное решение! цль была - примерно оценить скорость чтения записи в сравнении с БД.  И даже в таком варианте я признаю, что это сопоставимо. Если грамотно организовасть файловую систему, оптимизировать запись и чтение - это может быть быстрее, чем использовать БД. По крайней мере на небольших обьемах и сопоставимо по потреблению памяти.  Так понятнее? Не в рамках вопроса пытаться написать оптимальный скрипт на базе кода который я привел - он не для этого был написан.

Я могу затереть занные в файле, могу многократно писать одно и тоже, могу удалить случайно файл, могу записать в него недопустимые символы и он перестанет читаться.... Все это нужно предусматривать. А при работе с SQL все это уже есть

Влияет. все то что я написал выше. Например достаточно тип поля сделать уникальным и я избавляюсь от необходимости каждый раз проверять, есть ли такой айди в таблице. Добавление в CONSTRAIN ONDELETE Cascade - упростит мне очистку базу от ненужных данных. То есть вся та работа, которяа должна будет сделана при работе с файлами при работе с БД УЖЕ реализована. Да банальный бэкап обычно есть на любом хостинге. Наверное, давно не работал но сомневаюсь, что я ошибаюсь. 
Так что никакой гипотетичности. Все это пройдено собственными граблями на проектах с месячными бюджетами за который этот форум можно купить десяток раз. Поэтому я так критически отношусь к идее работы с файлами  в данном случае. 

Ну почитайте весь тредможет и не нужен будет мой ответ? Вкратце - стало интересно проверить, наклепал - убедился что со временем поиска больших проблем не будет. Понятно, что это только как студенческая лаба, такое решение никогда в жизни в прод не пойдет. Чисто сравнить скорость.