За два года использования к нему нет никаких нареканий (за исключением того, что я описал в статье). Свою основную задачу выполняет стабильно. Главное держать его где-нибудь неподалёку от себя и не забывать ставить на ночь на зарядку. В целом здесь работает принцип "Настроил и забыл".
Все-таки я рассматривал именно разработчиков, которые реализуют бизнес логику. Но считаю, что можно отнести и автотестировщиков, и спецов по разработке БД. Касательно CI/CD - не готов ответить однозначно, нужна большая личная статистика общения, работы с этими специалистами.
Цель применения метамодели — прийти от общих слов к более осязаемым, которые однозначно понимаются большинством. Так что лучше бы использовать при формулировании story и задач.
На счет стандартов интервьюирования, боюсь, не совсем понимаю о чем речь.
Методологии (такие как SCRUM) никак не конкурируют с метамоделью. Просто они про другое. Так что эти модели легко можно применять совместно.
Описанная метамодель предназначена для того, чтобы не упускать важные детали именно в разговоре. Она не для письменного ТЗ по нормам ГОСТ. И пример иллюстрирует лишь эффект глухого телефона, а не кейс из жизни.
Вы можете добавить ещё серверов с kafka-streams. Например, если у вас будет 5 серверов вместо 2, то в моём примере на каждого будет приходиться по 2 партиции и, соответственно, в 2,5 раза меньше данных.
Под разделами темы вы имеете ввиду партиции топика кафки?
Если да, то выглядит это так.
Например, у вас в топике 10 партиций и топик читают две ноды kafka streams.
Каждая нода берёт себе по 5 партиций. Соответственно у каждой ноды в её локальной базе RocksDB будут данные только с этих 5 партиций.
При условии, что ноды находятся в одной consumer-группе, естественно.
Если данные не умещаются в локальную базу, то будете получать стандартные для этого исключения: no space left on device, GC overhead limit exceeded и т.п.
У KSQL “под капотом” всё та же kafka-streams. То есть все проблемы, которые я описал выше, имеют место быть и в случае с KSQL. Но при этом KSQL внешне выглядит ещё проще: вроде бы просто написал SQL запрос и радуйся.
Проблема в том, что такая простота обманчива. Без глубокого понимания, как это работает, она может стать большой проблемой при увеличении нагрузок на систему.
При повышении уровня абстракции всегда приносится в жертву производительность.
В случае с KSQL такая жертва, думаю, будет чересчур велика.
Также уточню, что опыта работы с KSQL в production у нас нет, так что рассуждения выше — это только рассуждения.
К сожалению, это не так просто, потому что код сильно завязан на структуру музыкальных данных, которая использовалась именно в Dizzy. Если будет другой плеер, придется проводить дизассемблирование заново. К тому же точность эмуляции AY-3-8912 в проекте достаточна, чтобы похоже воспроизводить данные мелодии, но ее будет мало для других мелодий.
И да, кстати, виза — через курсы (Терра стади)
Их условие — 20 часов в неделю. В моем случае решалось все просто. Я работаю по Москве с 8-17 (7-16 по местному времени). С октября, когда в Испании часы переводят на час назад я ездил на занятия с 15-18 (3 часа в день).
За два года использования к нему нет никаких нареканий (за исключением того, что я описал в статье). Свою основную задачу выполняет стабильно. Главное держать его где-нибудь неподалёку от себя и не забывать ставить на ночь на зарядку. В целом здесь работает принцип "Настроил и забыл".
Все-таки я рассматривал именно разработчиков, которые реализуют бизнес логику. Но считаю, что можно отнести и автотестировщиков, и спецов по разработке БД.
Касательно CI/CD - не готов ответить однозначно, нужна большая личная статистика общения, работы с этими специалистами.
Ссылка указана в подписи к картинке (к сожалению, они там неактивные).
При работе с большими данными сильно выручает Clickhouse. Он работает быстро и позволяет нам реализовывать все потребности бизнеса.
Если же говорить про написанный нами код, то здесь мы постоянно пользуемся профайлером и стараемся держать производительность на приемлемом уровне.
На счет стандартов интервьюирования, боюсь, не совсем понимаю о чем речь.
Методологии (такие как SCRUM) никак не конкурируют с метамоделью. Просто они про другое. Так что эти модели легко можно применять совместно.
Если да, то выглядит это так.
Например, у вас в топике 10 партиций и топик читают две ноды kafka streams.
Каждая нода берёт себе по 5 партиций. Соответственно у каждой ноды в её локальной базе RocksDB будут данные только с этих 5 партиций.
При условии, что ноды находятся в одной consumer-группе, естественно.
Если данные не умещаются в локальную базу, то будете получать стандартные для этого исключения: no space left on device, GC overhead limit exceeded и т.п.
Проблема в том, что такая простота обманчива. Без глубокого понимания, как это работает, она может стать большой проблемой при увеличении нагрузок на систему.
При повышении уровня абстракции всегда приносится в жертву производительность.
В случае с KSQL такая жертва, думаю, будет чересчур велика.
Также уточню, что опыта работы с KSQL в production у нас нет, так что рассуждения выше — это только рассуждения.
Их условие — 20 часов в неделю. В моем случае решалось все просто. Я работаю по Москве с 8-17 (7-16 по местному времени). С октября, когда в Испании часы переводят на час назад я ездил на занятия с 15-18 (3 часа в день).