July 10, 2020 at 12:00 am
Comments posted to this topic are about the item Moving away from an RDBMS
July 10, 2020 at 6:02 am
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
July 10, 2020 at 10:30 am
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.
July 10, 2020 at 10:39 am
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
July 10, 2020 at 12:07 pm
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
July 10, 2020 at 12:43 pm
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:
Wasn't there an Oakridge Boys song that said 'Sometimes the gain ain't worth the pain'?
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
July 10, 2020 at 2:10 pm
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)
God is real, unless declared integer.
July 10, 2020 at 2:46 pm
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;">
- Whatever the technology, the most critical thing is the skill of the folks who use it.
- The technology needs to be chosen based on the desired end result.
- 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
Change is inevitable... Change for the better is not.
July 10, 2020 at 5:57 pm
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.
July 10, 2020 at 5:59 pm
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.
July 10, 2020 at 6:58 pm
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
Change is inevitable... Change for the better is not.
April 19, 2023 at 4:44 pm
Interesting reading this in 2023. I've seen a few cases where PostGres has quietly recaptured ground previously taken by NOSQL solutions.
I've seen people champion certain NOSQL solutions and then implement a model in those solutions that would be a better fit for an RDBMS. Basically, the people who struggle with RDBMS are exactly the same people who struggle with NOSQL. Its not just adaptability that is required its willingness to adapt. NOSQL is a valuable tool, you just have to have the use case for that tool.
April 21, 2023 at 3:58 pm
and knowledge on how to use the tool best. I think sometimes people move to NoSQL because it is easier for developers, but then reporting/analytics require ETL or a warehouse where these things would be simpler in an RDBMS
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply