ну вот, разрабы редиса были с видением как у вас, и послали гугл… веселый тикет был помню.
Их уже 100 лет просят создать 2 системных поля (entrydate, lastupdate) с выборкой по ним, а они всё носом вертят....
Самое что не хватает и почему ютуб отказался от редиса это отсутствие выборки последних изменившихся данных начиная с чекпоинта и отсутствие автоматической метки что по ключу были изменения или аналогичного атомарного incrementAndSet
Кто не в курсе что нужно было им напомню:
1) hashIncrement key:videoid field:up
2) hashIncrement key:videoid field:watch
2) hashIncrement key:videoid field:otherfield
3) select hashes where lastchange > 'datetime'
Почему при stream+table когда приходит со стороны table нету тригера? что это за бред?
Например у нас полностью асинхронный сайт:
1) добавляются видео (генерим guid, отправляем в очередь)
2) в UI можно сделать сразу допустим like (отправляем в очередь) (не придирайтесь я для простаты восприятия).
окей для видео TABLE — всё логично.
НО специально делать table для лайков вместо stream, из за того что не можем гарантировать кто первый придет, это бред!
вопросики
1) как понимаю у вас идет запрос к ~api/addnewnotif, они записываются в базу, потом сервис раз в Nt сканирует базу, берет новые и отправляет?
1.1) если это так как вы решается горизонтальное масштабирования этого сервиса?
2) есть ли группировка? какую логику используете?
"которые называются GitLab UI, плюс стили в GitLab."
открыл чуть не помер, млн зависимостей, нужны какието предкомпиляторы, компиляторы, синтаксис использование настолько разный как будто его писали 10 поколений
например установил ubuntu server, через месяц после обновлений и просто работы докера он уже занимал 20гб (чисто убунту, исключив всё от докера и почистив apt пакеты). Это прям как на windows привет WinSXS.
Я опять со своими АТОМ :)
Поигрался, всё равно как то не так работает на больших файлах, можете пояснить как получается вы играетесь с параметрами atom\keyframe? и случайно не используете -movflags negative_cts_offsets
(This enables the initial sample to have DTS/CTS of zero, and reduces the need for edit lists for some cases such as video tracks with B-frames. Additionally, eases conformance with the DASH-IF interoperability guidelines. This option is implicitly set when writing ismv (Smooth Streaming) files)?
Такое ощущение что вы как то джойните фрайменты и получается что перематывать можно только на большие дистанции, допустим что тыкнув посередине файла, он начнем загружаться за 10 минут назад, а также визуально ползунок скакнет на этот диапазон назад, очень криво.
да не ясно откуда были вызовы и до каких серверов всё это дело шло.
Про 40мс до первого байта, серьезно? Я думаю ютуб бы их купил моментально....
хорошая статья.
Но не хватает ссылок или кода с примерами из раздела формы чата
когда нужно колоссальное горизонтальное масштабирование, тактика с надстройками\хаками\каком то lua \ или через подобие транзакций multi не подходит
ну вот, разрабы редиса были с видением как у вас, и послали гугл… веселый тикет был помню.
Их уже 100 лет просят создать 2 системных поля (entrydate, lastupdate) с выборкой по ним, а они всё носом вертят....
Самое что не хватает и почему ютуб отказался от редиса это отсутствие выборки последних изменившихся данных начиная с чекпоинта и отсутствие автоматической метки что по ключу были изменения или аналогичного атомарного incrementAndSet
Кто не в курсе что нужно было им напомню:
1) hashIncrement key:videoid field:up
2) hashIncrement key:videoid field:watch
2) hashIncrement key:videoid field:otherfield
3) select hashes where lastchange > 'datetime'
учите документацию, вы пишите статью о граблях, не зная о таком лимите…
Почему при stream+table когда приходит со стороны table нету тригера? что это за бред?
Например у нас полностью асинхронный сайт:
1) добавляются видео (генерим guid, отправляем в очередь)
2) в UI можно сделать сразу допустим like (отправляем в очередь) (не придирайтесь я для простаты восприятия).
окей для видео TABLE — всё логично.
НО специально делать table для лайков вместо stream, из за того что не можем гарантировать кто первый придет, это бред!
разве это еще не в бете? " data!.id" "data?.id"
второй вопрос про "антиспам", если есть 100 нотификаций в минуту, вы пошлете 100 писем на email?
вопросики
1) как понимаю у вас идет запрос к ~api/addnewnotif, они записываются в базу, потом сервис раз в Nt сканирует базу, берет новые и отправляет?
1.1) если это так как вы решается горизонтальное масштабирования этого сервиса?
2) есть ли группировка? какую логику используете?
столько примеров кода и не одной схемы, хоть бы в итог добавили
закройте удалите этот репозиторий, чтобы его публика не видела .
когда запускаешь ваш первый dockercompose появляется 3 volume, хотя указан только один, это что за магия?
"которые называются GitLab UI, плюс стили в GitLab."
открыл чуть не помер, млн зависимостей, нужны какието предкомпиляторы, компиляторы, синтаксис использование настолько разный как будто его писали 10 поколений
лучше расскажите сколько ты собрал денег
Я надеюсь вы знаете что внутри образа cp-kafka:5.5.0 прописан хитрый mount (можете посмотреть через инспект) и ваши монтировки в композе не верны.
например установил ubuntu server, через месяц после обновлений и просто работы докера он уже занимал 20гб (чисто убунту, исключив всё от докера и почистив apt пакеты). Это прям как на windows привет WinSXS.
Я опять со своими АТОМ :)
Поигрался, всё равно как то не так работает на больших файлах, можете пояснить как получается вы играетесь с параметрами atom\keyframe? и случайно не используете -movflags negative_cts_offsets
Такое ощущение что вы как то джойните фрайменты и получается что перематывать можно только на большие дистанции, допустим что тыкнув посередине файла, он начнем загружаться за 10 минут назад, а также визуально ползунок скакнет на этот диапазон назад, очень криво.
а нужно в начале! из за этого не перематываются
подскажите как обстоят дела с ATOM для перемоток в вебе, вы их получается теряете ?