Slashdot Mirror
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.
Is this a big IT project that actually worked? Where's my fainting couch???
What is a "complex" message, exactly? And why is 500/sec substantial for a full cluster?
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!
As service-user I've always had the impression that the NHS database was a large Excel workbook and a load of VB macros written by interns.
Wait till you experience the NoSQL version.
Mongo DB is webscale
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
Fuck me, that's impressive! It even manages to track 17 million ghosts!
https://www.google.com/search?...
Tubal-Cain smokes the white owl.
how long til it gets hacked?
..., they actually rolled out something., Didn't a huge replacement project runs for years and years, soak up bazillions and then get cancelled? But maybe that's the 'clinical' side of things. Yes, here it us .. http://www.theguardian.com/soc...
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
Oh oh, the NoSql movement more or less wanted to gain scalability and performance at the expense of A.C.I.D. and other "integrity" features of "traditional" RDBMS. RDBMS are time-tested and thus relatively solid (if done right). NoSql is not.
What do they call the opposite of stocks? "Puts"? Put puts on this now, or sell if you got stocks in the health org.
Table-ized A.I.
This is unbelievable. Holy fuck, I sure hope that you don't work with databases professionally. I hope you don't work with them as a hobby! Nobody with an ounce of intelligence and even a minute of working with data would ever consider saying something as utterly stupid as what you just said.
If you're storing data, you need to use a system that provides atomicity, consistency, isolation and durability. Using anything less is pure idiocy. And it's not like you have to even spend money to get such a system. For crying out loud, just use PostgreSQL or Firebird or even SQLite! Fuck me, even MySQL manages to provide some of this functionality these days.
I know that some people will say that it's okay to trade off the consistency and quality of one's data, but it always comes back to bite them square in the ass. Why the fuck are you storing the data if you don't give a damn about keeping it consistent?
And storing medical data is without a doubt a case where atomicity, consistency, isolation and durability are extraordinarily important. It could be deadly if this data is not stored correctly! A patient could die if their medical records are incomplete or inconsistent, all due to a shitty database system not offering atomicity, consistency, isolation and durability. A doctor needs correct information in order to properly treat a patient. Medical data is among the most important that there is!
It is unconscionable to think that a database designer would intentionally put patients' health and lives at risk just because he doesn't want to use a real database. I really can't believe that you've suggested such a thing. That is truly disgusting.
The "NoSQL means Not Only SQL" crap you're shitting out is nothing more than the NoSQL community frantically backtracking after their "NoSQL means No SQL" ideas were shown to be disastrous bunk.
Instead of owning up to the fact that they were horribly, horribly wrong, and made some really fucking stupid suggestions, the NoSQLers have just decided to change history. They pretend that they weren't saying what they very clearly said in the past. And they obviously need to admit that SQL and relational databases are the only viable option, but can't do this without looking like the fools that they are, so they admit that it's okay to use "sometimes". And this "sometimes" ends up being "all the time", but again, they can't openly say that without looking like the incompetents that they are.
Face it, "NoSQL" does mean "No SQL". It always has, and it always will. No amount of backtracking will change the fact that the NoSQL crowd was full of shit, and still is.
What do they call the opposite of stocks?
I've always heard them being called short positions, which is the origin of the phrase "selling something short". A put option is something different: the right to sell a security for a given price between two given dates. Both can be used to make money in a falling market, though a short is a blunter instrument.
Summary says: "It logs the non-clinical information on 80 million people in Britain"
Well, yes it does hold clinical information. That is a big deal.
From the UK's HSCIC web site there's more (and authoritative) information on SPINE
http://systems.hscic.gov.uk/sp...
"The Summary Care Record:
SCRs provide emergency and out-of-hours healthcare professionals with faster access to key clinical information, including details of allergies, current prescriptions and bad reactions to medicines. The Summary Care Record helps to ensure continuity of care across a variety of care settings, and is provided by the Spine."
Having or losing corrupt information in a clinical record is a good way to kill some random person. However, it is a summary, so if a physician suspects a problem in the summary, they can go to the patient's main record. Getting prescriptions crossed can also be problematic for the patient.
Ignoring the NOSQL issue, I wish we had something like SPINE here in the USA.
"It logs the non-clinical information on 80 million people in Britain " when the population of Britain is about 64 million.
Why not mysql or postgres? Like we don't have enough sql languages as it is along with mssql and oracle...
Buck Feta. You know what to do.
That dropping ACID is not hazardous to your health.
> 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.
You don't get it. Consistency isn't something you "tune". Either the database provides consistency, or it doesn't. Anything less than perfect consistency is inherently not consistency; it's inconsistency!
Anyone who thinks that they don't need atomicity, consistency, isolation and durability does in fact need such things, they just may not be smart enough to realize it yet. Intelligent people don't have to wait for a disaster to happen before they learn the importance of atomicity, consistency, isolation and durability. They see the risks of using inferior NoSQL database systems, and instead choose real relational database systems that provide all of atomicity, consistency, isolation and durability. It's never acceptable just to have missing or partial implementations of such properties.
They say 45 days, but in reality it'll be six months.
I use the Electronic Prescription Service (EPS) component of the spine and take issue with the successful claim. The upgrade has been appalling.
It was rolled out over the UK's August bank holiday, with no advance notification. After the holiday, prescriptions pulled down from the spine (they haven't implemented push messaging ... ) had invalid digital signatures, rendering them illegal. Prescriptions that had been completed and payment claimed for in Jan 14 were redownloaded from the spine. Post dated prescriptions for October also began appearing. These are only supposed to be downloadable on after the valid date for obvious reasons.
Not only was this a logistical nightmare, some issues are still broken after two weeks.
I am amazed that so many issues got through testing.
Utter shambles.
Great, they've invented "MedBook"... what you see when you look at it is a fraction of the available data at any one time because it has "arrived" at the node where you are viewing it from yet.
What do I have to do so that my drug allergies and blood type are "sponsored postings" so that when my doctor looks at them, he doesn't kill me due to all of the auto-play video advertisements for Cialis being there instead of the information I want to be there?
It has only been rolled out yet. Just wait for the wash of leaked covered-up inexplicable medical wrongful harm and death cases due to "incomplete information" or somesuch. That'll be a score or two years down the road at the earliest.
What we have here is massively overpriced over-engineering getting ripped out by some jumped up kids with all the popular FOSS buzzwords but apparently no clue why Codd came up with relational algebra in the first place. I wouldn't call that proof his work is entirely unnecessary with your, or any, alacrity, no.
If it is proof of anything it's that you can cobble up something that looks like it works just as well for nine as for five figures, and it'll be a toss-up as to how well either will work compared to the other, though both will have glaring flaws and not work quite right. We simply haven't really licked this making IT work in the real world very well yet.
I certainly would like some data integrity guarantees in my medical records, but when I need that most I'm least equipped to complain about it.
And don't forget MUMPS!
e.g.: http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx
Search for other articles there as well.
Medical mistakes kill nearly 100k people a year in the US, and you think removing ACID from your data store is beneficial? Where do you work - I want to know what to avoid. mistaken fatalities
I think that most end-users (i.e. those needing medical care) would rather that their records be, on the whole, available.
Similarly, in banking, it's more profitable for banks to accept & reconcile consistency errors later, rather than the system becoming unavailable.
Commentors yelling about ACID-compliance in this thread would be totally right, _if_ the system could be ACID-compliant whilst maintaining the availability requirements. If it can't meet the availability requirements, then something has to be relaxed.
In the health service, since a patient's record is unlikely to be modified "simultaneously" it's likely that the consistency issues are surprisingly rare, so the reconcilliation step is likely a mere formallity on most days.
I do, however, agree that the NoSQL movment from the last couple of years has mostly been bunk. Most projects don't need 5-nines of uptime, most don't have that much data. ACID compliance makes the project measurably easier to deliver, and will often actually benefit the bottom line.
My wife is pregnant just like Her Grace, the Duchess of Cambridge, Kate Middleton, however unlike the Duchess, my wife was told she would have to wait 11 months time to see a specialist for her severe morning sickness.
I give them massive kudos for what they did in the face of another disastrous UK IT project that rolled on for a decade and cost the tax payer millions
The architecture is dead interesting if you dig around online and find the papers that explain it. There's a lot more to it than just NoSQL
I've read through the high rated comments on this thread whilst taking a lunch break, and I'm astounded by the number of people implying (but not explicitly stating) that the C in ACID is required in an RDBMS. Some use the argument that C is the downfall of RDBMS systems which makes nosql superior.
First off, I've designed DB code without transactions because I want eventual consistency. I've found that in many cases, you don't want to wrap that SQL batch in a transaction. The load process will eventually make the data line up by using a simple merge/upset statement later on, and that's perfectly fine in MANY use cases.
Second, I want to point out that database admins have been scaling out rather than scaling up for decades. We know how to do this with existing tools. NoSQL is a fucking crutch for application developers that don't want to learn SQL.
- DBA with 10 years of experience in healthcare
Can you read at all? He is saying among others that frequently some data (NoSQL tuned in one way) is better than no data at all (ACID). Is it better if my doctor knows only half of my previous illnesses, or if none at all in emergency?
Performance improvements should lead to faster load times for the massive waiting lists
... it would have been more accurate to refer to "England" than to "The UK".