NYT: Healthcare.gov Project Chaos Due Partly To Unorthodox Database Choice

← Back to Stories (view on slashdot.org)

NYT: Healthcare.gov Project Chaos Due Partly To Unorthodox Database Choice

Posted by timothy on Sunday November 24, 2013 @03:17AM from the even-if-it's-perfectly-nice dept.

First time accepted submitter conoviator writes "The NY Times has just published a piece providing more background on the healthcare.gov software project. One interesting aspect: 'Another sore point was the Medicare agency's decision to use database software, from a company called MarkLogic, that managed the data differently from systems by companies like IBM, Microsoft and Oracle. CGI officials argued that it would slow work because it was too unfamiliar. Government officials disagreed, and its configuration remains a serious problem.'" The story does not say that MarkLogic's software is bad in itself, only that the choice meant increased complexity on the project.

334 comments

Min score:

Reason:

Sort:

follow the money by ganjadude · 2013-11-24 03:23 · Score: 5, Insightful

Who owns this company?

how much do they contribute to XXX???

There has got to be some reason that this DB that ive never even heard of (and i work with DBs, its not my main point of work but I know my way around DBs) got the gig over the more established players.

or, perhaps they went with it because it is less known and therefore reduce the risk of known attacks in other DB systems?

--
have you seen my sig? there are many others like it but none that are the same
1. Re:follow the money by danbuter · 2013-11-24 03:29 · Score: 0
  
  I'm guessing they were lowest bid.
2. Re:follow the money by Anonymous Coward · 2013-11-24 03:33 · Score: 5, Insightful
  
  from wikipedia,
  
  The company’s main product, MarkLogic Server, is an XML based database management server.
  This sentence has basically summed up the entire problem.
3. Re:follow the money by Desler · 2013-11-24 03:54 · Score: 5, Funny
  
  They should have just used MongoDB. I hear it's web scale. *ducks*
4. Re:follow the money by WWWWolf · 2013-11-24 03:57 · Score: 2, Insightful
  
  Never attribute to malice that which can be explained by incompetence.
  To me, this sounds like a pretty open and shut case of "Hey, I've heard that these 'NoSQL' database thingies are trendy these days. Let's use one of those!"
  There's a difference between using fun, exciting new technologies and learning something new while doing that... and doing a project which stays in schedule and budget, is based on technology you already know thoroughly, and on which people's lives can depend (well, indirectly).
5. Re:follow the money by Charliemopps · 2013-11-24 03:59 · Score: 2
  
  WOW! No wonder they're having trouble. This has to be the worst idea for a database I've ever heard of. It definitely explains the problems they've been having.
6. Re:follow the money by Karl+Cocknozzle · 2013-11-24 04:06 · Score: 1
  
  There has got to be some reason that this DB that ive never even heard of (and i work with DBs, its not my main point of work but I know my way around DBs) got the gig over the more established players.
  or, perhaps they went with it because it is less known and therefore reduce the risk of known attacks in other DB systems?
  Perhaps either is the case: Obscurity or donations... A third option is that it provides some feature that doesn't exist in Oracle/SQL Server/Cassandra. However in digging into their web-site it looks like it is some sort of wrapper/hybridized product that mates to Hadoop, which would make sense given the vast volume of data you're talking about managing for the Federal exchange, which I believe services 36 states.
  But with that said, I've never heard of it either.
  
  --
  Who did what now?
7. Re: follow the money by sycodon · 2013-11-24 04:07 · Score: 3, Insightful
  
  XML soo sucks for db applications.
  
  --
  When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
8. Re: follow the money by MyDixieWrecked · 2013-11-24 04:07 · Score: 5, Insightful
  
  I used marklogic when I worked at a previous job and after learning how it worked and understanding it better, it made our jobs incredibly easy. It just had a serious learning curve.
  Marklogic is a nosql db, that uses XML for its object format and xquery for its query language. This thing is NOT mongodb. It actually works really well and allows for complex data modeling with the ability to do joins and have transactional isolation in making changes to the data as well as a really solid content processing framework with pipelining and all that jazz.
  Now, I can't imagine a reason for using marklogic, or any non-relational db for a project like this. The only clue is that marklogic has a lot of government contracts; mostly for the military. So maybe that's why it was used. But the fact that they chose a database system that they weren't experts in for a project that had so much visibility speaks volumes on how mismanaged this whole project was.
  
  --
  
  ...spike
  Ewwwwww, coconut...
9. Re:follow the money by MightyMartian · 2013-11-24 04:08 · Score: 0
  
  No fucking kidding. K-rust, I can only imagine how gawdawful slow such a database would be in every possible operation. Even if the XML itself is merely a wrapper for binary blobs, it's still an entire extra layer an engine is going to have to push through.
  Why would anyone design such a product? Why would anyone buy such a product?
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
10. Re:follow the money by jythie · 2013-11-24 04:08 · Score: 1
  
  It is also possible that someone high on the chain was simply enthusiastic about it for no apparent reason. Several projects I have worked on used inappropriate databases because someone with enough technical knowledge thought it would be a good idea and their persistant insanity was enough to get it chosen.
11. Re:follow the money by Karl+Cocknozzle · 2013-11-24 04:11 · Score: 2
  
  http://www.marklogic.com/what-is-marklogic/marklogic-hadoop/
  This seems like the relevant, interesting/crazy part. Whether it's the right choice or not, I leave to more seasons database professionals than myself.
  
  --
  Who did what now?
12. Re:follow the money by Anonymous Coward · 2013-11-24 04:14 · Score: 2, Interesting
  
  Because relational dbs are old and stuff. We don't tie onions to our belts anymore either, grandpa. NoSQL and XML are the future! A hipster I met at Starbucks told me so.
13. Re: follow the money by Mabhatter · 2013-11-24 04:20 · Score: 1
  
  The only agencies that would need NoSQL type support are the ones spying on us. My take is that the insurance industry said they would only communicate in EDI-XML formats and somebody in management though that meant buying an XML-based system to be "compatible".
14. Re: follow the money by MightyMartian · 2013-11-24 04:20 · Score: 1
  
  This thing is NOT mongodb. It actually works really well and allows for complex data modeling with the ability to do joins and have transactional isolation in making changes to the data as well as a really solid content processing framework with pipelining and all that jazz.
  So is SQL attached to any reasonably good content management framework.
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
15. Re: follow the money by uradu · 2013-11-24 04:21 · Score: 2, Insightful
  
  You're exactly right! I've done tons of "exploratory" coding over the years myself, either using some new techniques or new products, just for the fun of it or to learn something new. But that would always be on small, low visibility projects where the consequences of potential poor performance or other issues would be insignificant. To tread new ground on something so big with national visibility is foolish. You'd want the most well established and known reliable and performant tools and techniques possible. I played around a bit with these object based databases in the early days, and for some uses such as simple dictionary type access to a serialized object they're good. But the query syntax is almost always XPath oriented and less than optimal for complex joins such as you would find in massive systems like this. I guess they've learned their lesson now.
16. Re: follow the money by Nerdfest · 2013-11-24 04:24 · Score: 4, Insightful
  
  To me, the fact that it was a major problem is an indicator of bigger problems. With systems like this, the database should be just a simple repository for persisting an retrieving domain models. If they want to do any non-trivial reporting on it the data should be replicated to a reporting repository. Treating the database a a simple persistence repository makes most database operations trivial, and better yet, decouples the database from the business, meaning that if you couldn't even manage the simple operations, replacing the layer is fairly trivial.
  The problem is when people think the database is the starting point for a system, not just a tool to be used to support what your business logic is doing. It sounds like that's what happened here.
17. Re: follow the money by EMN13 · 2013-11-24 04:30 · Score: 1
  
  And you base this on what? Did the spagetti-monster tell you JSON was technically a better fit, or that XQuery doesn't work?
18. Re: follow the money by Anonymous Coward · 2013-11-24 04:32 · Score: 1
  
  I guess they've learned their lesson now.
  You give them entirely too much credit. In fact, they deserve none.
19. Re: follow the money by Anonymous Coward · 2013-11-24 04:45 · Score: 1
  
  Storing everything as XML means you're storing it all as strings (not very efficient). Now, if they're converting all the strings to binary data in order to store it, and then converting it back to XML to use it, then you're generating a lot of needless overhead because of the decision to store it as XML. Plus, searching XML sucks.
  I'm not knocking XML as a means of handling data - it absolutely has it's place. But not in this size of a project that requires so much data and very high performance in order to handle the number of connections and requests.
20. Re: follow the money by Pinky's+Brain · 2013-11-24 04:48 · Score: 1
  
  I don't mind XML for stuff like Docbook ... but for databases what's the point? XML is an editing format with some down and upsides, using it as a storage format for data never edited in XML is just retarded.
  At best it just provides a useless intermediary format which doesn't affect usability ... at worst you try to use XQuery to actually perform searches on large volumes of data.
21. Re: follow the money by Chris+Mattern · 2013-11-24 04:56 · Score: 4, Insightful
  
  In fact, all of those would suck donkey balls. That is because XML, JSON and XQuery are all *data-interchange formats*. Using them to run your database internals is like using a screwdriver as a hammer.
22. Re:follow the money by Anonymous Coward · 2013-11-24 04:58 · Score: 3, Funny
  
  Was this hipster drinking coffee or serving it?
23. Re:follow the money by Anonymous Coward · 2013-11-24 05:00 · Score: -1
  
  Never attribute to malice or incompetency that which can be explained by bribery.
  FTFY
24. Re:follow the money by Anonymous Coward · 2013-11-24 05:09 · Score: 0
  
  Was this hipster drinking coffee or serving it?
  The only thing I remember was his MacBook Pro. That's some serious hacker hardware.
25. Re:follow the money by mlts · 2013-11-24 05:09 · Score: 5, Insightful
  
  For them, it is a wise choice. It brings job security using a non mainstream RDBMS, which means that the data would take man-years to be migrated to Oracle, DB/2, or even MS SQL server which may not have the horsepower of a SPARC or POWER7 box, but one can always partition and cluster the RDBMS. It also is expensive to keep maintained, so it provides additional job security, as the expertise for this architecture is rare.
  Great win for the contracting company. Big loss for everyone else.
26. Re:follow the money by Anonymous Coward · 2013-11-24 05:13 · Score: 0
  
  Mongo like candy!
27. Re: follow the money by sycodon · 2013-11-24 05:22 · Score: 1
  
  Experience, fuckhead.
  And WTF with all these angry atheists?
  
  --
  When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
28. Re:follow the money by Chibi+Merrow · 2013-11-24 05:25 · Score: 4, Interesting
  
  Also, the Federal Government fscking LOVES XML. Like, a lot. The things I saw in the new "protocols" they're deploying for internatl air-traffic control data stuff... Wow...
  
  --
  Maxim: People cannot follow directions.
  Increases in truth directly with the length of time spent explaining them
29. Re: follow the money by Anonymous Coward · 2013-11-24 05:32 · Score: 0
  
  You're forgetting about the schema. Straightforward to use it to compress the data fields and architect into a network style database.
  Isn't MUMPS kinda like this? I wonder what influence it's use in the government had in this decision.
30. Re:follow the money by PapayaSF · 2013-11-24 05:35 · Score: 5, Insightful
  
  It definitely explains the problems they've been having.
  But this is only part of it. Check out this diagram. I'm no expert, but look at all the government systems in the upper left that Healthcare.gov is supposed to communicate with, in real time. And on the right, 50 state Medicaid systems. And at the bottom, all the insurance companies. Far, far simpler IT projects have failed. This site will not be ready by the end of the month as promised, and there is a good chance that it will never work as planned.
  
  --
  Q: What does the "B." in Benoit B. Mandelbrot stand for? A: Benoit B. Mandelbrot
