alexalexes

Если нет особых требований, то пока удобно создать такие таблицы:

Таблица "План накопления статистики"
id - идент. плана
begin_date - дата/время начала сбора статистики
end_date - дата/время окончания сбора статистики
name - название плана
description - описание плана
interval - интервал накопления статистики в секундах
... - другие параметры плана

Таблица "Точка фиксации показателей"
id - идент. точки
plan_id - инд. плана накопления статистики
begin_date - дата/время начала сбора данных для точки фиксации
end_date - дата/время окончания сбора данных для точки фиксации

Таблица "Агрегированные показатели точки фиксации"
id - идент. показателя
Name - название показателя
measure_id - инд. единицы измерения показателя (тоже нужна таблица справочник: байты, биты, байт/с, Ватт, Кг и т.д.)

Таблица "Значения агрегированных показателей точки фиксации"
id - идент. значения показателя
point_id - идент. точки фиксации
param_id - идент. показателя
value_int - значение показателя в целых числах
value_flt - значение в вещественных числах
value_str - значение в строковом представлении
value_... - если нужен еще какой-то тип данных, которых можно индексировать.

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

Если не вдаваться в категории, то простым языком это выглядит так:

Если нужно только 100Мбит/с, то подойдет любой попавшийся кабель (можно сэкономить и взять тонкий кабель с 2 парами).
до 1Гбит/с - кабель должен содержать 4 пары, остальные характеристики не важны.
до 2,5Гбит/с или 10 Гбит/с - 4 пары, плюс металлизированная изоляция коннектора и кабеля, длина кабеля не может превышать 40 метров.

Но для это подойдет для поиска одного размера, а мне прилетает несколько. Не ужели скажем если 10 размеров прилетит, писать 10 запросов для проверки каждого размера?

Да, будете страдать по полной, раз нет нормализованной структуры данных.
Ни нормального выражения с in не построить, ни возможности создать индекс для ускорения поиска.
Время поиска будет линейно расти от количества записей и умножаться на кол-во or, так как нельзя воспользоваться индексом.

select * from table
where 1 = 1 -- чтобы можно было однотипно подставить выражения с and или or, не заморачиваясь в каких случаях нужен and/or, а в каких нет.
or find_in_set('L', replace(value, ';', ','))
or find_in_set('XL', replace(value, ';', ','))
...
or find_in_set('XXXL', replace(value, ';', ','))

Вам нужно проработать архитектуру таблиц.
Чтобы удобно хранить свойства ads и serp в одной таблице, которые представленные в виде массива. Вам нужно не только выделить тип записи - ads или serp, но нужно как-то связать все записи, которые входят в одно событие свойства p1.
Допустим, для событий мы создаем таблицу Event со свойствами:
Event_Id - код события,
info - строка или JSON-тип,
success - число,
query - строка или JSON-тип,
total_count - число
...
Не все свойства p1 перечисляю, так как, например, paa - тоже массив, и нужно понять, будете ли под него выделять отдельную таблицу или приспособите какую-нибудь существующую, добавив новый тип - paa.
-----
А для хранения элементов массивов ads, serp (и, возможно еще каких-либо свойств-массивов, которые появятся непосредственно в p1 не во вложенных свойствах) вы создадите отдельную таблицу event_prop_array:
prop_arr_Id - код элемента свойства события
prop_id - тип свойства из таблицы-справочника типов свойств (внешний ключ)
event_id - событие, к которому относится запись, внешний ключ к таблице event
link - строка
snippet - строка
...
дальше идут другие скалярные свойства, которые можно найти в одном элементе ads или serp
------
Добавляем таблицу справочник, чтобы закодировать внешний ключ prop_id
Таблица event_prop
prop_id - код свойства
prop_name - имя свойства
----------------------------
Теперь, чтобы залогировать один элемент p1 нужно сделать так:
1. Вставить в таблицу event запись из простых свойств (info, success, query, total_count, ... )
2. Получить event_id вставленной записи (гуглите last_insert_id для PDO или дополнительную клаузу для insert - "returning event_id into :event_id", если вы используете, например, oracle, а не mySQL)
3. Получить prop_id из справочника (тут обычный select)
4. В цикле вставляете записи в таблицу event_prop_array, используя известные event_id, prop_id и текущие свойства элемента ads.
5. Тоже самое как 4, но используете свойства serp.
-------------------
Когда сформируете лог в базе, то типичный запрос для выборки чего-либо будет иметь вид:

select e.*, ep.*, epa.*
from event_prop_array epa
join event_prop ep on ep.prop_id = epa.prop_id
join event e on e.event_id = epa.event_id
-- какие-то условия для поиска
where e.event_id = 1
 and ep.prop_name = 'ads'

Контроллер памяти процессора в этом ноуте поддерживает до 32Гбайт.
https://ark.intel.com/content/www/ru/ru/ark/produc...
Так, что нет проблем поставить 2 по 8.

