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.
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.
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.
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.
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.
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.
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.
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.
Slashdot Mirror
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.
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.
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.
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.
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.
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.
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.
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.