31. Re:follow the money by Anonymous Coward · 2013-11-24 05:53 · Score: 2, Informative
  
  And NOBODY understands it! (if you don't believe me, try extracting useful information out of SEC EDGAR). The best I've seen so far just extracts tags using regular expressions.... not actual XML parsing.
32. Re: follow the money by Anonymous Coward · 2013-11-24 06:07 · Score: -1
  
  It may have bee a stupid decision, but your use of that hurtful slur denigrating the intellectually disabled, who as a class of people are probably in no way to blame for the AHCA web site roll-out fiasco, is entirely inappropriate.
33. Re: follow the money by HornWumpus · 2013-11-24 06:12 · Score: 1
  
  The only reason people store non key field data in one big XML blob is so they can add fields without having to go through useless, ossified DBAs.
  I'm not saying all DBAs are useless and ossified, I'm saying using XML blobs is a workaround for slow, control freak DBAs.
  After this is done, others work with the databases and continue the practice without ever knowing it's root. In some cases the DBAs gain control of the XML schema and the circle is complete.
  
  --
  John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
34. Re: follow the money by Nerdfest · 2013-11-24 06:12 · Score: 1
  
  I should add that with many languages and frameworks (Java & Spring/Hibernate for example), "we have machines for that". Only the fine tuning and performance tweaks need to be done my hand. Manually coding an data access layer is almost a "make work project" that's frequently a source of errors in what should really be managed by configuration.
35. Re: follow the money by Anonymous Coward · 2013-11-24 06:23 · Score: 1
  
  To me, the fact that it was a major problem is an indicator of bigger problems. With systems like this, the database should be just a simple repository for persisting an retrieving domain models. If they want to do any non-trivial reporting on it the data should be replicated to a reporting repository. Treating the database a a simple persistence repository makes most database operations trivial, and better yet, decouples the database from the business, meaning that if you couldn't even manage the simple operations, replacing the layer is fairly trivial.
  The problem is when people think the database is the starting point for a system, not just a tool to be used to support what your business logic is doing. It sounds like that's what happened here.
  Lemme guess...you've never actually administered or developed with a database?
36. Re:follow the money by rfugger · 2013-11-24 06:33 · Score: 1
  
  Great win for the contracting company. Big loss for everyone else.
  Except, according to the article, the contracting company wanted to use a regular RDBMS, but the government insisted on MarkLogic, which is a NoSQL solution, not relational.
37. Re:follow the money by I'm+New+Around+Here · 2013-11-24 06:33 · Score: 2
  
  Did you notice the box in the lower right that shows they have a plan to manage the serfs?
  Where do they come up with these things?
  
  --
  If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
38. Re: follow the money by countach · 2013-11-24 06:35 · Score: 1
  
  If a database is good, it should be possible to use it for ALL problem domains.
  Of course, by this criteria, a relational database is NOT "good".
  But I would have thought an object database is good, and would work in any situation. Unfortunately, they never seemed to really take off.
  Anyway, I'd rather be using an object database for complex data of ANY kind than some crazy XML database. I can sort of see why a health application that might have tons and tons of fields might be tempted to use an XML storage, but I still think its a mistake. XML is ALWAYS a mistake.
39. Re: follow the money by Anonymous Coward · 2013-11-24 06:36 · Score: -1
  
  Shutup you faggot.
40. Re:follow the money by Anonymous Coward · 2013-11-24 06:41 · Score: 0
  
  Oh, come one now. I've crapped out bigger projects than that. In more colors, too.
41. Re:follow the money by zippthorne · 2013-11-24 06:43 · Score: 1
  
  The chart doesn't show "employee or consumer" connecting to the portal / web site, instead connecting directly to the administration interface, customer service, and financial services (last two of which, based on the gradient, I assume have shared responsibilities between carriers and states, which implies another unspecified interface..).
  Maybe they just didn't think the web portal was important, because the consumers would hook directly (via implanted electrodes with network port? I assume that would be covered....) to lower level interfaces.
  
  --
  Can you be Even More Awesome?!
42. Re:follow the money by cold+fjord · 2013-11-24 06:54 · Score: 1
  
  MongoDB only pawn in game of politics.
  
  --
  much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
43. Re: follow the money by bill_mcgonigle · 2013-11-24 07:02 · Score: 1
  
  I don't know about this one, but I used to work at a place that used a proprietary object database, and then when XML became all buzzy, they re-branded themselves as an XML database. It was still an object database, but they put an XML front end on it and became buzzword-compliant.
  I'm guessing this one doesn't store its data in XML either. FWIW, my favorite database is an object database that has a very popular SQL interface to it. The backend data storage isn't SQL-formatted at all either.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
44. Re: follow the money by Aryden · 2013-11-24 07:03 · Score: 4, Insightful
  
  The reason we are control freaks is because when some moron wants to make a change and breaks the whole system, we are the ones that catch the blame and have to try to fix it if we don't get shit canned for it. You ever tried to re-key millions of records across hundreds of tables? You ever had to spend 3 days restoring db's from backup and having a site outage for 3 days because of it?
45. Re: follow the money by mikael · 2013-11-24 07:11 · Score: 1
  
  Just about every application stores configuration data in some TAFF format (Tagged Ascii File Format). You have to state things like the data version, the field name and the field value. Look at the various game industry formats out there: LUA scripts, Sony's COLLADA. Even Quake and Doom had the level stored in ASCII.
  The advantage of using XML is that it could be converted to a binary XML format or something else in the future. Design your API's correctly, so that the query functions level is separate from the XML loading/saving level and it would just be a matter of swapping one module for another.
  
  --
  Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
46. Re:follow the money by killkillkill · 2013-11-24 07:12 · Score: 4, Funny
  
  XML is like violence. If it doesn't solve your problems you are not using enough of it.
  I'm starting to think that saying came from the government.
47. Re:follow the money by cascadingstylesheet · 2013-11-24 07:16 · Score: 2
  
  Who owns this company?
  how much do they contribute to XXX???
  
  "XXX"?
  You mean "Obama and other democrats", right? Because this system is their baby.
  It's no mystery who "XXX" is; no need for a variable.
  I've noticed a Responsibility Diffusion Field around this whole thing ...
48. Re:follow the money by Anonymous Coward · 2013-11-24 07:39 · Score: 0
  
  > I hear it's web scale.
  Usually their fanbois say "here its web scale."
49. Re: follow the money by Anonymous Coward · 2013-11-24 07:47 · Score: 0
  
  I use my screwdriver as a hammer often, you insensitive clod!
50. Re:follow the money by fche · 2013-11-24 08:00 · Score: 1
  
  "It definitely explains the problems they've been having."
  Maybe a few technological parts, yes. The whole edifice, hardly.
51. Re: follow the money by Anonymous Coward · 2013-11-24 08:20 · Score: 0
  
  My experience differs. Screens, business rules and logic come and go but the database is forever. Inconsistent, missing or erroneous data will kill any system no mater how clever the programming.
52. Re: follow the money by Anonymous Coward · 2013-11-24 08:21 · Score: 0
  
  The database is the system. Everything else is a subsystem designed to put data in and out of it.
53. Re: follow the money by Anonymous Coward · 2013-11-24 08:28 · Score: 0
  
  I never got that part. I just tell the DBAs that i need a new property on an object. I give my one suggestion for where it goes but ultimately leave it up to them. I usually make the change to my dev db and keep on rolling. If it takes them too long then we'll just ask business if it's okay to promote and deploy my db change with the new feature. Post deployment i cancel the task for the DBAs to do work. It's in production now and is the new gold standard. Makes them look slow and incompetent.
  If the DBAs want to hold up a deployment i can just drop the whole thing in their lap and move on to the next feature. If anyone asks me about when it goes out i just refer them to the DBA who is holding everything up because i'm too busy with the next item in the chute. That never lasts long.
54. Re: follow the money by tibman · 2013-11-24 08:41 · Score: 1
  
  So someone made a change to production that didn't pass QA? And they did it without you doing a backup first? Three days restoring is too long too. Unless your server is remote and upstream is super slow. But none of these things should give you permission to be a control freak. You are responsible for keeping the databases up, yes. But you are not responsible for everything that happens to them. Sometimes your dbs just get screwed up and you'll have to fix it. Just like sometimes business wants things done to the site/app that will totally jack up the fung shui i had going on in code. Nobody is purposefully trying to screw anyone over. We all want the business to grow and succeed. People make mistakes and shit happens. There's no need to also be an ass to each other on top of it all.
  
  --
  http://soylentnews.org/~tibman
55. Re: follow the money by HornWumpus · 2013-11-24 08:41 · Score: 1
  
  The reason some of you are useless control freaks: Not knowing the difference between development and live databases. Attempting to insert themselves into the development team by refusing changes to the dev database without 'consultation'.
  Data Base Administrator. Not architect, not stored procedure developer, admin aka digital janitor. Make sure the backups work and the database doesn't run out of space.
  Granting some 'DBA's are misclassified and are in fact architects or back-end programmers and do actually belong on the development team. Most are just janitors and don't have any business near the design.
  
  --
  John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
56. Re:follow the money by artor3 · 2013-11-24 09:02 · Score: 4, Interesting
  
  The chart's hosted on the National Republican Congressional Committee's website. I would take it with a heaping tablespoon of salt, if I were you. It's say to say that chart was designed to look as scary and confusing as possible.
57. Re:follow the money by BlueStrat · 2013-11-24 09:20 · Score: 4, Informative
  
  I'm guessing they were lowest bid.
  Bids? What bids?
  There was no bidding.
  http://nypost.com/2013/11/01/obama-donors-firm-hired-to-fix-web-mess-it-helped-make/
  ----
  "WASHINGTON â" A tech firm linked to a campaign-donor crony of President Obama not only got the job to help build the federal health-insurance Web site â" but also is getting paid to fix it.
  Anthony Welters, a top campaign bundler for Obama and frequent White House guest, is the executive vice president of UnitedHealth Group, which owns the software company now at the center of the ObamaCare Web-site fiasco.
  UnitedHealth Group subsidiary Quality Software Services Inc. (QSSI), which built the data hub for the ObamaCare system, has been named the new general contractor in charge of repairing the glitch-plagued HealthCare.gov.
  Welters and his wife, Beatrice, have shoveled piles of cash into Obamaâ(TM)s campaign coffers and Âapparently reaped the rewards.
  Beatrice Welters bundled donations totaling between $200,000 and $500,000 for Obamaâ(TM)s campaign during the 2008 election Âcycle, according to campaign- Âfinance data compiled by Center for Responsive Politics.
  SICK CALL: Obama bundler Anthony Weltersâ(TM) firm owns the company picked to repair the health Web site.
  The couple then became top donors for Obamaâ(TM)s inauguration festivities, kicking in $100,000 out of their own pockets and bundling another $300,000 from friends and business associates, according to the center.
  The investments quickly paid off for Beatrice Welters. The Obama administration tapped her in 2009 for the plum job of US ambassador to Trinidad and Tobago, which she held through last November.
  The couple have been frequent guests at the White House.
  Visitors logs show at least a dozen visits between the two by the end of 2012, the most recent information available.
  The entire Welters family has gotten into the donation game.
  The Welters, along with their sons, Andrew and Bryant, have contributed more than $258,000 to mostly Democratic candidates and committees since 2007.
  Whatâ(TM)s more, UnitedHealth Group is one of the largest health-insurance companies in the country and spent millions lobbying for ObamaCare.
  The insurance giantâ(TM)s purchase of QSSI in 2012 raised eyebrows on Capitol Hill, but the tech firm nevertheless kept the job of building the data hub for the ObamaCare Web site where consumers buy the new mandatory health- Âinsurance plans.
  QSSI has been paid an estimated $150 million so far, but officials couldnâ(TM)t say how much more the company might collect on the Ârepair contract.
  By all accounts, the data hub has run smoothly while many other components of the Web site have failed.
  Meanwhile, tempers flared among Obamaâ(TM)s Democratic allies over the disastrous rollout of the presidentâ(TM)s signature initiative.
  âoeIâ(TM)m extraordinarily frustrated,â said Sen. Jeff Merkley (D-Ore.) Âafter top Obama-administration officials gave Senate Democrats a private briefing on the state of the Web-site repairs.
  He said they were losing confidence the site could be quickly fixed.
  âoeI donâ(TM)t think thereâ(TM)s confidence by anyone in the room. This is more of a show-me moment,â said Merkley."
  ----
  This thing was never meant to function in any event. They didn't pay attention to the details because they didn't matter.
  It was designed to fail so that the "Holy Grail" of single-payer government-run healthcare could be rolled out as a "fix". As a bonus, they get to hand a big bag of taxpayer's money to their "bag-man".
  Just watch. Single-payer will be the "fix" insisted upon.
  At least we won't have so many foreigners coming to the US for our excellent health care any more.
  Strat
  
  --
  Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
58. Re:follow the money by PapayaSF · 2013-11-24 09:27 · Score: 1
  
  The chart's hosted on the National Republican Congressional Committee's website. I would take it with a heaping tablespoon of salt, if I were you. It's say to say that chart was designed to look as scary and confusing as possible.
  No, this chart is designed to look as scary and confusing as possible. The one I posted is a pretty straight-forward description of the basic site architecture. I have a pretty good understand of information design, and I don't see how the chart I first posted is artificially enhanced to make it look worse than it is.
  
  --
  Q: What does the "B." in Benoit B. Mandelbrot stand for? A: Benoit B. Mandelbrot
59. Re:follow the money by Anonymous Coward · 2013-11-24 09:41 · Score: 0
  
  I have extensive on the job experience with transferring large datasets from xml documents (and a large variety of more exotic formats) to relational storage, and it's usually not that complicated. The xml interfaces of the big relational providers improved a lot around 10 years ago because of the hype around xml back then (if you didn't boast a good xml engine, you didn't play in the management offices), and just simply pumping data out of an xml file is easy. It's horribly slow compared to optimized storage formats of course, but if you're just doing it once to salvage the data, it's not necessarily much more complicated than any other text format.
  It's typical though that the one supposed big selling point of xml, it being "self-documenting", is entirely missing in all the migration jobs I have done. You need someone who knows what the data means just as much as if it was in orderly named tab-separated text files with a column header row.
60. Re: follow the money by citizenr · 2013-11-24 09:55 · Score: 1
  
  I don't mind XML for stuff like Docbook ... but for databases what's the point? XML
  but its HUMAN READABLE !!!1!7
  
  --
  Who logs in to gdm? Not I, said the duck.
61. Re: follow the money by Anonymous Coward · 2013-11-24 10:20 · Score: 0
  
  Data typically outlives business logic (applications) by a factor of 10x. Data is the asset, business logic just supports it.
62. Re: follow the money by Anonymous Coward · 2013-11-24 10:27 · Score: 0
  
  I used to work in government contracting and, for reasons I never understood, MarkLogic had a foothold. Don't know that it was necessarily corrupt - I think it could also be that there are a lot of really stupid people on the government payroll that are suckers for every marketing pitch they hear. Few people asked the right questions to differentiate real innovation from smoke and mirrors and marketing BS.
63. Re: follow the money by Anonymous Coward · 2013-11-24 10:35 · Score: 0
  
  I've worked with MarkLogic and I'll go so far as to say there are virtually no use cases that it is the optimal choice for. Especially since several relational DBs have added XML columns, you can get virtually all the flexibility of XML where you need it and still have better query performance by using relational features where it makes sense.
64. Re: follow the money by sycodon · 2013-11-24 10:36 · Score: 1
  
  You must work for HHS.
  
  --
  When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
65. Re: follow the money by Anonymous Coward · 2013-11-24 10:42 · Score: 0
  
  The advantage of using XML is that it could be converted to a binary XML format or something else in the future. Design your API's correctly, so that the query functions level is separate from the XML loading/saving level and it would just be a matter of swapping one module for another.
  That's not an advantage of XML at all, because once you have built your API you can do away with the tags and use a denser text format. Using a separate data access layer eliminates the one thing XML has supposedly going for it. You don't store your meta-data with the data, it's a beginner's mistake. "Meta-data" was invented by suits, at the storage level it is all just data, not meta, and it should be treated as such.
  The sad fact is that tons of money has been wasted on a technology that invented a problem before it came up with a solution, and that had already been discarded as impractical and obsolete 20+ years earlier (we did have hyrarchical storage formats before Codd you know?). Despite over a decade of practical proof that all XML does is adding unnecessary complexity at the storage level, there are still 'proponents' of the technology. It's like freaking moon landing deniers, it defies all logic and rationality.
66. Re: follow the money by plopez · 2013-11-24 10:45 · Score: 1
  
  Lack of ACID compliance would be a good start.
  
  --
  putting the 'B' in LGBTQ+
67. Re: follow the money by plopez · 2013-11-24 10:51 · Score: 1
  
  "Three days restoring is too long too."
  Depends on the size of the DB. Petabyte DB are becoming more common. Though if you link your backups to /dev/null they will run very fast. Try it, copy all your files and source code, including your source control directories, to /dev/null. You will find a huge performance increase in your compile times.
  
  --
  putting the 'B' in LGBTQ+
68. Re:follow the money by Lord+Crc · 2013-11-24 11:08 · Score: 4, Funny
  
  They should have just used MongoDB. I hear it's web scale.
  Web scale or not, I have no idea. But I do think they've got the best bug report ever in their tracker.
69. Re: follow the money by pegr · 2013-11-24 12:24 · Score: 1
  
  We have a winner! No, really, it makes so much sense now!
70. Re: follow the money by Anonymous Coward · 2013-11-24 12:34 · Score: 1
  
  I had a similar experience at my company. My team was assigned to a large MarkLogic project with a large user base. We had little to no experience with MarkLogic, but after making our way up the learning curve we went to production within a year. It ended up being a very capable application platform. If the contractor couldn't figure out MarkLogic in three years the problem isn't with MarkLogic.
71. Re: follow the money by HiThere · 2013-11-24 12:45 · Score: 1
  
  The only databases that are good by that criterion are the pre-relational network databases. They could do tables. The could store data hierarchically. They could...well, anything. But they were a pain in the ass to use. Because they could do everything, you had to specify everything by hand.
  N.B.: This isn't, or doesn't appear to be, the same kind of database that is currently called a network database, like Neo4j. It's more like assembly code. Primitives were things like, "Link this node to that node" or "follow the nth link from this node". But you could do hierarchies with rings of connections, you could do rings of rings, you could do simple tables. But since "table" wasn't a primitive concept, you had to write all the code that meant this link was a link across a row of the table, while that link was a link to the succeeding record of the table, etc.
  Perhaps you need to think again about what constitutes a good database. A certain degree of predefined rigidity of concept is greatly advantageous...of course any particular rigidity will render it less than optimal for certain purposes. But tables have proven very useful as a databse concept. So usefule that network and hierarchical databases have essentially dropped out of sight. And, of course, been reinvented. But if you want reports and queries, then relational databases are quite hard to beat. Personally, I often want something a bit different. And for my purposes all I need is a unsigned long for a key, and a binary dump of a struct for the data. Having to change these into strings is quite annoying. So I generally prefer to use something else. TokyoCabinet is a good choice. Currently I'm working on something that maps more nicely onto a fixed length record random access binary file. (A good old Fortran concept that has fallen out of fashion. You can emulate it in C, but the language doesn't really encourage it.)
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
72. Re: follow the money by Anonymous Coward · 2013-11-24 13:49 · Score: 1
  
  XQuery is a "data-interchange format" ... what? Not surprised to see such clueless posting on /., but a little surprised this was moderated "insightful".
73. Re: follow the money by Anonymous Coward · 2013-11-24 13:53 · Score: 0
  
  No, the problem is when people like you think a database is simply a way to persist data.
74. Re: follow the money by Anonymous Coward · 2013-11-24 13:56 · Score: 0
  
  You can't think of a reason to use an XML database to store XML data? Really?
75. Re: follow the money by Aryden · 2013-11-24 14:18 · Score: 4, Insightful
  
  Changes to production that pass QA can still break the system once they are in the wild and every instance of execution begins. Additionally, not every change that goes into production in all instances goes through the DBA especially when there isn't a schema change. A dipshit writes an app that works fine in QA, migrates to production, due to a difference in version he didn't pay attention to, he overwrites 5 million records. It really does actually happen in the real world and they ( many companies) don't bother consulting the experts until it's already fucked up.
  
  Three days restoring is too long too. Unless your server is remote and upstream is super slow.
  This is becoming more commonplace as companies are outsourcing or contracting out their admins and development.
  
  But none of these things should give you permission to be a control freak. You are responsible for keeping the databases up, yes. But you are not responsible for everything that happens to them. Sometimes your dbs just get screwed up and you'll have to fix it. Just like sometimes business wants things done to the site/app that will totally jack up the fung shui i had going on in code. Nobody is purposefully trying to screw anyone over. We all want the business to grow and succeed. People make mistakes and shit happens. There's no need to also be an ass to each other on top of it all.
  You'd think that, but when it's your job on the line because fucktards in management have 0 clue and assume that because it has something to do with the database and you are the admin, it's your fault. And having been subject to intentional sabotage, and seeing it done numerous times, it exists and happens.
76. Re: follow the money by Aryden · 2013-11-24 14:20 · Score: 1
  
  Don't know what planet you are from, but in the real world, DBA's quite often fill many roles in the development life-cycle. I've been the DBA as well as the fucking PM for projects just due to lack of man power, shit happens.
77. Re: follow the money by tibman · 2013-11-24 14:34 · Score: 1
  
  Petabyte DB is rare. Even a terabyte DB is rare. If you are storing actual content in your DB and not just data, i could understand it. But most people store actual files outside the DB with a reference to them. /dev/null seems to have great writing performance but has terrible reading performance. I wouldn't recommend it.
  
  --
  http://soylentnews.org/~tibman
78. Re: follow the money by tibman · 2013-11-24 14:46 · Score: 1
  
  There should always be an audit trail. If i made a mistake and ship bad code it isn't anyone's fault but mine. It can be verified via source control. DBs are no different. Anyone with access to prod has their own login which will show in the logs. Companies that fire people because they made mistakes will end up being a blame-game cluster fuck and their IT dept will die. Shit happens, fix it and move on. Nobody benefits (certainly not the company) if we spend more time pinning blame on someone than restoring from backups or doing a midnight bugfix release. Let's just try to do better next time.
  If management is clueless then that is telling me that they are literally hiring clueless people to work there. Abandon ship. If people are intentionally sabotaging production then serve up some logs and have the saboteurs outed for what they are. That sounds really crazy. I would be stressed out if someone was intentionally trying to break production.
  
  --
  http://soylentnews.org/~tibman
79. Re: follow the money by dmcassel · 2013-11-24 14:53 · Score: 1
  
  MarkLogic is ACID compliant. http://www.marklogic.com/blog/can-you-pass-the-acid-test/
80. Re:follow the money by zoffdino · 2013-11-24 15:15 · Score: 1
  
  Nah, TL; DR; I used to work as a system analyst (I'm a project manager now), and hate complicated diagrams. Other than developers, any diagram that takes me more than 60 seconds to read is too much. They could have made it simple if viewed from a purely SOA architecture: a health exchange module (with potentially 50 interfaces), and plan comparison module (just define a standard and make all insurance companies use it), a self-server portal, etc. It's not simple, but having clear distinct make it less of a mess than the clusterfuck that is HealthCare.gov now.
81. Re:follow the money by Anonymous Coward · 2013-11-24 15:16 · Score: 0
  
  Did you notice the box in the lower right that shows they have a plan to manage the serfs?
  Where do they come up with these things?
  SERFF is a site where insurance companies submit regulatory filings. Not about serfdom. Although, as a filer on that site, I feel like a serf.
82. Re:follow the money by dmcassel · 2013-11-24 15:26 · Score: 2
  
  It's actually really fast. The XML is indexed on ingest and many queries are answered just from the indexes.
  
  Why would anyone design such a product? Why would anyone buy such a product?
  Because for many kinds of data, once I became familiar with MarkLogic I found I could build complex applications more rapidly than I could with relational technologies. It scales out, it's schema agnostic, and it's ACID compliant. It has HA/DR features and a robust security model. Customers buy it because it solves their problems. For anyone interested in learning a bit about MarkLogic, the Enterprise NoSQL page is a good place to start. Disclaimer: MarkLogic employee.
83. Re: follow the money by VoidEngineer · 2013-11-24 15:48 · Score: 1
  
  Hey, now. :)
  Don't be hating on MongoDB. It's actually got all the good points of MUMPS, without any of the baggage. It's liable to be a big hit in healthcare and EMR systems in the future. Remember, the government has been using document-oriented NoSQL databases for some 40 to 50 years in VistA, the Veterans Administration EMR. They've been running NoSQL MUMPS systems for 40 years.
  
  http://en.wikipedia.org/wiki/Mumps
  http://en.wikipedia.org/wiki/VistA
84. Re:follow the money by VoidEngineer · 2013-11-24 15:55 · Score: 1
  
  Actually, the government has been using document-oriented NoSQL databases for some 40 to 50 years with MUMPS, the database in VistA, the Veterans Administration EMR. The US has been running NoSQL MUMPS healthcare systems for 40 years for the US Military.
  
  http://en.wikipedia.org/wiki/Mumps
  http://en.wikipedia.org/wiki/VistA
85. Re:follow the money by MightyMartian · 2013-11-24 16:36 · Score: 1
  
  So at least we know one person we can blame for this catastrophe
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
86. Re:follow the money by Anonymous Coward · 2013-11-24 16:58 · Score: 0
  
  Shhh!!!
  The first rule of government-run health care is you don't talk about government-run health care.
  http://youtu.be/3sTfZJBYo1I
  Somebody forgot to tell that guy, though.
  Oops.
  Just another way of getting where they've been trying to go for decades.
  http://youtu.be/fRdLpem-AAs
87. Re: follow the money by VoidEngineer · 2013-11-24 17:02 · Score: 1
  
  MUMPS is more like Mongo, but yes... both MarkLogic and MUMPS are document-oriented databases. The MUMPS record, in my opinion is a bit more like JSON than XML, but it's the same basic concept.
88. Re:follow the money by Krojack · 2013-11-24 17:20 · Score: 1
  
  Bidding ended decades ago. It's all about who buys what politician the most fancy vacation getaways.
89. Re: follow the money by Zontar+The+Mindless · 2013-11-24 17:41 · Score: 1
  
  You're talking about wheels, which are old hat.
  They're talking about WHEELZ, which are not.
  Not the same thing at all!
  
  --
  Il n'y a pas de Planet B.
90. Re: follow the money by Zontar+The+Mindless · 2013-11-24 17:49 · Score: 1
  
  Do I understand correctly that you advocate using the database as the place where you store the data for your application?
  If so, I concur.
  So... Is there some reason it took you 5x as much space to say so as it did me just now?
  
  --
  Il n'y a pas de Planet B.
