Дмитрий, "демон + очередь" у автора уже есть, но 1 демон не вытягивает по скорости. Отсюда собственно и вопрос автора о параллелизме, который он хотел решить потоками, а ему предложили процессами. Т.к. решать это потоками или асинхронностью будет гораздо сложнее и вряд ли выигрышнее. Собственно об этом я и написал в первом комментарии: "Самое простое решение, как уже указали, использовать несколько воркеров, столько, сколько будет оптимальным. Для этого проще всего запускать их в разных процессах, чем использовать потоки или подключать асинхронность."
Если нет возражений по поводу этого решения, то значит мы друг друга недопоняли и спорим не о том.
Дмитрий, вы описываете более сложную архитектуру, здесь достаточно простой.
Очередь - брокер сообщений или просто таблица в БД.
Воркер - скрипт работающий демоном. При запуске он подключается к Очереди, затем переходит в бесконечный цикл. В каждой итерации, забирает задание из Очереди, затем выполняет его, затем рапортует в Очередь, что это задание завершено. И заново тоже самое.
При необходимости можно запустить еще один воркер, и еще, и еще... Они независимы и не требуют специального управления. Это очень простая схема и не требуются ни потоки, ни асинхронность.
Дмитрий, я не завлял, что брокер сообщений это чтото плохое и не нужное. Но, вопрос совсем в другом, хоть с брокером, хоть без, автору нужен параллелизм обработчиков. Да, надо будет управлять воркерами, но, как правильно заметил автор, брокер сообщений ему здесь никак не поможет, т.к. задания будет делать не брокер.
К слову об управлении воркерами: их не нужно постоянно менять или создавать динамически, достаточно запустить их определенное кол-во с запасом, т.е. там вообще не нужен никакой "манагер процессов". А если уж нагрузка измениться в разы, то накинуть еще. Мониторить нужно только очередь. Железо тоже, конечно, надо мониторить, но это и так надо делать без всяких воркеров. Но, все это, опять же, надо будет делать в любом случае и без разницы есть брокер или нет.
Дмитрий, со стабильностью у php нет никаких проблем. Да и, правильно организованная очередь в БД работает также хорошо, как и при использовании брокера сообщений. Проблема у автора в том, что единственный воркер получив задание обрабатывает его долго, та же отправка email процесс не быстрый, все время пока воркер ждет ответ при обработке задания новых он не берет. Соответственно те же проблемы будут и с брокером очередей, воркер один, и время работы будет очень большим.
Самое простое решение, как уже указали, использовать несколько воркеров, столько, сколько будет оптимальным. Для этого проще всего запускать их в разных процессах, чем использовать потоки или подключать асинхронность.
Inajaf, готового нет, так как все зависит от задачи. Выше описано несколько алгоритмов и они будут давать разный результат. Если выберите расстояние Левенштейна, то учтите, что при сравнении придется накладывать эту функцию на каждую пару сравниваемое-образец. Т.е. это фулскан таблицы словаря, в зависимости от размера словаря и необходимой скорости ответа может и не подойти. Как вариант дерево Буркхарда-Келлера, но оно эффективно при получении одного ответа, при желании получить несколько, скорость работы будет деградировать очень сильно.
Примерно также с трехграмным поиском.
Фонетический анализ проще, мы в словаре можем хранить сформированный код и поиск будет по нему, здесь уже будут работать индексы и скорость будет высокой. Проблема здесь в том, что различные функции могут дать разные и очень неожиданные результаты. И дело не только в том, что они захватят лишнее, они могут не выдать очень похожие результаты.
Что касается синонимов в словаре, то группируете их (какое-нибудь поле group_id) и при совпадении одного слова выводите все слова группы.
Все очень зависит от ваших требований, быть может будет достаточно сравнения по расстоянию Левенштейна с определенным порогом чувствительности, как написал mayton2019.
Алексей, суть ответов в том, что вы кладете в очередь, а далее воркеры ее обрабатывают. Совсем не обязательно для этого подымать брокер сообщений. Вполне можно сделать очередь в БД.
mayton2019, а ложно-положительные срабатывания? Если я задам порог чувтствительности 5, то Левенштейн и Бронштейн будут одним и тем же. Если брать относительную чувствительность, т.е. поделить на кол-во букв в слове, то
Джон отличается от Джонатану на 125%
Джонатану от Джон на 55%
Левенштейн от Бронштейн на 55%
Nazar Markelov, имеетя ввиду, что python ООП неполноценный язык, чтото решается в нем "вручную", что-то не решается вообще. Если хочется ООП, то python плохой выбор. Если выбран python, а ООП нужно как его составляющая, то не вопрос.
Что такое ООП информации море. Как оперировать объектами в python тоже. Изучите синтаксис и пишите код, и смотрите как это делают другие (не в видосиках, а у спецов, например, в либах к языку). Понимание, что такое на самом деле ООП придет позже.
ООП это в первую очередь оперирование объектами, главное понять что, объект это не просто набор функций как в процедурном подходе.
И, все таки, не любой язык, python как раз не имеет модификаторов доступа и не только их.
mayton2019, Джон и Джонатану, Левенштейн по ним даст различие 5, т.е. по нему это абсолютно разные вещи.
Триграмный поиск упрется в тоже самое.
Фонетический анализ тоже мало чем поможет, разве что в варианте Джон и Джонатану, и то, только за счет совпадения начал слов.
Здесь только словарь и никак иначе, это реально разные слова.
Николай Савельев, тогда не факт, что он работает. Если он не подписан работодателем, то он не заключен. Также есть еще понятие "допуск к работе", могут и на него сослаться.
Но, если в электронной трудовой уже есть запись, то очень странно.
Про резидентство я упомянул, как стимул разорвать договор, если это интересно. Там не обязательно полгода, резидентство можно и раньше поменять.
Little_Junior, в первую очередь нужно задать себе вопрос, а зачем вы вообще делили на 2 базы данных? Если они неразрывно связаны и просто для логического деления, то ответ очевиден. Если эти базы независимы и в перспективы могут быть разнесены на разные серверы, то тоже понятно. Во втором случае, если вы боретесь за каждую мс, то можно сделать подключения в разных объектах, но которые будут использовать одно физическое подключение, подставляя нужное название базы при каждом обращении к таблице. В таком случае, будет легко переключиться на работу на двух физически разных СУБД.
В первом случае при генерациями каждый раз возникают запросы в базу, во втором случае количество запросов меньше, но надо хранить много файлов и следить за ними: удалять при обновлении исходного документа, как пример.
Собственно сами все понимаете, но если это не позволяет вам выбрать решение, то выбирайте то, которое проще. Т.е. генерите на лету, а когда базе реально станет тяжело, тогда и сделаете кеширование.
Автор хочет 2 отдельные строки, чтобы можно было с ними отдельно работать.
Тут sed излишен, можно обойтись и встроенным оператором баш. Но если очень хочется на sed, то нужно изменять обработку отдельных строк на весь текст, либо мудрить с буффером, либо просто использовать другой разделитель для перевода строк.
Если нет возражений по поводу этого решения, то значит мы друг друга недопоняли и спорим не о том.