Статья отличная и опыт полезный для рефлексии. Жалко что не сделаны (или не написаны) правильные выводы.
К проблемам привело применение неподходящего паттерна, стрельнуть могло в других местах и тонкостях.
Как можно было бы это условно почувствовать - для реализации необходим набор «костыликов» вида «тут не индексируй», «тут добавь условий», уникальный индекс не уникальный и прочее… Это и должно наводить на подозрения/сомнения.
Можно было просто держать отдельную базу для аналитики, все работало бы без «особенностей».
Нелинейный рост объема памяти скорее всего связан с особенностями заполнения hashMap/slice и массивов в php при неизвестном заранее размере, если я не ошибаюсь, при выходе за границы размер удваивается и в PHP и в Go.
С эластиком сравнивал только финальное время получения агрегата (коннект по сети, выполнение запроса, получение результата), это было около 2ух лет назад данные не сохранились.
Если хранить список продуктов целиком «как есть», это потребует значительно больше оперативной памяти и сама структура будет менее эффективна для прохода. Простой пример: представим у нас есть миллион товаров, среди которых 2 красных телефона. Доступ к id этих двух товаров с условием «красный» будет стремится к константе
$list = $data['color']['red'];
В случае с полным хранением атрибутов товаров нам нужно будет обойти весь список, а это уже линейная зависимость от количества товаров в индексе.
Было несколько подходов с разными вариантами хранения данных, в каждом были свои + и -, где-то больше памяти, где-то больше CPU. Скорее всего, есть какие-то более подходящее экзотические структуры, пока текущий вариант кажется наиболее сбалансированный с учетом особенностей PHP и задачи подсчета агрегатов.
Конечно можно написать на C++ :-)
Контекст задачи был иной — использовать PHP, индекс в runtime с возможностью доступа из кода, исключить хождения по сети, упростить API. Если бы был выбор писать на C++ или использовать готовое решение, эта статья бы никогда не появилась.
Естественно Elastic/Sphinx лучше как решения, в нашем случае удалось от них временно отказаться и сэкономить на инфраструктуре и интеграции. Возможно возникнут потребности, которые потребуют перехода на другое решение и это нормально. Два года эта штука крутилась и не доставляла боли, сервис начал генерировать прибыль это уже победа.
Низкоквалифицированные сотрудники тоже любят фреймворки, чаще всего 1 конкретный, бывает не умеют писать SQL запросы руками и не знают базовых вещей типа: как работает автозагрузка, как работать с PDO и прочее.
Бывают проекты в которых вообще нет смысла велосипедить, взял любой фреймворк и накидал приложение за пару дней. Та же история в проектах с десятками и сотнями программистов, где нужны общие практики.
Есть проекты которые живут 7,10 и более лет (ни один фреймворк не переживает такой срок, превращаясь в легаси с устаревшими подходами), а миграция на новую версию может грозить полным переписыванием.
Спасибо, интересное решение. У нас есть триггеры на огромных таблицах и foreign keys на некоторых. Триггеры не позволяют использовать pt-schema-change. И отказаться от них нельзя.
Очень интересно! Особенно если это не про pt-online-schema-change, не сливает всю таблицу в репликацию, не аффектит триггеры и совместимо с foreign keys.
Спасибо, полезное замечание, подправил. Естественно привел не все настройки, только те которые показались интересными. У нас transaction_write_set_extraction = XXHASH64
У нас на 40 000 QPS жило достаточно долго и не было таких проблем, потом нагрузку снизили изменением архитектуры. Как понимаю тут боль совсем не в базе и не в монолите как таковом, а в архитектуре монолита, которая не позволяет шардировать данные. Чтобы не быть голословным:
В теме запчастей задача поинтереснее — обрабатывать запросы вида «колодки кашкай» (если в наименованиии товара нет указания применяемости). Ее тоже можно решить текдоком и sphinx.
Пришел за откровением, часто пытаюсь объяснить эти принципы на пальцах. К сожалению, очередная из многих статей, объясняющих что такое ООП, SOLID…
Начинающему студенту / программисту все это пустой звук, можно зазубрить но тяжело осознать.
Понимание что такое и главное зачем нужно ООП приходит намного позже “начала использования классов”. Понимание SOLID приходит с опытом разработки, запуска и поддержки проектов.
Полное осознание приходит уже после того, как вы вовсю используете эти принципы.
Мораль. Нужно быть внимательнее к предвестникам (очевидно они должны быть при игнорировании заголовков бэкенда), если что-то пошло не так, разбираться до конца. Явно были проблемы с кэшированием статики.
Спасибо за статью, интересная тема оказалось.
Для себя понял, что видимо индексированные массивы всетаки не до конца оптимизировали в 7ке по сравнению с fixed.
Статья отличная и опыт полезный для рефлексии. Жалко что не сделаны (или не написаны) правильные выводы.
К проблемам привело применение неподходящего паттерна, стрельнуть могло в других местах и тонкостях.
Как можно было бы это условно почувствовать - для реализации необходим набор «костыликов» вида «тут не индексируй», «тут добавь условий», уникальный индекс не уникальный и прочее… Это и должно наводить на подозрения/сомнения.
Можно было просто держать отдельную базу для аналитики, все работало бы без «особенностей».
С эластиком сравнивал только финальное время получения агрегата (коннект по сети, выполнение запроса, получение результата), это было около 2ух лет назад данные не сохранились.
Если хранить список продуктов целиком «как есть», это потребует значительно больше оперативной памяти и сама структура будет менее эффективна для прохода. Простой пример: представим у нас есть миллион товаров, среди которых 2 красных телефона. Доступ к id этих двух товаров с условием «красный» будет стремится к константе В случае с полным хранением атрибутов товаров нам нужно будет обойти весь список, а это уже линейная зависимость от количества товаров в индексе.
Было несколько подходов с разными вариантами хранения данных, в каждом были свои + и -, где-то больше памяти, где-то больше CPU. Скорее всего, есть какие-то более подходящее экзотические структуры, пока текущий вариант кажется наиболее сбалансированный с учетом особенностей PHP и задачи подсчета агрегатов.
Конечно можно написать на C++ :-)
Контекст задачи был иной — использовать PHP, индекс в runtime с возможностью доступа из кода, исключить хождения по сети, упростить API. Если бы был выбор писать на C++ или использовать готовое решение, эта статья бы никогда не появилась.
Естественно Elastic/Sphinx лучше как решения, в нашем случае удалось от них временно отказаться и сэкономить на инфраструктуре и интеграции. Возможно возникнут потребности, которые потребуют перехода на другое решение и это нормально. Два года эта штука крутилась и не доставляла боли, сервис начал генерировать прибыль это уже победа.
В узкоспециализированных задачах, где важна производительность фреймворк может быть обузой.
Роберт Мартин про фреймворки: youtu.be/2dKZ-dWaCiU?t=4032
Низкоквалифицированные сотрудники тоже любят фреймворки, чаще всего 1 конкретный, бывает не умеют писать SQL запросы руками и не знают базовых вещей типа: как работает автозагрузка, как работать с PDO и прочее.
Бывают проекты в которых вообще нет смысла велосипедить, взял любой фреймворк и накидал приложение за пару дней. Та же история в проектах с десятками и сотнями программистов, где нужны общие практики.
Есть проекты которые живут 7,10 и более лет (ни один фреймворк не переживает такой срок, превращаясь в легаси с устаревшими подходами), а миграция на новую версию может грозить полным переписыванием.
Позволяет накатывать binlog реплики в несколько потоков и значительно уменьшить отставание (при должной настройке)?
Почему вы не создаете удаленные команды? Возможно было бы проще найти сотрудников.
Пришел за откровением, часто пытаюсь объяснить эти принципы на пальцах. К сожалению, очередная из многих статей, объясняющих что такое ООП, SOLID…
Начинающему студенту / программисту все это пустой звук, можно зазубрить но тяжело осознать.
Понимание что такое и главное зачем нужно ООП приходит намного позже “начала использования классов”. Понимание SOLID приходит с опытом разработки, запуска и поддержки проектов.
Полное осознание приходит уже после того, как вы вовсю используете эти принципы.
Easy easy, real talk :)
Для себя понял, что видимо индексированные массивы всетаки не до конца оптимизировали в 7ке по сравнению с fixed.
не тестировали?
Теперь понял, вы убрали оверхэд на создание мелкого массива свойств вовсе.