The NoSQL Misdirections

Question

Post reply

The NoSQL Misdirections

MVDBA (Mike Vessey)

SSC-Insane

Points: 21797
More actions
September 2, 2019 at 12:00 am

#3672897

Comments posted to this topic are about the item The NoSQL Misdirections
MVDBA

Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic. Login to reply

David.Poole SSC Guru Points: 76000 More actions · Answer 1

The page on the MongoDB site gives a 404.

MongoDB's strengths are also its weaknesses.

It doesn't care about the design of its collections. It'll punish poor design with poor performance but it will let you stick your Grannies fruitcake recipe in a collection intended for numeric data. It is faster and easier to make changes because it stores/retrieves JSON as the app would use it. This is great for the app and people with an in-depth knowledge of the object model generating the JSON. Not so Great if you are a bulk data consumer tasked with using data from a MongoDB. Software archeology has to be taken to a new level.

Skilled and disciplined developer's will come up with a good object model, good separation of collections based on the objects they are intended to store and good collection design. But there is nothing to stop someone using a collection to store objects of different types.

In the early days claims by MongoDB for what the product could do were hyperbole. I spoke to one consultant who said "yes, you can scale out and shard but please don't, it's a nightmare to administer and recover. If you can get away with it just scale up"! Far from being"Humongous" this limited the max DB size that would work reliably was 640Gb.

MongoDB is a great little system but your article draws attention to behaviours that destroy trust. We all know that salesmen accentuate the positive. Would you buy from a salesman who makes statements about competing products that are derogatory and you know to be patently untrue?

LinkedIn Profile

Kenneth Igiri SSCertifiable Points: 5001 More actions · Answer 2

Thanks for the article. 1 Trillion rows caught my attention. How would you compare and RDBMS row to a NoSQL row. Can I consider a NoSQL "row" as a single JSON entry?

Br. Kenneth Igiri
https://kennethigiri.com
All nations come to my light, all kings to the brightness of my rising

Gerard van de Ven SSC Veteran Points: 219 More actions · Answer 3

The link to the MongoDB site apparently is case sensitive (!). It should be https://www.mongodb.com/nosql-explained.

Thanks for the article. Interesting read, especially in combination with the original one as you referred to.

MVDBA (Mike Vessey) SSC-Insane Points: 21797 More actions · Answer 4

MVDBA (Mike Vessey)

SSC-Insane

Points: 21797

September 2, 2019 at 9:21 am

#3676293

thanks for the correction … my bad

MVDBA

MVDBA (Mike Vessey) SSC-Insane Points: 21797 More actions · Answer 5

Kenneth Igiri wrote:

Thanks for the article. 1 Trillion rows caught my attention. How would you compare and RDBMS row to a NoSQL row. Can I consider a NoSQL "row" as a single JSON entry?

there are several different types of NoSQL database types

Graph, Document, Key value - all of them have slightly different structures, so each will be different

I'm more familiar with Amazon DDB which is a wide column store database (AKA a key and a JSON structure with a range index)

The 1 Trillion row example was for a system which collected changes to registry entries, new files and behavioural patterns of a lot of machines ( several hundred million)

we used the key to tie it back to our relational data and then our teams could get 50 rows of json into a temp table that we could join on our main query... a hybrid system

MVDBA

Gabriel P SSCarpal Tunnel Points: 4289 More actions · Answer 6

The current place I work we have to get 2 week advance notice for anything that requires a schema lock on any of the busier tables. Granted we are still using pessimistic concurrency but all of the remarks about ALTER tables ring true and is one of the factors preventing us from achieving true CI/CD.

Mongo has been known to make jabs at its relation counterparts. Ironically they keep copying features from relational databases. Also ironically I can create a schemaless table in a rdms:

CREATE KeyValue ([Key] uniqueidentifer NOT NULL PRIMARY KEY, [Value] nvarchar(max) );

Jeff Moden SSC Guru Points: 1004323 More actions · Answer 7

Gerard van de Ven wrote:

The link to the MongoDB site apparently is case sensitive (!). It should be https://www.mongodb.com/nosql-explained.
Thanks for the article. Interesting read, especially in combination with the original one as you referred to.

Confirmed! I changed only the "N" of "nosql" in the all lower case url and got the 404.

With origins from the Simpsons cartoon series, I have just 2 words that will adequately portray my feelings about that...

BWAAAAA-HAAAAAA!!!! 😀

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Jeff Moden SSC Guru Points: 1004323 More actions · Answer 8

@ MVDBA ,

Awesome article. Thanks for taking the time to research it and post it, especially since it's coming from someone that does have experience in both worlds.

Heh... so, inquiring minds want to know... does "MVDBA" stand for "Mongo Virtual DBA". 😀

Just playin'... thanks again for the great article.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Alan Hyneman Mr or Mrs. 500 Points: 510 More actions · Answer 9

I feel the exact same way when comparing entity framework and sql+.net - these days, you have to be careful to discern marketing hype and misrepresentation to what you know, through experience, to be true.

Alan Hyneman

jennym Old Hand Points: 376 More actions · Answer 10

Could not agree more! btw... I intended to click '5 stars', mouse slipped, and clicked 2... could not find a way to update to 5... apologies!!!!

x SSC-Insane Points: 23660 More actions · Answer 11

I rated this article a 1 based on the following quote (and of course, 0 wasn't available):

"I'm sorry, I can't see this one. If your data design is correct, then your classes in C# will map nicely to your data design."

Clearly object relational mapping is a much more troubling topic then your dismissive quote would imply, in fact its one of the rather difficult challenges mentioned untold times on the web. If you don't know that, you are just not doing your homework, and you should stop writing articles in that case.

Chris Harshman SSC-Forever Points: 42192 More actions · Answer 12

Gabriel P wrote:

The current place I work we have to get 2 week advance notice for anything that requires a schema lock on any of the busier tables. Granted we are still using pessimistic concurrency but all of the remarks about ALTER tables ring true and is one of the factors preventing us from achieving true CI/CD.

This sounds more like a business process that was put in place for a reason than a limit of a RDBMS. Perhaps the request has to go through change control and get the approvals of necessary parties. I imagine similar processes would still need to be in place for changes made to a live production environment Mongo DB system.

@@caffeine_level Old Hand Points: 368 More actions · Answer 13

If one considers the requirement to understand and practice the relational data model of a SQL database as a drawback, then NoSQL is in favor. Otherwise, I am still waiting for the outstanding breakthrough of NoSQL. Maybe IoT will drive the change.

In the companies I met so far, minimum 95% of all important business data still were processed by RDBMS called MS SQL Server, Oracle DB, IBM DB2 or SAP HANA.

David.Poole SSC Guru Points: 76000 More actions · Answer 14

As with all things it is recognising what the intended use of a tool may be and then deciding if that fits your use case.

The MongoDB tech folk were very clear on what their tool was for and the disciplines that would be required to get the best out of it. If you were lucky enough to engage with their tech folk it was pretty simple really. Unfortunately a combination of unscrupulous marketing from MongoDB and willing suspension of disbelief from clients caused an immense pain that was entirely unnecessary. Mike's article illustrates how dubious marketing claims can be a well poisoner.

If you found yourself having to fall back to an EAV model in an RDBMS then that was a bit of a clue that MongoDb (other document stores are available, some more highly than others) might be a good fit.

LinkedIn Profile