91. Re: follow the money by Unordained · 2013-11-24 18:24 · Score: 3, Interesting
  
  For those wondering about the link between MUMPS and government healthcare, my vague recollections from years ago when I worked as a developer for health + insurance software: the old MUMPS language included its own looks-like-all-in-memory database system (essentially just a recursive map of string to object, either a value or another map -- the JSON comparison is fair) which made serialization simple. The language got used to build some early health IT systems, including the one for the VA (VistA) and its IHS derivative (RPMS). That stuff's available for free, by the way, through FOIA. The projects have sufficient inertia that they still use the same data-store (at least at the API level). InterSystems Caché, for example, is a MUMPS-compatible database with some relational features (and SQL parsing) thrown on top. They bill themselves as post-relational, but yeah, it's a network database pretending to be a relational database.
  It kind of makes sense to continue using network databases for health data -- in a privacy-conscious world, it's not insane to isolate patient data into a document-oriented storage system, because you're not planning to relate data willy-nilly. We were somewhat frustrated that the HL7 interchange format tended to assume things were hierarchical, where we had seen potential graphs and coded for them -- but nobody wanted our better-related data. They prefer to re-enter the data in each place, and prevent things from being synchronized -- it protects the data from unexpected changes. So if all the systems and agencies you're integrating with have this attitude anyway, and you're constantly worried about data-interchange, I can see how you might come to the conclusion that a document-oriented, XML-backed storage engine would be a good idea.
92. Re:follow the money by Unordained · 2013-11-24 18:34 · Score: 1
  
  That was childish, petty, mean-spirited and entirely out of line.
93. Re:follow the money by Unordained · 2013-11-24 18:45 · Score: 1
  
  What's more, UnitedHealth Group is one of the largest health-insurance companies in the country and spent millions lobbying for ObamaCare.
  The insurance giant's purchase of QSSI in 2012 raised eyebrows on Capitol Hill, but the tech firm nevertheless kept the job of building the data hub for the ObamaCare Web site where consumers buy the new mandatory health-insurance plans.
  Yes, we're talking about huge players and huge deals. This is no different from Raytheon, Boeing, etc. Big players spend big bucks, and big players get picked for big projects -- and very often there's little or no competition at the scale they're operating at. It is not necessary to assume bribery or corruption, to see how this would happen.
  But I'll take your bet that this is all a conspiracy to bring about single-payer healthcare. You've made a prediction, now we'll sit back and observe you being wrong.
94. Re: follow the money by Anonymous Coward · 2013-11-24 22:40 · Score: 0
  
  Love your backed-with-sources, helpful non-generalised comment there.
  XML as a data or domain model is *perfect* in some situations - row/column models best in others.
  Seems to me that a complex, hierarchical set of data domains that need to be stored together is very well suited to the hierarchical XML model.
  hmm?
95. Re: follow the money by Anonymous Coward · 2013-11-24 22:46 · Score: 0
  
  MarkLogic uses a very efficient binary representation of data - not XML strings. It also contains an integrated search technology - you're not searching XML strings. Queries and searches can run completely out of the indexes which make it very fast.
96. Re: follow the money by Anonymous Coward · 2013-11-24 22:54 · Score: 0
  
  I don't mind XML for stuff like Docbook ... but for databases what's the point?
  How about for a domain model that is already hierarchical? What do you think Docbook is? It's one agreed upon format for storing documents full of information. (perhaps like medical information? Complex information about where, when and how insurance history works perhaps?)
  Do you think you would get benefits from having the same capabilities you would expect in your RDBMS but over XML content?
  XML is being used here as a content description language - just as viable but much more flexible as defining VARCHAR16.
  
  XML is an editing format with some down and upsides, using it as a storage format for data never edited in XML is just retarded.
  Maybe, depends on your use case. how many tables do you think you would have to create for all the different data sources, and how complex would that get? Schema-agnosticism is pretty important for the design of this system so that it would complete within this millennium. XML seems like a natural choice for a complex set of hierarchical data points.
  
  At best it just provides a useless intermediary format which doesn't affect usability ... at worst you try to use XQuery to actually perform searches on large volumes of data.
  MarkLogic's search is pretty good - their founder is Christopher Lindblad, who's built a few search engines in his time: http://www.marklogic.com/company/management-team/
  sounds like you're succumbing to you pre-concieved notions of what is good. get out a bit more...
97. Re: follow the money by Anonymous Coward · 2013-11-24 22:57 · Score: 0
  
  In fact, all of those would suck donkey balls. That is because XML, JSON and XQuery are all *data-interchange formats*. Using them to run your database internals is like using a screwdriver as a hammer.
  Quite apart from everything else wrong with this comment, XQuery is a data-interchange format?
  You sure about that? Wikipedia deigns to disagree: "XQuery is a query and functional programming language that is designed to query and transform collections of structured and unstructured data, usually in the form of XML, text and with vendor specific extensions other data formats (JSON, binaries, ...)."
  -http://en.wikipedia.org/wiki/XQuery
98. Re: follow the money by dylan_- · 2013-11-24 22:59 · Score: 1
  
  /dev/null seems to have great writing performance but has terrible reading performance. I wouldn't recommend it.
  That's because it blocks while waiting on zero point energy. If performance is an issue, you can use /dev/unull instead, if you don't really need high quality nullity.
  
  --
  Igor Presnyakov stole my hat
99. Re:follow the money by Anonymous Coward · 2013-11-24 23:16 · Score: 0
  
  Quick, let's destroy the new stuff because I'm too old to be bothered to learn new things and scared that my skills are now too out of date to be even considered "legacy"!
100. Re:follow the money by BlueStrat · 2013-11-24 23:47 · Score: 2
  
  Yes, we're talking about huge players and huge deals.
  No, we're talking about an Obama campaign contribution bundler getting a sweet payback at taxpayer expense to create something that's not designed to work in the first place. Not that that kind of thing is out of character for this administration [cough]rape-A-scan[cough].
  
  But I'll take your bet that this is all a conspiracy to bring about single-payer healthcare. You've made a prediction, now we'll sit back and observe you being wrong.
  What conspiracy? It's no secret. Here's one of the architects of Obamacare openly stating it, in a manner and tone suggesting that anyone would be stupid to NOT believe Obamacare is a path to single-payer government health care.
  Jacob Hacker, The Architect of ObamaCare and the Public Option in making his case, admits that this idea is a covert route to a Single Payer System.
  http://youtu.be/3sTfZJBYo1I
  Sorry, but the facts seem to be in conflict with your world-view. I'll take facts over hand-waving, thanks all the same.
  Strat
  
  --
  Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
101. Re: follow the money by Anonymous Coward · 2013-11-25 00:20 · Score: 0
  
  That is all true and is exactly why you can't use traditional RDMSs to solve this kind of problem. Like most NoSQL databases, MarkLogic's actual data model is a tree and triple model that efficiently stores the data represented as XML or JSON.
102. Re: follow the money by Anonymous Coward · 2013-11-25 01:36 · Score: 0
  
  Storing everything as XML means you're storing it all as strings (not very efficient). Now, if they're converting all the strings to binary data in order to store it, and then converting it back to XML to use it, then you're generating a lot of needless overhead because of the decision to store it as XML. Plus, searching XML sucks.
  With the wrong technology, definitely - but with a technology that has been built specifically to do just that, not so much. Have you seen the full text search capabilities MarkLogic seems to have available?: http://docs.marklogic.com/guide/search-dev/searchdev
103. Re: follow the money by adamfowleruk · 2013-11-25 02:12 · Score: 1
  
  As many have said, XML is here there any everywhere and so we need strategies to manage it. Some people use it purely as a data interchange format, which is fine. Others want to manage documents using an XML representation, which is fine too.
  MarkLogic takes an XML document and stores a highly compressed binary tree representation of it. It doesn't store 'raw text', or even strings. This makes it storage efficient. MarkLogic also indexes the entire document's structure, values, words and phrases (and stems thereof) for search. The database and the search engine use the same indexes, rather than a set of indexes each.
  Special range indexes can be created too. E.g. a geospatial co-ordinate pair appearing anywhere in the document. As the point's XML element could conceivably be anywhere in the document, creating a traditional schema for this is nigh on impossible. Storing the document itself, with indexes along side it, is actually quite an elegant solution.
  I would agree with your statement if it were 'XML soo sucks for traditional relational db applications', because those RDBMS systems require shredding/rebuilding of the documents, or store the XML as 'dumb' column types. Thus you lose the flexibility of the XML. MarkLogic takes advantage of the fact the data is XML anyway.
  Why not use a document database with built in support for XML to store data that is XML? Seems pretty straight forward to me.
  More details here: http://adamfowlerml.wordpress.com/2013/11/25/marklogic-huh-what-is-it-good-for/
104. Re:follow the money by ganjadude · 2013-11-25 02:21 · Score: 1
  
  The reason I used XXX was because this issue, while correct it is solely on the democrats and obama, this issue is not unique to them, it is a problem of big government as a whole.
  
  --
  have you seen my sig? there are many others like it but none that are the same
105. Re: follow the money by matt_turner_nyc · 2013-11-25 02:29 · Score: 1
  
  Spike - its the data complexity that kills relational - you would have to design the perfect schema up front and then spend years transforming all the data feeds which by the time you are done would all have changed. Schema flexibility is a huge advantage for complex data of any kind. So the fact that MarkLogic works, scales, is ACID and has flexibility makes it a strong choice for complex data problems.
106. Re:follow the money by Unordained · 2013-11-25 03:37 · Score: 1
  
  I have no problem with the idea of the ACA being a first step in a long series toward single-payer healthcare. I doubt it'll happen, because it's too controversial and it wouldn't make sense to risk everything when we've gotten this far. But hey, maybe. And I don't mind, either. There's nothing scary about it.
  But I do have a problem with the idea that making a non-functioning healthcare.gov was all part of a master-plan. I do love how we can have two narratives: that the administration is so incompetent they would allow something like this to happen, OR, it's all part of their super-genius plan to take us to medicare-for-all but LOOK like bumbling idiots along the way. That anyone should pick the latter concerns me greatly.
  So, to put a timeline to your prediction: how long should we wait to see if the healthcare.gov failure was really just a front to take us to single-payer "as the fix"? 6 months? Because any longer than that, and they wouldn't be able to keep the supposed charade up, they'd have to fix the site or implement single-payer. If your answer is on the order of 10 years, then you're talking about an entirely different political game, not about healthcare.gov.
107. Re:follow the money by Anonymous Coward · 2013-11-25 06:04 · Score: 0
  
  Who owns this company?
  how much do they contribute to XXX???
  There has got to be some reason that this DB that ive never even heard of (and i work with DBs, its not my main point of work but I know my way around DBs) got the gig over the more established players.
  or, perhaps they went with it because it is less known and therefore reduce the risk of known attacks in other DB systems?
  Dear expert sorry to disappoint you but there are databases that are not relational.
  I can not claim an expert but I used oracle, informix, db2, sql server, mysql, mongodb, marklogic ...
  each have advantages and disadvantages - what to use is based on project sometimes its even better to mix different type of databases for different data.
  Perhaps you are an expert in relational databases but that does not make you an database expert. Please add relational in front.
  Cheers
108. Re: follow the money by TuRRIcaNEd · 2013-11-25 13:23 · Score: 1
  
  As someone who worked alongside the teams on the UK NHS data spine project, I must point out that you're way off-base. To the best of my knowledge, signup data on healthcare.gov was using RDBMS technology - the NoSQL component was likely only used for unstructured data - i.e. documents and communications materiel.
  
  --
  - "How do we do it? Volume!" - The Bursar of Unseen University.
109. Re:follow the money by DGorbet · 2013-11-25 14:25 · Score: 1
  
  Hello Ganjadude. I run Engineering at MarkLogic, so I'm quite familiar with the technology, and I'd be happy to answer any questions about what it is and how it works. Here's a start:
  
  MarkLogic (the company) is a privately held company based in Silicon Valley, backed by Sequoia Capital, Tenaya Capital, and Northgate Capital. We've been around for over a decade, and have hundreds of customers in production. We like to think we were "NoSQL before NoSQL was cool."
  
  MarkLogic (the product) is an Enterprise-class document-centric NoSQL database. Enterprise-class means that it doesn't throw out the enterprise functionality you need to run mission-critical applications. Things like ACID transactions, automatic failover, database replication, and item-level role-based security. Document-centric NoSQL means that it's optimized for storing complex data that contains a mix of traditional values (dates, names, etc.) and unstructured full text in denormalized (document) form. The document-centric model allows it to store hierarchical, sparse, or repeating data easily. MarkLogic is schema-agnostic, which means that entities (documents) in the database do not need to conform to a schema (although if they do, we can take advantage of it to do things like schema validation). This also means that a database can contain a mix of data from different sources in different formats that can all be queried together. This is a key reason why many customers use us. If you want to combine complex data from multiple sources (especially if those sources are changing over time) and query it in real-time with sub-second response time, MarkLogic lets you do that.
  
  Like many NoSQL technologies, MarkLogic is built with a scale-out architecture that allows it to scale horizontally. It processes queries in parallel across nodes in the cluster, and it uses a sophisticated indexing scheme that mixes full-text and structured indexing together to provide sub-second response time to complex queries across huge amounts of data. MarkLogic uses MVCC to provide ACID transactions. For transactions that span nodes in a cluster, we use two-phase commit. Unlike many NoSQL technologies, we were designed for enterprise use, so for our customers, data consistency is important.
  
  MarkLogic is not the only technology in use in the healthcare.gov architecture, but we are used in places where it makes sense to take advantage of our ability to integrate data from a variety of sources and query it quickly and consistently. In this particular application MarkLogic is performing well, responding in less than 1/4 second for 99.9% of queries.
  
  MarkLogic is in use in hundreds of Global 1000 companies, and in many applications in public sector, civilian, military, and intelligence. We power the emergency operations network for the FAA. We powered the BBC's live coverage of the 2012 Olympics. We power the operational trade store for major investment banks. If you haven't heard of us, you should check us out. You can read more about us in Gartner's recent operational DBMS Magic Quadrant: http://gtnr.it/Ieh0hq. You can also download and play with MarkLogic at http://developer.marklogic.com/products.
  
  -- David
110. Re:follow the money by DGorbet · 2013-11-25 14:31 · Score: 1
  
  Yes, this is definitely a complex project. This is exactly the type of thing you want to use something like MarkLogic for. Combining complex data from a variety of sources and making it queryable in real time is what we do (I work for MarkLogic).
111. Re: follow the money by DGorbet · 2013-11-25 14:38 · Score: 1
  
  Just to be clear, MarkLogic doesn't store XML on disk. We store a tokenized, compressed binary representation of a hierarchical document structure. That could be XML or JSON (or just flat text). We tokenize it on ingest as part of our indexing strategy, so compression takes no extra overhead beyond what we take to index the document. We index both full text and structure, so we can answer database-style queries combined with full-text queries. Most queries can be resolved out of indexes, resulting in sub-second response times (in healthcare.gov case, MarkLogic's response time is less than 1/4 second for 99.9% of queries). There is some overhead in indexing, which you recapture many times over on the query end by being able to do complex queries quickly.
112. Re: follow the money by DGorbet · 2013-11-25 14:46 · Score: 1
  
  Hi Chris. XML and JSON are data serialization formats. It is true that they are often used for interchange (especially JSON), but for data that is best modeled as denormalized documents, it makes sense to store it in a denormalized form (versus shredding it into a complex relational schema that requires a lot of joins to re-combine it when you want to use it again). XQuery is not a data interchange or serialization format. It's a query language for content conforming to the XML data model. If your source data is XML, using a database like MarkLogic that can work well with XML is actually like using a screwdriver as a screwdriver. Using an RDBMS to do this is more like the hammer metaphor.
113. Re: follow the money by Anonymous Coward · 2013-11-25 15:01 · Score: 0
  
  Well I guess if you never do anything you never do anything to get yourself in trouble. Great strategy.
114. Re:follow the money by Anonymous Coward · 2013-11-26 08:24 · Score: 0
  
  FYI - Top management and 10Gen/Mongo are ex MarkLogic :)
115. Re: follow the money by HornWumpus · 2013-11-26 10:02 · Score: 1
  
  As I noted: They are sometimes misclassified and those DBAs are sometimes actually useful.
  
  --
  John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
116. Re: follow the money by HornWumpus · 2013-11-26 10:06 · Score: 1
  
  This idiot is a prime example of useless DBA. He thinks he is the 'expert' on code deployment and validation, based on his years of experience backing up databases.
  
  --
  John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
117. Re: follow the money by mcswell · 2013-11-26 17:00 · Score: 1
  
  There are plenty of things for which XML databases make sense. We use it for dictionaries (and so does everyone else I know who works on dictionaries). I have no idea whether it makes sense for the government insurance data, but it certainly has application outside of DocBook. (And yes, I also do XML DocBook.)
118. Re: follow the money by Anonymous Coward · 2013-11-27 17:24 · Score: 0
  
  Stop reading Murdoch's n y post. It spews counterfactuals daily. It doesn't even pretend to be real journalism. The fact is SAIC and all the other govt. teat sucking contractors who built this are heavily right wing and want the aca to fail, guaranteed. Murdoch loves nothing beter than to 'uncover' the exact opposite of the truth, and then feed it to his 100% gullible readership who are just as immune to the charms of reality as he is.
Project Chaos by Anonymous Coward · 2013-11-24 03:25 · Score: 0

