[erlang-questions] Guidance to a cache mechanism

[Richard O'Keefe]

On 31/10/2012, at 6:55 PM, Maruthavanan Subbarayan wrote:
> I thought of keeping the time stamp as the key in the ets table and maintain that in state when a timeout event occurs. I hope this would help me to delete the entries in ets table with less burden.

Like I said, "Time tells your program when to delete a message."
But the question was "How is your program asked to give a message back?"
Because if your program is never asked to give a message back, why keep
it at all?

Suppose you are running Brekekek.example.com, a site where users
exchange 'croaks' (which must be at most 140 characters of Attic
Greek).  You receive

	{add,User,Croak}

		Here is User's latest Croak, which you add to
		the cache with erlang:now() -- ignoring the
		microsecond part -- as its timestamp.

	{ask,User,Sender,Time}

		The Sender process wants to be told all of
		User's Croaks since Time.

messages, amongst others.  In order to delete Croaks easily,
you want to store them keyed by time.  But in order to answer
'ask' requests, you want to store them keyed by User.  And
ETS allows a table only one key.  Oh dear...

Think of it in relational data base terms.

	Cache(User, Time, Croak)
	fd User x Time -> Croak
	hash bag index on User
	b-tree index on Time

	{add,User,Croak} => into Cache insert (User, now(), Croak)
	{ask,User,Sender,Time} =>
		Sender ! select Croak from Cache
			   where Cache.User = User and Cache.Time >= Time
	tick => delete Cache where Cache.Time < now() - Expiry_Time

Basically what I am saying is that if your cache is to be any use,
there _have_ to be operations other than adding and deleting, and
you need to consider _all_ the operations.