Memcached implementation inquiry
lexington.luthor at gmail.com
Fri Apr 20 19:36:22 UTC 2007
Steven Grimm wrote:
> Try PostgreSQL instead. MySQL has awful concurrency problems. Much
> better in 5.x than it was in 4.x, but still not great.
I can confirm that PG is excellent at highly concurrent loads (> 1000
transactions), and I have read that it scales linearly to ~32 CPUs.
> Michael Firsikov wrote:
>> A typical complex search involves 5-10 tables, all properly indexed.
>> tables have in excess of 12-15 million records) However, the
>> concurrency is
>> problematic (1000+ concurrent users).
For this particular problem, memcache seems somewhat inappropriate, and
I think you will be better served by using postgresql and materialized
views updated by triggers or by cron depending on your mix of reads/writes.
I have a similar set-up where a particular view was being hit very
frequently and was too large to cache entirely. It consisted of a
complex query joining 14 tables, so materializing it was just perfect
for performance and subsets of the view can now be cached in memcached
without requiring the entire result-set to be regenerated every cache miss.
More information about the memcached