We have released a new white paper, which explains how we relate to Brewer’s CAP Thereom.
(We’ve decided to stop writing huge long technical posts on the blog – instead, we’ll write them as white papers, so we can send people PDFs of it; people keep complaining about reading multi-page posts on a blog!)
The slides and recorded video from our Under The Radar presentation are now online.
Thanks to everyone who showed up to watch us!
As you may have gathered, our product is based around a replicated database. But there’s a number of types of replicated database out there, so today I’m going to explain what type we have used, and why.
But first, let’s look at the problem we’re trying to solve.
We are pleased to announce that GenieDB have been selected to present at Under The Radar in April this year.
Under The Radar does not normally accept startups at such an early stage as ours, but our ground-breaking innovative approach to DBMS design, bringing immediate consistency, NoSQL+MySQL, self-healing and more, has been creating ripples in the community!
On of our team, Andy Bennett, is giving a talk on the seventh of April. The title is “Fail to Scale: some pitfalls for successful websites”, and as you may have guessed, the subject matter is web site scaling.
It won’t be a GenieDB product pitch; it’s a technical introduction to the problems of web site scaling.
Click here for more details, or to sign up to attend. It’s free!
We’ve always felt that “SQL vs. NoSQL” is unnecessarily confrontational – why not have both?
So it’s refreshing to read this insightful analysis by Dennis Forbes, in which he pokes holes in some common misunderstandings about the role of the interface you access your data through (SQL or not) in how ‘fast’ your site is.
Remember, SQL is just an interface. Yes, interfaces have some bearing on the efficiency of the systems they form a part of – but the implementation is often a far bigger factor. And fixing a performance issue in an interface is often easier than in an implementation!
From Times Online, March 24, 2010: No techs please, we’re British
Priya is a member of our development team. She’s professional, skilled, great to work with, and as far as we can tell, shares our enthusiasm for our work; and her gender has no bearing on her professional life whatsoever. The fact that she’s good with people may or may not be an attribute of her gender – some say women are more sociable, although whether that’s really true or not, and if so, whether it’s genetic or just social conditioning, is not something I’m sure has been settled – but that’s irrelevant; we took the fact that she’s good with people into account when deciding who to hire out of our selection of candidates – regardless of where this attribute comes from.
The UK technology community is undeniably male-dominated, which is a shame – because people are missing out on excellent careers in technology (and it is a very rewarding field to work in) just because of their gender.
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