Wide Awake Developers

« Budgetecture and it's ugly cousins | Main | Two Sites, One Antipattern »

Read-write splitting with Oracle

Speaking of databases and read/write splitting, Oracle had a session at OpenWorld about it.

Building a read pool of database replicas isn't something I usually think of doing with Oracle, mainly due to their non-zero license fees.  It changes the scaling equation.

Still, if you are on Oracle and the fees work for you, consider Active Data Guard.   Some key facts from the slides:

  • Average latency for replication was 1 second
  • The maximum latency spike they observed was 10 seconds.
  • A node can take itself offline if it detects excessive latency.
  • You can use DBLinks to allow applications to think they're writing to a read node.  The node will transparently pass the writes through to the master.
  • This can be done without any tricky JDBC proxies or load-balancing drivers, just the normal Oracle JDBC driver with the bugs we all know and love.
  • Active Data Guard requires Oracle 11g.

Comments

I'm looking at a different way to do read-write splitting by using the web tier instead of the data tier. This can be done by using the RAM on the web servers to cache the low volatility data, or by looking at employing a distributed in-memory cache over the web tier so that data items aren't cached O(N) number of times, where N is the number of web servers.

Anyway, I have a blog post up describing the nitty gritty details of getting such a solution to work.

http://udidahan.weblogs.us/2007/11/10/asynchronous-high-performance-login-for-web-farms/

Thoughts?

Udi,

Yes, I had seen your posting a little while ago. I think it was linked from either www.highscalability.com or www.infoq.com.

I'm interested in hearing more about how far you have been able to scale that approach. Prefetching the credentials certainly would speed up the response time, but my impression is that asynchronously (eagerly?) loading the in-memory cache would work best when the space of possible keys is finite and relatively small. On the other hand, login credentials may be the least finite key space we deal with.

How large a key space have you taken this technique up to?

After dealing with geography, use the first letter of the username as your key. Would that help?

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)