The NoSQL Misdirections

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

    MVDBA

  • 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?

  • 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

  • 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.

  • thanks for the correction … my bad

    MVDBA

  • Br. 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

  • 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) );

     

     

  • 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)
    Intro to Tally Tables and Functions

  • @ 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)
    Intro to Tally Tables and Functions

  • 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

  • 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!!!!

  • 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.

     

  • 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.

  • 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.

  • 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.

     

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

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