Руслан .

Вопрос не глупый а вполне себе хороший.

Его плавное развитие приводит к концепции баз данных. Самое главное что можно сказать тезисно это
1) Пока памяти хватает (массив) - используй смело память
2) Диск - больше и дешевле памяти
3) С памятью работать легко. С диском - очень неудобно и надо обрабатывать IOExceptions почти всегда.
Диски внезапно полны сюрпризов. Могут быть сетевыми дисками.
4) Разные диски имеют скорость на порядки разную.
5) Диски ведут себя очень плохо на random access. От этого даже метрика IOPS появилась.
Ее очень любят обсуждать админы баз данных.
6) Существуют структуры данных которые спецом создавались только для дисков (B+Tree)
7) Диск - переживает выключение питания.
8) Самые разумные решения - сочетают в себе и диск и память в тех частях кода где это нужно.
9) Есть интерфейсы программирования которые виртуализирут диск как память. Этим пользуется
SQLite например.
10) Диск может достигать очень высокой последовательной скорости чтения или записи в файл
при условии отсутствия конкурирующих записей в данный момент. Этим пользуются в БД
для журналирования событий.

В принципе если современный программист просто будет использовать только оперативную память
то никто ему не сможет ударить по рукам или подойти с какой-то метрикой и чего-то там измерив
сказать что он неправ. Тут уж только падения по OOM и потери информации и performance issues
могут быть каким-то значимым аргументом.

Шаг 1. Опиши каждую цифру числа как бинарную строку, где каждому биту соответствует спичка в цифре. 1 - спичка есть, 0 - нет. Тебе понадобится 7 бит на цифру, можно округлить до 8 и считать 8й бит всегда 0. Это, по сути, семисегментный индикатор.
Шаг 2. Научись преобразовывать число из нескольких цифр в длинную бинарную строку. Если гарантируется, что число 4значное или меньше, то эта строка будет выражена как 4 байтовое беззнаковое целое.
Шаг 3. Если сделать XOR между двумя такими строками, то значение 1 примут только биты, соответствующие пропавшим/появившимся спичкам. Посчитать число единичных бит нетрудно.
Шаг 4. Перебирай числа по возрастанию, для очередного числа построй битовую строку. Если число единичных бит в строках равно (для их "записи" используется равное число спичек), а число единичных бит в XOR равно четырём (две спички переложили = две спички пропали + две появились), число подходит.

За скорость, правда, не ручаюсь. Но есть возможности по оптимизации подсчёта единичных бит, и по оптимизации перебора (перебирать не все числа, а только те, которые можно выразить тем же числом спичек).

allowed = set('01')

def check(test_str):
    return set(test_str) <= allowed

print(check('010111010110'))
print(check('1264893215'))
print(check('ZXvn,mdg^&%32012mjcv'))

https://stackoverflow.com/questions/1323364/in-pyt...

MySQL имеет собственный встроенный планировщик (MySQL 8.0 Reference Manual / Stored Objects / ...), который может делать практически что угодно. Создаёшь Event Procedure, задаёшь периодичность выполнения - остальное сервер сделает сам. Вообще без помощи/управления со стороны.

Народ обычно любит предлагать внешние планировщики (как правило CRON) - настоятельно не рекомендую, если требующий выполнения код есть чистый SQL. Другое дело когда надо выполнять скрипты на иных языках или внешние приложения - тут да, без крона скорее всего не обойтись. Хотя и тут есть способ - подключить внешний модуль с требуемым функционалом.

Есть папка, которая хранит в себе sql файлы для создания бд, таблиц в этой бд, импорт данных в эти таблицы.
Как автоматизировать запуск этих sql скриптов?

Создание БД, таблица, начальное наполнение - это как бы одноразовое действие. Нафига их шедулить?

zero, one, two, three, four, five, six, seven, eight, nine = \
  [ lambda f = None, v = i: f(v) if callable(f) else v for i in range(10) ]

plus = lambda a: lambda b: b + a
minus = lambda a: lambda b: b - a
times = lambda a: lambda b: b * a
divided_by = lambda a: lambda b: b // a

Но немаловажная суть микросервисов в том, что бы минимизировать зависимости, в том числе обеспечить каждый микросервис своей БД.

Именно.

Дублировать данные для каждого микросервиса нет никакого смысла.

В микросервисной архитектуре в дублировании как раз есть смысл.

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

Веб-разработка и администрирование сетевых ресурсов более востребованы, поэтому я бы рекомендовал изучить следующее:

• основы и стандартная библиотека Python -- навык лучше прокачивается написанием скриптов и программ для решения неучебных задач. И если основной навык миддла -- это гуглить (полу)готовые решения, то основной навык джуна -- уметь писать свои "велосипеды". Разработчик, который по-максимуму использует и полагается на готовое -- столь же неэффективен, как и предпочитающий использовать готовое по-минимуму;
  
• веб-фреймворк Django -- пилите небольшой проект, получаете общие представления о веб-разработке и практику ООП, но о Python этот веб-фреймворк расскажет мало, делает слишком много работы за программиста, а в его исходном коде можно заплутать, так и не поняв как он работает;
  
• система контроля версий Git -- обязательно для разработчика и желательно для сисадмина;
  
• wsgi-сервер uWSGI (или Gunicorn) -- см. ниже;
  
• http-сервер Nginx -- см. ниже;
  
• GNU/Linux -- пробуете развернуть проект с использованием предыдущих двух пунктов;
  
• веб-фреймворк Flask -- просто пощупайте или сделайте ещё один небольшой веб-проект, по исходникам этого веб-фреймворка проще понять как работают другие веб-фреймворки и как писать поддерживаемый код, к тому же на Flask часто пилят всякие API / бэкенды;
  

Настольные приложения и мобильная разработка на Python кажется менее развита и менее востребована, но когда-нибудь можете пощупать:

• Python GTK+ 3 (или PySide2) -- Python обёртки над GUI инструментариями для разработки настольных приложений;
  
• Kivy -- фреймворк преимущественно для мобильной разработки.
  

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

При условии, что product_id всегда имеет не более одного типа property_id:

SELECT `product_id` 
FROM `product_properties_values`
WHERE (`property_id`=1 AND `value`=2) OR (`property_id`=3 AND `value`=3)
GROUP BY product_id
HAVING count(*) = 2

, и при условии, что я угадал то, что вы хотите.

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

Вот здесь смотри:
https://dba.stackexchange.com/questions/116142/get...

Опрашивать файл не надо, достаточно использовать inotify от самой ОС.
Под Python есть кросс-платформенные реализации отслеживания изменения файлов через inotify-like подсистемы. Отслеживающие скрипты будут ловить событие по итогам записи и закрытия файла, даже без коммуникации с основным процессом.

А так, скрипты могут взаимодействовать друг с другом как по HTTP (публикуя от себя маленький веб-сервер), так и по любому самописному RPC-протоколу поверх TCP или unix socket'ов.