Hacker News Reader

Comment by bhouston | Hacker News Reader

Or just add to each user record the time of their last action if their last action is more than a day old (or what ever interval.) Given that you usually have the user record already in memory, this can be moderately efficient. Then you can pass through your user records linearly with no memory usage to figure out MAU, DAU, YAU, etc.

View on HN

Using a mutable "last active time" from some sort of users table is pretty dangerous for post-hoc analysis because if (when!) something goes wrong, the information is overwritten and gone forever. It's better to use immutable event logs as the post describes.

"pretty dangerous for post-hoc analysis because if (when!) something goes wrong, the information is overwritten and gone forever."

If your last active time table is being fumbled then yes, but I'd worry about all the other parts of your data if that was the case.

Dangerous is not something I would ascribe to a "last active time" table (except if you're using it for security audit purposes)

Mutable data does not give you any ability to analyse actions over a period of time. For example: "How many people were active during the month of the Indian Elections?" Can't tell you today, because all the data has been mutated away.

Secondly, mutable data also means that you have less scope of drawing new insights from historic data. (Primarily because you never have historic data)

And yet, file systems have backtracked from having a 'last accessed' timestamps for files for performance reasons (http://en.wikipedia.org/wiki/Stat_(system_call)#Criticism_of...). Moderately efficient it may be, but many OS experts think its performance impact is too high in their use case.

Reply on news.ycombinator.com