Maybe they should choose better code names for their projects. This reminds me too much of Project Mayhem.
1. Re:Project Chaos by Anonymous Coward · 2013-11-24 05:10 · Score: 0
  
  "Project Chaos" wasn't the name of the project, it was:
  - the project management philosophy (it's a combination of "agile project management" and "700 monkeys type Shakespeare").
  - a failed episode of South Park centering around Captain Chaos.
  - the definition in the dictionary next to a picture of the website.
  - all of the above.
Noobs? by Anonymous Coward · 2013-11-24 03:26 · Score: 5, Insightful

FTA: "An initial assessment identified more than 600 hardware and software defects — 'the longest list anybody had ever seen,' one person involved with the project said. "
Strikes me as none of these people seemed to have ever worked on large projects before.
1. Re:Noobs? by Anonymous Coward · 2013-11-24 03:40 · Score: 3, Funny
  
  You don't understand. That's not "600 bugs in the software" that they are talking about. "Thousands of bugs in software" is just one of 600 items that was a defect. Others included "Not enough servers", "Data connection to limited in capacity and speed", and apparently "No hablo espanol".
2. Re:Noobs? by larry+bagina · 2013-11-24 04:56 · Score: 3, Insightful
  
  I counted 279 defects. (60 in the senate, 219 in the HoR). Had but 1 in the senate or 4 in the house been fixed, all this would have been averted. My kingdom for a horse, indeed.
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
3. Re:Noobs? by bananaquackmoo · 2013-11-24 06:27 · Score: 1
  
  I'm pretty sure he understands. Like he said, it seems to me as though those people have never worked on large projects before.
4. Re:Noobs? by Anonymous Coward · 2013-11-24 09:18 · Score: 0
  
  If "the longest list anybody had ever seen" is "more than 600" that does not place any upper bound on the size of projects they have participated in.
5. Re:Noobs? by Anonymous Coward · 2013-11-24 23:59 · Score: 0
  
  Racist.
Taxes... by 3seas · 2013-11-24 03:28 · Score: 0

I do not approve my taxes being spent for this.
1. Re:Taxes... by Anonymous Coward · 2013-11-24 03:54 · Score: 0
  
  I do not approve my taxes being spent for this.
  I'm sure they took that into consideration...
2. Re:Taxes... by Anonymous Coward · 2013-11-24 04:02 · Score: -1
  
  Too bad the election was decided by the 47% that pay no taxes.
3. Re:Taxes... by Anonymous Coward · 2013-11-24 04:02 · Score: 1
  
  That's ok, your share of taxes actually was specifically allocated to paying for a toilet in the Ozarks.
4. Re:Taxes... by Bengie · 2013-11-24 04:08 · Score: 4, Insightful
  
  The "47%" that people keep talking about are almost entirely retirees, adults going to full time college, or the disabled. The largest portion of the group are the retired people. Are you saying that people who have worked their whole like and are now retired, should not have a say in taxes?
5. Re:Taxes... by dugancent · 2013-11-24 04:13 · Score: 1
  
  Everyone pays taxes, income or not. Buy something? Sales tax. Pay utility bills? Taxed. Buy gas? Taxed.
  
  --
  SJWs are the new boogeyman. -Me
6. Re:Taxes... by Fwipp · 2013-11-24 04:17 · Score: 4, Informative
  
  Also the working poor - 47% pay no _income_ tax, but more than half of those people do pay payroll taxes, and even many those who don't (after deductions) still work.
  They also pay sales tax, property tax, etc etc.
7. Re:Taxes... by Dereck1701 · 2013-11-24 04:37 · Score: 3, Informative
  
  Sorry to break it to you but that "statistic" is a bunch of BS. Everyone in the US pays taxes of some sort. I'm not particularly high on the tax scale (about $36k a year) and I estimate that i pay at least 30% of my income in local, state, federal and specific taxes (sales, gas, property, vehicle, etc). MAYBE some very poor (or very rich) people can avoid some of those taxes but EVERYONE pays at least a few of them.
8. Re:Taxes... by Anne+Thwacks · 2013-11-24 04:40 · Score: 1
  
  Please use MY tax for that - its way better than most of the stuff that tax gets used for! (On condition that it is a unisex toilet).
  
  --
  Sent from my ASR33 using ASCII
9. Re:Taxes... by larry+bagina · 2013-11-24 05:01 · Score: 1
  
  Bad news -- it's a glory hole. Still a better use than most tax dollars.
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
10. Re:Taxes... by Anonymous Coward · 2013-11-24 09:40 · Score: 0
  
  Too bad the election was decided by the 1% that pay no taxes.
  FTFY
11. Re:Taxes... by Cordus+Mortain · 2013-11-24 12:33 · Score: 1
  
  I don't approve of my taxes being used to wage war on people we have no right waging war on. Guess what - don't have a say in that either.
12. Re:Taxes... by fredrated · 2013-11-25 02:24 · Score: 1
  
  That's funny, I didn't approve of my taxes being spent killing hundreds of thousands of people that were no threat to me or anyone I know, yet it still happened. WTF?
NIH syndrome by Gothmolly · 2013-11-24 03:28 · Score: 4, Insightful

You could take a handful of proven DB technologies such as Oracle/DB/MSSQL, throw a web (Apache/IIS) and app (.Net/WAS/Jboss) front end to it, and it would work. Why did these guys fuck up the whole thing? It's like the scene in The Fountainhead when the second-rate architects smash up the plans and add their own stuff, "to express their own individuality". This could have been a solved problem - hell, it WAS a solved problem.

--
I want to delete my account but Slashdot doesn't allow it.
1. Re:NIH syndrome by Anonymous Coward · 2013-11-24 03:35 · Score: -1
  
  NoSQL is a proven technology. It is used in production all over the place including where I work. Sorry about your late 80s db schemas.
2. Re:NIH syndrome by Anonymous Coward · 2013-11-24 03:38 · Score: 0
  
  but but but... NoGirlsAllowedSQL is WebScale!
  WEBSCALE!
3. Re:NIH syndrome by Anonymous Coward · 2013-11-24 03:47 · Score: 0
  
  But it would not have worked if configured poorly, so I doubt using oracle, mssql or whatever would have helped, since they would have been quite likely to configure it just as poorly and to skip load testing anyways.
  My university went for an Oracle solution(Software and hardware) for db for their intranet that handled everything and used it as a magic bullet since it cost so much. So first few months with the new system were a mess because it couldn't handle 100 simultaneous users due to combination of poor design that caused unnecessary amounts of lookups to be performed and bad configuration of the database, namely having a connection limit that was hit way before resources were at low. Of course the whole system could have been handled with postgre or even mysql, but they had a budget and burning it on license and hw seemed like a smart idea by the head of the IT(who was cursed by faculty of course and was cursed regardless of this particular decision).
4. Re:NIH syndrome by Anonymous Coward · 2013-11-24 03:49 · Score: 0, Flamebait
  
  Of course it was already solved. All the federal government really needed to do was allow health insurance to be sold across state lines so it could be portable, allow a range of plans to fit people's budgets with minimum coverage requirements, and pool high risk patients. Then, corporations or small businesses could have provided a tax free stipend to their employees who could purchase whatever coverage they wished.
  Instead, we got a top down centralized planning crony corporatist version with a fucked up website and database, that requires young and healthy people to pay far more for insurance than required. You can't call it an unintended consequence, because it was well predicted that this administration would screw the pooch.
5. Re:NIH syndrome by Okian+Warrior · 2013-11-24 03:52 · Score: 5, Insightful
  
  Why did these guys fuck up the whole thing?
  All actions by Federal government players seem rational when viewed from their point of view.
  The problem with most analysis, here or on other sites across the web, is in the assumptions. Specifically, if you assume that the government actions are for some benefit to the people, or efficiently completes some task (which is assumed to benefit the people), then nothing they do makes sense. That assumption makes for good outrage which can attract readers, but it doesn't answer the question of "why".
  When government actions are viewed in light of more obvious motivations, everything it does makes sense. You start to see them not as an pack of incompetent, bureaucratic screw-ups, but as a self-sustaining, self-absorbed, engine of corruption.
  I'm not aware of *anything* the federal government's done in the past two decades that's been in the interests of the people. All the useful stuff, the stuff you would want to keep across a reboot, was several decades ago.
  I don't know the specifics of why an obscure database was chosen over the obvious players, but the reason wasn't "best utility for the people". Look for another reason.
6. Re:NIH syndrome by Anonymous Coward · 2013-11-24 03:53 · Score: 0
  
  NoSQL is an almost meaningless word. It is not a technology, it's a mass of different technologies. Some of which are complete crap.
7. Re:NIH syndrome by Anonymous Coward · 2013-11-24 03:55 · Score: 0
  
  > It's like the scene in The Fountainhead
  No, NO!!! That WORD, it BURNS, BURNSSS!!!
8. Re:NIH syndrome by jythie · 2013-11-24 04:17 · Score: 5, Insightful
  
  Sad thing is, much of the behavior one sees out of federal contracts is due to taxpayer groups demanding anti-corruption measures. A great deal of the bureaucracy comes directly from people complaining about waste and demanding a complex audible process.
  
  I would actually put forward that the problem is not the government, our government is pathetically weak in many ways. The problem are all the private groups flexing their muscles and making the government dance. Most of the people I have worked with on these kinds of projects are good people who just want to get stuff done, but they are weighted down by a nearly impossible set of requirements, many of which are mutually exclusive, dropped on them by outside groups who mainly are interested in showing off their power to their own people and have no investment in the project itself being successful.... and often have an active interest in the project failing since they can always use that as fuel for more personal power.
9. Re:NIH syndrome by MightyMartian · 2013-11-24 04:24 · Score: 2
  
  Can someone explain to me how, for a project like setting up exchanges for Obamacare, NoSQL database systems is a rational choice? There are SQL-based systems like Oracle and MSSQL that can certainly handle recordsets of that size,and with that level of activity, and give you dialects of SQL sufficiently close to the norm that anybody with a reasonable level of RDBMS experience should be able work with it.
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
10. Re:NIH syndrome by Anonymous Coward · 2013-11-24 04:51 · Score: 0
  
  They probably have a bunch of XML feeds from different government agencies and private insurers, and some PHB saw "XML database" and decided it was perfect for the job.
11. Re:NIH syndrome by Anonymous Coward · 2013-11-24 05:16 · Score: 0
  
  I'm just thrilled they didn't use Wordpress for the site. I don't want to read about a HealthCare.gov plugin.
12. Re:NIH syndrome by Will.Woodhull · 2013-11-24 05:38 · Score: 1
  
  It is a solved problem if and only if you limit database operations to today. Then you can use today's best software and practices.
  But this is too big a system to be taken through the revisions that are needed every 7 to 10 years to keep a DBMS up to date. For one thing, once it is in full operation it cannot be taken off line for a weekend upgrade. That adds a lot of headaches as you can count on always having to support simultaneous database operations by two or more different versions of software: the pre-upgrade version and the post-upgrade version. You also have to assure that records last updated 50 or more years ago can still be accessed, even though fields may have been added, dropped, or merged in the meantime.
  I am surprised that any corporation took this on. Winning this contract was a poison pill, and that would have been obvious to anyone with a memory of what the Veterans Administration went through when they began implementing ViSTA and the Computerized Patient Record System in the last years of the last century. And ViSTA was a simple overlay on a proven database engine, not this kind of build from scratch project.
  
  --
  Will
13. Re:NIH syndrome by mlts · 2013-11-24 05:45 · Score: 1
  
  You hit the nail on the head. There is just so much expertise at building a mainstream Web stack and backend database, that it is almost acting in bad faith not to take advantage of it.
  Then there is the security aspect. You can throw money to buy the skills needed at Oracle to have it locked down. Same with Windows, Linux, Solaris or AIX for the OS, Apache or IIS for the webserver, and a backend platform of choice.
  Using something so off the beaten path may just mean that something can't be done on the platform, period, be it security modifications that are needed, added capacity, functionality, and them some. With a normal Linux or Windows stack, it would be a matter of enlisting help to work on new DB schema. With this stuff, the talent may not be there.
14. Re:NIH syndrome by zippthorne · 2013-11-24 06:48 · Score: 1
  
  Surely it's more due to lobbyists corrupting the anti-corruption measures demanded by taxpayer groups.
  
  --
  Can you be Even More Awesome?!
15. Re:NIH syndrome by Anonymous Coward · 2013-11-24 07:21 · Score: 0
  
  You could take a handful of proven DB technologies such as Oracle/DB [sic]/MSSQL, throw a web (Apache/IIS) and app (.Net/WAS/Jboss) front end to it, and it would work. Why did these guys fuck up the whole thing? It's like the scene in The Fountainhead when the second-rate architects smash up the plans and add their own stuff, "to express their own individuality". This could have been a solved problem - hell, it WAS a solved problem.
  Is this Slashdot I just logged into, or InformationWeek?
  BUT there's the expected disgust and sarcasm at what the government officials and private contractors have done, so I guess there's the continuity.
16. Re:NIH syndrome by Jim+Hall · 2013-11-24 07:41 · Score: 1
  
  Sad thing is, much of the behavior one sees out of federal contracts is due to taxpayer groups demanding anti-corruption measures. A great deal of the bureaucracy comes directly from people complaining about waste and demanding a complex audible process.
  *auditable
  I'm going to assume that was an autocorrect error on your post.
17. Re:NIH syndrome by Anonymous Coward · 2013-11-24 08:54 · Score: 0
  
  All the federal government really needed to do was allow health insurance to be sold across state lines so it could be ... regulated as interstate trade by the federal government. FTFY. But then, the purpose here is to make sure states can't regulate what goes on in their own borders. True to the Republitard standard, they're all for states' rights, until they exercise the right to do something the Repulitards don't want.
18. Re:NIH syndrome by ultranova · 2013-11-24 08:59 · Score: 2
  
  Can someone explain to me how, for a project like setting up exchanges for Obamacare, NoSQL database systems is a rational choice?
  
  Well, the obvious answer is that someone involved has goals other than the site succeeding, such as lining their pockets or even outright sabotage. After the government shutdown fiasco, the latter sadly can't be ruled out; the US is basically at Civil Cold War at this point.
  
  --
  Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
19. Re:NIH syndrome by Anonymous Coward · 2013-11-24 09:26 · Score: 0
  
  No, accessing the DB direct isn't done that often. Your class objects handle it, and developers use them rather than constructing their own SQL. The underlying DB is totally irrelevant.
20. Re:NIH syndrome by Bite+The+Pillow · 2013-11-24 13:59 · Score: 1
  
  No, it would not work. The database portion might be faster, or more stable, or at least better understood by the developers.
  The database is XML - that's neither good nor bad. The rest of the system seems to be where they have problems - authentication, load, and accessing external data.
  Your statements do not make any sort of sense given what we know. And your mention of Rand, where the context was a choice of individuality, and in this case it was a requirement given by Medicare to the contractor, is a complete non sequitur.
21. Re:NIH syndrome by Bite+The+Pillow · 2013-11-24 14:11 · Score: 1
  
  You would have a point, if anything about this gave anyone self-sustainment.
  HHS Secretary Sebelius took the arrow for Obama, saying he didn't know (and she did) that it would fail. That's one Democrat ex-Governor with a giant black mark.
  Obama might not care because he's a lame duck. But this is a major act that Republicans did not want, and they will use this failure to gain voters in the next 3 federal elections at least.
  The main contractor has a huge black mark, despite being given concrete (and ever changing) requirements to use specific technologies. They were asked to manage, but not given power to manage, subcontractors.
  There is quite literally no one in this mess who comes out better than before. At least, I can't think of one. Unless you think that the Democrats in general took one for the team so the Republicans could take over, keeping the two party system in power. To make anything good out of this would require such broad, long-term planning that it would be impossible to believe. I'm going to need some more specifics from your hazy conspiracy theories, and by God if you don't include at least one reference to the Illuminati, Skull and Bones, Lizard People, or Dan Brown, I will find you and punch your silly little nose.
22. Re:NIH syndrome by VoidEngineer · 2013-11-24 17:04 · Score: 1
  
  Remember, the government has been using document-oriented NoSQL databases for some 40 to 50 years with MUMPS, the database in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology solution for government healthcare projects for decades.
  
  http://en.wikipedia.org/wiki/Mumps [wikipedia.org]
  http://en.wikipedia.org/wiki/VistA [wikipedia.org]
23. Re:NIH syndrome by Zontar+The+Mindless · 2013-11-24 18:02 · Score: 1
  
  NoSQL is a proven technology. It is used in production all over the place including where I work...
  ... but evidently not as a developer.
  
  --
  Il n'y a pas de Planet B.
24. Re:NIH syndrome by matt_turner_nyc · 2013-11-25 02:37 · Score: 1
  
  If you are equating NoSQL with unreliable, no transaction systems with no security then I can see your point. But as others have pointed out MarkLogic has ACID and scaling and flexibility as well as security and is pretty well proven out to be stable and scalable. So now it comes down to the data model -> complex ever changing data is a hard task for relational. You have to create the perfect model first and then transform all the data into that model. Several years later when that is done you can start again because the data has all changed. NoSQL brings schema flexibility and with that the whole process is changed -> you can load the data first, execute mappings and normalizations as needed and get up and running with reliable access much much faster. You still need a data model, you still need to understand the data, but the whole process takes much less time and, assuming you are using MarkLogic, is as reliable as any RDBMS system.
25. Re:NIH syndrome by interkin3tic · 2013-11-25 02:48 · Score: 1
  
  For anyone else who might be confused, "NIH syndrome" is short for "Not invented here syndrome. . Not the National Institute of Health. Perhaps I was the only one confused there.
26. Re:NIH syndrome by bobaferret · 2013-11-25 04:33 · Score: 1
  
  As someone who's built and runs a fairly large government website, I agree with you. Every year 3 months there are more legislative requirements and fields to deal with etc, permissions, changing points of interest, reporting etc. It's a complex moving target, with no one to have a dialog with. The governor will mandate one thing, while the house will do another, the feds another, and the supreme court another. 1/3 of the time all conflicting with each other. Then you layer that on top of 102 local government rules, and political agendas, and things start to get complicated, then make it real time. There of course is the lack of budget, due to cutbacks, but that just makes it fun.
  Most of the data exchanges between agencies are XML based. Check out IEPD's and NIEM for a sense of what folks are dealing with. You have to have a large amount of flexibility to collect and store the ever changing data that gets submitted to you. In a way that can be gone through later when someone out there decides that some piece of data is important, or indexable/searchable, yet you may end up in a situation where a large majority of your data providers won't/ can't even provide that data for months or years. They are all different/independent vendors with their own priorities and budgets. It's a glorious mess out there. We use a combination NoSQL and RDBMS to get it done.
  I've been surprised that healthcare.gov made it as far as they did. I don't think the marklogic call was a bad one though. I think what looks to be the hiring of a company without a lot of experience in the XML/NoSQL/NIEM arena was.
27. Re:NIH syndrome by AliciaSlashdot · 2013-11-25 06:09 · Score: 1
  
  Ask the folks in Oregon how well Oracle is working for them... http://www.slate.com/blogs/weigel/2013/11/22/oregon_has_signed_up_zero_people_for_private_health_insurance.html
28. Re:NIH syndrome by micahraleigh · 2013-11-25 10:23 · Score: 1
  
  I don't think it's the outside anti-corruption groups that are causing them to adopt unusual DBMSs and outspend what Facebook invested (over the course of its entire lifetime).
  
  Keynesians don't turn to anti-corruption groups since it slows the aggregate demand. The people who want expanded government are the ones who put this together.
Stop with the excuses. by Anonymous Coward · 2013-11-24 03:29 · Score: -1

It's a clusterfuck. And it was designed from the start to be a clusterfuck because half the people involved wanted it to fail. So they could blame the other half.
1. Re:Stop with the excuses. by Anonymous Coward · 2013-11-24 03:42 · Score: 2, Informative
  
  It was designed from the start to pave the way for single payer health care.
2. Re:Stop with the excuses. by DarkOx · 2013-11-24 03:48 · Score: 5, Insightful
  
  Bullshit. Since the law has been passed almost the entire implementation has been up to the administration. Which in case you had not noticed is lead by partisans in favor of the affordable care act.
  If the GOP can be accused of anything material in terms of interfering with the implementation it would preventing the law from being amended, and if it needs amending there is your proof it was bad law to begin with. Sorry Obama owns this and really HE owns it not even the larger DNC as its HIS branch of government that has been responsible for implementation from the moment HE signed the thing.
  *IF* it fails its either because it was unworkable in the first place as written and should not have been enacted or because the Obama administration failed to execute. Those are really the only honest high level conclusions.
  The argument well because they had to pass the Senate bill as is it did not get the usual fixes and tweaking is why its got so many problems is also bogus. They had to pass the Senate bill by abusing the budget reconciliation process to deny the minority party in the House at the time its rights; they knew if usual procedures were followed it would never have become law. So again it either should not have been enacted or the administration has failed to execute.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
3. Re:Stop with the excuses. by Assmasher · 2013-11-24 03:59 · Score: 1
  
  Since the law has been passed almost the entire implementation has been up to the administration.
  The implementation is, for the most part up to the administration and they certainly have screwed the pooch on this; however, the GOP can quite easily be accused of willfully sabotaging the process through the ACA lawsuits and intentional state exchange shortcomings (not to mention a myriad of other issues that relate to the shutdown, refusing ancillary funding out of spite, and issues with the Supreme Court.)
  In any case, even if the GOP are being total jerks about the law, healthcare.gov requires a software solution that has been patterned thousands of times. It's a total fumble by the Democrats.
  The party system should simply be banned outright.
  
  --
  Loading...
4. Re:Stop with the excuses. by I'm+New+Around+Here · 2013-11-24 04:00 · Score: 1
  
  To be fair, the AC didn't specify Republicans and Democrats. It could have been internal groups behind the website itself that wanted to blame other internal groups, to pump up their own importance. That could be what he meant.
  .
  But, yeah, he almost certainly made a laughable dig at the GOP there.
  
  --
  If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
5. Re:Stop with the excuses. by DarkOx · 2013-11-24 04:36 · Score: 1
  
  GOP can quite easily be accused of willfully sabotaging the process through the ACA lawsuits
  Attempting to sabotage it maybe, succeeding no. There was never even so much as a stay issued, as far as I am aware, preventing the administration from getting started on implementation. If I am wrong on that please correct me but I don't think the court cases could have had much impact on the implementation.
  The medicare expansion issue is going to create a coverage gap, in the states that did not do it. That is about the only *problem* the legal challenges successfully created.
  As far as states not implementing their own exchanges the law always intended to provide a federal solution for them; so that isn't much of an excuse for its failure.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
6. Re: Stop with the excuses. by jhoger · 2013-11-24 05:46 · Score: 1
  
  Uh, no the Republicans do not have clean hands in this foaled rollout.
  By refusing to set up the state exchanges they shifted a massive burden to the Feds unplanned for in the law. Then, they refused to expand funding for this massive integration effort. Think about it... Most of the state exchanges are doing fine. Why? Because they only have to meet one state's requirements. The Feds were forced by Republican tactics to handle the differing requirements for 30+ states.
7. Re:Stop with the excuses. by wiredlogic · 2013-11-24 07:10 · Score: 1
  
  The GOP is more Machiavellian then you give them credit for. All it takes to cause interference is to buy off some insiders that will make strategic blunders that are beneficial to ones goal. Malice masquerading as incompetence is the safest way to stop up the works in DC. As long as the money trail can be hidden there is no risk of blowback.
  
  --
  I am becoming gerund, destroyer of verbs.
8. Re:Stop with the excuses. by Velex · 2013-11-24 07:42 · Score: 0
  
  Well, then, good. Let's get on with it.
  My car insurance doesn't cover oil changes; my homeowner's insurance isn't going to cover replacing a screen door that went kaput during the storms last weekend; so why the hell does health insurance cover routine check-up visits?
  I'll even go one step further. If I were to use my prescription coverage for my meds, it'd end up costing me more out of pocket. Here's what I want. I want health insurance that doesn't play stupid games with deductibles and routine services. I need my meds every day, and I know how much those cost. I need bloodwork every now and then as a completely routine matter, and I want to know how much that costs so I can budget for it. However, if I get run over by a bus tomorrow, I want to wake up in a hospital knowing that I'm insured and will only have to worry about a small deductible, same as if a drunk driver plows into my car and I need $10k of body work or if a tree falls on my house and I need to replace the roof.
  Why do we have a system where "insurance" covers routine things and it's nearly impossible to get a price for so many things?
  I don't want to pay for womyn-born-womyn to use the pill. It's not my problem. You don't want to pay for me to take estrogen. It's not your problem. These aren't life-threatening things.
  The only problem is that unlike you and me, the vast majority of people aren't and never will be perfect, virtuous Randians[!]
  Now, the following is a misogynist rant, sure, but I hope to illustrate the larger problem. If it's more useful, imagine I were writing about some other failure of human behavior like dudebros cruising around town drunk and having a near-fatal crash wherein somebody innocent, but lacking any kind of insurance, requires intensive medical care for some extended period of time.
  If womyn-born-womyn have to pay some amount per month to have access to the pill, then there are a good number of them that won't. However, being falliable human beings, they'll go out and have sex anyway. Then, since if they weren't willing to take a basic precaution that somebody with a womb should take before going on a wild sex adventure (not saying there's anything wrong with wild sex adventures, but we have the technology to go about it safely!), they're sure as hell not going to have the cash sitting around for an abortion. Then, 9 months later we have a real problem: an unwanted or at least unexpected mouth to feed.
  So, it makes financial sense to make the pill and abortions available to womyn-born-womyn at no cost, because the alternative is that my tax dollars, instead of going to services I may wish in a perfect world a womyn-born-womyn would consider before having sex (simply because life isn't fair and they'd be perfect Randians in this ideal world and realize that their self-interest is served by taking precautions even if guys don't have to but it's just the way it is no matter what anyone wants), will now go towards feeding a child for 18 years.
  People (regardless of gender) are bad at judging risk. People are especially bad at making financial judgements when it comes to health.
  I used to be a libertarian (and intend to keep voting Libertarian because I think we need to seriously reconsider the scope of the federal government and I have this abstract hope that one year, enough people will vote Libertarian and Green not just to send a message to the two big parties but that the form of that message will be a number of gold and green seats in Congress), but the older I get the more I realize that the free market does not work for health care.
  Our current system is utterly broken. Romney/Obamacare is even more broken, and as others have said, the more information that comes out about the failure of the healthcare.gov rollout, the more it becomes apparent that Obamacare at least is more about shuffling money around Washington than it is about attempting to do anything about the things that ar
  
  --
  Join the Slashcott! Stay away entirely Feb 10 thru Feb 17! Close all tabs to prevent autorefresh!
