Viktor T2

На сайте используется TLS Fingerprint (вероятно, JA3) как один из индикаторов сессии в системе перед веб-сервером, вероятно, это анти-DDoS.
Так как браузер и curl используют разные SSL-библиотеки и передают разные наборы шифров, сервер предлагает вам пройти challenge.

Все очень просто, используй matplotlib, pandas и seaborn. Возможности не ограниченные.
сначала читаем это дело в pandas фрейм и затем рисуем scatterplot. Можно их соеденить сделать их разного размера создать любую палитру цветов, да все что угодно

import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
df = pd.read_csv('data.csv',sep=';')
sns.scatterplot(df, x='x',y='y',hue='c')
plt.show()

Вот простенький пример где data.csv это твои данные. Открывай доки как seaborn так и matplotlib и кастомизируй по своему желанию. Рабочий маленький пример рисования точек по цвету третьей переменной я привел.

sqlite3 не потоко-безопасна - если ты одновременно обращаешься к базе из нескольких потоков, это может запороть базу.
Соответственно, по умолчанию библиотека проверяет, что подключение к базе используется тем же потоком, который создал этот подключение - т.е. что оно ограничено рамками одного потока. Если это не так, выбрасывается исключение. Это поведение по умолчанию, чтобы новички потом не плакались "почему у меня иногда база портится?!!"

Но если ты очень осторожен и не допускаешь одновременных запросов (с помощью синхронизации по мьютексу. например), то можно безопасно использовать одно подключение из нескольких потоков. Тогда можно сказать sqlite "не дергайся насчёт потоков, я знаю что делаю". Вот эту возможность (подавить проверку) и предоставляет параметр check_same_thread = False.

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

UPDATE:
Надо же, с 2019-го многое поменялось в интересную сторону. Для PyQt и PySide есть qasync, который активно развивается, а для Tk вообще не нужны сторонние библиотеки:

import tkinter as tk
from tkinter import ttk
import asyncio


class App:
    async def exec(self):
        self.window = Window(asyncio.get_event_loop())
        await self.window.show();


class Window(tk.Tk):
    def __init__(self, loop):
        self.loop = loop
        self.root = tk.Tk()
        self.animation = "░▒▒▒▒▒"
        self.label = tk.Label(text="")
        self.label.grid(row=0, columnspan=2, padx=(8, 8), pady=(16, 0))
        self.progressbar = ttk.Progressbar(length=280)
        self.progressbar.grid(row=1, columnspan=2, padx=(8, 8), pady=(16, 0))
        button_block = tk.Button(text="Calculate Sync", width=10, command=self.calculate_sync)
        button_block.grid(row=2, column=0, sticky=tk.W, padx=8, pady=8)
        button_non_block = tk.Button(text="Calculate Async", width=10, command=lambda: self.loop.create_task(self.calculate_async()))
        button_non_block.grid(row=2, column=1, sticky=tk.W, padx=8, pady=8)

    async def show(self):
        while True:
            self.label["text"] = self.animation
            self.animation = self.animation[1:] + self.animation[0]
            self.root.update()
            await asyncio.sleep(.1)

    def calculate_sync(self):
        max = 3000000
        for i in range(1, max):
            self.progressbar["value"] = i / max * 100

    async def calculate_async(self):
        max = 3000000
        for i in range(1, max):
            self.progressbar["value"] = i / max * 100
            if i % 1000 == 0:
                await asyncio.sleep(0)


asyncio.run(App().exec())

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

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 - на запись).