mayton2019

В классическом SQL нет возможности работать с массивами и списками внутри одной ячейки. Фактически - это таблица не удовлетворяющая 1НФ и поэтому она не имеет право на жизнь.

Explode. Да, верно. Функция explode разворачивает строки на 90 градусов и позволяет посмотреть на participantid как на дочерние строки от основной таблицы. Но объем обработки как-бы возрастает и если вы передаете эти развернутые стороки на клиента то соотв. растет размер трафика. И работать с такой опухолью не лучше т.к. уникальность по PK/UK переносится на эксплоднутые атрибуты.

Как с этим бороться? Никак. Надо переделывать софт.

Like не работает. Это да. Это - проблема.

Swap может быть полезен для режима Hibernate.

Сама формула расчета размера свопа была разная для разных объемов оперативки для разных линуксов. Кажется для памяти меньше чем 2Гб рекоммендовалось брать своп хотя-бы в 2 раза больше. Для иного варианта - брать хотя-бы не менее чем размер свопа.

Какого размера у тебя массивы? Там для маленьких - вообще теоретическая формула не работает.
Видимо в силу когерентности кеша тупые и жлобские алгоритмы работают лучше чем умные и сложные.

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

Я для мелких массивов (2,3 элемента) сортировка пузырем вполне себе делает минимум операций.
Ее даже можно хардкодить размоткой циклов.

Есть также вопросы на собеседовании для джунов (Java) которые практически позволяют нагнуть новичка
показав ему на практике что вставка примитива в ArrayList (массив) работает быстрее чем вставка в LinkedList.

Опять-же этот эффект заметен на малых размерах массивов.

В обсуждении архитектуры приложения с Redis никто не считает питонские структуры данных.

Главные фичи Redis - это управление временем жизни записей. Работа c key/value, с множествами, очередями и т.п. И обеспечение персистентного хранилища. Тоесть редис переживает физическую перезагрузку. И сохраняет данные. Он также поддерживает кластерные режимы и имеет сетевой API. Тоесть несколько разных языков и технологий могут работать с одним кластером.

Тоесть писать через запятую Redis и Dict Python нельзя. Никто-же не сравнивает двигатель от машины и саму машину!

Любой Kafka-consumer имеет атрибут group.id. И если у нескольких консюмеров он совпадает
то они начинают делить топик поровну (по round-robin). В более расширенном варианте - нужно
настраивать поля самого сообщения чтоб был более умный партишенинг.

Несмотря на то что Кафка работает быстро, сам процесс включения и перебалансировки консюмеров
может быть не очень быстрым поэтому такие манипуляции следует делать не очень часто.

Вопрос состоит из двух частей.

1) Загрузка файлов из CSV в некую модель или внутренне представление двух таблиц. Это может быть Pandas, Spark, реляционная БД неважно. Задача прямая. Деревянная и много раз решенная. Для java есть библиотечка Apache Commons CSV которая обеспечивает итератор по файлам и выдает объекты-записи.

2) Генерация новых данных (таблиц?) (массивов?). Здесь из сбивчивого и эмоционального описания ничего
нельзя понять кроме того что автор сам не знает точного задания.

Если совсем-совсем не знает - то проще делать как в модульных тестах. Дать вход. И что должно быть на выходе.

Input:

Output:

Значит имеет место некий pipeline который работает в 3 фазы.

1) Скачивание из гугло-таблиц в файлы. Здесь я предполагаю что у нас есть full-structured данные xlsx
Тоесть таблицы и фиксированная шапка.

2) Конверсия xlsx-csv. Ну здесь как-бы все понятно. Это можно сделать локально уже без веба.

3) Загрузка (или merge) данных из CSV в реляционную базу данных.

Мне кажется что интересно обсуждать только пункт (3). Потому что первый и второй - это просто задачи скачивания и конверсии без изменений. Задача чисто техническая и любой "школьник-парсильщик" это делает.
Чисто утилитарная задача.

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

Если в какой-то момент (например фазы 1-2) схема может быть изменена или сломана - то это надо тоже обсуждать как ветки алгоритма загрузки. Как грузить.

Что делать если новая колонка зашла?
Что делать если колонка изменила тип? Был int. Стал - string.
Что делать если колонка дропнулась? Удалять ли в БД.
Что делать если schema evolution нарушается. Был string, и пошел int. Это сужает возможности загрузки.

Вот эти все вопросы надо ответить до разработки.

UPD:

Тут нет теоретически верного ответа на вопрос. Дело в том что параметров Full HD 1080p и fps недостаточно чтобы судить о трафике. Есть еще и неизвестный кодек и куча настроек у него. Есть плавающий и шумящий интернет. Плавающий wifi. Все эти узлы не гарантируют полосу пропускания поэтому трансляции скорее всего будут транслировать иногда на более низком разрешении. Это иногда заметно глазом при просмотре трансляции. Когда шрифты "мутнеют".

Какой тариф покупать? Ну можно каждый день перед выключением роутера заходить в его статистику и просто смотреть какой объем трафика был скачан. Или если есть решим отчета по дням - то даже лучше так.

Вот и эта цифра будет основанием для месячного объема. Экстраполируем. Складываем. Не знаю как щас а во времена ADLS модемов провайдеры были очень жадные и считали оба типа трафика входящий и исходящий. Тоесть если вы стояли на раздаче торрентов достаточно долго - то можно было выйти за лимиты легко.

Да все будет в порядке. Проскочит как сквозняк. Главное длительных транзакций не делать.
И архитектура у SQLite - такая. Один процесс который держит открытым файлы sqlite.

Вообще так вопросы спрашивать нельзя. Потому-что тут ответы и да и нет и оба верные.
И автор должен быть в теме как работает мультипоточка в Питоне. Иначе получается
как в анекдоте про "активного читателя" который пишет письма в "Академию Наук про
подземный стук".

Нужна новая нейросеть которая будет обучена на выборке обычных постов. И на выборке ответов GPT.
Supervized. Тоесть мы как учитель - указываем где какие.

Простые частотные метрики текста такие как tf/idf здесь не подходят. Скорее всего. Тут нужна
структурная. Я заметил что GPT часто выдает ответ в виде однородной структуры.
Типа введение. Пункты перечислений. И какое-ро резюме.

Люди обычно такой схемы не придерживаются.

Данный фильтр - слишком избыточен. Его можно переписать через

SELECT * FROM products WHERE id IN (
    SELECT product_id FROM filters_products WHERE 
        (filter_id = 1 AND filter_value BETWEEN 1000 AND 4000)
      OR
        (filter_id = 3 AND (filter_value = 'Intel® Core™ i5 11400F' OR filter_value = 'AMD Ryzen 5 5600G'))
      OR
        (filter_id = 2 AND filter_value = 6)
);

В оригинальном запросе стоял INSERSECT и по идее надо было заменять предикаты на AND.
Но я поставил OR поскольку мне кажется что автор тоже ошибается и INSERSECT - это
слишком строгий фильтр и пересечение с ключами 1-2-3 даст пустоту. И скорее всего
там надо объединение а не пересечение.

Просадки-шмосадки... Будут или нет. Никто не знает. Смотрим execution план в двух вариантах. И сравниваем.

Еще раз я призываю всех SQL писателей - указывать целевую dbms.

Если в игре есть 1000 взаимодействующих тел - то для их "сканирований" надо как минимум посчитать пол-миллиона взаимодействий. Каждое тело может видеть или не видеть каждое. По крайней мере прямая
реализация такого взаимодействия имеет квадратичную стоимость.

Странная задача. Зачем копировать ссылки на "то чего нет" ?
Ценность такой информации - на уровне рандомного шума.