Moving away from an RDBMS

  • Comments posted to this topic are about the item Moving away from an RDBMS

  • The problem is that a typical developer uses relational database as document storage.

    Thanks to MS providing embedded support to XML, JSON, Columnsstore, etc.

    Obviously, a relational database is not the most effective tool to handle documents. And it missiles the most important part of NoSQL databases - distributed storage and computing.

    you can't possibly see any performance or any other advantage of relational databases before NoSQL ones if you use it only as an integration utility for non-relational data.

     

    _____________
    Code for TallyGenerator

  • It is a bad example to use for that type of DB engine, but as the article was aimed at RDBMS people they had to use something that could be related to by the audience.

    Personally, I'm always interested in how other NoSQL engines work. I've had a little exposure to Vertica and MongoDB, both of which I found interesting. The problem as ever, is using the tools for their intended purpose - and that isn't helped by the sales pitch that we're given by the vendors.

    And no storage system will ever escape the requirement for a good, consistent design that is actually followed by those that use the database. I know of at least one MongoDB system that has inconsistent data structures from different teams, for the same information. Any reporting has to be done by extracting the data from MongoDB, cleaning it up and writing it to a SQL Server DB.

    Neo4J is next on my list, as we have a few within my company, then I'll have a look at Cosmos too. I find it helps me look at issues from different angles.

  • I can remember a heated debate about scaling out a DB and the DBA asked "why the hell would I want to scale out for a load this small"?

    If your company is operating in a mature market then the market share you have may go up or down a few percentage points but I doubt you are going to get radical growth.  I'd ask how much scale you need and does it require a technology change?

    I'd certainly use a document store for new markets and prototyping new products.

    Back in 2014 I listened to a presentation from 10Gen who are not MongoDB Inc on the subject of data modelling.  They were very clear that data modelling becomes MORE important in the NOSQL world, not less.  Getting the boundaries of what constitutes a document is extremely important.

    People who can produce a well designed application object model will produce a competent document model just as they used to produce competent relational models.

    People who collect, implement and invent anti-patterns will produce godawful document models just as they used to produce abominations in RDBMS.  If you allow them to scale out you will find 5 large instances doing the work that 1 small instance should be able to cope with.  If all you have to do is click a switch to throw hardware at a problem then that will be the predominant choice.  Your costs are going to go sky high.

    The appeal of the cloud is not that you can scale up, it is that you can scale down.  In the physical world we used to provision for 3x peak load with the expectation that what we bought would cover demand for the next 3-5 years.  Now we can provision for the load we actually have and actually achieve.

    I'm sure many of us have worked with software engineers who have insisted that they could manage DRI in the app and we didn't need it in the DB.  I can't think of anyone who proved that this was really achieved.  I have lost weeks of my life to finding and dealing with non-DB DRI failures.

    NOSQL came into being to satisfy specific needs where a more general solution reached its limits.  If you are running an app that works at its optimum with a particular non-relational DB tech then fantastic.  My experience is that the principle of "Data Is Shared" torpedoes the benefits of that solution.  You have an app that works really well and has a particular access pattern that suits your chosen DB platform.  Then someone wants to run BI workloads against that data.  At the very least you need a reporting replica but more likely you need to shift the data into a.n.other data technology.

    As soon as you talk about shifting data from A to B you create the need for a reconciliation process, incident management/resolution process.  You create duplication of processes too.  GDPR Right To Be Forgotten being an example.  This is true regardless of the tech but in a world with different data technologies the effort to make sure similar processes work against different technologies is expensive, time-consuming and fraught with difficulties.

    Ultimately it isn't about how fast one part of IT estate can run, it is about the whole.  Think of it like a small car.  You drop in a more powerful engine.  Unless you think about the suspension, brakes, wheels and tyres it isn't going to end well.

    How does CosmoDB perform with updates?  MongoDB used to be appalling.  Reads - excellent, writes - excellent, updates - is it broken?

    In short

    • Look at you total cost of ownership
    • Look at the productivity change end-to-end not just for the team gaining from the use of the NOSQL tech
    • Watch your costs like a hawk

     

     

     

  • I'm jumping in early, as I haven't yet read Leonard Lobel's blog post. As a developer I am very interested in NoSQL databases, and in particular CosmosDB. However, there's also a practical side of me. I recently heard a MS Dev Show podcast, where they interviewed a startup that used various Azure offerings. They started with CosmosDB. They quickly realized that if they'd stayed with CosmosDB, it would become very expensive for them, so they switched to Azure SQL instead, thus realizing a great savings.

    That podcast article has, at least for the time being, put it off of CosmosDB. I want to explore it, but if its going to be significantly more expensive than a more traditional approach, I'll go with the traditional approach. At least for now.

    Rod

  • Well, my career progressed from card decks (80 column, then 96 column) and MICR sort machines, then flat files that we had to write sort utilities to reorder, through indexed files, through hierarchical databases and to relational databases.  Of course I am inexperienced in the newer options since I retired, but I would say several things about this:

    1.  Whatever the technology,  the most critical thing is the skill of the folks who use it.
    2. The technology needs to be chosen based on the desired end result.
    3. The first question when considering changes and new technology should be 'Do we really need to do this'.

    Wasn't there an Oakridge Boys song that said 'Sometimes the gain ain't worth the pain'?

     

    • This reply was modified 1 year, 2 months ago by  skeleton567.

    Rick

    One of the best days of my IT career was they day I told my boss if the problem was so simple he should go fix it himself.

  • I'd assume that the NoSQL data model fits better for very specific approaches, where you can encapsulate a bigger part of data and assign it to a specific user etc..

    Imaging you are creating a roleplaying style mobile game. Your players will have multiple heroes, each hero has some equipment, level, class ... And of course each player will have some sort of global inventory, maybe a mailbox etc.

    Of course you can create this as relational database model with maybe 10-20 tables, but every time the player logs in, you'll have to launch several SQL queries to all of this tables (often with joins between them).

    If you put all the data that belongs to a player (his set of heroes including all attributes / equipment), his inventory etc.) into a single JSON file, you would just need a single SELECT to get this file (ideally compressed) and the mobile application could parse it and put everything into its place on the screen.

    Modifications will be done by a middle tier service (mobile app sends a 'add 500 gold to player 123' to the server, the service (or stored procedure) validates it, modifies the JSON and sends an okay back).

    The main difference to the typical webshop here is, that the hot data all belongs to a specific user and will usually not needed to send to another, while the global data (as which attacks a monster uses or how much gold a weapon costs) are very stable (changes usually only with newer application versions) - compared to e.g. the products in a shop)

    • This reply was modified 1 year, 2 months ago by  Thomas Franz.

    God is real, unless declared integer.

  • skeleton567 wrote:

    Well, my career progressed from card decks (80 column, then 96 column) and MICR sort machines, then flat files that we had to write sort utilities to reorder, through indexed files, through hierarchical databases and to relational databases.  Of course I am inexperienced in the newer options since I retired, but I would say several things about this:

      <li style="list-style-type: none;">

    1.  Whatever the technology,  the most critical thing is the skill of the folks who use it.
    2. The technology needs to be chosen based on the desired end result.
    3. The first question when considering changes and new technology should be 'Do we really need to do this'.
      <li style="list-style-type: none;">

    Wasn't there an Oakridge Boys song that said 'Sometimes the gain ain't worth the pain'?

    I don't know about the song (can't find the title on a quick search) but the rest of your post is spot on.  I'd add a #4, though.

    4. In regards to #3, do the people making that decision actually know enough about the current method(s) to actually be able to make that decision?

    I find that the answer to that question is frequently a resounding "NO".  There also seems to be a contingent of people that think that change is essential and so appear to have taken on a mindset of "We have to do something" even if it's flat out not needed or even just wrong.

    And with that, I'll repeat what it says in my signature line because it's so true...

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

    Of course, I'll also add that we shouldn't stop trying to change things for the better.  I just get really miffed when someone claims something is better and forces everyone else in the group to adopt and adapt and then it turns out to not actually be better.   With that, we need to add #5...

    5.  Are you sure and have you actually tested it and compared it to the current method(s)?

    Sadly, the answers there usually boil down to "No, but so and so says it is" or "Everyone is talking about it on the internet" or, in an insulting fashion, "Don't be such a stick in the mud" or  "Get with it... it's what everyone is doing".

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

  • Thomas Franz wrote:

    I'd assume that the NoSQL data model fits better for very specific approaches, where you can encapsulate a bigger part of data and assign it to a specific user etc..

    Imaging you are creating a roleplaying style mobile game. Your players will have multiple heroes, each hero has some equipment, level, class ... And of course each player will have some sort of global inventory, maybe a mailbox etc.

    ...

    In one sense, what you note here is true and I agree that some things are simple. However, you're also putting all the technical debt of the data model in the application here, and that will need to be maintained over time. I find that developers don't think about all the permutations of handling different document structures over time.

    There also is the update issue when something fundamental changes. The RDBMS  has the challenge of pulling together data from multiple tables to satisfy some needs, but this also makes problems in data, updates, and aggregations easier.

    Not saying NoSQL is worse, but it's a tradeoff.

     

  • Doctor Who 2 wrote:

    I'm jumping in early, as I haven't yet read Leonard Lobel's blog post. As a developer I am very interested in NoSQL databases, and in particular CosmosDB. However, there's also a practical side of me. I recently heard a MS Dev Show podcast, where they interviewed a startup that used various Azure offerings. They started with CosmosDB. They quickly realized that if they'd stayed with CosmosDB, it would become very expensive for them, so they switched to Azure SQL instead, thus realizing a great savings.

    That podcast article has, at least for the time being, put it off of CosmosDB. I want to explore it, but if its going to be significantly more expensive than a more traditional approach, I'll go with the traditional approach. At least for now.

    Take this with a grain of salt. Both platforms have altered pricing at times, so you need to perform your own analysis here.

    And, if you do, please publish something. We need good guidance, not just with design, but also pricing.

     

  • Doctor Who 2 wrote:

    I'm jumping in early, as I haven't yet read Leonard Lobel's blog post. As a developer I am very interested in NoSQL databases, and in particular CosmosDB. However, there's also a practical side of me. I recently heard a MS Dev Show podcast, where they interviewed a startup that used various Azure offerings. They started with CosmosDB. They quickly realized that if they'd stayed with CosmosDB, it would become very expensive for them, so they switched to Azure SQL instead, thus realizing a great savings.

    That podcast article has, at least for the time being, put it off of CosmosDB. I want to explore it, but if its going to be significantly more expensive than a more traditional approach, I'll go with the traditional approach. At least for now.

    Do you have a link to that podcast article?  I'd love to listen to it.

     

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

Viewing 11 posts - 1 through 11 (of 11 total)

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