As a replicated database, the core of our technology is multicasting update operations to a number of servers efficiently.
Most of the difficulty is making sure they all get there, even though networks may come and go, servers come and go, and so on. However, that’s not what I’m going to talk about today!
We’re going to look at the opposite problem – stopping too many updates coming through the system at once.
One of GenieDB’s design goals is resilience. Databases are one of the most critical points in application deployments. You can add more Web servers, and more load balancers, and more caching proxies, and just spread the incoming requests between them. If they break, you can just replace them, as they have no state beyond caches, and identical configurations.
But either way, few applications can run for long with their database down – and since the database is updated as well as read from, you can’t normally just run lots of copies of it, as they all need updating.
Which, of course, is why we decided to write a replicated database!
Your humble author was pressed, by persons who shall remain nameless, to face his nervousness about public speaking and give a five-minute lightning talk on the NoSQL movement at CloudCamp London January 2010.
Unfortunately, the event was filmed.
Further material may appear in future on my SkillsMatter profile or my CloudBook profile.
Why the most ‘alternatively dressed‘ (and certainly not the most attractive) member of the team should be asked to become the public face of the company is anyone’s guess; less technical materials will probably appear at GenieDB’s CloudBook profile.
Follow GenieDB news