Евгений Вольф, не думаю, что есть большая разница между втроенным функционалом и функционалом расширения. Но я больше спрашивал об опыте работы с многопоточностью в 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
В общем, яснее не стало, нужно еще разбираться с планами запросов.
Игорь, поэтому и писал, что можно не столкнуться, все зависит от специфики, не все пишут демонов на PHP.
По-моему учить все что под руку попадется, ради "было бы не плохо", это просто тратить время и в итоге не уметь ничего полезного. Учить ассемблер? Зачем? Это уже третья ниша, совсем иная. Где планируете применять? Ладно бы Си (про web видно уже речи не идёт), но ассемблер? Когда, уже для микроконтроллеров пишут на java. Причем какой именно ассемблер?
Хотя, если подразумевается, просто узнать что такое прерывания, регистры и уметь разобраться в несложном коде, то это все таки не знание. Сложностей в таком изучении не будет, если, конечно, не с этого начинать, но и пользы для изучения языков высокого уровня немного.