напомню из соседней темы что нету в пульсаре для хайлоуда
1) на конкретное сообщение сказать "сейчас нет, повторить через 5 минут" , как это умеет Azure Service Bus ? ps. без принятия, и повторного забрасывания клона сообщения уже с delay в очередь.
2) есть ли в пульсар аналог ktable и можно ли делать join в новый ktable на основе двух других ktable?
3) может ли пульсар при оконной агрегации записывать только финальных результат окна ? а не как сейчас в кафке , если заселектить результирующий топик окна, то там будут все изменения, а не только финальные.
4) если хочу записывать из пульсара в db их фичей из коробки. Если такая возможность как отправка только финальной (сейчас поясни ниже) данных чтобы не убить db при супер изменяемых параметрах?
например в пульсаре будет супер изменяемая метрика колво кликов от всех пользователей от сайта , каждый клик = 1 сообщение и мы делаем по этому топику инкремент
в топике будет:
count: 500
count: 501
count: 502
В секунде допустим будут млны записей, так вот если их все пульсар будет слать в базу ,1) то DB умрет 2) это бессмысленно если нам не важен реалтайм.
1) использовал mongodb для отношения лайков для видео: VideoID:[userID] , почему? потомучто есть атомарность без транзакций и блокировок , тоесть db.addIfNotExist(videoId, userId), но появилась проблема , что появились популярные люди , их посты начали собирать по N млн лайков . На их форуме "профессионалы" ты всё правильно деалешь , но надо использовать bucket паттерн , я окей... но появилась еще проблема
2) использовав bucket паттерн поломалась пагинация , тоесть если бакеты все заполнены , то все отлично
10 | 10 | 10 | 10
но добавляем еще один лайк и создается новый бакет
1 | 10 | 10 | 10 | 10
И получается что если я возьму 1 бакет (отображаем на сайте самые новые), то выведется 1 запись , хотя можно больше .... "знаточки" предложили В КОДЕ while(count < pageSize) { db.loadMore} :D
3) попытался создать рекомендательную систему , для этого попытался с помощью механизма mongodb CreateView найти пересечения пользователей около 10 млн , и что вы думаете ? НЕ проворачивается , просто бесконечный (PS даже в JS такая операция пересечения пару секунд проворачивает)
Ладно про 3й пункт окей , но как быть в двумя первыми?
1) совместить абсолютно разные "микросервисные" которые по логике и смыслу работали идеально не зная об друг друга совместить в одну?
2) И самое главное это производительность , вы хотите в одну базу слить эти две логике , у которых в А - редчайшие обновления , Б(статистика) - невероятно сильная нагрузка и апдейты млн раз в секунду. Вы хотите в вашем подходе теперь чтобы тормозила невиновная А из за этого?
напомню из соседней темы что нету в пульсаре для хайлоуда
1) на конкретное сообщение сказать "сейчас нет, повторить через 5 минут" , как это умеет Azure Service Bus ? ps. без принятия, и повторного забрасывания клона сообщения уже с delay в очередь.
2) есть ли в пульсар аналог ktable и можно ли делать join в новый ktable на основе двух других ktable?
3) может ли пульсар при оконной агрегации записывать только финальных результат окна ? а не как сейчас в кафке , если заселектить результирующий топик окна, то там будут все изменения, а не только финальные.
4) если хочу записывать из пульсара в db их фичей из коробки. Если такая возможность как отправка только финальной (сейчас поясни ниже) данных чтобы не убить db при супер изменяемых параметрах?
например в пульсаре будет супер изменяемая метрика колво кликов от всех пользователей от сайта , каждый клик = 1 сообщение и мы делаем по этому топику инкремент
в топике будет:
count: 500
count: 501
count: 502
В секунде допустим будут млны записей, так вот если их все пульсар будет слать в базу ,1) то DB умрет 2) это бессмысленно если нам не важен реалтайм.
почему Flink а не pulsar ?
я вот не нашел ответов на свои вопросы:
1) использовал mongodb для отношения лайков для видео: VideoID:[userID] , почему? потомучто есть атомарность без транзакций и блокировок , тоесть db.addIfNotExist(videoId, userId), но появилась проблема , что появились популярные люди , их посты начали собирать по N млн лайков . На их форуме "профессионалы" ты всё правильно деалешь , но надо использовать bucket паттерн , я окей... но появилась еще проблема
2) использовав bucket паттерн поломалась пагинация , тоесть если бакеты все заполнены , то все отлично
10 | 10 | 10 | 10
но добавляем еще один лайк и создается новый бакет
1 | 10 | 10 | 10 | 10
И получается что если я возьму 1 бакет (отображаем на сайте самые новые), то выведется 1 запись , хотя можно больше .... "знаточки" предложили В КОДЕ while(count < pageSize) { db.loadMore} :D
3) попытался создать рекомендательную систему , для этого попытался с помощью механизма mongodb CreateView найти пересечения пользователей около 10 млн , и что вы думаете ? НЕ проворачивается , просто бесконечный (PS даже в JS такая операция пересечения пару секунд проворачивает)
Ладно про 3й пункт окей , но как быть в двумя первыми?
QUIC — это протокол поверх UDP
после этого сразу закрыл
сколько пытался понять так и не понял зачем графкл нужен если есть рест
не страшно , мы уже почти с рф дел и не имеем
и еще после него появилась байка которая как видим до сих пор жива "Для сервера
Масштабируемость: вы освобождаете потоки"
для клиента всё верно
для сервера "Для сервера
Масштабируемость: вы освобождаете потоки,"
не верно
зачем нам все этьи фичи , просто кратко напишите быстрей или нет хрома - всё ! больше ничего не нужно
н у как добавите так повторни шильните
web api + vue = идеально , другого не нужно
русского нету = не нужен
да всё не нужно , UI будет какойнибудь vue через PWA
Главное проблема в 2021 это не физическая память , а пожирании виртуальной
очень жду статью по данным ситуациям , спасибо!
да не описана самая большая проблема когда разделяешь при высокой нагрузки - это атомарность без транзакций и локов.
Например Видео хранит теперь только кол-во лайков , а кто лайкнул в отдельной таблице (или бд).
и теперь твой код превращается в две строки....
добрый день. сколько мб оперативной памяти потребляет при старте ?
тоесть вы хотите
1) совместить абсолютно разные "микросервисные" которые по логике и смыслу работали идеально не зная об друг друга совместить в одну?
2) И самое главное это производительность , вы хотите в одну базу слить эти две логике , у которых в А - редчайшие обновления , Б(статистика) - невероятно сильная нагрузка и апдейты млн раз в секунду. Вы хотите в вашем подходе теперь чтобы тормозила невиновная А из за этого?
согласитесь как ангуляр и реакт соснули у vue по чистоте понятности минимализму ?
знаю одну такую независимость....
Имеет очень большую таблицу в одной базе (сервисе контента)
И имеем статистику к этому контенту в базе 2 (сервисе статистике)
И вдруг понадобилась сделать join по ним с фильтрами для базы1 и сортировкой по базе2.
Удачи!!!