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.
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.
..., 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.
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?
You hear that? That was the giant whoosh sound that just went over your head.
What we would indeed need, is the multi-datacenter capability. Which you get for free with Cassandra... We also sorely needed performance a few years ago (15k SAS drives was slow after an internet hiccup for example), but SSD drives helped in that. Again we could get infinite scalability with Cassandra for free.
You must choose in such a situation: either the - only theoretically needed - ACID, or the actually performing and highly available NoSQL with its additional operations, coding burden?
Consistency is easy when there is a single non-distributed database. That's not always possible and even if when it is possible its not always desirable because it is an inherent bottleneck. I agree many many companies pretend that they're facebook and end up with NoSQL for stupid reasons (hey, if my website ends up with a 100,000,000 active users then a single db won't cut it...) but there are situations where availability is more important than consistency. Funnily enough, one of them is banking.
http://rareformnewmedia.com/
Its a confusing point, but ACID is only one way of ensuring the things you want. Yuo can, for example, use a form of check-it-worked-and-compensate-afterwards to achieve the same level of reliability without actually having an ACID system.
Most banking transaction, I'm told, use this instead of traditional ACID transactions. I suppose you could say its a coarser-grained version of ACID and therefore still ACID, but I think that would confuse most people who think ACID = relational DB with integrity checking.
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
Again we could get infinite scalability with Cassandra for free.
Jesus Christ......
Again we could get infinite scalability with Cassandra for free.
Jesus Christ......
No, no, it is the Apacha Foundation.
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