MDB - another positive article

Investment Analysis Clubs Saul’s Investing Discussions
21

I don’t know. I like Feynman as much as the next person, but I think there are different ways to talk about things that correspond to different levels of understanding of things.

My upshot was: I think Mongo has some problems that are intrinsic that limits it’s share of the NoSQL TAM, which will not grow as a large as the entire database TAM.

You’re right. Document oriented DBs store related data as documents. The way other types of distributed databases persist related data different, and as a result, tend to specialize in different use cases.

The “flexible schema” aspect of Mongo is the problem, where I feel that the flexibility will give enterprises headaches with it in the future. Say you persist {“poster”:“SteppenWulf”,“score”:“10000”} but later change your mind at an application tier about your document model’s score representation and save {“poster”:“ajm101”,“score”:“0xA1”}. You wouldn’t do this, just for example. You now have two versions of your document. Your application tier has to be aware of this. In the regular (OLTP) example you CREATE TABLE poster(alias VARCHAR(128), score int) and while you have to worry about changing your data model over time, its fairly well defined for all consumers at a given point in time. I was just saying that more complicated document structures, more documents, and more generations of document schema creates a high complexity obligation on the application tier. Maybe you know more than I do about current best practices around json schema validation on update/create operations, or the cost of doing so.

If you just like the document paradigm, I’m just saying that you can still enjoy the performance of PostgreSQL (the jsonb type is the mechanism) and get that and happily scale to many TB and be highly available.

I also know about sharding and replication, of course. Typically you have an implied primary key that is associated with a unit of replication (node, shard whatever). I don’t think that you require blockchain for this (https://docs.datastax.com/en/cassandra/3.0/cassandra/archite…) and I thought that Mongo had a low-rent for of it (but wasn’t masterless and it had coordinating processes) but I’m not sure and happy to be corrected.

I think they bought WiredTiger (that’s fine) and I don’t know how multimodel it is already or how much it will be. But everyone is converging to the same thing there, and Mongo will be competing against Marklogic, DataStax, Couchbase, and Redis as independent vendors. And AWS DynamoDB, Oracle NoSQL, MSFT Cosmos DB, and Google Spanner are going to be tough competitors (data sovereignty/privacy aside).

2 Likes
22

Possibly Steppenwulf does not know, but I believe Mongo’s customers do know:

https://www.mongodb.com/who-uses-mongodb

Might want to take it up with Cisco’s CTO, or Barclay’s CTO.

Tinker

2 Likes
23

Check out the Met Life story. MetLife tried for years to put together a project with SQL and miserably failed. If I recall correctly, with Mongo, they completed the project successfully in 6 months or less.

Nothing incredible to see there…

Tinker

4 Likes
24

Oh, I’m so embarrassed I forgot to mention it early, but congratulations on MongoDB World! Do you have a talk? Have a great time.

25

Possibly Steppenwulf does not know, but I believe Mongo’s customers do know:

https://www.mongodb.com/who-uses-mongodb

Might want to take it up with Cisco’s CTO, or Barclay’s CTO.

Tinker

You can go do literally any “www..com/customers” page and see a list of blue chip customers. It’s software marketing 101. Also, case studies are puff pieces intended to create sales funnels, it’s not advisable to take them seriously.

Ask the those CTOs why Gartner dropped MongoDB altogether off their 2017 operational database Magic Quadrant.

2 Likes
26

MongoDB and the “magic Quadrant”

http://info.enterprisedb.com/2017GartnerMQreport_LP.html

https://www.enterprisedb.com/blog/we-shouldn’t-be-surprised-…

The reality is that this new wave of innovation that NoSQL and other new technology vendors provide has been absorbed into mainstream relational databases just as it was in previous waves.

***Relational databases have a greater capacity for extension to provide the capabilities of NoSQL solutions than NoSQL solutions have for adding relational capabilities ***

. And, since customers are looking for more robust solutions to leverage resources across more workloads, it should come as no surprise the number of vendors still recognized in the Gartner Magic Quadrant has declined.

This does not mean the new functionality is no longer relevant, but rather that the database market as a whole is maturing and the market for fit-for-purpose solutions is shrinking.

3 Likes
27

Gartner also added MDB to their Data Warehouse quadrant.

They are regularly updating and modifying and recategorizing quadrants as tech evolves.

I believe Alteryx bounced across a few different quadrants for that reason.

Nutanix was in “integrated systems” quadrant before gartner finally even created an hci quadrant.

Dreamer

4 Likes
28

@Tinker Possibly Steppenwulf does not know, but I believe Mongo’s customers do know:
Sorry I didn’t get the context on this. The world of what I don’t know is so large, I can’t even begin to guess :wink:

@ajm The “flexible schema” aspect of Mongo is the problem

This is a common concern in IT - giving developers too much flexibility can lead to hard to maintain code. My view is different. I think good developers with good processes build maintainable code, and bad developers in bad processes build spaghetti code, practically regardless of tools.

Mongo allows you to put any document in any collection. But the reason it has collections is because it follows a table-like paradigm. Any good data design for Mongo will be similar to a Sql design, but with an order of magnitude fewer tables (since documents can contain subdocuments, so you can avoid most tables and most joins).

So long story short - you can totally screw up a Mongo data design, if you don’t know what you are doing. You can totally screw up a Sql data design if you don’t know what you are doing. In enterprises, you have compliance and multiple levels that validate data designs, and good architects set up patterns to follow such as Master Data and Canonical Model.

I personally don’t see poor data design as a significant risk for Mongo - in fact I see the opposite. Mongo’s flexibility allows superb data designs that good architects will take advantage of.

I also know about sharding and replication, of course

I just meant that I don’t consider Mongo a distributed database. Blockchain is a true distributed database. Hadoop (Hadoop Distributed File System) is another implementation of a distributed data structure that is specifically optimized for distributed analysis.

I consider Mongo to have horizontal scaling, which Oracle also has, and many others. Not trying to be pedantic here - I have no problem if you want to consider horizontal scaling a subtype of distributed data structure. Just not the way I normally use the term.

I think they bought WiredTiger (that’s fine) and I don’t know how multimodel it is already

They bought WiredTiger and integrated it into Mongo 3.0. This was an amazing tech integration - they took a quite different engine and integrated all the cool parts, while keeping all their own key value propositions, all in record time and without affecting existing deployments. This is what basically convinced me they would win the NoSql wars, which they then proceeded to do. WiredTiger itself is a multi-modal engine. They started by integrating it in and provided multiple modes to your data storage implementation, without requiring a change in its design. Very slick. They backed out a few of the modes as they are moving to 4.0 with its ACID compliance, but they use it for their in-memory db, and I expect they will open it up again once they have 4.0 out.

You know that one of the most powerful things of their 4.0 ACID transaction implementation is that it is optional and declarative, right? It doesn’t affect (according to their literature) the performance of non-ACID-transactional actions. I am pretty sure this is implemented using WiredTiger, which implements the Strategy Pattern, allowing you to change your implementation as needed without changing your design. Just a guess - but it explains a lot about their direction since buying WiredTiger - I think this has been their strategy for a long time, and I really respect both their ideas and their execution.

11 Likes