UK's National Health Service Moves To NoSQL Running On an Open-Source Stack

An anonymous reader sends this news from El Reg: The U.K.'s National Health Service has ripped the Oracle backbone from a national patient database system and inserted NoSQL running on an open-source stack. Spine2 has gone live following successful redevelopment including redeployment on new, x86 hardware. The project to replace Spine1 had been running for three years with Spine2 now undergoing a 45-day monitoring period. Spine is the NHS’s main secure patient database and messaging platform, spanning a vast estate of blades and SANs. It logs the non-clinical information on 80 million people in Britain – holding data on everything from prescriptions and payments to allergies. Spine is also a messaging hub, serving electronic communications between 20,000 applications that include the Electronic Prescription Service and Summary Care Record. It processes more than 500 complex messages a second.

Comments

Holy shit!

[jtownatpunk.net]

Is this a big IT project that actually worked? Where's my fainting couch???

How quickly will they run back to Oracle?

[Anonymous Coward]

I can't help but get the feeling that within a few months they'll be running back to Oracle or some other real database system.

At this point, anyone who works with databases in industry knows that "NoSQL" has come to mean inconsistent data, corrupted data, and silently lost data.

One just can't throw away atomicity, consistency, isolation and durability without running into some serious problems.

And that's totally ignoring how it becomes damn near impossible effectively query NoSQL databases. Sorry, writing complex queries in some imperative subset of JavaScript is totally the wrong way of doing things. Intentionally not learning SQL takes more effort than learning how to use it!

Re:How quickly will they run back to Oracle?

[Anonymous Coward]

I've heard managers and analysts say, "Oh, those data won't need to be queried!" in the past. And guess what happens? The data do need to be queried, and usually on a very tight deadline.

Making it easy to write queries isn't the priority

[raymorris]

> Sorry, writing complex queries in some imperative subset of JavaScript is totally the wrong way of doing things. Intentionally not learning SQL takes more effort than learning how to use it!

With 80 million records and heavy load, the number one priority is not "make it easy for any teenager to write queries ".
I system that requires the programmer to think things through, and therefore write an efficient query, is better in some cases.
Just as manually chosen mutexes are sometimes better than automatic full-column lovks actoss 80 million rows.
Easy isn't always best, my friend.

Re: Are you fucking serious? Tell me you aren't!

[ranton]

Sorry, I'm not the AC using the expanded ACID acronym names. Regardless of how they're referred to, they aren't buzzwords. They are the essential properties of any modern and safe database system. Anyone who insists on them all being present is totally justified, and totally correct.

Anyone who insists on all four aspects of ACID being present without knowing anything about a system's requirements is not justified at all. There are plenty of use cases where ACID compliance is ridiculous, such as most banking transactions.

Re: Are you fucking serious? Tell me you aren't!

[gaspyy]

Do you even know what ACID means?

Atomicity - either everything is committed or nothing is. I find it crucial to avoid inconsistent states.
Consistency - data is valid in all states.
Isolation - ensure that concurrent transactions work correctly.
Durability - no data is lost due to software crashes or power failures

How could these not be important for banking is beyond me.