mayton2019

Много путей. Можно отсортировать и потом просто пройтись по всем сериям.

aaaaaaaabbcccccdeeeeeeeeeeee
Вот здесь глазами видно что серия а и е самые длинные а потом еще с.

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

Ох инженеры пошли совсем никудышние.

Заходи в cmd. И делай

c:
cd \
cd Users
cd "Пользователь"
cd "PycharmProjects"
cd "pythonProject1"

Вот на каком-то фолдере ты увидишь несоотвествие.

выгружаются данные в виде json(csv):

Я вижу 2 стратегии как с этим работать.

1) Как с чистым JSON документом. Можно работать языком запросов JsonPath. И выбирать и трансформировать узлы Json многократно до полного формирования результата.

2) Как с дата-фреймом технологии Pandas, Databricks/Spark. Судя по внешнему виду это Пандас
загрузит успешно. Насчет Датабрикс я не уверент. Тот точно работает с Json-Lines а не с таким деревом где
есть единый корень. У дата-фрейма есть свойства SQL-курсора. Тоесть по нему можно бегать и выбирать
данные. Или другой датафрейм. И датафрейм обычно имеет больший запас прочности по объему данных.

Какую стратегию выбрать - это больше вопрос к автору. Вот что он лучше знает - то пускай и выбирает.

В классический реляционных БД - никак. БД проектировались исключительно как сервер который "отвечает на вопросы". И при этом сам ничего не уведомляет.

Если нужно ловить события в той точке где они возникают - то лучшее место не БД а именно сервер приложений. И для хранения событий использовать топики Kafka или RabbitMQ.

Если этого всего нет - то тогда дергай запросы 1 раз в час. Другого выхода нет.

Первым делом надо доказать отсутсвие глупых ошибок. Типа вместо продуктовой БД пошел в тестовую.

Сделай этот-же запрос из mysql консоли

mysql> SELECT flag FROM designbase WHERE id = 501285409

И попробуй для 2 исходника включить автокоммит как тут пишут https://mariadb.com/kb/en/mysql_autocommit/

Андрей Прохоренко, попробуй использовать библиотеку Numpy.

Но самые сильные оптимизации мы можем сделать только поняв суть алгоритма.
Поэтому для общей пользы было бы полезно нам всем узнать настоящую цель.

Обычно при работе с распознаванием картинок не используют точное равенство пикселов. Картинка может
быть отрегулирована по яркость/контраст/гамма. И это сбивает такие компараторы.

А цвета сравнивают по цветовой дистанции. Тоесть насколько далеко один цвет отстоит от другого в цветовом кубе
например. Функция какого-то такого вида

def colorDistance(r1,g1,b1, r2,g2,b2) -> int :
   return .....

Для сравнения картинки с картинкой можно использовать аналогичный прицнип. Скалярное произведение
всех пикселов. Вот. И сравнить с известными образцами. В теории это можно назвать однослойным нейроном
(или 0-слойным) в зависимости от определений.

Как-то так
$ python3 app.py 2>err.log >out.log

Можно попробовать решить обратную зачачу. Генерировать все с 3 одинаковыми.

Например.

111x = генератор для последовательности 1111,1112,1113....1119
11x1 = для 1111, 1121,1131....

А потом - отфильтровать те которые не заходят в заявленный диапазон.

Существует много техник взаимодействия между процессами. Основное ключевое слово для поиска - IPC (Inter process communications). Там дальше надо выйти за границы Питона потому что эти техники немного разные для Windows/Linux. Некоторые похожие (Network Sockets).

Если надо просто вести учет строк в PIPE между процессами то можно так

bzip2 -d -k -c very_long_file.txt.bz2 | pv -l > /dev/null

Это не будет работать. Base64 использует специальные символы padding в конце файла чтоб указать
какой из символов терминирует поток байтов.

Поэтому если ты просто текст base64 тупо разрежешь на 2 части то эти две части станут невалидные
с точки зрения кодировки base64. Надо примерно так

input string => base64decoder => bytearray => split_3500 => encode_each_array_base64 => save_to_files

вот на таком выдуманном всевдо-коде.

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

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

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

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

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

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

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

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

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