Jack444

Здесь класс ClientRequest можно изучить подробнее.
Если в краце то с каждым запросом он генерирует новые заголовки для отправки через прокси, до талого исходники не изучал но уже выглядит что каждый запрос генерирует новое подключение. Хотя сам по себе aiohttp поддерживает keep-alive а это значит что при запросах на сервера поддерживающие HTTP/1.1 должно держатся подключение через прокси.

Первое что бросается в глаза так это то что сессия создаётся для каждого запроса, в итоге питон очень много времени затрачивает на инициализацию и подготовку подключений, сессиию надо создать в create_gather и после передовать в main.

aiohttp под капотом имеет лимит в 100 tcp подключений в пуле, если на сервере ресурсов хватает то конечно хотелось бы иметь возможность держать хотя-бы 500 подключений на один воркер, ещё aiohttp получая ответ приводит заголовки в CMultiDict, лично у меня на тестах он работал в 20 раз медленее чем стандартный словарь

Я бы заменил aiohttp на httpcore, httpcore это минимальный клиентский интерфейс который используется в другой популярной библиотеке httpx.
httpcore работает с байтами, заголовки с ответа элементарно сплитятся и возвращаются в виде списка кортежей, можно задать хоть 1000 подключений в пуле, настроить keep-alive и слать запросы по протоколу HTTP/2.0, результат в разы быстрее чем aiohttp.

Создав большое количество подключений + задач столько же или в разы больше то скрипт начнёт подвисать на обработке цикла событий, чтобы снизить издержки стоит установить uvloop, он работает под linux.

Вместо bs4 я бы использовал parsel, по скоростям не могу сказать, чисто вкусовщина.
Если учитывать что у вас там милион доменов и они все разные то скорее всего вам нужны какие-то общие данные в виде тегов meta/title/h1 то быстрее будет написать свою функцию для анализа html.

psycopg нужно заменить на asyncpg он очень быстро преобразует python типы в типы postgresql.
asyncpg позволяет создать пул подключений к базе а после создать воркеров в количестве созданных подключений, каждый воркер должен прослушивать asyncio.Queue, в очередь можно сразу закидывать аргументы для asyncpg.
Все данные желательно кэшировать локально в dict, в словаре хоть миллион хоть 100 миллионов ключей, доступ к ним по методу .get() отрабатывается за доли микросекунды но потребление оперативной будет не малой. Пришедший и распарсенный ответ чекаем в локальном кэше, если данные изменились то отправляем задачу в очередь на обновление, если нет такого ключа то аппем куда-то значения для одного запроса INSERT с множеством VALUES, для обработки INSERT отдельную задачу надо сделать чтобы чекать раз в несколько секунд VALUES и если они есть то генерить SQL и отправлять в очередь.

В какой документации вы находите чтобы делать подобный ход?

def group(message):
    global group
    ...
    group = 1

функция group тоже является объектом и туда можно закинуть дополнительные атрибуты а после к ним обращаться из других функций.
Как минимум правильно можно сделать так

@bot.message_handler(content_types=['text'])
def group(message):
    ...
    _group = 1
    group.groups[message.chat.id] = _group
    ...

group.groups = {}

bot.polling(none_stop=True)

И всё потом можно обращаться от куда угодна к функции group и её аттрибуту groups с id пользователя чтобы получить группу пользователя.

если не парится и делать в одну строку то так, но в иделе надо вынести в отдельную функцию и там дополнительно считать количество точек и их положение относительно цифр чтобы ошибка не вылетала при таких значения '.jhg87.9273.43likoj.'

x = lambda y: float(''.join([i for i in y if i.isdigit() or i == '.']))

print(x("ksrkfkkkedj 0.01 vkelrncksk"))
print(x('slkhjskljhksss342.921.khksjks'))
print(x('s,jhfskjyu932uio hi32n 89hnj3h287bn d98yn2.hiu3'))

ExecStart=/usr/bin/python3.7 -m uvicorn sql_app.main:app --host xx.xx.xxx --reload

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

Для начала добавь первичный ключ
Ser_Num = models.PositiveIntegerField(primary_key=True)
Затем выполни миграции, если вылетит ошибка, удали всё что в __migrations__ и удали эти таблицы из БД, по новой всё мигрируй.
Сейчас у тебя неявно id как примари в Engine идёт, поэтому связывается ForeignKey по другому полю

import psycopg2
E = lambda field: f'$myseckey${field}$myseckey$' if type(field) is str else field
with connection.cursor() as cursor:
        cursor.execute(
            f"""INSERT INTO data(photo_avatar,
                                 name,
                                 type,
                                 reach,
                                 engagemant_er,
                                 engage_percent)
                                 VALUES ({E(profile_name)}, 'N\A', {E(reach)}, {E(engagement)}, {E(engage_per));"""
            )
        
    connection.commit()

v=input('Введите слово/')
def input_words_english(v):
     with open('test.txt', '+') as file:
        exec(file.read())
        Spisok.append(v)
        file.seek(0)
        file.write(f'{Spisok=}')
        return Spisok

print(input_words_english(v))

Чтобы от SQL инъекции защитится в строчных полях достаточно заменить одиночные ковычки на две одиночные ковычки.
Например тебе в поле вписали DELETE * from Table1
Не обработано это полетит в базу как 'DELETE * from Table1' код не выполнится.
Но если отправить так Moskow'; DELETE * from Table1;
То сначала выполнится insert а после delete, в лучшем случае вылетит ошибка.
Но если принудительно одну ковычку реплейсить на две одиночные ковычки то этот весь запрос как строка запишется и нечего не произойдет

А зачем тебе __del__? Ищи в любом фреймворке события startup и shutdown, через них открывай и закрывай коннекты

Celery конечно удобно но по моему старомодно, если что современный python и django запущенный через ASGI будет работать в цикле событий и можно спокойно юзать стандартные инструменты asyncio вместо сторонних библиотек.