Ух жесть. Битовый сдвиг и конкатенация строки на себя же чтобы немного уменьшить алгоритмическую сложность и нагрузку на GC, но оставив по-сути проблему треша на своём месте… Мир JS жесток и беспощаден. )))
Странно, что у автора этой заметки, ведущего инженера Stack Overflow, нет претензий к дичайшему гавнокоду в указанном "ключевом модуле" и что никто до сих пор его не выправил. Делать в цикле конкатенации по количеству необходимых символов с генерацией каждый раз нового String объекта на каждой итерации вместо "return ch.repeat(len — str.length) + str" — это какой-то эпикфейл.
И что? Вопрос же не в том, как хранить и преобразовывать, а в том, чтобы вообще не создавать тяжёлые объекты на каждый запрос, а пользоваться расшаренными. Кеши байткода избавляют от стадии компиляции. Но не избавляют от процесса создания объекта. А это те самые потерянные миллисекунды и процессорное время, которое вполне можно было бы потратить на что-то полезное. Да и конфиги — это малая из бед. Половину аппликейшена можно было бы реюзать если был бы нормальный инструмент. Естественно, апплекейшн пришлось бы изначально проектировать как стейтлесс, но это уже тема для отдельного топика.
Конечно, можно было бы использовать язык, изначально заточенный под event-loop или с легковесными потоками как в Go. Но не вижу никаких препятствий запилить нечто подобное и в Пыхе. Всё равно имхо к этому идёт.
Шарить что-то между серверами — это совсем другой уровень. Межпроцессный шаринг объектов очень пригодился бы для хранения тяжёлых read-only объектов вроде конфигов. На больших нагрузках может неплохо съэкономить на создании сокета, хендшейке, поиске информации в хранилище, отправке, закрытии соединения, десериализации. Всё это абсолютно лишнее, если уже готовый собранный конфиг лежит в виде zval где-то в памяти.
pthreads — совсем не то
shmop — почти то, если к нему ещё прикрутить мьютексы. И всё равно требует сериализации.
Идеально было бы: высокоуровневая языковая конструкция, позволяющая создавать и использовать объекты в разделяемой памяти с внутренней имплементацией exclusive&shared locking и TTL чтобы у дева голова об это не болела.
Я к тому, что идея shared memory в PHP имеет право на жизнь. Хранить сериализованные данные в одном из хранилищ — это не всегда выход. Собственно, APCU частично решает эту задачу. Но было бы круто вслед за мега-фичей в виде PHP FPM следующим шагом дать нативный инструмент работы с объектами в shared memory.
Мне довелось поработать с true Fast CGI на С++. Это ад. Но сама идея иметь объекты, живущие между запросами, жива и её вполне можно было бы органично имплементировать в стандарте языка.
Сериализация-десериализация крупных объектов может стать проблемой. Гораздо логичнее использовать уже созданный объект в shared memory. Конечно, это добавляет головняка с race conditions и на любое обновление данных придётся вешать мьютекс, но производительность сего решения может стоить того. Особенно если задача состоит в хранении крупного иммутабельного объекта вроде конфига, редко меняющегося и часто читаемого.
Данный подход хорош для атомарных сущностей. Если же для инициализации объекта необходима инициализация зависимостей, то тут уже без велосипеда на костылях не обойтись.
В моём понимании splitshard — это скорее скорая помощь при дизбалансе шарды, а не инструмент шардирования. Нативных инструментов шардинга в Solr два: composite и implicit методики шардирования. Оба с предзаданным количеством шард. И split, если что-то пошло не так.
Из моего личного опыта шардирование из коробки на 100 инстансов плюс пара кастомных плагинов а-ла триггеры моего авторства работало на постоянную дозаливку и апдейт 2 ярда+ широких документов как часы. Но изначально был выбран правильный двухуровневый ключ, благодаря которому запросы формировались максимум к 3 шардам.
Строго говоря, сильно смутил только один аргумент в статье «Автоматическая ребалансировка по шардам предполагает, что одна наша партиция может быть разбросана по нескольким шардам». Как это и почему?
ЗЫ. Три Solr инстанса на отдельных портах плюс ZK поднимается для дев-машин за полчаса. Зато каждый дев может сразу прочувствовать, как его запросы будут работать в распределённой среде. Ибо, как говорят у нас в Одессе, это две большие разницы. :)
Почему решили не использовать композитный ключ формата «batchId!docId» и запросы соответственно с указанием _route_? Это бы гарантировало попадание всех документов из одного батча в одну шарду и балансировку по пулу шард без дополнительных бубнов. В случае, если по-факту работы на проде будут появляться перекосы в размерах шард, в качестве решения всё тот же split.
Это может работать только на небольших датасетах. В ситуации, приближенной к боевой, когда одна модель может считаться сутки, рандомный перебор предикторов и поиск цепочки алгоритмов займёт время начиная приближенное к бесконечности.
Очистку данных, генерацию композитных предикторов вообще вряд ли получится автоматизировать.
И самое главное. Получение модели — это прекрасно для теоретиков и конкурсов. Главная задача — получить модель, пригодную к использовании в продакшене. И тут без человека точно не обойтись.
Интересно, что в парламенте в принципе много официально небедных людей. А в прокуратуре — сплошные выбросы. Вообще ни разу не коррумпированная структура, да.
Спасибо за интересные данные.
Что-то вспомнились из моего детства 4 дискеты, принесенные из института старшим братом моего друга, со словами «Это С++! Самый крутой язык в мире!» И тоненькая жёлтая книжка, сразу начинавшаяся с сакрального «Объект — это инкапсулированная абстракция, которая включает информацию о состоянии и чётко определённое множество протоколов доступа». Что это такое я понял только несколько лет спустя. :)
Конечно, можно было бы использовать язык, изначально заточенный под event-loop или с легковесными потоками как в Go. Но не вижу никаких препятствий запилить нечто подобное и в Пыхе. Всё равно имхо к этому идёт.
shmop — почти то, если к нему ещё прикрутить мьютексы. И всё равно требует сериализации.
Идеально было бы: высокоуровневая языковая конструкция, позволяющая создавать и использовать объекты в разделяемой памяти с внутренней имплементацией exclusive&shared locking и TTL чтобы у дева голова об это не болела.
Мне довелось поработать с true Fast CGI на С++. Это ад. Но сама идея иметь объекты, живущие между запросами, жива и её вполне можно было бы органично имплементировать в стандарте языка.
Из моего личного опыта шардирование из коробки на 100 инстансов плюс пара кастомных плагинов а-ла триггеры моего авторства работало на постоянную дозаливку и апдейт 2 ярда+ широких документов как часы. Но изначально был выбран правильный двухуровневый ключ, благодаря которому запросы формировались максимум к 3 шардам.
Строго говоря, сильно смутил только один аргумент в статье «Автоматическая ребалансировка по шардам предполагает, что одна наша партиция может быть разбросана по нескольким шардам». Как это и почему?
ЗЫ. Три Solr инстанса на отдельных портах плюс ZK поднимается для дев-машин за полчаса. Зато каждый дев может сразу прочувствовать, как его запросы будут работать в распределённой среде. Ибо, как говорят у нас в Одессе, это две большие разницы. :)
Очистку данных, генерацию композитных предикторов вообще вряд ли получится автоматизировать.
И самое главное. Получение модели — это прекрасно для теоретиков и конкурсов. Главная задача — получить модель, пригодную к использовании в продакшене. И тут без человека точно не обойтись.
Спасибо за интересные данные.
Первый персонаж шикарный. Круглая сирота без семьи и доходов. С квартирой в Киеве и Лексусом.