Ну вот я и пишу, что средний разраб у нас оказался без подозрений, что именно гуглить в области cs, и начал упарываться кешами как единственным известным ему эффективным способом оптимизаций.
Верно ли, что тогда мы считаем обязательными понимание medium-алгоритмов с литкода или хотя бы информированность о подходах к их решению?
light-уровень не рассматриваю, так как он - необходимый минимум, чтоб держать хеш-мапы правильной стороной вверх
у меня был кейс: бизнес хотел аналог реалтаймовых персональных рекомендаций. Нужно было достать из базы, условно, все "items", поскорить их функцией, персональной для юзера, выдать первые 100 из списка. Потом, если юзер промотал всю ленту рекомендаций, надо выдать вторые 100 элементов из списка.
Автор кода, который реализовывал задачу, доставал, скорил, вызывал .sort(), потом .slice(0, 100). Код был читабельным, работал за O (N log N). Автор заявил "ну оно ж влезает в память" и был прав. Всё вычисление повторялось и для второй страницы, только брался следующий slice из результата.
Потом с ростом базы, числа юзеров и общего qps началась беда - "влезает в память" перестало влезать, а те машины, на которых всё-таки памяти в определённый момент хватало, не успевали ответить за отведённый на запрос таймаут.
Автор исходного кода пытался обмазаться кешами. Но не помогало: кеши не заполнялись, ибо расчёты не могли закончиться. И не понятно, как персональные кеши для каждого юзера должны были решить проблему глобально.
И тогда настал мой звёздный час как задрота литкода: я модифицировал k-th order statistic (работает за O(n)), чтоб она ещё могла порционно данные подгружать и не ломаться. Сервис заработал, код стал трудночитаемым неподготовленным человеком.
К чему всё это:
Поймает ли тут проблему регрессионный тест или перформанс тест, если код не был ухудшен, а был изначально "плохо" написан?
Считаем ли этот код "плохим", если на момент его создания он вписывался в имеющиеся требования, а новые требования сформированы были через год в связи с ростом сервиса?
Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота? Просить начальство удвоить память на серверах в дц? а с O(N LogN), которое не укладывается в таймауты запросов что делать?
За 7 лет работы это был один конкретный случай, где мне пригодилось знание, как самому организовать сортировку быстро. Стоит ли ожидать такое знание от всех кандидатов? до сих пор не могу ответить себе на этот вопрос.
у ютуба есть тупость с премиумом: он недоступен там, где ютуб не монетизирует рекламу.
например, у меня был премиум, которым активно пользовался для скачивания и оффлайн прослушивания записей конференций. Потом я приехал в Армению и офигел, что у меня эта опция стала недоступна. Потому что "в этой стране youtube premium не нужен". Эй, корпорация, а за что я тебе денег занёс?
считаю, что стоит ещё сделать выжимку, чтобы сэкономить время хабровчанам.
она продала 40% бизнеса в нулевых Финаму, так как "тогда в нулевых это было модно". Это реально цитата из видео. Условия продажи она не читала, так как там очень большая стопка бумаг, а она не может себе позволить юристов за 100 000$, чтоб они прочитали стопку за неё. Не гиперболизирую, реально это её слова.
Потом владелец Финама переезжает в штаты, продаёт эту долю бизнеса инвестиционному фонду из США.
менеджеры из фонда относятся к бизнесу не как к семейному ремеслу, а именно как к бизнесу. Капают ей много лет на мозги, что её муж - гендиректор - владеет недостаточными скиллами, чтобы бизнес рос быстро. Требуют его заменить. Только требуют, сами поменять не могут - не хватает полномочий.
В подписанном ими договоре при продаже доли бизнеса обнаруживается, что фонд имеет право блокировать решения гендира. Напомню, что договор они не читали, и теперь считают, что их обманули.
Из-за морального давления менеджеров и блокировки решений ими же муж сам сдаёт пост гендира.
Удивляются, что теперь они совсем не управляют компанией.
в их докладах на highload++ говорилось, что это разные типы узлов CDN с разным географическим положением и разной конфигурацией для разных характеров нагрузок.
Кстати, вот это как раз самое интересное, и новость можно было бы превратить в статью. Интересно посмотреть на результаты измерений от самых простых, когда продаётся коробка с утюгом, до сложных, когда продаётся "турник для дома" в пакете, который имеет форму торчащих во все стороны "рогов".
А как оно определяет габариты "аморфных" товаров? например, пакет стирального порошка, который может быть и 30х30х30, и - если его утромбовать иначе в абсолютно том же пакете - 40х20х33.75?
но покупать на уже влитые в стим деньги, хранящиеся на внутреннем кошельке - можно. И с точки зрения данных для аналитиков это будет покупка, совершённая в россии
а я правильно понимаю, что теперь "эксперт" из суда может не суметь найти следов питерской ООО "ИнтеллиджейЛабс" и заявить, что IntellijIdea теперь принадлежит специальной аккредитованной компании?
докину ещё несколько трюков, которые в статье [вроде бы] не упомянуты:
Не ставить TTL константой в 2 часа, а рандомизировать в диапазоне 110-130 минут. Иначе ключи, появляющиеся одновременно (например, по крону), протухают тоже одновременно и разом бьют по базе.
Вместо продлевания TTL в решении проблемы "стаи собак" можно зайти с другой стороны - с некоторой малой вероятностью умышленно проигнорировать кеш и отправить один запрос читать напрямую из баз и обновлять ключ. Например, с вероятностью 0.001%. Если это настоящий хайлод-ключ с 1000qps - он будет обновляться раз в ~100 секунд без нагрузки на базу. Если ключ не по-настоящему хайлодный, то его протухание по ttl не ударит по базе.
В особо упоротых случаях вероятность делают динамической, и чем меньше времени осталось до протухания, тем выше делают вероятность "пробива" кеша.
И вопрос: вместо размазывания ключа по нескольким индексам сразу с разными префиксами/суффиксами вы выбрали in-memory-кеш с кафкой. Если вы знали о схеме с размазыванием ключей, но выбрали другую, то какие критичные для себя минусы вы увидели в схеме с размазыванием?
Почему спрашиваю: когда-то на проекте с такими же qps довольно неплохо жили как раз на размазывании, и массовая инвалидация не требовалась: требовалось массовое обновление до актуального состояния. И тогда тот кусок бизнес-логики, который обновлял данные в бд, сам актуализировал их в N репликах ключа, новая нагрузка на кеши и базу не создавалась, обновлённые данные были видны всем. А если и были ошибки сети на обновлении 1 ключа, то они случались так редко, что залипшая 1 из N реплик данных нам вредила не очень сильно как раз из-за сравнительно быстрой актуализации через трюк №2.
p.s.: имхо, странно, что в статье делается много акцента на инвалидации кешей, а не на их актуализации. Хотя это намного более приятная процедура.
ВКонтакте, Инста. не обязательно рекламные блоки, это может быть и вполне "органический" посев, когда просто паблики сами постят Аяза как рекомендацию. Та же реклама, но не блочится адблоком.
Кроме того, Аяз и Артём "штора" Маслов являются своего рода мемами среди SMM-специалистов, потому что они реально в периоды пиковой активности заполняют собой всё медиапространство.
Кроме SMM инфоцыгане довольно сильно мешают сервисам аналитики рекламного трафика, так как эти сервисы ловят баны доменов от меты и вк за "скам", потом долго разбираются, как восстановить бизнес. И у меня есть знакомые, которые от них пострадали так.
И при масштабах их курсов даже среди ваших знакомых должны затесаться любители быстрой халявы, которая лежит у всех на виду, просто никто не видит, а Аяз сейчас покажет на неё. Вот у меня такие знакомые есть.
Так что это надо жить в каком-то информационном вакууме, чтобы никогда в жизни не столкнуться с их деятельностью.
"лучшие компьютерные игры", "навигатор игрового мира", "game.exe", и прочие умерли с приходом интернета. "Игромания" худо-бедно адаптировалась под видео-форматы и интернет-статьи и продолжила существование в каком-то виде, но всё равно страдает от обилия альтернативных площадок.
Печатные издания проигрывают прогрессу. Требовать решить эту проблему законодательно - какой-то сюр.
так в аду будут гореть те, кто не обработал исключение где-то глубже.
+ кроме "неизвестной ошибки" интерфейс должен предложить отправить отчёт о ней, где будет распечатано это непойманое исключение + дебаг-инфа окружающего контекста.
ну и "попало туда, где уже непонятно, что конкретно случилось" фиксится тем, что в исключения разных этажей подкладывают поле causedBy: Exception. в результате видна цепочка проблем на всех этажах софта. Да, это не решает проблему на 100%, но это наааамного лучше, чем "oopsie-woopsie, something wrong"
Ну вот я и пишу, что средний разраб у нас оказался без подозрений, что именно гуглить в области cs, и начал упарываться кешами как единственным известным ему эффективным способом оптимизаций.
Верно ли, что тогда мы считаем обязательными понимание medium-алгоритмов с литкода или хотя бы информированность о подходах к их решению?
light-уровень не рассматриваю, так как он - необходимый минимум, чтоб держать хеш-мапы правильной стороной вверх
у меня был кейс: бизнес хотел аналог реалтаймовых персональных рекомендаций. Нужно было достать из базы, условно, все "items", поскорить их функцией, персональной для юзера, выдать первые 100 из списка. Потом, если юзер промотал всю ленту рекомендаций, надо выдать вторые 100 элементов из списка.
Автор кода, который реализовывал задачу, доставал, скорил, вызывал .sort(), потом .slice(0, 100). Код был читабельным, работал за O (N log N). Автор заявил "ну оно ж влезает в память" и был прав. Всё вычисление повторялось и для второй страницы, только брался следующий slice из результата.
Потом с ростом базы, числа юзеров и общего qps началась беда - "влезает в память" перестало влезать, а те машины, на которых всё-таки памяти в определённый момент хватало, не успевали ответить за отведённый на запрос таймаут.
Автор исходного кода пытался обмазаться кешами. Но не помогало: кеши не заполнялись, ибо расчёты не могли закончиться. И не понятно, как персональные кеши для каждого юзера должны были решить проблему глобально.
И тогда настал мой звёздный час как задрота литкода: я модифицировал k-th order statistic (работает за O(n)), чтоб она ещё могла порционно данные подгружать и не ломаться. Сервис заработал, код стал трудночитаемым неподготовленным человеком.
К чему всё это:
Поймает ли тут проблему регрессионный тест или перформанс тест, если код не был ухудшен, а был изначально "плохо" написан?
Считаем ли этот код "плохим", если на момент его создания он вписывался в имеющиеся требования, а новые требования сформированы были через год в связи с ростом сервиса?
Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота? Просить начальство удвоить память на серверах в дц? а с O(N LogN), которое не укладывается в таймауты запросов что делать?
За 7 лет работы это был один конкретный случай, где мне пригодилось знание, как самому организовать сортировку быстро. Стоит ли ожидать такое знание от всех кандидатов? до сих пор не могу ответить себе на этот вопрос.
у ютуба есть тупость с премиумом: он недоступен там, где ютуб не монетизирует рекламу.
например, у меня был премиум, которым активно пользовался для скачивания и оффлайн прослушивания записей конференций. Потом я приехал в Армению и офигел, что у меня эта опция стала недоступна. Потому что "в этой стране youtube premium не нужен". Эй, корпорация, а за что я тебе денег занёс?
считаю, что стоит ещё сделать выжимку, чтобы сэкономить время хабровчанам.
она продала 40% бизнеса в нулевых Финаму, так как "тогда в нулевых это было модно". Это реально цитата из видео. Условия продажи она не читала, так как там очень большая стопка бумаг, а она не может себе позволить юристов за 100 000$, чтоб они прочитали стопку за неё. Не гиперболизирую, реально это её слова.
Потом владелец Финама переезжает в штаты, продаёт эту долю бизнеса инвестиционному фонду из США.
менеджеры из фонда относятся к бизнесу не как к семейному ремеслу, а именно как к бизнесу. Капают ей много лет на мозги, что её муж - гендиректор - владеет недостаточными скиллами, чтобы бизнес рос быстро. Требуют его заменить. Только требуют, сами поменять не могут - не хватает полномочий.
В подписанном ими договоре при продаже доли бизнеса обнаруживается, что фонд имеет право блокировать решения гендира. Напомню, что договор они не читали, и теперь считают, что их обманули.
Из-за морального давления менеджеров и блокировки решений ими же муж сам сдаёт пост гендира.
Удивляются, что теперь они совсем не управляют компанией.
хм, какая-то странная история про "отжим бизнеса", если ей не угрожали, и подписи она сама ставила под всем.
это не отжим, это результат наивности.
в их докладах на highload++ говорилось, что это разные типы узлов CDN с разным географическим положением и разной конфигурацией для разных характеров нагрузок.
https://sun9-44.userapi.com/impg/c857024/v857024708/197ce/VI9AiceJ2Ic.jpg?size=567x567&quality=96&sign=6caa56524830c6fae0df21de50a913ee&type=album
https://pp.userapi.com/impg/c857024/v857024708/197ce/VI9AiceJ2Ic.jpg?size=567x567&quality=96&sign=6caa56524830c6fae0df21de50a913ee&type=album
Одна и та же ссылка, но разные домены. Открываются обе. Но по одной из них хабраэффект будет больнее.
Кстати, вот это как раз самое интересное, и новость можно было бы превратить в статью. Интересно посмотреть на результаты измерений от самых простых, когда продаётся коробка с утюгом, до сложных, когда продаётся "турник для дома" в пакете, который имеет форму торчащих во все стороны "рогов".
А как оно определяет габариты "аморфных" товаров?
например, пакет стирального порошка, который может быть и 30х30х30, и - если его утромбовать иначе в абсолютно том же пакете - 40х20х33.75?
по ссылке один экстремизм. заблокировать!
платить из россии нельзя.
но покупать на уже влитые в стим деньги, хранящиеся на внутреннем кошельке - можно. И с точки зрения данных для аналитиков это будет покупка, совершённая в россии
а я правильно понимаю, что теперь "эксперт" из суда может не суметь найти следов питерской ООО "ИнтеллиджейЛабс" и заявить, что IntellijIdea теперь принадлежит специальной аккредитованной компании?
и FlipperZero государственным станет?
ничосе!
докину ещё несколько трюков, которые в статье [вроде бы] не упомянуты:
Не ставить TTL константой в 2 часа, а рандомизировать в диапазоне 110-130 минут. Иначе ключи, появляющиеся одновременно (например, по крону), протухают тоже одновременно и разом бьют по базе.
Вместо продлевания TTL в решении проблемы "стаи собак" можно зайти с другой стороны - с некоторой малой вероятностью умышленно проигнорировать кеш и отправить один запрос читать напрямую из баз и обновлять ключ. Например, с вероятностью 0.001%. Если это настоящий хайлод-ключ с 1000qps - он будет обновляться раз в ~100 секунд без нагрузки на базу. Если ключ не по-настоящему хайлодный, то его протухание по ttl не ударит по базе.
В особо упоротых случаях вероятность делают динамической, и чем меньше времени осталось до протухания, тем выше делают вероятность "пробива" кеша.
И вопрос: вместо размазывания ключа по нескольким индексам сразу с разными префиксами/суффиксами вы выбрали in-memory-кеш с кафкой. Если вы знали о схеме с размазыванием ключей, но выбрали другую, то какие критичные для себя минусы вы увидели в схеме с размазыванием?
Почему спрашиваю: когда-то на проекте с такими же qps довольно неплохо жили как раз на размазывании, и массовая инвалидация не требовалась: требовалось массовое обновление до актуального состояния. И тогда тот кусок бизнес-логики, который обновлял данные в бд, сам актуализировал их в N репликах ключа, новая нагрузка на кеши и базу не создавалась, обновлённые данные были видны всем. А если и были ошибки сети на обновлении 1 ключа, то они случались так редко, что залипшая 1 из N реплик данных нам вредила не очень сильно как раз из-за сравнительно быстрой актуализации через трюк №2.
p.s.: имхо, странно, что в статье делается много акцента на инвалидации кешей, а не на их актуализации. Хотя это намного более приятная процедура.
а x86 эквивалентно x86-64!
он поглажен?
ВКонтакте, Инста. не обязательно рекламные блоки, это может быть и вполне "органический" посев, когда просто паблики сами постят Аяза как рекомендацию. Та же реклама, но не блочится адблоком.
Кроме того, Аяз и Артём "штора" Маслов являются своего рода мемами среди SMM-специалистов, потому что они реально в периоды пиковой активности заполняют собой всё медиапространство.
Кроме SMM инфоцыгане довольно сильно мешают сервисам аналитики рекламного трафика, так как эти сервисы ловят баны доменов от меты и вк за "скам", потом долго разбираются, как восстановить бизнес. И у меня есть знакомые, которые от них пострадали так.
И при масштабах их курсов даже среди ваших знакомых должны затесаться любители быстрой халявы, которая лежит у всех на виду, просто никто не видит, а Аяз сейчас покажет на неё. Вот у меня такие знакомые есть.
Так что это надо жить в каком-то информационном вакууме, чтобы никогда в жизни не столкнуться с их деятельностью.
p.s.: а про Мавроди вы знаете? ну вдруг.
дело в том, что пока журналы месяц верстают отчёт о поездке на E3, куча персональных блогеров уже выпустила контент прямо в день проведения выставки.
аналогично с другими журналами - пока они верстаются, куча блогеров и просто новостных сайтов уже навыпускали материалов приемлемого качества.
этот прогресс я и описывал: теперь один и тот же контент могут нести в массы тысячи людей, а не 2-3 издания.
"лучшие компьютерные игры", "навигатор игрового мира", "game.exe", и прочие умерли с приходом интернета. "Игромания" худо-бедно адаптировалась под видео-форматы и интернет-статьи и продолжила существование в каком-то виде, но всё равно страдает от обилия альтернативных площадок.
Печатные издания проигрывают прогрессу. Требовать решить эту проблему законодательно - какой-то сюр.
дальше "внезапный самокатчик"
Приложу фрагмент портфолио студии.
Как по мне, озвучка у них, как бы помягче сказать: уж очень на любителя.
так в аду будут гореть те, кто не обработал исключение где-то глубже.
+ кроме "неизвестной ошибки" интерфейс должен предложить отправить отчёт о ней, где будет распечатано это непойманое исключение + дебаг-инфа окружающего контекста.
ну и "попало туда, где уже непонятно, что конкретно случилось" фиксится тем, что в исключения разных этажей подкладывают поле causedBy: Exception.
в результате видна цепочка проблем на всех этажах софта. Да, это не решает проблему на 100%, но это наааамного лучше, чем "oopsie-woopsie, something wrong"