mayton2019

Очень много. Практически все современные NoSQL-in-memory-dbms используют хеш-таблицы в каком-то варианте.

Хеш-таблицы являются частью механизма буферного кеша (страничного кеша) в дисковых БД. В Oracle, Postgres e.t.c.

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

Дисковые файловые системы могут использовать хеш-таблицы (в зависимости от настроек). Как хранить списки файлов в директориях. Там кажется выбор есть. Дерево или хеш-табличка.

В простейшем случае ты можешь сделать такую табличку

b'\x01' => '01'
b'\xff' => 'ff'

Где одному байту будет соотвествовать 2 символа.

Или можно разбирать 1 байт на 2 части по 4 бита и для каждого из них ставить в соотвествие одну
шестнадцатеричную цифру.

Ну и API-ев богатое множество должно быть.

По поводу твоих экспериментов с utf-8. Там есть запрещенные комбинации байтов. Потому
не любой рандомный массив байтов обязан преобразовываться в символы.

В SQL - много таких особенностей. Тоже самое с group by и оконными фунециями. Надо много повторяющихся expressions написать.

Попробуй еще так написать.

WITH HT AS (
 SELECT `product_id`, MD5(`value`) AS myhash
  FROM modx_ms2_product_options
  LIMIT 10
)
SELECT * FROM HT WHERE `myhash` = 'e59253548ffcb090ecc0cd0944afd27f'

Да может. Мобильные телефоны используют уже обученные модели для коррекции лиц.

Поскольку речь идет уже об обученной модели - то от нее много не потребуется. Кроме того
в задачах работы с графикой всегда есть большая фора - разрешение картики. Если ее регулировать
то можно даже слабую конфигурацию заставить работать но она будет работать с разрешением 320х240
хотя и будет терять лица которые слишком далеко отошли от камеры.

Такое связывание специфично для Java-фреймворков а не для языка С.

Я-бы предложил обсудить вопросы безопасности. Что будет если пользователь вызовет функцию которую ему нельзя вызывать? Как мы вообще ограничиваем пользователя? Стоит-ли такая гибкость получаемого удобства? Может лучше пойти классическим путем? Перечислить все возможные варианты действий явно и в switch-case обработать?

Сравнительно недавно в Кафку завезли новый стандарт кворума на основе Raft-протокола. Это означает что Смотритель зоопарка будет скоро не нужен и его можно будет выкинуть нафик. А все ноды Кафки будут решать кворумные вопросы самостоятельно.

Тут надо сезон "разлохматить" на 4 входа. Обычно НС не работают с текстовым вводом. Поэтому
будет во входном слое 6 входов типа:
- area
- AC
- isSummer
- isWinter
- isSpring
- isAutumn

Всем сезонным факторам присваивается нолик на входе кроме текущего сезона.
Там можно дать единичку. Для признака кондиционера тоже можно брать 1.0 если он есть.

Дальше можно искать решение в виде например однослойной сети. Я-бы пошел от простого.

И данных нужно побольше. Чтоб хотя-бы была выборка учебная и контрольная.

Нормальный Б/У десктоп будет лучше чем все эти Распберри и ардуинки. Я не понимаю чем там автор хочет
заниматься но эти все просто несерьезно. Любая верстка - предполагает хорошую клавиатуру а работа
человека за столом - предполагает нормальный монитор. Все эти телевизоры и джойстики и блютус-игровые клавиатуры - дадут вам билет в хронические заболевания глаз, шеи и поясницы.

Работать нужно засучив рукава а не дурачится.

В классическом 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 модемов провайдеры были очень жадные и считали оба типа трафика входящий и исходящий. Тоесть если вы стояли на раздаче торрентов достаточно долго - то можно было выйти за лимиты легко.