Viktor T2

Лучше из бинарника ставить.
Всегда самая свежая версия!

wget https://telegram.org/dl/desktop/linux -O /tmp/telega.tar.xz; sudo tar -xpf /tmp/telega.tar.xz -C /opt; sudo ln -s /opt/Telegram/Telegram /usr/local/bin/telegram-desktop; sudo chown -R $USER:$USER /opt/Telegram; telegram-desktop & exit

snap - отстой!

• Если ожидается большой проект с высокой посещаемостью и долгой поддержкой то у aiogram нет альтернативы. У них беда с документацией, но есть чат в TG где всегда подскажут. Там можно пообщаться и с разработчиком данной библиотеки.
  
• Если это что-то простое на десяток хэндлеров и лень долго разбираться то у python-telegram-bot очень подробные wiki, документация, снипеты. Можно без опыта очень быстро разобраться... в асинхронность тоже умеет простым декоратором @run_async, можно даже запустить serverless на какой нить azure/google/aws/yandex functions с бесплатным лимитом в 1000000(azure) обращений за месяц
  
• Если ограничения bot api слишком тесные и вы хотите делать то что может только клиент (например выгружать файлы больше 40Мб), то посмотрите в сторону telethon (тоже async) плюс он общается с серверам телеграма не через request-respons, а по протоколу MTProto. В частности можете посмотреть на Garnet — bot-friendly telethon
  

Поиск тут сильно так себе, так что искать лучше через гугл. Лично я использую запрос следующего вида:

site:qna.habr.com <имя-пользователя> <тег> <чего ищем>

Отобрать вопросы/ответы - подписываетесь на интересующие вас теги, заходите в профиль, раздел "подписки", подраздел "теги", появится список тегов - рядом с каждым будут ссылки на списки соответствующих вопросов и ответов (конечно, если таковые у вас есть). Но, разумеется, можно и напрямую пройти, если знать, как нужный url выглядит. Вот ваш laravel, например.

Если человек ничего не понимает в какой-то теме, он никогда не должен выступать с заявлениями вида "у меня возникла потребность". Потому что такие заявления базируются не на реальных потребностях, а на неграмотности, фантазиях и путанице в голове. И получаются вопросы вида "У меня возникла потребность забивать гвозди микроскопом. Я обыскал весь интернет но ничего понятного не нашел, только понял то что это делается на кухне. "

Вместо таких заявлений он должен подробно изложить исходную задачу.
Про которую ему подробно расскажут, как её решать нормально.

Хранить фото и видео в БД - это как надевать штаны на голову.
Хранить фото и видео в монге - как надевать на голову помойное ведро.

Файлы надо хранить в файловой системе.
Структурированные данные надо хранить в Базе Данных.
Монгу не нужно использовать ни для чего. Это вообще не база данных, а просто хранилище по типу "куча мусора", которое используется исключительно в стильных модных молодёжных стартупах, в которых не нашлось ни одного специалиста по базам данных. Это была тупиковая ветвь, поднявшаяся на отсутствовавшей на тот момент поддержке JSON в базах данных и хайпе

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