9. Re: Stop with the excuses. by Anonymous Coward · 2013-11-24 07:46 · Score: 0
  
  > they refused to expand funding
  Exactly. They are at fault. Everyone knew that $2 per person that was spent on the web site was not nearly enough. They killed it on purpose. They are irrational and are willing to hurt themselves just to make sure that minorities don't get health care. The site, as has been proven by reality, should have gotten at least four times that much funding. $2.4 billion would have left us with a working web site. Instead, the Republicans cut the funding to kill the site. They always do that, and the media didn't cover any of the votes where they stole money from ACA to give to defense contractors.
10. Re:Stop with the excuses. by JDG1980 · 2013-11-24 07:56 · Score: 1
  
  My car insurance doesn't cover oil changes; my homeowner's insurance isn't going to cover replacing a screen door that went kaput during the storms last weekend; so why the hell does health insurance cover routine check-up visits?
  Because if it doesn't, then a lot of financially strapped people will skip those visits, and incipient problems won't show up until later, when they are much more expensive to fix. Funding preventive care actually saves money in the long run.
11. Re:Stop with the excuses. by Assmasher · 2013-11-24 08:20 · Score: 2
  
  Attempting to sabotage it maybe, succeeding no. There was never even so much as a stay issued, as far as I am aware, preventing the administration from getting started on implementation
  Sorry, but even as an independent I would have to disagree with that. The statute provided monies for states to create their exchanges, there was no stipulated money to fund a federal exchange because it was entirely expected that states would want to control this themselves.
  Suddenly GOP led states started saying "we're not building that" which makes absolutely zero sense except as a political stratagem to sabotage the process. You should note that the only two non-GOP states to leave the burden entirely to the feds are Montana and Missouri. Montana wasn't able to build their own because the GOP controlled legislature killed the governor's attempt to begin designing the exchange. Missouri is doing this for EXACTLY the same reasons.
  The ambiguity over how many states the federal system would have to account for apparently hampered the setting of specifications (it would seem that most states needed custom integration bridges into the federal system) and severely impact the costs and complexity of the project (which was funded through means other than the bill.) It was always the goal of the statute that as many states as possible would manage their own exchanges - it was clearly not expected that the GOP would directly urge Republican led states to add their load the the federal exchange out of spite for the ACA. The irony is that this is the GOP asking states to give up authority to the federal government, lol.
  You'll note that the states that did build their exchanges with the federal monies set aside for them seem to be doing ok, many of them exceeding their target roll-out goals.
  It's also kind of silly to argue that GOP opposition hasn't made it more difficult and complicated to build, roll out, and run Healthcare.gov, I mean, simply ask yourself - "Would the healthcare.gov rollout gone better or worse with support from the GOP?"
  The GOP is clearly doing everything in its power to have the federal exchange fail, and "doing everything in their power" doesn't mean just sitting quietly as you seem to suggest, it is actively sabotaging the funding and the process.
  As for Democrats, apparently they ...couldn't build anything other than a good case of hemorrhoids.
  BTW, totally agree with you regarding the 17th amendment - states lost virtually all of their ability to be effectively represented when this happened.
  
  --
  Loading...
12. Re:Stop with the excuses. by Mansing · 2013-11-24 08:42 · Score: 1
  
  Since the law has been passed almost the entire implementation has been up to the administration.
  I think you meant:
  Since the law has been passed almost the entire implementation has been up to the bureaucrats.
  FTFY.
13. Re: Stop with the excuses. by Anonymous Coward · 2013-11-24 10:58 · Score: 0
  
  The media also didn't cover me having sex with Kim Kardashian last night. Possibly because it don't happen, either.
14. Re:Stop with the excuses. by HiThere · 2013-11-24 13:16 · Score: 1
  
  I don't know about YOUR health care insurance, but mine decided that if Medicare didn't consider a routine physical to be worth covering, then they wouldn't cover it either.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
15. Re:Stop with the excuses. by Velex · 2013-11-24 16:50 · Score: 1
  
  That's kind of the point and one of the reasons, perhaps, that the free market or even the insurance model doesn't work for health care. I also read an argument once that the reason that chiropracty and homeopathy work is because the provider spends more time with the patient and thus obtains a better understanding of the risks that patient might be subject to. Of course, homeopathy itself is bunk; and chiropracty might have specific uses, but I lol every time I see the banner down the main drag in town that this chiropractor can cure ear infections. However, it does seem to reason that better outcomes would result if patients and their providers shared more information. Profits create a perverse incentive that minimize the contact between patient and provider.
  
  --
  Join the Slashcott! Stay away entirely Feb 10 thru Feb 17! Close all tabs to prevent autorefresh!
16. Re:Stop with the excuses. by Anonymous Coward · 2013-11-25 06:45 · Score: 0
  
  Someone somewhere decided it was cheaper to pay for the tens of people who get colon cancer rather than thousands of people having colonoscopies.
17. Re:Stop with the excuses. by Anonymous Coward · 2013-11-25 13:01 · Score: 0
  
  Amendments are patches/upgrades to the law to fix bugs that were found. Doesn't mean the law was bad, means issues were overlooked or they need to adjust it to match reality.
MarkLogic = NoSQL by NeverWorker1 · 2013-11-24 03:35 · Score: 4, Interesting

