планируются ли плюшки SQL:2011? в частности интересуют темпоральные таблицы. у конкурентов либо медленно (MariaDB - возможно поддерживает на колоночном движке, но сомнительно и вряд ли блещет стабильностью), либо безумно дорого (Oracle, SQLServer - вроде даже умеет поверх колоночных) , либо в виде плагинов сомнительной свежести (у PostgreSQL вроде к какой-то из версий было, производительность хз), либо вообще эзотерика (CockroachDB - темпоральные таблицы есть, но с нюансами). Сноуфлейк с его 90 дней и сложными присинговыми моделями тоже как-то не очень обнадеживает.
Хотелось бы видеть на рынке что-то, что позволяло бы компактно (на уровне кликхауса) хранить данные, и при этом гулять по их изменениям.
вот только изобрели не до конца. имеет смысл сразу и использовать созданный класс, а не пытаться обмануть IDE.
И самое главное, смысл не в том, что так надо делать всегда, а в том, что если других вариантов нет (ограничены по времени и т.д. и т.п.), то можно применить эту технологию.
смысл как раз в том, что описывать данные классами стоит как можно чаще. ну без фанатизма, но вы поймите, массивы это как раз от бедности, когда нужно быстро и можно тяп-ляп. массивы в PHP это очень мощный инструмент и использовать его можно абсолютно по-разному, поэтому и используют его кто на что горазд. но если мы хотим, чтоб проект был поддерживаемым, а люди, с ним работающие, не себе рвали волосы в труднодоступных местах, то использование DTO это очень замечательная практика.
ассоциативные массивы это замечательно, а на 8.1 с jit местами даже быстрее SplFixedArray и, внезапно, ds (ну или у меня специфика приложения такая попалась).
просто многие любят их использовать в местах, где вместо массива должен быть объект, поэтому исторически сложилась нелюбовь к такой широте подхода, а заодно и к массивам.
Для осознаний масштаба, размер базы данных postgresql >250Гб (с индексами)
ну 250гб это не много, у нас в марии 8тб лежат, есть таблица весом 45гб с индексом на неё 50гб. и даже это как-то язык не поворачивается назвать масштабом.
Раньше «бутстрап» нашего аппа занимал более 120мс
это очень странные показатели. такое ощущение что это без опкеша вообще.
Некоторый выгрыш, например, мы получили тем, что убрали хранение кеша для доктрины из редиса внутрь shared in memory хранилице для всего пода — тем самым снизили накладные расходы на сетевую задержку.
ну это можно было и в php-fpm сделать, через тот же shmop. может у вас там редис был в другом полушарии с каналом 1мбит и весь выигрыш случился из-за этого.
в общем да, сложно о чем-то судить. такое ощущение что оптимизацией не занимались вообще, будто крутился php-fpm, где в дефолтных конфигах поменяли только количество воркеров.
описание утилизации ресурсов до переезда на swoole выглядит так, будто вы там Множество Мандельброта считали на каждый запрос.
не пользовался конкретно octane, но в таком подходе не вижу никаких вообще преимуществ. тем более с тех пор как в 7.4 появился preload. может какие-то очень узкие юзкейсы, которые так в голову и не придумаются сходу. но в целом это редкость, потому что php очень хорошо масштабируется вширь и проблемы обычно в другом.
асинхронщина в пхп обычно применяется либо для легких api, либо в фоне: работа с сокетами (в частности вебсокетами, но не только), обработка событий - например, у нас на реакте крутятся воркеры для очередей. скрапперы всякие хорошо пишутся в асинхронной манере.
кроме того разнообразные приложения удобно писать - php клиент телеграма использует amphp. у меня есть наброски моста для расшаривания файлов из телеграма в веб (на уровне альфа версии), тоже на amphp писал. в черновиках валяются зачатки статьи, но похоже что дописать её будет сложней, чем стабилизировать свой проект :) еще нашел очень интересную библиотеку (синхронную) - https://github.com/krowinski/php-mysql-replication, по бенчмаркам у меня выжимает 40к событий в секунду с загрузкой ядра на 100%, в мыслях скрестить её с amphp и прикрутить многопоточный парсинг на основе amphp/parallell и, возможно, FFI, чтоб посмотреть сколько можно выжать в таких сценариях в принципе. благо с файберами теперь должно быть проще простого.
radiative cooling это когда тело, излучая тепло, теряет температуру. и radiation (radiative) тут значит лишь "излучение", а "радиация" вовсе не причем.
pcntl_fork это не про многопоточность, так как к потокам не относится вообще. это про многопроцессность. еще параллельных процессов можно наспаунить, например, через proc_open.
для многопоточности от слова "потоки" есть pthreads и parallel.
в parallel, кстати, есть каналы. в остальных подходах они с переменным успехом эмулируются.
я помню как я облизывался глядя на темы windowblinds. была, конечно, бесплатная StyleXP, но она очень недотягивала.
а пределом мечтаний до сих пор остается эта тема, но я даже не уверен что таковая действительно существовала и это не просто чьи-то фантазии еа тему как могло бы быть.
Вроде всё просто. Конечно мы могли бы отправить скачанное аудио-сообщение сразу в Wit без предварительного сохранения на диск, но аудио-файл скачанный из telegram кодирован в OGG
ну, мы все еще можем отправить его без сохранения, в каком бы формате он ни был.
не знаю насчет стандартных средств, но есть sandboxie - в ней можно создавать разнообразные песочницы и в них запускать приложения, тогда приложения запущеные в песочнице изменяют теневую копию файла.
либо вообще shadow defender, там все изменения файловой системы, кроме доверенных, живут до перезагрузки системы.
c этим отлично помогает, например, proxifier
планируются ли плюшки SQL:2011?
в частности интересуют темпоральные таблицы.
у конкурентов либо медленно (MariaDB - возможно поддерживает на колоночном движке, но сомнительно и вряд ли блещет стабильностью), либо безумно дорого (Oracle, SQLServer - вроде даже умеет поверх колоночных) , либо в виде плагинов сомнительной свежести (у PostgreSQL вроде к какой-то из версий было, производительность хз), либо вообще эзотерика (CockroachDB - темпоральные таблицы есть, но с нюансами). Сноуфлейк с его 90 дней и сложными присинговыми моделями тоже как-то не очень обнадеживает.
Хотелось бы видеть на рынке что-то, что позволяло бы компактно (на уровне кликхауса) хранить данные, и при этом гулять по их изменениям.
вот только изобрели не до конца. имеет смысл сразу и использовать созданный класс, а не пытаться обмануть IDE.
смысл как раз в том, что описывать данные классами стоит как можно чаще.
ну без фанатизма, но вы поймите, массивы это как раз от бедности, когда нужно быстро и можно тяп-ляп. массивы в PHP это очень мощный инструмент и использовать его можно абсолютно по-разному, поэтому и используют его кто на что горазд. но если мы хотим, чтоб проект был поддерживаемым, а люди, с ним работающие, не себе рвали волосы в труднодоступных местах, то использование DTO это очень замечательная практика.
посмотреть хорошие практики, как это реализовать и использовать, можно например, тут - https://github.com/spatie/data-transfer-object
поздравляю, вы изобрели Data Transfer Object
я думаю он имел ввиду сопереживание описанной истории. читается очень легко, мне прям на одном дыхании зашло.
насчет лени, невозможности сходить самому в магазин и прочее - будто про себя читал :)
в случае с объектом класса у вас есть гарантия, что объет обладает некоторыми свойствами и т.д.
в случае, если на этом месте массив, у вас есть только честное слово и надежда.
ассоциативные массивы это замечательно, а на 8.1 с jit местами даже быстрее SplFixedArray и, внезапно, ds (ну или у меня специфика приложения такая попалась).
просто многие любят их использовать в местах, где вместо массива должен быть объект, поэтому исторически сложилась нелюбовь к такой широте подхода, а заодно и к массивам.
мало того, сейчас через решетку пишутся атрибуты
ну 250гб это не много, у нас в марии 8тб лежат, есть таблица весом 45гб с индексом на неё 50гб. и даже это как-то язык не поворачивается назвать масштабом.
это очень странные показатели. такое ощущение что это без опкеша вообще.
ну это можно было и в php-fpm сделать, через тот же shmop. может у вас там редис был в другом полушарии с каналом 1мбит и весь выигрыш случился из-за этого.
в общем да, сложно о чем-то судить. такое ощущение что оптимизацией не занимались вообще, будто крутился php-fpm, где в дефолтных конфигах поменяли только количество воркеров.
описание утилизации ресурсов до переезда на swoole выглядит так, будто вы там Множество Мандельброта считали на каждый запрос.
не пользовался конкретно octane, но в таком подходе не вижу никаких вообще преимуществ. тем более с тех пор как в 7.4 появился preload. может какие-то очень узкие юзкейсы, которые так в голову и не придумаются сходу. но в целом это редкость, потому что php очень хорошо масштабируется вширь и проблемы обычно в другом.
асинхронщина в пхп обычно применяется либо для легких api, либо в фоне: работа с сокетами (в частности вебсокетами, но не только), обработка событий - например, у нас на реакте крутятся воркеры для очередей. скрапперы всякие хорошо пишутся в асинхронной манере.
кроме того разнообразные приложения удобно писать - php клиент телеграма использует amphp. у меня есть наброски моста для расшаривания файлов из телеграма в веб (на уровне альфа версии), тоже на amphp писал. в черновиках валяются зачатки статьи, но похоже что дописать её будет сложней, чем стабилизировать свой проект :) еще нашел очень интересную библиотеку (синхронную) - https://github.com/krowinski/php-mysql-replication, по бенчмаркам у меня выжимает 40к событий в секунду с загрузкой ядра на 100%, в мыслях скрестить её с amphp и прикрутить многопоточный парсинг на основе amphp/parallell и, возможно, FFI, чтоб посмотреть сколько можно выжать в таких сценариях в принципе. благо с файберами теперь должно быть проще простого.
в общем вот вам и асихнронный php.
radiative cooling это когда тело, излучая тепло, теряет температуру. и radiation (radiative) тут значит лишь "излучение", а "радиация" вовсе не причем.
если, конечно, вы не нейросеть google translate.
pcntl_fork это не про многопоточность, так как к потокам не относится вообще. это про многопроцессность. еще параллельных процессов можно наспаунить, например, через proc_open.
для многопоточности от слова "потоки" есть pthreads и parallel.
в parallel, кстати, есть каналы. в остальных подходах они с переменным успехом эмулируются.
я помню как я облизывался глядя на темы windowblinds. была, конечно, бесплатная StyleXP, но она очень недотягивала.
а пределом мечтаний до сих пор остается эта тема, но я даже не уверен что таковая действительно существовала и это не просто чьи-то фантазии еа тему как могло бы быть.
ну, мы все еще можем отправить его без сохранения, в каком бы формате он ни был.
например,
вполне валидная запись
не знаю насчет стандартных средств, но есть sandboxie - в ней можно создавать разнообразные песочницы и в них запускать приложения, тогда приложения запущеные в песочнице изменяют теневую копию файла.
либо вообще shadow defender, там все изменения файловой системы, кроме доверенных, живут до перезагрузки системы.
потому что не всем и не всегда нужна симфони, но при этом некоторые не готовы мириться с приколами ларавеля, например?
не знаю как там с другими языками, но в случае с php вам как минимум нужно
отключить буфферизацию в PDO (или какой там драйвер вы используете)
отключить буфферизацию ответа самого php (ob_... функции)
отключить буфферизацию сервера (например, для nginx
fastcgi_buffering off;)вы уверены, что выполнили хотя бы эти действия?
ну так файберы же добавили, вот вам и асинхронность и параллельность будет.