The difference between memcached (or redis etc) and mysql _may_ be a factor
for your low latency requirement in terms of IO.  Choosing a disk-based DB
may mean configuration overhead in tuning for IO performance and caching.
Fundamentally, whatever your solution, something in memory will be much
faster than anything that might involve a disk-seek. Right tool for the job
etc.

http://architects.dzone.com/articles/every-programmer-should-know

If your end process is single threaded, a local variable would be the
simplest way to track such a small number of events. Avoiding loss of
events sounds like a job for the queue (or an additional gateway queue).

- Roger


On 11 January 2013 11:43, blindman2k <[email protected]> wrote:

> Thanks for the great responses ... some more detailed parameters have to
> be drawn out:
>
>
>    1. I can't tolerate delays of more than a few milliseconds.
>    2. I can't lose events.
>    3. I can't tolerate duplicates (although there is some level of
>    duplicate protection downstream, I can't rely on it).
>    4. The events are not very frequent, say one every 5-10 minutes.
>    5. memcache was an early thought but it introduces another failure
>    point and another configuration item. Given the previous point (the events
>    are not very frequent), a transactional database should be a sufficient
>    replacement.
>
>  --
> You received this message because you are subscribed to the Silicon Beach
> Australia mailing list. Vist http://siliconbeachaustralia.org for more
>
> Forum rules
> 1) No lurkers! It is expected that you introduce yourself.
> 2) No jobs postings. You can use http://siliconbeachaustralia.org/jobs
>
>
> To post to this group, send email to
> [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/silicon-beach-australia?hl=en?hl=en
>

-- 
You received this message because you are subscribed to the Silicon Beach 
Australia mailing list. Vist http://siliconbeachaustralia.org for more

Forum rules
1) No lurkers! It is expected that you introduce yourself.
2) No jobs postings. You can use http://siliconbeachaustralia.org/jobs


To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/silicon-beach-australia?hl=en?hl=en

Reply via email to