Все эти особенности легко обнаружить еще на стадии чтения документации. Самое интересное начинается при моделирование таблиц, агрегатов. Немного моего опыта работы с ksql:
1) Написать запрос для создания агрегата действительно очень легко и быстро. Но сразу возникает вопрос, а как проинициализировать изначальные данные? Часто бывает, что топик-источник либо слишком огромный, чтобы его перечитывать, либо вообще нету данных старее X лет. И в таком случае приходится городить специальный инициализирующий топик агрегат и из-за этого монстра вся модель данных из простой и красивой превращается в что-то сложное и непонятное. 2) Изменения схемы агрегатов практически невозможно, так что если вам необходима будет дополнительная колонка, то скорее всего придется делать новый агрегат. И тут вы либо придете к якорной модели, либо придется выдумывать сложный механизм создания нового агрегата и миграции старых данных.
---
В целом текущее состояние развития технологий в стриминговой обработки пока очень плохо работает с агрегатами для которых необходимо хранить состояние. Если хочется легко и быстро, то пока это только агрегаты с маленьким окном в минуты/часы, максимум день, для которых не нужна история всех данных
Часто используемый скрин приложения отправлял impression аналитику при прокрутке экрана с дублированием. Например если вы видели на экране “XYZ” 10 раз прокрутив контент вверх вниз несколько раз, то аналитика отправлялась 10 раз. Хоть 1 раза было достаточно.
А с каких пор для аналитики это стала проблема? мне кажется это автор своим решением сделал проблему для аналитиков
Спасибо за ссылки. Видимо я пока плохо разобрался, попробую перефразировать вопрос.
Точкой подключения для клиента (приложения) что является? какой-то конкретный мастер сервер? Или у вас умный клиент и он сам определяет куда подключится?
А где можно почитать про общую архитектуру? из статьи и из оф. документации так до конца и не понял как она устроена. В кластере один мастер и несколько slave? При этом все запросы идут через мастер и проксируются на рабочие ноды(Tablet), потом результат собирается на мастере и отдается клиенту?
и я так понял под капотам там key->value хранилище?
Очень крутая статья, спасибо!
Из стати не совсем понял в какой момент вы накатываете миграции БД? В момент деплоя или в момент старта приложения? И почему именно такой способ?
Есть ли у вас какой-то отдельный процесс ревью миграций (а то вдруг кто-то захочет добавить индекс на проде в не concurrently режиме)?
А есть какие-то рекомендации по кол-ву сегментов? Какое-то минимально кол-во сегментов, при которых исползование GreenPlum уже будет оправдано? Сейчас исползуем 6 сегментов на 3 серверах и результат не лучше, а временами даже хуже, чем на одном инстансе Postgress.
чтот цифры какие-то нереальные. Вложив 40 миллионов долларов, они хотят выпускать 4,5-18 млн устройств в год?
т.е. при цене устройства более 10$, инвестиции окупятся за год. И кому они собрались продавать столько устройств?
Все эти особенности легко обнаружить еще на стадии чтения документации. Самое интересное начинается при моделирование таблиц, агрегатов.
Немного моего опыта работы с ksql:
1) Написать запрос для создания агрегата действительно очень легко и быстро. Но сразу возникает вопрос, а как проинициализировать изначальные данные? Часто бывает, что топик-источник либо слишком огромный, чтобы его перечитывать, либо вообще нету данных старее X лет. И в таком случае приходится городить специальный инициализирующий топик агрегат и из-за этого монстра вся модель данных из простой и красивой превращается в что-то сложное и непонятное.
2) Изменения схемы агрегатов практически невозможно, так что если вам необходима будет дополнительная колонка, то скорее всего придется делать новый агрегат. И тут вы либо придете к якорной модели, либо придется выдумывать сложный механизм создания нового агрегата и миграции старых данных.
---
В целом текущее состояние развития технологий в стриминговой обработки пока очень плохо работает с агрегатами для которых необходимо хранить состояние. Если хочется легко и быстро, то пока это только агрегаты с маленьким окном в минуты/часы, максимум день, для которых не нужна история всех данных
Проблема
Часто используемый скрин приложения отправлял impression аналитику при прокрутке экрана с дублированием. Например если вы видели на экране “XYZ” 10 раз прокрутив контент вверх вниз несколько раз, то аналитика отправлялась 10 раз. Хоть 1 раза было достаточно.
А с каких пор для аналитики это стала проблема? мне кажется это автор своим решением сделал проблему для аналитиков
Спасибо за ссылки.
Видимо я пока плохо разобрался, попробую перефразировать вопрос.
Точкой подключения для клиента (приложения) что является? какой-то конкретный мастер сервер? Или у вас умный клиент и он сам определяет куда подключится?
А где можно почитать про общую архитектуру? из статьи и из оф. документации так до конца и не понял как она устроена.
В кластере один мастер и несколько slave? При этом все запросы идут через мастер и проксируются на рабочие ноды(Tablet), потом результат собирается на мастере и отдается клиенту?
и я так понял под капотам там key->value хранилище?
Из стати не совсем понял в какой момент вы накатываете миграции БД? В момент деплоя или в момент старта приложения? И почему именно такой способ?
Есть ли у вас какой-то отдельный процесс ревью миграций (а то вдруг кто-то захочет добавить индекс на проде в не concurrently режиме)?
Решили присмотреться к этой системе как к in-memory DISTRIBUTED SQL, но результаты пока совсем не впечатляют
т.е. при цене устройства более 10$, инвестиции окупятся за год. И кому они собрались продавать столько устройств?