MongoDB 3.4 and “multimodel” query
“Multimodel” database management is a hot new concept these days, notwithstanding that it’s been around since at least the 1990s. My clients at MongoDB of course had to join the train as well, but they’ve taken a clear and interesting stance:
- A query layer with multiple ways to query and analyze data.
- A separate data storage layer in which you have a choice of data storage engines …
- … each of which has the same logical (JSON-based) data structure.
When I pointed out that it would make sense to call this “multimodel query” — because the storage isn’t “multimodel” at all — they quickly agreed.
To be clear: While there are multiple ways to read data in MongoDB, there’s still only one way to write it. Letting that sink in helps clear up confusion as to what about MongoDB is or isn’t “multimodel”. To spell that out a bit further:
- In query, MongoDB mixes multiple paradigms for DML (Data Manipulation Language). The main one is of course JSON.
- When writing, the DML paradigm is unmixed — it’s just JSON.
Further, MongoDB query DML statements can be mixed with analytic functions rooted in Spark.
The main ways to query data in MongoDB, to my knowledge, are:
- Native/JSON. Duh.
- SQL.
- MongoDB has used MySQL as a guide to what SQL coverage they think the market is calling for.
- More to the point, they’re trying to provide enough SQL so that standard business intelligence tools work well (enough) against MongoDB.
- I neglected to ask why this changed from MongoDB’s adamantly non-SQL approach of 2 1/2 years ago.
- Search.
- MongoDB has been adding text search features for a few releases.
- MongoDB’s newest search feature revolves around “facets”, in the Endeca sense of the term. MongoDB characterizes as a kind of text-oriented GroupBy.
- Graph. MongoDB just introduced a kind of recursive join capability, which is useful for detecting multi-hop relationships (e.g. ancestor/descendant rather than just parent/child). MongoDB declares that the “graph” box is thereby checked. 🙂
Three years ago, in an overview of layered and multi-DML architectures, I suggested:
- Layered DBMS and multimodel functionality fit well together.
- Both carried performance costs.
- In most cases, the costs could be affordable.
MongoDB seems to have bought strongly into that view on the query side — which is, of course, exactly the right way for them to have started.
Comments
4 Responses to “MongoDB 3.4 and “multimodel” query”
Leave a Reply
> I neglected to ask why this changed from MongoDB’s adamantly non-SQL approach of 2 1/2 years ago.
You addressed in the point above that one. Customers want to use BI tool that speak SQL over ODBC (Tableau, etc.) Every JSON store has a unique query language making it difficult for tool vendors to choose or keep up.
> MongoDB has used MySQL as a guide to what SQL coverage they think the market is calling for.
At one point, the MongoDB BI Connector was a PostgreSQL instance: http://www.bluetreble.com/2015/12/mongodbs-bi-connector-postgres/
Has this changed with a different approach for SQL support?
Really strange how mongodb calls itself a multimodel database with minimal graph features.
A true multimodel database is arangodb.
Thanks
Sreeni
http://www.sreenivaskandakuru.com
일본AV
RDF and graphs | DBMS 2 : DataBase Management System Services