This message was deleted.
# general
s
This message was deleted.
a
every solution is not solution Boy
you should consider milionse of events are comming per second and we want change state of each row/user ...they are related together ......
d
Good luck.
a
suppose the ram down what happen for stream
how much is shi...t
r
alive with million of events in the same leaderboard? that's unusual, and will require unusual software. I would recommend to enter in contact with redis enterprise bc even clustering will not help you if you really want just one big board with a very very long tail
if you have a lot of small leaderboards, then you can use redis with replica for failvover, and kafka for replaying when things goes bad and you need to reprocess until the last savepoint
a
hi the problem is just not (sorting)a leader board. we should process new event consume it for past events match to rank 1 if remained more amount match it to second rank if not match add it to somewhere is best rank for it...🙂
redis is nice for persisting it even we can replicate but it has not processing part .... we should compute new board also when new orders comming always......it is a stream problem but also at same time a board
d
Sounds like a moving average, but instead a moving leader board. The problem is if you are always adding and always removing you have to always be recalculating. If you know the duration of time between something entering and leaving the board, you could have one real time stream and another delayed stream and the real time stream adds and the delayed stream removes. You are probably going to have to develop something bespoke.
a
i am thinking more to know whether it is streamble or not ..
r
I'm not sure I'm following, but if it's a moving avg problem, then it's possible to use kafka-stream to emit the avg when it changes, and capture the change to update the ranking somewhere else kafka-stream internally uses a RocksDB to store the stateful info required by the windowing and other processing, and it's somewhat crash-resilient
I would start with ksql, instead of building direly over kafka-stream
a
Kafk-stream can not access to past events ....we discussed before kafka stream partioning data in network ...just spark can be model it in memory
r
the window is bigger than the kafka retention? because i'm pretty sure that you can read past data if it's stored in the topic
with this ksql code it writes a java program using kafka-stream to do the heavy part it will keep emitting for each key at regular interval if there's changes then you can use it to save into another topic to update the ranking in redis or other tool
a
i dont know what are you taliking about
r
ksql is sort of a spark but when the source and destination is a kafka
a
ksql is nothing just is sql lang of kafka
d
So I guess it would be that, but instead of avg it would be sum for this use case.
r
you write the instructions in sql, it compile into a program that can run in cluster mode across multiple workers, etc
d
That's really interesting. I will have to investigate using this in the future.
a
this problem is not moving average
it is matching engine
moving avg🤣