A little googling turns up that MarkLogic's offering is NoSQL. Without getting into the whole SQL/NoSQL debate, I can't help but noting that this is clearly relational data with a fairly limited number of records (clearly there can't be more than 300M people listed) and for which ACID is (or should be) a major concern.
1. Re:MarkLogic = NoSQL by mobby_6kl · 2013-11-24 03:45 · Score: 1
  
  But how would a traditional relational database scale to the 1 billion, or 1,000 billion users, huh? Did you think about the need to future-proof the application?
2. Re:MarkLogic = NoSQL by Anonymous Coward · 2013-11-24 03:47 · Score: 5, Interesting
  
  A customer at work has a MarkLogic database. I don't know what version it is, but I assure you IT IS HORRIBLE. It's like... an XML database or some shit. Just awful, and extremely confusing to use.
  A couple years ago I was asked to do automatic database backups. The only documentation I could find for backing up the database requires logging into a web interface I had no idea existed on an obscure port and clicking a backup button. I literally had to write a perl script to fake a browser and do this just so they could get a database dump.
  Do not use this product. Please.
3. Re:MarkLogic = NoSQL by Anonymous Coward · 2013-11-24 03:52 · Score: 2, Funny
  
  They should have used MongoDB, because MongoDB is webscale.
4. Re:MarkLogic = NoSQL by Anonymous Coward · 2013-11-24 03:53 · Score: 0
  
  Let me know when that hits 1 billion.
  http://www.census.gov/popclock/
5. Re:MarkLogic = NoSQL by Anonymous Coward · 2013-11-24 03:58 · Score: 0
  
  Mod: I think this should be marked as humor
6. Re:MarkLogic = NoSQL by Assmasher · 2013-11-24 04:02 · Score: 1
  
  AKF cube.
  Healthcare.gov isn't a particularly difficult scaling problem to solve. You can 'swim lane' the hell out of it.
  It's not like it's a social network where people need to be constantly sharing things and an arbitrarily large (potentially huge) group of people need to be notified of everything each of them does/doesn't do...
  
  --
  Loading...
7. Re:MarkLogic = NoSQL by Charliemopps · 2013-11-24 04:03 · Score: 1
  
  Oh, but they claim to be ACID complaint: http://www.marklogic.com/blog/can-you-pass-the-acid-test/
  lol
8. Re:MarkLogic = NoSQL by DarkOx · 2013-11-24 04:05 · Score: 1
  
  But how would a traditional relational database scale to the 1 billion, or 1,000 billion users, huh? Did you think about the need to future-proof the application?
  I don't know if you are kidding or not but I'll try anyway.
  The US population might hit 1 billion inside the period where something form of the ACA is intact in a recognizable way. Unlikely but its possible. Using partitioning schemes it should be fairly simple to scale on traditional database technologies because for most queries you don't need to know about Abby to handle a transaction regarding Bob. There are some where you do but even those are mostly simple 1:1 update operations, you might need to set Abby's spouse attribute to Bob's SS number or something; never the less there are lots natural ways to partition the data which should make scaling out across more RDBMS servers workable; at least out to the 1 billion mark.
  At 1,000 billion we will probably be so concerned with were our next glass of water is coming from that who has health insurance and who is claiming to be President for that matter won't really matter to anyone.
  
  --
  Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
9. Re:MarkLogic = NoSQL by I'm+New+Around+Here · 2013-11-24 04:05 · Score: -1, Offtopic
  
  About two years after they open the borders to all illegal immigrants who promise to vote Democrat.
  
  --
  If you think I voted for Trump because of this post, you're wrong. I voted for Dr. Jill Stein of the Green Party. Again.
10. Re: MarkLogic = NoSQL by MyDixieWrecked · 2013-11-24 04:16 · Score: 4, Interesting
  
  Marklogic, afaik, is the only acid compliant nosql solution that exists.
  
  --
  
  ...spike
  Ewwwwww, coconut...
11. Re:MarkLogic = NoSQL by swilver · 2013-11-24 04:18 · Score: 1
  
  It would scale just fine, assuming you make proper indexes for your queries.
  Since the general use case is probably gonna be something like "pull up records for patient that is sitting infront of me and edit them", I think an index lookup + atmost a couple of dozen records pulled from related tables will be handled just fine.
  Any other use cases that involve statistical analysis on all data can be handled by copying it to specialized DB's every few weeks.
12. Re:MarkLogic = NoSQL by gmuslera · 2013-11-24 04:36 · Score: 3, Informative
  
  Google and Facebook seem to be doing pretty well having that order of users. Facebook even uses simple mysql replication and their pool scanner. And health system is not a social network, there is no so much connection between different users.
13. Re: MarkLogic = NoSQL by xaxa · 2013-11-24 04:56 · Score: 2
  
  Marklogic, afaik, is the only acid compliant nosql solution that exists.
  Neo4j is an ACID-compliant graph database (so it's NoSQL, but that word is a bit pointless).
  It's also the most useful non-relational DBMS: relationships become first-order entities, having a type and properties.
  http://www.neo4j.org/
14. Re:MarkLogic = NoSQL by Anonymous Coward · 2013-11-24 05:08 · Score: 0
  
  I desperately wish that I could upvote this.
  Alas I can only provide a URL: http://nosql.mypopescu.com/post/1016320617/mongodb-is-web-scale
15. Re:MarkLogic = NoSQL by mcgrew · 2013-11-24 05:19 · Score: 1
  
  You make little sense there. By the time there are a billion people in the US we'll either be single-payer like the intelligent, civilized world has, or we'll go back to "no money? Let 'em die."
  
  --
  Free Martian Whores!
16. Re:MarkLogic = NoSQL by Anonymous Coward · 2013-11-24 08:57 · Score: 0
  
  I'm pretty sure even a couple years ago MarkLogic had scheduled backups.
17. Re:MarkLogic = NoSQL by Bite+The+Pillow · 2013-11-24 14:18 · Score: 1
  
  The base data is correlated with external data sources at all times. While signing up, it is important to keep obtained data together. And keeping a record of who signed up certainly needs to be logged.
  But I can't see, given all of the external data sources, any requirement to make this a traditional RDBMS. ACID yes, but the vendor claims it is.
  The exchange is just a place to match up customers, plans, and subsidies. The actual transaction happens between the customer and insurance company, which is where RDBMS makes sense. Being the intermediate holding place, NoSQL is not an inappropriate choice here. Not saying MarkLogic is a good choice, but I do not see anything pointing one way or another for the intermediary.
  You don't even need a list of 300 million people - the source datasets (IRS and Experian primarily) house that information.
18. Re:MarkLogic = NoSQL by lordbyron · 2013-11-24 16:16 · Score: 1
  
  Should be 300M per year...
19. Re:MarkLogic = NoSQL by Anonymous Coward · 2013-11-25 00:55 · Score: 0
  
  Whooooosh! Oops, that was a joke.
20. Re:MarkLogic = NoSQL by dmcassel · 2013-11-25 01:40 · Score: 1
  
  MarkLogic has scheduled backups. You can also do a backup through the Admin UI, which is mentioned pretty early in the Administrator's Guide.
21. Re:MarkLogic = NoSQL by matt_turner_nyc · 2013-11-25 02:18 · Score: 1
  
  there isn't any reason a NoSQL database can't be ACID and scale AND support a complex data problem. The problem is that most of the current systems were built for web scale (cough cough) and when you try to use them for a real project you have to make up all kinds of silly reasons to work around the lack of ACID.
22. Re:MarkLogic = NoSQL by matt_turner_nyc · 2013-11-25 02:20 · Score: 1
  
  SQL doesn't work well for complex DATA from multiple ever changing sources. You have to create the entire perfect model before you can even load data and by then, with any complex problem, the data has changed and you are in a refactoring death spiral.
23. Re: MarkLogic = NoSQL by adamfowleruk · 2013-11-25 02:25 · Score: 1
  
  FoundationDB actually did a pretty good job of separating out the truth from the hype recently in their post about NoSQL and ACID Compliance: https://foundationdb.com/acid-claims#!
  Doesn't mention neo4j specifically - don't think the article authors considered graph/triple stores in their article - but it's a good read nonetheless. The article mentions MarkLogic too. Added my comments on it here: http://adamfowlerml.wordpress.com/2013/11/17/foundationdb-joins-acid-transaction-crusade/
  FWIW MarkLogic 7 also is a triple store (not graph store), including support for the W3C Graph Store protocol and SPARQL. http://www.marklogic.com/what-is-marklogic/marklogic-semantics/
  [Yes, I do work for MarkLogic - and proudly so!]
24. Re:MarkLogic = NoSQL by HideyoshiJP · 2013-11-25 06:26 · Score: 1
  
  I heard webscale is what applications crave.
25. Re:MarkLogic = NoSQL by TuRRIcaNEd · 2013-11-25 12:04 · Score: 1
  
  From my reading, MarkLogic Server is the only product in the "NoSQL" space that is specifically intended - and designed - for enterprise use. Unlike most of the better-known OSS "NoSQL" offerings, it is 100% ACID-compliant, resilient and has been building up a considerable and high-profile user base for the last decade. I can't help but suspect that MarkLogic's involvement extended mainly to storage of data that does not fit into the relational paradigm, and that the NYT published FUD promulgated by competitors without first contacting MarkLogic themselves.
  The companies I've worked for have been using it with very few problems for at least 8 years.
  
  --
  - "How do we do it? Volume!" - The Bursar of Unseen University.
26. Re:MarkLogic = NoSQL by aaron1rosenbaum · 2013-11-25 13:34 · Score: 1
  
  A universal data model for all health insurance policies - proposed and as-written, pricing and issuing? Thats been tried before in RDBMS's and hasn't gone that well (ChannelPoint had about 1,000 people working on this problem in 2000 and didn't succeed...) While the auto and property insurance has standardized on some processes between broker and issuer, health insurance has really lagged. This is a place where NoSQL has really sped development.
27. Re:MarkLogic = NoSQL by aaron1rosenbaum · 2013-11-25 13:42 · Score: 1
  
  I would imagine if CMS had even 1% the infrastructure Facebook or Google deploys, many issues would go away...except for the budget. I think Google has spent over $21B on data centers so far to service their users - $21/user? CBO said 7M predicted to enroll by 2014 so $142M on data center resources would be an equivalent spend..before any programming. There is no evidence in the spending that CMS was given anywhere near that budget..... Oh, and that $21B in data center spend? Thats just to build them, not actually operate them...add electricity, bandwidth, people.....
28. Re:MarkLogic = NoSQL by DGorbet · 2013-11-25 17:39 · Score: 1
  
  Hi Anonymous. As I mentioned in a previous post, I run Engineering at MarkLogic. I'm sorry to hear about the difficulties you had. Here's the link to our admin API, which allows you to script backups: http://docs.marklogic.com/admin/database. Hope this helps. If you have other questions, feel free to contact Support, who is there 24x7 to assist our customers.
  
  It's also worth pointing out (since we're talking about backups), that in order to back up a database, you need to be able to get a consistent view of the data at a point in time and hold that consistency for the duration of the backup. For databases that don't provide strong consistency, you usually have to quiesce the database before backing it up. Another advantage of ACID transactions, even for applications that aren't OLTP-type applications.
  
  -- David
29. Re:MarkLogic = NoSQL by NeverWorker1 · 2013-11-26 02:11 · Score: 1
  
  Postgres 9.3 has a native json type which should go a long way here allowing one the flexibility of strict relational data where that helps (linking people to families, employers, plans, etc.) and free-form json where that's the way to go.
30. Re:MarkLogic = NoSQL by Anonymous Coward · 2013-11-26 08:18 · Score: 0
  
  Troll. ML has a CLI import/export tool that works just fine.
New tech can be great, but tough to find skills... by Anonymous Coward · 2013-11-24 03:38 · Score: 0

This is the problem every time you try to use some nifty new tech that hasn't matured yet. Heaven forbid your skills lead decides to leave for greener pastures (and believe me, there are a lot of greener IT pastures than government contracting...), you're stuck trying to replace him or her and you soon find out that there's only 10 people in the entire universe that actually are proficient with WizBangDB.
Blow to NoSQL movement by ilsaloving · 2013-11-24 03:40 · Score: 4, Insightful

And here is a fantastic example of what happens when hype trumps common sense. NoSQL is the new hawtness, and apparently the dumbasses running the project wanted to be part of that. Now MarkLogic, and NoSQL in general, will have a massive blow to their reputations, and it's unknown how badly this will hurt them.
As someone who has done databases for a long time, I have very little respect for NoSQL, but that is mostly because everyone keeps trumpeting it as a killer of traditional databases. There are scenarios where NoSQL systems are an ideal fit. However, NONE of those scenarios require data to be very reliably stored in a guaranteed and predictable way.
If you don't get your tweets or your friends facebook posts as soon as they are posted, no one will really care. But for something as truly important as health insurance coverage? Are you f__king kidding me? And that's just from a reliability standpoint. Nevermind the fact that NoSQL is currently at the wild west stage where nobody is compatible with anybody else, there is nothing resembling a standard set of APIs between products, making it very difficult to develop expertise.
Sounds like the Gov was just begging for problems.
1. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-24 03:56 · Score: 0
  
  Which makes me wonder what bugs exists in that system that aren't very apparent. I mean what data loss issues are there that don't just jump out like something that's outright broken and will never work.
2. Re:Blow to NoSQL movement by ducomputergeek · 2013-11-24 03:59 · Score: 1
  
  Just had this debate with a current project with some wanting to use a NoSQL solution for the whole thing. Problem is most of the data is relational and I stuck my foot down and said we're using PostgreSQL for anything that needs to be retained. That mean users accounts & transaction records, and really all the data is relational.
  Now there are other elements, like the chat system and distributing JSON strings to large numbers of persistent clients that seem a perfect fit for a NoSQL database. Since the JSON strings are basically information caches from the backend database to be widely distributed so what if the NoSQL db crashes. Spin up a new instance and reload the data from the main DB and start distributing again. Chat messages only need to persist for a few minutes at most. So honestly a crash or glitch and frankly very little of value would be lost.
  
  --
  "The problem with socialism is eventually you run out of other people's money" - Thatcher.
3. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-24 04:05 · Score: 2, Interesting
  
  The agency imposing their "unconventional" choice of DB, and this sentence:
  "They ordered CGI technicians to drive from their offices near Dulles International Airport in Virginia to the agency headquarters near Baltimore to review their code with government supervisors."
  sum up everything that went wrong.
  Basically you had a bunch of arrogant idiots who thought themselves experts (which they may well be, _in the healthcare domain_) who not only ignored the views of the _software/IT_ experts ("technician" my a**, senior software engineer, more like), who they saw as plebes, but proceeded to question their work.
  When will those guys realize that software developers are not blue collar workers?
  That they went for the usual bigco contractors and their hordes of yes-men certainly didn't help.
4. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-24 04:05 · Score: 2, Insightful
  
  NoSQL predates SQL because we were storing stuff back then to. Relational databases are nice for consistency, but you sacrifice a lot of control and speed improvements for that consistency. A good NoSQL database and a good NoSQL programmer will always outperform SQL based applications. However, it means you need to have programmers capable of operating at that level AND you need to have solid strongly enforced conventions.
  I also think that you are largely misreading the problem. Being able to get a quote and select your insurance isn't a strongly time sensitive endeavor. Really, most of the information you need is static. And as soon as you put data into a properly configured NoSQL database it should be available everywhere. There really shouldn't be race conditions of import for this sort of system. The system essentially asks you a few questions. You give it those answers and it returns a set from which you pick. After agreeing to some conditions you submit and are done; at least, that seems like the best thing.
  I honestly think either platform, configured correctly, would work. And I program in a NoSQL database that predates C. Not C++, Not C#. I mean C. This kind of system scales just fine when you build indices and if your NoSQL database presents the right tools. I don't know anything about MarkLogic; but would you judge C by how a programmer operates in whitespace?
  If you think NoSQL can't or doesn't perform in high risk environments, think again:
  http://robtweed.wordpress.com/2012/10/21/mumps-the-universal-nosql-database/
5. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-24 04:05 · Score: 1
  
  MarkLogic's NoSQL managed to land a giant lucrative contract for the venture capitalists backing the operation. Failure to provide an actual working solution really doesn't matter to the profiteers. In that sense, MarkLogic has been a massive success. See also, Microsoft Corporation, and decades of foisting off third-rate software (with massive known security and reliability failings) for supposedly "mission critical" business and government applications, raking in billions and billions in profit. If the corporate PR spinmeisters do their jobs right, public blame for system failure can be placed directly on President Obama's shoulders, and MarkLogic's products will be the "big data solution of choice trusted for national-scale deployment."
6. Re:Blow to NoSQL movement by anon+mouse-cow-aard · 2013-11-24 04:07 · Score: 3, Insightful
  
  Why do people insist that NoSQL means losing data and inconsistency? What you are losing with NoSQL real-time consistency horizontally across large number of instances spread over multiple data centres. When you are doing a transaction, and it should be "eventually consistent." meaning on the order of minutes. So if someone, somewhere else, who you do not know about and are not interacting with asks about your data, it might be a few minutes old. ACID makes it so that random person will get an upto the milli-second accurate answer. That makes transactions orders of magnitude slower, and much more complicated to scale. When you relax that constraint and let the people doing the transactions (the person, and the providers they are dealing with) get the right answer immediately, but just post the transaction so that the backups etc... get informed in due course, you gain much simpler scaling. The choice of NoSQL vs. SQL is not about the importance of the transaction. It is about application scaling and design, and the biases (tastes?) of the team doing the work.
7. Re:Blow to NoSQL movement by Assmasher · 2013-11-24 04:23 · Score: 4, Interesting
  
  I ran into this recently at a company whose new head of engineering was talking to me (an outsider) about the technology problem they had to solve and I thought it sounded very traditional and simple except they'd need to carefully plan for horizontal scaling.
  Basically a potentially huge number of devices (in the range of millions) would be reporting in periodic data that had to be stored and potentially evaluated in real-time. The data was quite easily swim laned by geolocation and the data had no appreciable inter-related significance. So basically, one piece of data from one device had nothing to do with any other device's information except in the general sense that can come from a more heuristic correlation of their data.
  I should mention that the new engineering head and I had already (together) handle a situation very similar to this at a previously successful software company.
  Well, the new engineering head had inherited an external architect who had different ideas. All of these different ideas involved things like Cassandra over Hadoop, AMP/Spark, BDAS. He showed me a diagram of the technologies he wanted to integrate and I'd never heard of almost half of them (and I deal with scaling issues all the time), this diagram had about 15 different technologies stacked together. It was crazy - all to solve a relatively simple data volume problem.
  Almost needless to say, I advised otherwise, and afaik they're going the bid data way because it will make it easier for them to pull in VC money since shockingly few VC's actually evaluate technology before they put money in (I do this for VCs also, and other VCs wonder how I get paid to do this, lol.)
  
  --
  Loading...
8. Re:Blow to NoSQL movement by smpoole7 · 2013-11-24 04:31 · Score: 1, Insightful
  
  > MarkLogic's NoSQL managed to land a giant lucrative contract for the venture capitalists ...
  +24 insightful and informative. This.
  Here's another angle on it. Haven't you ever wondered why everything associated with the government takes longer and costs more?
  I once worked with a guy who did government contracts all the time. He said, "you deliberately underbid* to make sure you get the deal. Just be sure to put a clause in there protecting yourself when the government (which is Rule By Committee, remember) makes changes. After you get the contract, you KNOW the government will make changes. You can charge whatever you want and take as long as you want."
  * he also said, and I quote: "and you buy the people making the decision a bunch of hookers and get them drunk." Basically his exact words. You'd probably have to update that now to a government that includes many females in management positions, but you get the idea. :)
  
  --
  Cogito, igitur comedam pizza.
9. Re: Blow to NoSQL movement by Anonymous Coward · 2013-11-24 04:44 · Score: 0
  
  Politicians (like lawyers) areexperts! They just read a few articles in a few hour period and *bam*, they're instant "experts" on the subject.
10. Re:Blow to NoSQL movement by Anne+Thwacks · 2013-11-24 04:47 · Score: 3
  
  I once worked with a major multinational who did government contracts all the time. They said the exact same things (but you failed to mention the brown envelopes filled with banknotes).
  
  --
  Sent from my ASR33 using ASCII
11. Re:Blow to NoSQL movement by ilsaloving · 2013-11-24 05:14 · Score: 1
  
  Everything you say is true. However, they didn't call it NoSQL back then. Back then, they were called 'proprietary data stores', all of which ultimately became utterly inflexible in how they dealt with data because the products would be originally designed to satisfy one problem (or set of problems), but then when a new requirement came down the line that needed to manipulate the data in a different way, you had to go through contortions trying to make things work.
  That was the whole reason SQL systems were invented.... because companies were constantly painting themselves into a corner with proprietary systems. And heaven forbid you needed to extract data to feed it into a different system.
  NoSQL doesn't solve anything that hasn't been solved before. The only thing it does is take one single database use case, and streamlines it. But the second you try to go outside that use case, you're screwed.
  Good luck taking your JSON stored form and parsing it to extract only the entries that satisfy some criteria.
  Like I said, NoSQL has it's place. But it is NOT a replacement to a proper SQL database, and never will be. Nor is it appropriate to use NoSQL for anything that requires any sort of data manipulation.
12. Re:Blow to NoSQL movement by larry+bagina · 2013-11-24 05:17 · Score: 1
  
  Postgres has JSON support as of 9.2. Some people say it's faster than MongoDB. There's also plv8 if you want to use javascript for your stored procedures. (since javascript doesn't have integers (only floating point), I'd be a little concerned about that).
  
  --
  Do you even lift?
  These aren't the 'roids you're looking for.
13. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-24 05:25 · Score: 0
  
  If that's the case, with regard to NoSQL (only familliar w/ PostgreSQL, MySQL, Oracle...), I'd really like to know who in the chain of command for decision-making the ACA site integration, made this call. Google has yet to help me on that.
  Was a an evaluation of all existing Gov. medical databases not done? Were insurance database inventories not done for compatability? I know Govenment projects fuck up from time to time, that's to be expected. But from a tech standpoint, since scaled databases, web frontends, traffic off-loaders aren't new, how did the ball get dropped? The US, companies...., built most if not ALL of this technology! How? Just, HOW did they manage to screw up this bad?
14. Re:Blow to NoSQL movement by ilsaloving · 2013-11-24 05:52 · Score: 1
  
  Can someone please upvote the parent post? It's actually very interesting, and it's worth reading about this MUMPS system. I had never heard about it myself and it looks interesting.
15. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-24 07:56 · Score: 0
  
  Sounds like you didn't understand anything about their desire to do machine learning and/or real-time analytics across all the device streams. Presuming that there is no relationship between devices that you have a priori segregated into different swim lanes and then materializing that segregation into a system that is not adaptable to in-memory analytics that crosses swim lane boundaries sounds like a good way to prevent you from ever realizing any of the larger insights that you presumed away at the outset.
16. Re:Blow to NoSQL movement by WaffleMonster · 2013-11-24 08:05 · Score: 1
  
  Why do people insist that NoSQL means losing data and inconsistency?
  I have no idea what NoSQL means. It is no different than someone belching out "Cloud" in a context free manner and expecting them to read your mind and have any clue what your talking about.
  NoSQL is an empty vessel covering such a staggeringly disparate array of technologies as to be totally devoid of any meaningful context on its own.
  
  When you are doing a transaction, and it should be "eventually consistent." meaning on the order of minutes. So if someone, somewhere else, who you do not know about and are not interacting with asks about your data, it might be a few minutes old. ACID makes it so that random person will get an upto the milli-second accurate answer. That makes transactions orders of magnitude slower, and much more complicated to scale.
  This warped sense of coherency many people seem to be peddling is quite amusing.
  Every last bit of data that comes out of a "rational" RDBMS is stale the very instant it is read out. It in no way matters whether it is read out within an active transaction. Answers read out are only guaranteed to be transactionally consistent.
  You normally deal with this by optimistically making dependent assertions on subsequent changes such that incompatibilities arising from conflicting subsequent states can be detected and resolved.
  No sane RDBMS ever blocks reads to offer non-stale responses. They only provide transitionally consistent responses. While there are some RDBM's allowing such foolishness the more sane offerings have no capability to even allow it. The very concept any read data can be held on to without being assumed to be stale is totally insane SQL or NoSQL.
17. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-24 08:28 · Score: 0
  
  Relational Database Vs NoSQL
  http://www.youtube.com/watch?v=Nu1UQblRQdM
18. Re:Blow to NoSQL movement by anon+mouse-cow-aard · 2013-11-24 08:52 · Score: 1
  
  Completely agree with that. It only emphasizes that people who insist on using SQL for data safety and security reasons are doing it out of a kneejerk reaction. There is no magic tech that will just make stuff work. Folks need to understand the application. Choice of tools/engines is largely a matter of taste, and success a matter of the skill of the craftsmen in selecting and applying the chosen tools.
19. Re:Blow to NoSQL movement by Assmasher · 2013-11-24 13:01 · Score: 1
  
  Good thinking. Let's complicate things enormously and introduce huge levels of new risk into the product in the off chance that it may benefit some unknown and non existent requirement. Do you happen to work for the government? Lol.
  
  --
  Loading...
20. Re:Blow to NoSQL movement by VoidEngineer · 2013-11-24 15:41 · Score: 1
  
  Actually, the government has been using document-oriented NoSQL databases for some 40 to 50 years in government run EMR systems, by way of MUMPS. Specifically, check out VistA which is run by the Veterans Administration, and is considered by many to be the largest and oldest healthcare network in the US.
  
  http://en.wikipedia.org/wiki/Mumps
  http://en.wikipedia.org/wiki/VistA
21. Re:Blow to NoSQL movement by matt_turner_nyc · 2013-11-25 00:56 · Score: 1
  
  That's only a valid argument if the choice was in fact one of the NoSQL databases that has reliability and security (you forgot about that - its equally appalling in most NoSQL). But there is such as thing as enterprise NoSQL with real transactions and security and MarkLogic has been replacing Oracle for mission critical systems for over 10 years. The new generation of database with schema flexibility along WITH reliability is a killer combination for hard data aggregation problems.
22. Re:Blow to NoSQL movement by matt_turner_nyc · 2013-11-25 02:08 · Score: 1
  
  Except of course that you CAN have actual transactions and simple scale out in NoSQL - just most of the NoSQL databases out there weren't designed to manage that. The database in question here, MarkLogic, has fully ACID transactions and horizontal scale out without any penalty to ingestion speed or query. Its all about the core design being right from the start and MarkLogic's architecture isn't complicated its MVCC with write forward over a shared nothing cluster.
23. Re:Blow to NoSQL movement by dmcassel · 2013-11-25 02:23 · Score: 1
  
  As someone who has done databases for a long time, I have very little respect for NoSQL, but that is mostly because everyone keeps trumpeting it as a killer of traditional databases. There are scenarios where NoSQL systems are an ideal fit. However, NONE of those scenarios require data to be very reliably stored in a guaranteed and predictable way.
  If you don't get your tweets or your friends facebook posts as soon as they are posted, no one will really care. But for something as truly important as health insurance coverage? Are you f__king kidding me? And that's just from a reliability standpoint. Nevermind the fact that NoSQL is currently at the wild west stage where nobody is compatible with anybody else, there is nothing resembling a standard set of APIs between products, making it very difficult to develop expertise.
  I certainly get where you're coming from with this, but a couple of points to address your concerns:
  MarkLogic has been around since 2001, with features needed for enterprise deployments (ACID, HA/DR, security) baked in from the start; it's not just the new hawtness.
  NoSQL systems aren't just for lots of data, they are for data with lots of variety. In those cases, a schemaless approach allows for much more rapid application development. And yes, many of those scenarios do require reliable storage. MarkLogic does ACID transactions. The MarkLogic customer page shows some of the customers who have found this helpful.
  Regarding interoperability, MarkLogic has a REST API and a Java API, in addition to the ability to work with XQuery. Custom HTTP service endpoints can be built to fit into an existing environment. It still requires some learning -- a document store is different from relational, so that's unavoidable -- but with a little training developers can use a lot of their current skills.
24. Re:Blow to NoSQL movement by adamfowleruk · 2013-11-25 02:31 · Score: 1
  
  On the 'eventually consistent' point, just wanted to point out that MarkLogic does NOT use the 'eventually consistent' model. Instead MarkLogic uses MVCC and is fully serializable when it comes to transactions. In addition, MarkLogic's indexes are updated within the transaction boundary, so as soon as the transaction commits, you know the journal has been updated and the indexes are updated too.
  Combine this with MarkLogic's ability to save any arbitrarily complex search as an alert, and you can power many interesting mission critical information sharing applications.
  I have a blog entry that describes this: http://adamfowlerml.wordpress.com/2013/11/25/marklogic-huh-what-is-it-good-for/
  Also around Serializability: http://adamfowlerml.wordpress.com/2013/01/25/true-acid-compliance/
  [Yes, I work for MarkLogic! I work here because it's an awesome piece of tech. ]
25. Re:Blow to NoSQL movement by ilsaloving · 2013-11-25 02:39 · Score: 1
  
  "Eventual" consistency, oh that's just dandy. So you don't mind at all if you bank switches to a NoSQL system, so that it's possible for multiple people at several simultaneous ATMs to withdraw $500 without tripping the max withdrawal flag because it'll take who knows how long for the data to sync up?
  Or maybe someone's insurance claim for a critical medication gets lost because the node they just performed the transaction has a failure and loses all it's data?
  I find it disturbing that so many NoSQL people treat data integrity as secondary to performance. It's not having "up to the milli-second accurate" data. It's about data being accurate, PERIOD. If there is a chance, any chance at all that data can be corrupted just because a server node fails, then it's not a database. It's a poker deck.
  Again, NoSQL is all fine and dandy for useless garbage like facebook posts and tweets, but in all other circumstances, absolute data integrity trumps performance.
26. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-25 05:38 · Score: 0
  
  haha, but no hookers for the programmers!
27. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-25 07:31 · Score: 0
  
  "Everything you say is true. However, they didn't call it NoSQL back then. Back then, they were called 'proprietary data stores', all of which ultimately became utterly inflexible in how they dealt with data because the products would be originally designed to satisfy one problem (or set of problems), but then when a new requirement came down the line that needed to manipulate the data in a different way, you had to go through contortions trying to make things work."
  It sounds like you're confusing the generic database and the application. Aren't ALL databases designed to satisfy one problem and if there's new requirements you've got difficulty manipulating the data in other ways?
28. Re:Blow to NoSQL movement by Anonymous Coward · 2013-11-25 07:40 · Score: 0
  
  So your solution is "I've not heard of it so you should go with something I have?"
29. Re:Blow to NoSQL movement by ilsaloving · 2013-11-25 08:27 · Score: 1
  
  That's because there was little separation between applications and data back then. There was little fundamental distinction between databases and applications back then. There were some attempts to do so, but even then the data structures and communication focused on specific data structures which could be used for certain classes of application, but the second you tried to use said databases for other types of applications, you had a heck of a time making it work.
30. Re:Blow to NoSQL movement by anon+mouse-cow-aard · 2013-11-25 12:27 · Score: 1
  
  The person/entity you are doing the transaction with will get the right data. It is random people/programs elsewhere in the cluster that might be behind the times. I don't care when the NSA learns what my insurance premium is. A couple of minutes delay is fine. Also for Google trying to figure out what ads to show me, also the business intelligence part of the vendors stack, etc... there are many, many perfectly reasonable business applications where ACID is not necessary.
  cheap performance trumps pointless reliability in a surprisingly large number of cases.
31. Re:Blow to NoSQL movement by ilsaloving · 2013-11-25 16:34 · Score: 1
  
  In other words, asynchronous updates. How does a NoSQL solution solve this problem better than all the other dozens of middleware packages out there? (eg: MQ Series, Vitria, etc)
  I'm not trying to be snide... this is an honest question. I'm trying to understand what problem NoSQL solves that hasn't been solved before. I'm one of those people that doesn't subscribe to the idea of just because something is new, it's automatically better.
32. Re:Blow to NoSQL movement by DGorbet · 2013-11-25 17:51 · Score: 1
  
  Hey ilsaloving, if you have an application where you need to parse your JSON to extract only the entries that satisfy some criteria (in other words query your JSON with arbitrarily complex queries), and you need to do it fast, you should check out MarkLogic. We can do that.
33. Re:Blow to NoSQL movement by DGorbet · 2013-11-25 18:10 · Score: 1
  
  I agree with you ilsaloving. At MarkLogic, we think data consistency is a critical feature of a DBMS. Some NoSQL technologies have it, some don't. A NoSQL choice doesn't have to mean eventual consistency. And yes, many banks do use our software. As you point out, transactional consistency and durability are important to them.
  
  Since you're asking an honest question, I'll try to provide a good answer.
  
  Enterprises choose NoSQL when they have data that's hard to represent in a relational model. Often that's just due to the complexity of the data. Equities transactions, for example, are easily modeled in rows and columns, but derivatives transactions are like contracts. They're hard to model in a relational database. Not impossible, but hard. Health records are another good example; these are frequently document-centric data structures with lots of freeform text in them. Journal articles, emails, legal documents, etc. are all examples of this kind of hard-to-model data. Sure you can blob or clob it into a relational database, but then it's hard to access. Another type of complex data is very sparse data. If you have to have tens of thousands of columns because you occasionally need to store data in a queryable field, that's not efficient. In many sparse data models, the "columns" change frequently as well. One day you may discover that you have to track some new trait. Do you add a column for that? With a document-centric model it's much easier. Just ingest a document that has that element in it, and MarkLogic will index it for you.
  
  That brings me to the other reason why people opt for NoSQL. Even if the data is relatively simple, if you have many data sources, and they change all the time, it's hard to keep up if you have a relational schema to keep up to date. This is the problem financial institutions have with reference data. They get feeds from a variety of sources, and these feeds change from time to time with no notice. They also have to track metadata like the provenance of each piece of data, which complicates the problem. So if you're trying to combine lots of different data sources that are changing all the time, that's another good use case for NoSQL.
  
  Hope that helps,
  -- David
34. Re:Blow to NoSQL movement by ilsaloving · 2013-11-26 04:00 · Score: 1
  
  I totally see what you're saying. The problems you are describing are a lot like the issues that, say, IBM tried to solve with Lotus Notes. And it makes sense.
  To be honest, I had never even heard of MarkLogic until this whole blowup happened, so I think I will have to look into what it can do. Up till now I've only been seeing silly nonsense like MongoDB, and the overarching theme of NoSQL has been that performance trumps integrity. I'm glad there's at least one company out there that is talking sense.
35. Re:Blow to NoSQL movement by DGorbet · 2013-11-26 12:07 · Score: 1
  
  To be honest, I had never even heard of MarkLogic until this whole blowup happened, so I think I will have to look into what it can do.
  We'd love to have you check us out. If you want to learn more about it, you can read more about us on our web site at http://www.marklogic.com/what-is-marklogic or in Gartner's recent operational DBMS Magic Quadrant: http://gtnr.it/Ieh0hq. You can also download and play with MarkLogic at http://developer.marklogic.com/products. Let me know if you'd like more info or help.
  
  Best,
  -- David
36. Re:Blow to NoSQL movement by Anonymous Coward · 2013-12-02 06:32 · Score: 0
  
  But, for most popular NoSQL databases, "eventually consistent" means "accepts write conflicts silently" hence data loss or inconsistency. It's not mandatory that this be the case but the only way to completely avoid the problem is a lock. Data versioning can help but unless you use a single version number to impose a total order over all writes that have any relationship at all you can still get inconsistency.
MarkLogic is an XML repository, not a RDBMS by CyberLeader · 2013-11-24 03:41 · Score: 5, Interesting

"Some people, when confronted with a problem, think 'I know, I'll use XML.' Now they have two problems."
-JWZ
MarkLogic is an XML database, not a relational database, so if your data primarily consists of XML content then it's the right tool for the job. Sounds like the vendor building the system had a favorite hammer and decided that a rather traditional database problem looked like a nail.
MarkLogic itself is fine if your data fits neatly into an XML schema, but with healthcare.gov that tree is probably enormous and hard to optimize for DB activity.

--
Software Shouldn't Suck

E-mail: frank at jacquette dot spamless com (remove the spamless!)
1. Re:MarkLogic is an XML repository, not a RDBMS by Anonymous Coward · 2013-11-24 06:06 · Score: 0
  
  Sounds like the vendor building the system had a favorite hammer and decided that a rather traditional database problem looked like a nail.
  So, you didn't even pretend to read the summary???
  The vendor building the system objected strenuously to this choice of database.
2. Re:MarkLogic is an XML repository, not a RDBMS by KiloByte · 2013-11-24 07:15 · Score: 1
  
  Even if you ship around data in XML it's still not a remotely sane format for storage of large amounts of data.
  
  --
  The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
3. Re:MarkLogic is an XML repository, not a RDBMS by Tailhook · 2013-11-24 08:48 · Score: 4, Insightful
  
  Sounds like the vendor building the system had a favorite hammer and decided that a rather traditional database problem looked like a nail.
  It was the Medicare folks that imposed MarkLogic over the objections of the prime contractor. Calling Medicare a "vendor" is a bit of a stretch. Like non-IT staff calling themselves "customers" of IT in a corporation, as if they have a choice of IT departments.
  
  Another sore point was the Medicare agency’s decision to use database software, from a company called MarkLogic, that managed the data differently from systems by companies like IBM, Microsoft and Oracle. CGI officials argued that it would slow work because it was too unfamiliar. Government officials disagreed, and its configuration remains a serious problem.
  The CGI argument was that it would slow work. I have absolutely no doubt about that. Every NoSQL system is it's own distinct thing with unique APIs, protocols, conventions, quirks, etc. This is fine when you are dealing with a limited group of good developers that can be expected to rapidly climb a learning curve. This is not fine when you are the top contractor in a herd of contractors, populated by a vast number of mediocre programmers that last learned anything new in the late 90's.
  In that case the correct choice is to select the most ubiquitous technologies. A boutique NoSQL XML-base is not appropriate, even if it is excellent, which MarkLogic may be. I don't know. I just know CGI was 100% correct in objecting to it. CGI's fault in this case was its failure to win that argument.
  Not that it matters much. The project was doomed in any case — political agenda driving pie-in-the-sky requirements using crony contracting — Fucked at birth, as they say.
  
  --
  Maw! Fire up the karma burner!
4. Re:MarkLogic is an XML repository, not a RDBMS by VoidEngineer · 2013-11-24 16:09 · Score: 1
  
  Remember, the government has been using document-oriented MUMPS databases for some 40 to 50 years in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology for government healthcare applications for decades.
  
  http://en.wikipedia.org/wiki/Mumps
  http://en.wikipedia.org/wiki/VistA
5. Re:MarkLogic is an XML repository, not a RDBMS by shutdown+-p+now · 2013-11-24 22:01 · Score: 1
  
  XML databases don't actually store the data as XML on disk. It's parsed, serialized in some efficient binary format, and heavily indexed for fast queries. It's "XML" insofar as the interface to the database remains XML-based - you send and receive XML nodes, and write queries in terms of XML Infoset or something based on it (like XDM), in a language that is designed for this kind of thing (XQuery).
  It's actually a reasonably decent way of storing and querying heterogeneous documents - especially if you still have a schema for them, just not the kind that maps well to relational algebra. So it's kinda in the middle between the modern "everything goes" hipster key-value NoSQL, and the classic relational databases.
6. Re:MarkLogic is an XML repository, not a RDBMS by matt_turner_nyc · 2013-11-25 02:11 · Score: 1
  
  Yup and ML indexes that tree and largely uses search engine like indexes to resolve queries. What this gives you is schema flexibility and that is key for bringing together many complicated data sources. With a relational approach you would have to define the entire master schema up front.
Executive Fiat will fix this!!!! by Anonymous Coward · 2013-11-24 03:42 · Score: -1, Flamebait

Have no fear, citizens! All that glorious leader Obama needs to do is declare that the website must get fixed by the end of November and by golly, it WILL get fixed by the end of November. ...And then he'll amend it to say "by the end of December -- PERIOD!" ...And then he'll later say months later when it is still in shambles "In all fairness I didn't say December 2013".
mohd dowN by Anonymous Coward · 2013-11-24 03:42 · Score: -1

PPoper. Nothing Is Ndying and its if you don't win out; either the
Wonder which Reps own share on MarkLogic by Anonymous Coward · 2013-11-24 03:45 · Score: 0

Would make for interesting reading
Re:New tech can be great, but tough to find skills by Anonymous Coward · 2013-11-24 03:47 · Score: 0

her and you soon find out that there's only 10 people in the entire universe that actually are proficient with WizBangDB.
And one of those 10 is in the Tardis, asking the Doctor what went wrong with healthcare.gov
How cait it be the problem by arthurpaliden · 2013-11-24 03:51 · Score: 1, Insightful

Well they did have the flashiest ads which used lots of buzzwords.

--
Undetectable Steganography? Yep, there's an app fo
1. Re:How cait it be the problem by Anonymous Coward · 2013-11-24 04:20 · Score: 0
  
  It could've been worse. Word is they considered HarryLogic and DickSolutions before settling on MarkLogic.
Govt contracts by Anonymous Coward · 2013-11-24 03:52 · Score: 0

Anyone who has worked for anything in the govt knows most contracts are a formality. The deal is done before the job is pulbished seeking bids.
Open Source by Murdoch5 · 2013-11-24 03:52 · Score: 2

Why not just use MySQL, MongoDB or MariaDB? At least use a database system that has good support, an easy learning curve and loads of followers. That beings said, proper testing would easily of mitigated this entire issue.
1. Re:Open Source by NeverWorker1 · 2013-11-24 03:56 · Score: 4, Insightful
  
  Because Postgres exists.
2. Re:Open Source by Anonymous Coward · 2013-11-24 04:12 · Score: 0
  
  i am mostly surprised they didn't use oracle. because that is the fastest way to waste money.
3. Re:Open Source by Anonymous Coward · 2013-11-24 10:23 · Score: 0
  
  This is the correct answer.
4. Re:Open Source by Anonymous Coward · 2013-11-24 11:14 · Score: 0
  
  spot on!
healthcare.gov by Anonymous Coward · 2013-11-24 04:00 · Score: 0

I can create an account, but I can't fill out the application form. The website gives me an error message when I click the button to go to the next page. arg
CGI = Computer-generated imagery
Impressive by SuperCharlie · 2013-11-24 04:04 · Score: 1

Just when I think.. wow.. you couldnt screw this up any worse... they step up and prove me wrong.
What happened to Vivek Kundra by Anonymous Coward · 2013-11-24 04:07 · Score: 0

The guy who Obama appointed the first US CTO with great fanfare? He was supposed to be heavily involved in getting stuff like this right.
Oh right, he resigned in 2011 to pursue a job in the private sector. I don't think that absolves him responsibility. He should've stayed to get the health care rollout right, then he could leave.
1. Re:What happened to Vivek Kundra by Anonymous Coward · 2013-11-24 09:19 · Score: 0
  
  Vivek Kundra
  You mean the thief that got arrested stealing clothes?
Unorthodox by Horshu · 2013-11-24 04:09 · Score: 1

I've lost count of how many projects I've been on where the architect decides to "make his mark" by using unconventional design choices. Then the project gets stuck in a dev hell where the actual developers struggle with either integration headaches or difficulties with the code not acting like they expect. There's something to be said for plain vanilla.
1. Re:Unorthodox by Anonymous Coward · 2013-11-24 04:24 · Score: 0
  
  In an data-driven organization, DBAs rule. Sorry.
2. Re:Unorthodox by Anonymous Coward · 2013-11-24 06:44 · Score: 0
  
  Rule the backup scripts...
US Federal Government Systems Projects by vrhino · 2013-11-24 04:20 · Score: 5, Interesting

I worked as a contractor developing a system at FDA. It lasted for 5 years. Inside the Beltway, it's pretty much the same all over. Dysfunctional communications and ridiculous breakdown of authority not corresponding to lines of management. No accountability. Project management requirements that have never been followed by any project. No commitment to the output of requirements gathering. No requirements change control. No performance engineering. Inadequate testing. No acceptance process by the government. IT groups with oversight for contractor output that have never written a line of code. All in all, pretty sick and ugly. Prior to my project there were 5 failed attempts. My project followed PMI practices, worked them hard and succeeded.
MarkLogic's Pitch by conoviator · 2013-11-24 04:25 · Score: 1
From a slide that promotes MarkLogic's appropriateness for the health exchange's particular set of challenges:
- - Highly complex data in many formats that change often and have varying quality
- - Massive amounts of data at high velocity; highly transactional
- - Highly structured data, but multiple and changing schemas
See: http://assets1.csc.com/innovation/downloads/LEFBriefing_MarkLogic_031512.pdf (slide 23)

My two cents:
- When faced with a very complicated software project, use what's been proved to work.
- Why would the CMS (Centers for Medicare & Medicaid Services) dictate this particular less common technology? Very strange.
1. Re:MarkLogic's Pitch by VoidEngineer · 2013-11-24 16:17 · Score: 1
  
  Remember, the government has been using document-oriented MUMPS databases for some 40 to 50 years in VistA, the Veterans Administration EMR. NoSQL databases have been a go-to technology for government healthcare applications for decades.
  
  http://en.wikipedia.org/wiki/Mumps
  http://en.wikipedia.org/wiki/VistA
  
  The problem, of course, being that MUMPS has some serious flaws with regard to it's integrated language M, and they don't want to *actually* use MUMPS for any new projects. What they were doing was betting on a NoSQL technologies to replace MUMPS. They were hoping to find something that had all the benefits of MUMPS, but not the drawbacks and problems. Unfortunately, XML was probably not the answer.
  
  I'm keeping my fingers crossed that JSON and MongoDB will be the eventual successors of MUMPS.
2. Re:MarkLogic's Pitch by matt_turner_nyc · 2013-11-25 02:41 · Score: 1
  
  When faced with a very complicated software project, use what's been proved to work -> MarkLogic has been proven to work - its behind some of the largest and most complicated databases of information out there.
Unnecessary complexity is actually bad in itself by JoeyRox · 2013-11-24 04:38 · Score: 2

From the summary:

"The story does not say that MarkLogic's software is bad in itself, only that the choice meant increased complexity on the project."

Unless that complexity was necessary to solve a problem, then it is in fact bad.
Auth problem - Oracle Identity Manager by mveloso · 2013-11-24 04:51 · Score: 2

We were looking at what we could figure out about the architecture of healthcare.gov, and one problem is that it looks like it's using Oracle Identity Manager to manage the permissions of what users can/can't see. That means that OIM is burned in - and it's probably brutally slow, since every time you need to check a permission you go through OIM.
I'm not positive that's the case, but it fits given what pieces of the architecture I've seen. It would also explain why the system doesn't perform - permissions checking is always brutal, especially if you don't cache them. Caching permissions has more issues.
It is not the tool, stupid by Cr8zyguy · 2013-11-24 05:08 · Score: 3, Interesting

It is NEVER the tool, but who and why it was chosen.
Furthermore, MarkLogic is a legitimate NoSQL vendor with strong ACID.
So the question is "how does MarLogic screw up the site", without the answer to that question, we should all refrain from pointing finger to merely a small piece in a huge software project.
NoSQL is NOT the new hotness, it's been out there for at least 5 years and many successful projects are using them, so for the ones that things NOSQL shouldn't be used, wake up and breath some fresh air.
1. Re: It is not the tool, stupid by Anonymous Coward · 2013-11-24 05:39 · Score: 0
  
  You are an idiot.
2. Re:It is not the tool, stupid by Anonymous Coward · 2013-11-24 14:04 · Score: 1
  
  No, actually sometimes it *is* the tool. Right tool for the job and all that - perhaps you've heard that expression?
3. Re:It is not the tool, stupid by VoidEngineer · 2013-11-24 16:17 · Score: 1
  
  5 years? The government has been using document-oriented NoSQL MUMPS databases for some 40 to 50 years in VistA, the Veterans Administration EMR.
  
  http://en.wikipedia.org/wiki/Mumps
  http://en.wikipedia.org/wiki/VistA
MUMPS database integration? by Anonymous Coward · 2013-11-24 05:34 · Score: 0

Is MUMPS used by government agencies as a healthcare database?
1. Re:MUMPS database integration? by paugq · 2013-11-24 08:01 · Score: 1
  
  MUMPS is used by the Veteran's Administration, and probably others too. In fact, it became an ISO/IEC standard in 2005.
  Intersystems Caché and FIS GT.M are the most popular implementations. GT.M is open source and available under the GPLv2.
  http://en.wikipedia.org/wiki/MUMPS
2. Re:MUMPS database integration? by Anonymous Coward · 2013-11-25 06:54 · Score: 0
  
  Take a look at what Epic uses for a database.
Not the entire problem. by Arker · 2013-11-24 05:45 · Score: 1

It's even more basic than that. According to TFA the design goal was: "creating a cutting-edge website that would use the latest technologies to dazzle consumers with its many features. "
In other words, even if they had gotten this thing up and working as they wanted, right on time, it would have been an accessibility nightmare that would never work unless you have a brand new computer configured with no security anyway.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Laugh by koan · 2013-11-24 05:56 · Score: 1

"The story does not say that MarkLogic's software is bad in itself, only that the choice meant increased complexity on the project. "
But the subliminal take away is that MarkLogic was used and things went poorly. I feel for the people at MarkLogic in that they may succumb to someone else's stupidity even though their product is fine.
So why that decision? Whose family member is in that company?

--
"If any question why we died, Tell them because our fathers lied."
CGI "officials" by gtirloni · 2013-11-24 05:59 · Score: 1

So the private-owned company has "officials". Cool...

--
none
Toni Townes-Whitley by approachingZero+ · 2013-11-24 06:01 · Score: -1

First Lady Michelle Obama’s Princeton classmate is a top executive at the company that earned the contract to build the failed Obamacare website.

Toni Townes-Whitley, Princeton class of ’85, is senior vice president at CGI Federal, which earned the no-bid contract to build the $678 million Obamacare enrollment website at Healthcare.gov. CGI Federal is the U.S. arm of a Canadian company.

Read more: http://dailycaller.com/2013/10/25/michelle-obamas-princeton-classmate-is-executive-at-company-that-built-obamacare-website/#ixzz2laSNJyGs

--
'I don't know what it's called. I just know the sound it makes, when it takes a man's life.' ~ Four Leaf Tayback
MarkLogic for Healthcare.gov ? WTF by Anonymous Coward · 2013-11-24 06:02 · Score: 0

I've used MarkLogic; even took MarkLogic training at their office in bay area.
While it's been a while since I last used MarkLogic, and don't rate myself at more than at intermediate level comfort level with it, still ... WTF .
MarkLogic IS quite excellent at handling large XML content repositories. The last project I worked on at a publishing company, they used MarkLogic to sift through & transform content to the order of multitude of TB.
But HealthCare.gov ??
If there was ever a case of wrong tool for job ... this appears to be it.
What could possibly go wrong? by Anonymous Coward · 2013-11-24 06:08 · Score: 0

Big Federal government contract for something that hasn't been done before, health care industry lobbyists hovering, little known NoSQL vendor chosen, storing everything as XML.
International incident in the making by DaveAtFraud · 2013-11-24 06:41 · Score: 3, Insightful

But how would a traditional relational database scale to the 1 billion, or 1,000 billion users, huh? Did you think about the need to future-proof the application?
Current population of the U.S. is a little over 300 million. That includes children, people who have company provided health insurance, etc. who don't need to access HealthCare.gov so that the number of users of HealthCare.gov is expected to be about 30 to 45 million people.
The only way HealthCare.gov would need to support 1 billion or more users would be if we inflicted it on the China or India. That could lead to war or poor technical support and customer service. Although the later does raise an intereting question of who does someone at a call center call when they need technical support? Likewise, the population of the planet is between 7 and 8 billion. For the 1,000 billion users are you planning on also providing health insurance to E.T?
Cheers,
Dave

--
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
1. Re:International incident in the making by Anonymous Coward · 2013-11-25 05:05 · Score: 0
  
  The only way HealthCare.gov would need to support 1 billion or more users would be if we inflicted it on the China or India. That could lead to war or poor technical support and customer service.
  Best idea yet!
  But, should we attack India first to force HealthCare.gov on them first? If we do it that way, when we start on China we'll be forcing the Chinese to get customer support from Mumbai! Win-Win!
  Or, should we just skip planning and send the troops and consultants in now?
Computer time..where does it all go? by WaffleMonster · 2013-11-24 06:51 · Score: 1

I get there must be tons of complexity in managing healthcare.gov site interacting with all necessary stakeholders... Must be quite a lot of different databases, systems, operators to say nothing of complexity of working the actual problem space. I can understand how there might be glitches that cause wrong rates and plans to be communicated.
What I am still puzzled by are the "waiting rooms" with 40k people waiting to use a site. What the hell can justify it being so computationally expensive to spit out a list of plans? Does the universe need to be recalculated every time someone signs up? Is there some manner of massive graph problem needing to be solved for each user? If you ran a profiler on the web site what would it most be spending its time doing?
Government made them use it? by Anonymous Coward · 2013-11-24 07:02 · Score: 0

Last I checked the government can't tell contractors what software to use, they can only define requirements. Its up to the contractor to satisfy them. Now that's not to say that they can't get super specific with the requirements where one product is only one that fits, but on something of this scale I would be surprised if they did since it would open them to intense scrutiny. One of the contractors choose unwisely and screwed the others.
Well that explains it by kilodelta · 2013-11-24 07:07 · Score: 1

It uses NoSQL. Which does add a serious amount of complexity to the picture. SQL by comparison, row based, column addressable and relational. Gee, what could be so wrong with that?
There was a fundamental problem anyway by Beryllium+Sphere(tm) · 2013-11-24 07:25 · Score: 1

The system had to coordinate with multiple independently run systems from multiple agencies and wasn't led by anyone with authority to dictate terms or experience in ugly systems integration.
Gaaah! by Anonymous Coward · 2013-11-24 07:26 · Score: 0

After 30+ years as a database expert, teacher (I have trained engineers for many major companies in SQL and relational database theory), developer, using a NoSQL database for this sort of application is, in my opinion, just plain stupid! I do use NoSQL/Hadoop databases for other purposes, but this is a classical example of a transaction database, and SQL is very well suited for that purpose. I have developed systems that process millions of queries per hour, joining many tables, and these systems run most major semiconductor, flat-panel display, and disc drive manufacturing plants world-wide today.
The current crop of NoSQL databases are a reversion to the old network databases of the past, but with some "enhancements". They are NOT good for ad-hoc queries and indexed searches. SQL is very good for that. So, IMHO, someone who thought NoSQL was a good idea had the pull to force it to be used as the database access methods for ACA. Whoever they are should be taken out to the woodshed and taught a painful lesson!
1. Re:Gaaah! by Anonymous Coward · 2013-11-26 06:28 · Score: 0
  
  So as a dastabase expert you've only taught relational database theory? Could it really be that you're really a relational database expert, rather than an expert on databases?
Why is Slashdot & tech media behind on this st by Mof-Tan · 2013-11-24 07:27 · Score: 1

As a European living in a country with a fairly well working public health system (Sweden), and a tech background, I am amazed that Slashdot and other tech media is behind the curve on this story. Why is NYTimes and other mainstream media the ones running with this and finding the background etc? Damn common sense tech people in the U.S.! Get on top of this to fix it!

--
Die dulci fruere. Have a nice day.
Just one more whack by InsightfulPlusTwo · 2013-11-24 07:33 · Score: 1

The real problem with this website is too much ambition. They should have started with the simplest working project, something like Health Sherpa, proved that it worked, and then tried scaling up from there. That's the Lizze Borden school of web design. Cut your design down to the bone. Just when you think you're done, no matter -- there's always one more whack you can make!

--
I felt bad for the man who had no signature, until I met a man who had no comment.
Forget Healthcare.gov - Look at EMR by Anonymous Coward · 2013-11-24 07:35 · Score: 0

Healthcare IT has bigger problems.
The #1 EMR (clinical information system) being deployed across the nation is called EPIC.
It's written in MUMPS and runs on a non-relational database called Cache'.
1. Re:Forget Healthcare.gov - Look at EMR by Anonymous Coward · 2013-11-25 07:00 · Score: 0
  
  But where is the problem?
No. by mosb1000 · 2013-11-24 07:52 · Score: 2

The problem is this:

CGI officials argued that it would slow work because it was too unfamiliar. Government officials disagreed, and its configuration remains a serious problem.
Government officials like issuing "cost plus" contracts because they allow them to remain in control of the work while not doing any of it themselves. They probably wanted to use it because they had used it in other projects in the past. If the'd just issued a fixed pice contract and said "get it done" the contractor would have selected a database they know and everything would have been much easier for them.
The whole idea was "unorthodox" by mike555 · 2013-11-24 08:12 · Score: -1

Now they got you arguing about technical details of the issue, making you accepting this state-imposed bullshit healthcare implicitly.
To paraphrase Tom Marcos' "Peopleware."... by mswope · 2013-11-24 08:20 · Score: 1

Since the days of computers first came into common use there must have been tens of thousands of database programs written. There are probably thousands of database projects underway as you read these words. And somewhere today, at least one of them is failing. ... Databases are wheels that have been re-invented so often that many veteran developers could stumble through such projects with their eyes closed. Yet these efforts sometimes still manage to fail.
Good Product - Bad Match by fmteter · 2013-11-24 08:23 · Score: 1

MarkLogic is a good product when used as intended. Bad use case here. Like driving in wood screws with a hammer - defeats the intended purpose of the screws and causes things to fall apart.
They also pay VAT by Anonymous Coward · 2013-11-24 08:48 · Score: 1

VAT is disproportionally more painful for those without means than those with a lot of money.
1. Re:They also pay VAT by Anonymous Coward · 2013-11-24 12:05 · Score: 0
  
  The US doesn't have a VAT, but most states have a sales tax which the GP mentioned. (VAT and sales tax are two different ways of implementing a consumption tax; VAT is more complicated but harder to dodge, so tends to be used in jurisdictions with high consumption tax rates.)
Nothing wrong with the tech. by BaronM · 2013-11-24 12:34 · Score: 3, Interesting

I've used it, personally, to implement a public-facing website. That site endured the dreaded 'slashdot effect' several times. No failures.
When implemented properly, Marklogic is damn near unkillable. It will slow down, it will reject connections when queues are full, but it will not fall over. Naturally, this assumes proper underpinnings and capacity calculations. With Marklogic, those are actually documented.
Mandatory disclosure: I do not have and have never had any association with Marklogic other than a paying customer.
1. Re:Nothing wrong with the tech. by Anonymous Coward · 2013-11-25 06:57 · Score: 0
  
  I've used it, personally, to implement a public-facing website. That site endured the dreaded 'slashdot effect' several times. No failures.
  When implemented properly, Marklogic is damn near unkillable. It will slow down, it will reject connections when queues are full, but it will not fall over. Naturally, this assumes proper underpinnings and capacity calculations. With Marklogic, those are actually documented.
  Mandatory disclosure: I do not have and have never had any association with Marklogic other than a paying customer.
  Agreed. You could of given these government contractors any nosql technology and they would of found a way to screw it up. How many failed federal IT projects have these contractors been behind that used "safe" technologies such as Oracle ?
2. Re:Nothing wrong with the tech. by Anonymous Coward · 2013-11-25 09:34 · Score: 0
  
  That's because MarkLogic is a fine product for publishing a limited amount of data, not so good for big data. Ask why the company hasn't been able to go public after so many years, why they are not one of the most popular NoSQL databases even though they have been on the market for such a long time. I'm not saying Marklogic caused the problems, but it probably wasn't the best choice of solutions. The US Government is probably their biggest customer which means ML knows how to work the system better than other NoSQL providers.
  Not a coward. I can't share my name because of business relationships.
Some data points about the technology by Anonymous Coward · 2013-11-24 14:24 · Score: 0

A few data points:
* MarkLogic does supports XML and JSON really well, but it does not use either as it's on-disk format.
* MarkLogic is fully ACID using MVCC
* MarkLogic is a scale-out cluster architecture that supports, replication, failover, HA/DR, XA transactions, ...
* MarkLogic database operations and full-text and structured search
* It's often used when the data to be managed comes from lots of different sources, with lots of different schemas (as is the case to the nth degree with this system)
* It takes time to get used to ML, but after about a month, it's a highly productive
* It's been around for 10 years and is used in some extremely demanding and mission-critical apps
It's long, but if you want to know more about the database, take a look at "Inside MarkLogic Server": http://developer.marklogic.com/pubs/architecture/inside-marklogic-server-r7.pdf
What happened to Google and Oracle? by Collin · 2013-11-24 14:47 · Score: 1

A few weeks ago, the press did a bunch of reporting that the Gov had reached out to Google and Oracle to come help fix their website. Haven't heard anything else since. Anybody know what happened with that move?
Given what was in this article, I wouldn't be surprised if the Google engineers showed up, looked at the mess and said, "yeeah. good luck with that." and walked out. Maybe even said, "We'll help you if we get to throw out everything and rewrite it clean in a couple of months and host it on the Google-plex."
Underlying Obama Gay Lover Is The Choice by Anonymous Coward · 2013-11-24 15:37 · Score: -1

Bell, CEO of MarkLogic is the Gay Lover de jour of Obama.
Definately an innapropriate choice by Timmy+D+Programmer · 2013-11-24 18:41 · Score: 1

NoSQL and Notes types databases are ideal when volume is low, and variety is high and needed values change frequently. Seems to me the data they were collecting and presenting are ideal SQL candidates, and terrible NoSQL candidates. Even if the DB is not bad, it IS a very bad choice for this type of application. Although I'm sure the salesperson/campaign contributor would disagree.

I'm sure it is more difficult to 'hack' simply because it is less familiar to hackers, but validated input, and well patched servers is a better way to prevent getting hacked.

--

(If at first you don't succeed, do it different next time!)
1. Re:Definately an innapropriate choice by DGorbet · 2013-11-25 14:55 · Score: 1
  
  Hey Timmy, I'm curious as to why you would say that NoSQL is ideal for low-volume applications.
gov run health care duh bad idea by Anonymous Coward · 2013-11-24 19:39 · Score: 0

I don't understand why we as American's keep giving up what's made our country great and what all other's wanted to be! Our freedom's! I mean the Federal gov should only have two jobs 1-security and 2-international relations otherwise the state should be that there own state we are no longer the united states of America were just America and were looking less n less like capitalist nation n more communist over the last 10years are we really living in that much fear that we'd sell our souls?
Satisfied ex-customer by JamesW22 · 2013-11-25 01:41 · Score: 1

I used MarkLogic at a customer for over 8 years and its the best technology we used by far. This is a blame-fest and I never had any problems with the technology. MarkLogic scales really well and our website had over 300 hits per second AVERAGE to it daily and MarkLogic was never slow and always performed. In something like this I would look towards the group doing the finger pointing, thats usually a good place to start!
1. Re:Satisfied ex-customer by batwanger70 · 2013-11-25 01:47 · Score: 1
  
  Same here...ex-customer that built "web scale" public facing sites with MarkLogic. The tech was rock solid...and perfect for when you want to combine multiple schemas. We'd had several project fail trying to come up with the perfect relational schema to consolidate all our data feeds.
  There's something wrong here. The article says:
  "the Obama administration has requested that all government officials and contractors involved keep their work confidential"
  And yet CGI commented that MarkLogic was difficult to implement, hmmm. Scapegoating?? That's assuming you believe that the press quoted CGI correctly...
In other words... by Anonymous Coward · 2013-11-25 03:13 · Score: 0

They went the super cheap unreliable route...
The reason behind XML in the DB is simple... by jmj2 · 2013-11-25 11:10 · Score: 1

Starting in 2009, the Government's data strategy has emphasized data interoperability across organizations. MarkLogic has a fine product that optimizes XML communications between and among organizations. Because the public sites' data stores would be transmitted among the states' repositories, it's easy to see that data strategy would center on exchanges in the chosen lingua franca. Contrary to many of the posts here, I will not take issue with XML. Using it is complex, and it requires verbose communications, certainly - but the real issue with the healthcare.gov fiasco was too many moving parts. I have never seen a fully functional XML capture-and-exchange DB, but I have seen several long, drawn-out projects that sought to produce such a DB as their end product. For a mission-critical system such as healthcare.gov, they should have built two prototypes, one with XML architecture as the to-be model, and the other with a functional architecture that could evolve into an XML structure - but engineered for risk reduction. The real problem here was ineffective risk management, and the ship just kept running toward the rocks while the helmsman held the wheel steady.
Reality check by TuRRIcaNEd · 2013-11-25 12:54 · Score: 1

I should make clear that I'm posting on the basis of personal experience. I have no particular ties to MarkLogic (though companies I've worked for do use the technology), or the US government.
Firstly, the NYT article is poorly researched. My sources tell me that MarkLogic Server is far from the only data storage technology and vendor involved, and that while the MarkLogic-powered aspects of the system did require some remedial action, those aspects were not central to the publicised problems. Remember when MS used their press contacts and marketing clout to smear OSS on the server back in 1999? I wouldn't be surprised if that's going on here.
Secondly, I have it on good authority that the primary points of failure upon launch were related to middleware connecting the modules that were in fact using RDBMS technology.
Thirdly, many Slashdotters will be learning of MarkLogic Server for the first time through this article, and I urge them to give the technology a go before making a judgment call. For one thing, while XML is the (apparent) native storage format and XQuery is the native language, the actuality is somewhat different from what might be assumed. For one thing, the native storage format is not raw XML, but a fully-indexed compressed format which provides a decent compromise between storage requirements and rapid query/retrieval. Additionally, while XQuery is still the native language used by the technology, there has been a significant effort to provide a usable interface to the data through REsT, native Java and even basic SQL. Storage is journaled, implemented as an MVCC system and ACID-compliant in a way that no other "NoSQL" platform can offer. As an example of the platform's resilience under load, I am reliably informed that the BBC's real-time online coverage of the 2012 London Olympiad (which left other news and broadcast organisations in the dust) was powered by MarkLogic Server.
Just like Linux and the OSS BSD implementations that were creaming Microsoft's NT server implementations at the turn of the millennium, alternative data storage, query and search technologies are now challenging the old guard, and the old guard are running scared, and I'd bet significant money that the NYT sources are from the established RDMS vendors. I've been contracting with employers who have been using MarkLogic Server for the best part of a decade, and IMO the technology represents the most viable threat to the RDBMS hegemony and the vendors that rely on it that has ever existed. This opinion is not based on hype, it's based on nearly ten years of experience with the technology and fourteen years of experience with RDBMS development strategies.
I'm not preaching, in fact I urge you all to make your own minds up.

--
- "How do we do it? Volume!" - The Bursar of Unseen University.
Campaign contributions from MarkLogic by Anonymous Coward · 2013-11-26 03:17 · Score: 0

http://www.opensecrets.org/orgs/summary.php?id=D000043843&cycle=A