March 9, 2015 at 9:05 pm
Comments posted to this topic are about the item Limitations of MongoDb
March 10, 2015 at 12:01 am
I think the author of this article is missing the point of MongoDB (as an example) quite entirely. It is designed as a 'flexible design model' and in fact moves away from constraints such as rigid referential integrity checks to encourage free flowing data changes & schema changes for Developers. If you want foreign keys and feel that data integrity is key, DON'T use MongoDB. Its not what it is designed for!
I speak as a DBA and not as Developer, and whilst MongoDB is not without its faults (what tech is without?!) its a breath of fresh air to administer & support. Its strength in my eyes is met by businesses that want to store JSON style documents (such as Media & Entertainment organisations) and not by my companies that want to store relational data on a NoSQL platform. This being said it still has a long way to go to be a fully embraced as a data layer solution
March 10, 2015 at 12:57 am
I disagree with dbridgman that the editorial misses the point. My reading of it was that sometimes OTHER people misunderstand MongoDB and other NoSQL Databases and apply them to inappropriate solutions.
I agree with dbridgman's assertion that MongoDB applies a different paradigm and, therefore, applies to different solutions. This is what I feel the editorial was asking for i.e. where do people feel MongoDB and its fellow NoSQL Databases apply.
For me I can see value of NoSQL Databases in high volume web front ends. The cliche would be to use it for the stock catalogue which is a near time representation of the stock control system which may well be persisted in a RDBMS and for capturing baskets and orders placed before they enter the order management system (which again may well be persisted in a RDBMS) as well as other data used for the UI.
Basically, I see NoSQL databases as a performant persistence mechanism that can enable front end systems (including those interfacing other external systems) but are not part of the core enterprise data. I see them very much as caches and/or stores of transient data.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 10, 2015 at 2:40 am
dbridgman (3/10/2015)
I think the author of this article is missing the point of MongoDB (as an example) quite entirely. It is designed as a 'flexible design model' and in fact moves away from constraints such as rigid referential integrity checks to encourage free flowing data changes & schema changes for Developers. If you want foreign keys and feel that data integrity is key, DON'T use MongoDB. Its not what it is designed for!I speak as a DBA and not as Developer, and whilst MongoDB is not without its faults (what tech is without?!) its a breath of fresh air to administer & support. Its strength in my eyes is met by businesses that want to store JSON style documents (such as Media & Entertainment organisations) and not by my companies that want to store relational data on a NoSQL platform. This being said it still has a long way to go to be a fully embraced as a data layer solution
I would tend to agree somewhat only because you are talking about uses. Then again, you're also putting a lot of power in someones hands who is not specifically responsible for the data either. I think most of the database guys I talk to over the years fear that the most. Eventually, why even have a database lead?
However, I won't make it that one-sided. The use of free flowing data has it's place in my world simply for the use of giving the data scientist access to a data repository they can analyze and mark data as valuable. There is no real limitations such as the constraints you mentioned outside of disk space.
BUT--BIG BUTT HERE--when the data get's evaluated and deemed important, it goes into a RDBMS. It goes from free flowing to controlled or as I tell management in simple terms: less work to more work. Less work meaning, I don't have to touch it or develop anything for it such as an ETL system, data modeling or anything. It's in the hands of the data scientist or analyst until they deem value. Then it's in my lap. 😎
That said, here is some more info from the article that I found in the MongoDB documentation on multi-document updates in case others were wondering:
MongoDB(3/10/2015)
Because only single-document operations are atomic with MongoDB, two-phase commits can only offer transaction-like semantics. It is possible for applications to return intermediate data at intermediate points during the two-phase commit or rollback.
And here is some info on how MongoDB handles multiple applications touching the same transaction:
MongoDB(3/10/2015)
For example, applications App1 and App2 both grab the same transaction, which is in the initial state. App1 applies the whole transaction before App2 starts. When App2 attempts to perform the “Update transaction state to pending.” step, the update condition, which includes the state: "initial" criterion, will not match any document, and the nMatched and nModified will be 0. This should signal to App2 to go back to the first step to restart the procedure with a different transaction.When multiple applications are running, it is crucial that only one application can handle a given transaction at any point in time. As such, in addition including the expected state of the transaction in the update condition, you can also create a marker in the transaction document itself to identify the application that is handling the transaction.
March 10, 2015 at 3:43 am
To quote from Eric's article: "In not having foreign key constraints I am at the mercy of every application and database developer to ensure data integrity is persisted."
In my learning MongoDB, it was designed to perform very quickly 80% of what relational databases can do.
If understood, that 80% is OK and maybe even good.
Most of our application and database developer have been educated on relational databases, and make those assumption of the protections that are standard in a relational database.
Where we get burned is that 20% where we need "to ensure data integrity is persisted."
March 10, 2015 at 4:40 am
dbridgman (3/10/2015)
I think the author of this article is missing the point of MongoDB (as an example) quite entirely. It is designed as a 'flexible design model' and in fact moves away from constraints such as rigid referential integrity checks to encourage free flowing data changes & schema changes for Developers. If you want foreign keys and feel that data integrity is key, DON'T use MongoDB. Its not what it is designed for!I speak as a DBA and not as Developer, and whilst MongoDB is not without its faults (what tech is without?!) its a breath of fresh air to administer & support. Its strength in my eyes is met by businesses that want to store JSON style documents (such as Media & Entertainment organisations) and not by my companies that want to store relational data on a NoSQL platform. This being said it still has a long way to go to be a fully embraced as a data layer solution
Yes - the MongoDB guys deliberately dropped RI (among other things) in order to streamline the feature set. It's not intended as a drop in replacement of an RDBMS.
March 10, 2015 at 6:31 am
There is a distinct difference between data that can be 'mostly right' and data that must be 'absolutely right'. Accounting, sales orders etc. need rigorous control.
Other data however (large scale marketing statistics, for example) can easily tolerate a little slop. And if that allows use of a lower overhead tool, it's not a bad idea.
...
-- FORTRAN manual for Xerox Computers --
March 10, 2015 at 6:35 am
It all comes down to this: use the right tool for the right job. NoSQL databases have their uses and function well in that space just as RDBMS databases do in theirs. The problem comes from trying to make one function as the other. After all, just because you can use a screwdriver as a chisel doesn't mean that you should or that it will be effective.
As I see it (and I'm sure someone will correct me if I'm wrong) the big difference between NoSQL and RDBMS is a matter of WHEN you apply structure to the data. NoSQL gets its power from being able to store data very quickly without much constraint but to use that data effectively requires the application that retrieves the data to know about that structure and how it's related to any other stored data. On the other hand, relational databases impose and enforce rigid structure and rules on the data BEFORE it's loaded which requires the retrieval application to know very little about that structure and its relationships.
I see lots of uses for NoSQL that should not be ignored. Its ability to quickly collect data without structural constraints can be extremely useful. For example, often times structures and relationships may not be known until data is collected and analyzed. Once known and understood, then the data could be moved to an RDBMS structure if needed. NoSQL is great at facilitating websites, handling chunks of related data together as a unit in structured documents, or as a sandbox for exploring new concepts or trying out new techniques that are inhibited by the more rigid structures of an RDBMS environment.
On the other hand, NoSQL is NOT a replacement of RDBMS. They each have their abilities, purposes and functions. Trying to make a NoSQL database function as an RDBMS database is just as bad of an idea as trying to make an RDBMS database function as a NoSQL one. It is NOT a competition as they each have their strengths and weaknesses and each tool should be used to their greatest effect. It's a very similar argument to procedural vs. set-based programming. They are both sides of the same coin. You cannot have one without the other and the sooner people recognize that and stop making it a competition, the sooner we will be able to realize the benefits of using both together with awesome results.
LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com
March 10, 2015 at 6:43 am
I agree there is a place for each of these in the IT world. As long as one doesn't attempt to use NOSQL or MongoDB in the wrong way and also to keep in mind the limitations of these than that is fine.
Microsoft is opening the door to these. With the price of SQL Server going up greatly over the last few years it opens the door to these lower level ones creeping in.
March 10, 2015 at 6:59 am
Difficult to maintain integrity without foreign key contraints, perhaps, but not impossible. I worked for years in a small shop and did just fine developing without the contraints or the transaction rollback. But the bigger the IT staff got, the harder it became.
March 10, 2015 at 7:11 am
Aaron N. Cutshall (3/10/2015)
...relational databases impose and enforce rigid structure and rules on the data BEFORE it's loaded which requires the retrieval application to know very little about that structure and its relationships...
I don't see how that works. Most applications have to know and understand the structure. Although some/all can be hidden within stored procedures that still requires the application to know and understand that logical structure.
It is more about the enforcement of structure than the understanding from my point of view.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 10, 2015 at 7:12 am
The strength of MongoDB is its original core concept of fire and forget. Flexibility at both the data and architecture level of MongoDB tend to lure businesses in, and, of course, the fabricated mantra of "minimal administration". Truth is, the design of the database engine poses significant issues for data consistency, resource management, cost, and increasing transaction volume. Our company uses it for the purpose of storing cache data, which is ideal. If 20% of our data has been lost, there is no impact to our day-to-day operations. Not even the long-awaited version 3.0 would suggest to me that the technology is ready to be a primary data store.
[font="Arial"]Matthew[/font]
March 10, 2015 at 7:13 am
Take a look at Azure DocumentDb, it has transactions, indexes, SP's/UDF's, SQL interface and isolation level control for transactions
No FKs and ultimately I think this is deliberate. Once you have FK's you remove the "no downtime" goal of the database.
Applications need to manage the flexibility but they can do it with the load balanced and stateless deploy flexibility of a large scale cloud based application
I definitely intend to use it for some of my projects where it is appropriate.
March 10, 2015 at 7:24 am
I feel the same way about MongoDB as I do Microsoft Access. It's a great tool for the job it was designed for. The problem comes when people who don't understand it's strengths and weaknesses, create an application that hits the wall. It's the developers job to select the best tools for the job and design their application that takes advantage of the strengths, and minimizes the weaknesses. It's the DBA's job to guide the developers on how best to persist the data and facilitate it's flow. It helps when a DBA comes up from the developers ranks, and when a developer has experience as a database designer. Cross training is the key... stay curious about things that are not in your core competency. This is why I'm studying MongoDB and related NoSQL products and concepts. I may never do a major project with MongoDB, but I'll be prepared to if called upon to use it. 😉
March 10, 2015 at 8:12 am
Disclaimer: I have no practical experience with MongoDB at this point, so if my assumptions below are wrong, then please let me know.
I can see MongoDB as an ideal database for serving Write Once / Read Many website content, for example Amazon or New York Times Online. It would clearly be superior to ASP.NET + SQL Server, where data for a webpage is queried from relational tables on demand and then transformed into HTML just in time. The same goes for persisting online shopping carts in MongoDB.
However, I would have serious doubts about it's suitability for a line of business application like CRM (due to lack of data integrity constraints) or for data warehousing (due to limited support for aggregate queries and indexing).
Also, because MongoDB is a document centric database that contains data as serialized JSON or XML, I suspect that it would less suitable than a RDMS database for data that is frequently appended or updated. In other words, if you update a MongoDB document, perhaps something like adding additional office visitation records to a patient's chart, then the change of size operation would require that the updated document be re-written to a new physical location on file. I'm thinking here about fill factor, page splits, and fragmentation.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 15 posts - 1 through 15 (of 38 total)
You must be logged in to reply to this topic. Login to reply