sqlite - для хранения метаданных файлов и виртуальных путей расположения (с точки зрения внутренней логики приложения).
Плюс физический каталог media для сохранения содержимого файлов в одном или нескольких подкаталогах, рассортированных по расширению (виду контента), с именем в виде уникального хеша (хеш записывается в метаданные в качестве ссылки на media).
По-моему, это самое распространенное решение, если взглянуть на внутренности популярных мессенджеров.

Что нужно знать и уметь для реализации такого алгоритма?

По алгоритмам ровно ничего, создать свой сервис для распознавания музыки - это сверхакадемический уровень (или уровень серьезного сеньора, которого оторвут с руками и возьмут на работу в youtube после того как его уведут из shazam).

Какие технологии применяются?

Для обычного разработчика применяются навыки работы с API любых сервисов, к которым можно получить доступ через авторизацию, и в которые в режиме запрос-ответ дадут искомые данные.
1. Изучаете API условного Shazam-a, куда будете отправлять образцы звуковых данных.
2. Изучаете API музыкальных библиотек, куда будете отправлять результат ответа от Shazam, чтобы получить недостающие данные.

Как foreach-ем обходили контейнеры, чтобы инициализировать каждый слайдер:

$(какой-то селектор элемента или нода).slick(какие-то свойства инициализации);

Таким же путем нужно пробежаться по всем слайдерам и дать им команду обновить свое состояние (refresh) после того, как отработает функция renderProducts.

$('.slider__body').each(function () {
  $('.slider', $(this)).slick('refresh')
  $('.slick__thumbs', $(this)).slick('refresh')
})

Если у вас строго режим одностраничного сайта, то да, сами перелицовываете body в любой непонятной ситуации (на самом деле для такой модели подбирают подходящий клиентский фреймворк. сами вы вряд ли охватите все обработчики событий, чтобы не заботится об реактивности блоков всей страницы). При этом нужно не забывать вести url history, чтобы адрес страницы фиктивно изменялся, следуя логике посещения виртуально нарисованных разделов сайта.
Или же у вас не строго одностраничный сайт, то...
Если у вас только некоторые контейнеры на странице обновляют сведения по ajax, то на какие-то действия нужно вызывать перезагрузку страницы, изменяя windows.location.href / windows.location.reload.

Я, конечно, дилетант в Python, но могу сказать точно, что blob нужен в СУБД, чтобы можно было сохранять бинарное содержимое файла как есть.
То есть подключались к файлу в бинарном режиме. Потом читаете поток файла как есть, без этого преобразования:
hex_file = binascii.hexlify(bin_file)
А сразу использовать bin_file как входной параметр запроса.
Кроме того, можно обнаружить, что использование bin_file в качестве временного хранения содержимого файла в оперативной памяти phy-сервера - это опять нецелевое использование возможности блоб.
Я специально не буду гуглить phy-функцию, но такая точно есть, которая открывает дисковый файл и тут же привязывает дескриптор файла к параметру запроса (bind), не считывая тело файла. При запуске выполнения запроса, файл самостоятельно средствами среды отправляется в базу, не нагружая серьезно оперативную память.
Такую же функцию можно найти для выборки данных сразу в файл.
Это позволяет ворочить гигабайтовыми файлами, используя считанные мегабайты оперативной памяти сервера, при выполнении phy-скриптов.

Принял решение обслужить сам, заказал жидкий металл от термал гризли

Прямой путь нарваться на ремонт всего и вся ввиду короткого замыкания, в следствие проникновения капелек жидкого металла под чипы, которые были им обслужены. Новичок не сможет грамотно обслужить этим интерфейсом технику, а профессионал не будет его использовать там, где отродясь его не было.
В вашей ситуации, проще купить бу ноут по объявлениям, и на нем работать, пока к вам придет правильный ремкомплект, а потом его продать, когда почините основной ноут. Меньше денег потеряете.
Видео по теме:
https://youtu.be/Bi6hxoIVeVc?t=69

А что вам мешает css инлайн стилем добавить? Можно даже картинку в base64 перевести и туда же интегрировать, чтобы не обращаться ни к каким сторонним ресурсам.

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

Думаю что первым делом, происходит подсчетом суммы общей заполненности данных по полям групп, потом это число делится на количество записей

Нет, методы оценок чего-либо не всегда сводятся к вычислению математического ожидания.
У каждого города может быть выведен регрессионный показатель:
y = t1*x1 + t2*x2 + ... + tn*xn
x-ы - допустим, значения рейтингов в группах.
t-ы - допустим, веса эти гр. рейтингов (влияние на общий показатель).
Коэф. t может оказывать и нелинейное влияние. Ничего не мешает провести его через логарифм, с близким к экспоненте показателем (чтобы чуть-чуть отличаться от линейности). Может даже на отдельных значениях срабатывать пороговый триггер (например, если входное t > 0.8, то считаем, что оно 1.0).

X-ы могут быть нормированы к интервалу 0...1. Также могут применятся хитрости с нелинейностью и триггерами.

Y - тоже можно нормировать по тем же правилам.
Чтобы на первое место вылезло больше кандидатов с рейтингом больше 0.99 - подкрутите логарифм.