1. Случайный и многопоточный доступ - принципиальная необходимость задумываться об этом исходит из физической особенности накопителей, последовательный доступ от случайного (имеется в виду как у hdd так и у ssd (в меньшей степени, зависит от размера читаемого блока кластера, потребительскиее ssd это 256кб) значительно отличаются (на порядок или даже два) по времени. Аппаратные контроллеры на материнской плате и даже на диске (или драйвера и планировщик ос) могут физически считывать данных больше чем потребуется (read ahead), делая это фоном, после запроса и сохраняя в своей памяти.
Если несколько приложений одновременно потребуют данные с разных областей устройства хранения, специальный планировщик ос может приостанавливать работу этих приложений, собирая как можно больше запросов на данные, сортируя их для оптимальной их обработки. Пользовательское приложение может делать это значительно эффективнее, если заранее озаботится о том, как именно данные будут храниться на диске (обычно речь идет о хранении данных минуя файловую систему).

2. Кеширование чтения - в подавляющем большинстве случаев хватает функционала операционной системы, операционные системы используют разные стратегии (fifo или к примеру на основе частоты запросов), системные вызовы ОС позволяют управлять стратегией кеширования, в т.ч. полное ее отключение (это может быть недоступно для некоторых файловых систем, например fuse в linux, если об этом не позаботился их разработчик), с целью перенести логику выбора кеширования данных в приложение.

3. Кеширование (буферизирование) записи - приложение может управлять, стоит ли ждать окончания физической записи данных на диск или это можно сделать фоном или даже отложить на потом. Например fflush позволяет принудительно сбросить буфера при использовании fwrite (и других от stdlib), более низкоуровневые вызовы позволяют точнее управлять процессом. Помимо инструментов управления кешированием на уровне приложения есть способы настроить это на уровне ОС (например ext4 позволяет настроить стратегию записи data=writeback, это делает файловую систему уязвимой к сбоям но значительно ускоряет запись, так как даже fflush из приложения не будет ждать окончательной записи), так же разные сетевые файловые системы могут накладывать дополнительные ограничения (точно помню что nfs обрабатывает fwrite по другому в отличии от локальных записей, делая больше лишних действий на диске)

p.s. про mmap, меанизмы ОС (как linux так и windows) позволяет вместо работы с файлом по кусочкам (fopen/fread/fwrite/...) 'замапить' указанный файл или даже раздел/диск на область памяти, при доступе к которой прозрачно будут совершаться чтения и записи на диск. Этот способ работы с файлами зачастую самый производительный (кстати по умолчанию используются на исполняемый файл приложения и .dll/.so) и очень часто еще и удобнее, так как кеширование данных будет произведено средствами ос, и при повторном запуске приложения данные уже будут в памяти (при обычном fopen их пришлось бы считывать в память, т.е. копировать что дает 2x накладные расходы на процессор).

-------------

4. Файловые системы это уровень абстракций ОС, значительно добавляет накладные расходы на работу с данными но за счет удобства (например возможность расширить хранилище без полного копирования данных, просто увеличив размер раздела или добавив новый накопитель, как это позволяют файловые системы - комбаины типа btrfs/zfs), разные файловые системы организуют хранение по разному, что значительно влияет на скорость как записи так и чтения.
Например cow файловые системы (xfs/zfs/btrfs) каждое последующую запись делают последовательно, даже если записываемые чанки/кластеры принадлежат разным файлам, даже если это модификация а не добавление в конец, что благосклонно сказывается на скорость записи но отвратительно фрагментирует размещение файлов на диске (там есть механизмы борьбы с этим), т.е. для хранилище файлов разного размера, считываемых/изменяемых целиком такие файловые системы идеальны, но для баз данных наоборот очень неэффективны (в таких фс можно принудительно отключить cow для определенных файлов). btrfs/zfs за эти накладные расходы (незначительные) дают бонусом функционал быстрых снапшотов (почитай про btrfs snapshot incremental backup) и высокую устойчивость к сбоям.
Еще пример, файловые системы, с целью защитить данные от сбоев, добавили к функционалу понятие журнал, промежуточное место, куда записываются данные (метаданные) до тех пор пока приложение не зафиксирует изменения (закрытие файла или fflush), в нормальных ОС существует возможность разместить этот журнал на отдельном, более быстром, накопителе (например ext3/ext4) или отключить полностью. Это позволяет заметно ускорить запись и не покупать на весь объем данных быстрый и дорогой накопитель.
Было время, когда можно было буквально (кажется у xfs но я могу ошибаться) указать разные накопители для метаданных (информация о том как файл размещен на диске и информация о атрибутах файлов) и самих данных, что тоже в условиях значительного отличия скорости работы емких hdd и быстрых но не емких ssd, сэкономить на построении хранилища.

5. Сжатие данных на лету - некоторые файловые системы позволяют прозрачно для приложений пропускать данные через библиотеку сжатия (в пределах кластера или даже нескольких соседних), например ntfs использует compress, а btrfs позволяет выбирать, например zstd (один из лучших по соотношений скорость/сжатие), было время когда включение сжатия на медленных накопителях давала двух-трех кратное ускорение скорости чтения практически бесплатно (а запись почти не замедлялась но повышалась нагрузка на процессор), на современных же накопителях процессор может не поспевать (но есть дорогие контроллеры с таким функционалом).
Еще есть тип сжатия - sparse files (дырявые файлы), части файла, в которые не производилась запись, физически не занимают место (фактически тратится место только крохотная часть в области метаданных файловой системы), при чтении таких частей будут возвращены нули, так же есть функции по замене ранее записанных частей файла на такие дырки. Такие файлы могут понадобиться, например, когда нужно хранить огромные разряженные матрицы с индексацией по позиции, индекс тут будет использоваться от файловой системы но выигрыш по производительности сомнителен и требует измерений под ваши данные.

p.s. любая сторонняя библиотека, добавляющая еще один уровень абстракции к хранилищу, может дать выигрыш только если стратегия работы с данными совпадает с той, на что заточена эта библиотека. Например реляционные базы данных дают готовый и обширный функционал по индексированию данных, многопользовательских транзакций но за счет больших накладных расходов на их поддержание. Помню был тут вопрос про хранение терабайтов данных числовой ключ -> крохотное значение (несколько байтов хеш), так вот майкрософтовская sql уже с миллионами записей могла до секунды на запись диском шерстить (тысячи iops), когда как самодельный и примитивный велосипед с одноуровневым индексом по хешу от значения мог дать скорость доступа и записи 1к1 iops накопителя (от 1 вызов к диску на запрос чтения и от 2 - на запись).

вообще - Эластик не стоит использовать никогда, но такая роскошь недешева

дело в том что "других систем" особо не существует, их ровно одна: Sphinxsearch и ее отдельная ветка - Manticoresearch ( ее вот и стоит на сегодня),
они сильно лучше Эластика по техническим параметрам: там где на Эластик уходит ~10к на кластер Амазона, Сфинксы обходятся 1-2к сервером ( вообще 1, но приходится все же побольше SSD ставить)

но!

почему-то ж Вы когда-то выбрали Эластик?
да, именно поэтому:

• есть мануалы
  
• есть API (в сфинксе наверно и сейчас нет, в Мантикоре есть - учли это)
  
• есть "кто-то кто уже работал"
  
• есть плагины, надстройки, аддоны
  

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

это , в общем-то, и много чего в project mamagement касается

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

Вариант 2. error_message = error_message.replace(r'\n', '\n')

Ты уверен что ты понимаешь что такое объект Figure в matplotlib? Это канва, на которой ты размещаешь axes (оси координат и уже на этих осях ты непосредственно рисуешь графики). Прямого api что бы засунуть sympy plot на matplolib figure, не существует. Потому что это не оси с графиками а своя ФИГУРА с осями и на них графиками.

Можно ли это обойти, да конечно можно создать урода и присобачить на figure sympy plot.

import matplotlib.pyplot as plt
import numpy as np
from sympy import Symbol
from sympy.plotting import plot
x = Symbol('x')
X = np.linspace(-3,3,100)
y = np.cos(X)
def add_plot(p, ax):
    backend = p.backend(p)
    backend.ax = ax
    
    backend._process_series(backend.parent._series, ax, backend.parent)
    backend.ax.spines['right'].set_color('none')
    backend.ax.spines['bottom'].set_position('zero')
    backend.ax.spines['top'].set_color('none')
    plt.close(backend.fig)

p = plot(x**2, (x, 0, 3), show=False)

fig, ax  = plt.subplots(1,2, figsize=(18,9))
ax[0].plot(X,y)
add_plot(p, ax[1]);

Вот мы имеем фигуру с двумя осями, одна нормальная matplob'вская вторая из sympy.
Вот здесь кто то постарался и прикрутил. Почитай, что пишут.

lowendstock.com
Поисковик по хостингам с ценами от 2$ в год (за какой-нибудь 128ram со 100мбит сетью), не обслуживаемые, слабая надежность (в зависимости от хостера)....
Мне кажется нормальные начинаются где то от 2-3$ в месяц (с 1GB ram), пользуюсь buyvm(frantech) с оплатой в bitcoin lightning network.

настоятельно рекомендую выбирать kvm версии, в них ты сможешь поставить любую ос, настроить свою файловую систему и т.п., когда как более дешевые lxc/openvz ничего этого не позволят.