Алекс Кузнец, git это свободная распределённая VCS, поэтому блокировать нечего. Если говорить о блокировании на внешнем сервере, куда вы положите код, то даже в этом случае ваша локальная версия никуда не денется. Подозреваете мировой заговор против себя, храните на внутреннем сервере или вообще только в локальной версии. Git тут совсем не при чем.
Евгений Вольф, вот и я даже не знаю кто бы пробовал многопоточность в PHP, а очень интересно. Но как демон вполне стабилен. А если акцентироваться на производительности и потреблении памяти, то это не про интерпретаторы вообще, не только PHP.
Евгений Вольф, не думаю, что есть большая разница между втроенным функционалом и функционалом расширения. Но я больше спрашивал об опыте работы с многопоточностью в PHP, если таковой был, то какие были сложности или может быть непреодолимые проблемы, которые заставили уйти от PHP при решении таких задач?
lovebarcafc, сокет поможет оперативно передать сообщение от сервера, когда тот узнает о новых данных, если сервер контролирует все потоки идущие на БД, то задача решена. Но если кто-то "додумался" использовать БД по-сути для сообщений, то придется еще и решать вопрос оповещения сервера о новых данных в БД. Тут либо тупо опрашивать постоянно БД, либо использовать всякие изощренные инструменты (как notify в PostgreSQL), либо переводить работу на сервер очередей, внутреннюю шину обмена или что-то подобное.
Почему нужно скидывать в файл? Может стоит выбрать другой способ передачи, если это для передачи? Как часто нужно актуализировать файл, достаточно ли будет по завершении скрипта?
JustScript88, только прежде изучите рынок, писать можно на чем угодно, но шанс продать работу очень разный. С node.js вас будут воспринимать как full stack, и вряд ли уйдете от верстки, но лучше сами полистайте вакансии.
Johnick, тоже немного потестил, получил достаточно странные результаты. Пробовал на MariaDB, MySQL, PostgreSQL. На каждой из них более выигрышными оказывались разные запросы. На MySQL действительно более быстрым получается вариант с OR, на остальных он сильно проигрывает из-за материализации подзапросов, в MySQL оптимизатор почему-то выбирает не материализацию, а subquery. На PostgreSQL запрос с OR уходил в астрал и не возвращался (более 2 минут ждать не стал, план показал дикую стоимость в сотни тысяч раз выше нормальных, на Partial Aggregate из-за Parallel Seq Scan). Решил переписать на более оптимальный и однозначный по работе оптимизатора (так мне казалось):
select count(*) from test
left join test1 on test.id=test1.id
left join test2 on test.id=test2.id
where test1.id is not null or test2.id is not null
И, действительно, он был быстрее всех запросов на всех СУБД, всех... кроме OR на MySQL.
Использовал таблицы с первичным ключом на 1 млн. строк с рандомными id. Все тесты на одной машине. count(*) чтобы IDE не подменял запрос и не ждать фетча. Получилось так:
MariaDB 10.3.14:
JOIN: 3.4c, OR: 9.4c, UNION: 4.6c, UNIONALL: 5.4c
MySQL 8.0.15:
JOIN: 8.3c, OR: 7.8c, UNION: 9.8c, UNIONALL: 15.1c
PostgreSQL 10.7:
JOIN: 1.6c, OR: >120c, UNION: 5.0c, UNIONALL: 2.1c
В общем, яснее не стало, нужно еще разбираться с планами запросов.