March 21, 2022 at 12:00 am
Comments posted to this topic are about the item Is CosmosDB the One?
March 21, 2022 at 2:49 am
From the Article:
"I'd love to be able to insert data into a table, have it not available as a live value until committed on other nodes, and avoid locking my table. "
Haven't you just described the "SWITCH" functionality of a partitioned table?
I have also developed a bit of fascination about "shiny new objects" not because the objects are "shiny new objects" but because so many people think they're the best thing since sliced bread and round wheels. There are a few (very few) in the last 3 to 4 decades that actually have been but I've found that most are just "new", especially in software products. I've also found that many are actually worse for one reason or another and yet people are excited about them and ride huge band-wagons . I wonder if they'll put in any more effort to learn the full functionality of the new objects than they have when the old objects were new. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
March 21, 2022 at 1:36 pm
I think of CosmosDB as like a fusion restaurant at an international airport where you can order from the menu of your choice (table, document, key store, graph, etc.) using the language of your choice (SQL, MongoDB, Gremlin), and then all the work is performed behind the scenes in a single - but infinitely scalable - kitchen by master chefs.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 21, 2022 at 6:01 pm
About Fusion restaurants: it's pretty rare for them to do everything (or even most things) at a master chef level.
I've never worked with CosmosDB, so I don't speak from experience here.
March 21, 2022 at 9:03 pm
"I'd love to be able to insert data into a table, have it not available as a live value until committed on other nodes, and avoid locking my table. I realize I'm asking for something that seems like a bit of magic, but I bet Microsoft could add this to the SQL Server relational engine."
Except for distributed transactions, isn't what you're describing above also how the existing two variations of snapshot isolation level have basically worked in SQL Server since 2005 ?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 22, 2022 at 1:00 am
About Fusion restaurants: it's pretty rare for them to do everything (or even most things) at a master chef level.
I've never worked with CosmosDB, so I don't speak from experience here.
Pun intended, you said a mouthful there.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 22, 2022 at 9:12 am
I think people want an automagical database that requires minimal investment in learning to be effective in its use.
I found that people were trying to use MongoDB the way that they would use MySQL rather than the way that works best for MongoDB. The developers doing that just didn't like the disciplines that MySQL imposed.
Perhaps developments in machine learning and AI will get us to the stage where the interpreter of a declarative data language is such that it can choose the optimum data model and queries to store and retrieve data for a given use case. Much like there are tools that can give a really good hint as to how to write your code. Sourcery for Python being my current favourite
March 22, 2022 at 1:14 pm
larry.blake wrote:About Fusion restaurants: it's pretty rare for them to do everything (or even most things) at a master chef level.
I've never worked with CosmosDB, so I don't speak from experience here.
Pun intended, you said a mouthful there.
The thing about cloud database services is that they don't need to be expertly optimized in the same way as an on-prem SQL Server instance. These databases are scaled out across distributed nodes - either on demand, on a schedule for known usage peaks, or in response to pressure from unexpected spikes.
I honestly don't know if I've ever eaten a meal prepared by a master chef. When I'm eating lunch out, I'm typically looking for a meal that's prepared well enough, something different that's within my budget and time constraint. That's actually what a lot of customers are looking for when it comes time to host a database for their application. The masters can focus on other applications that require their higher skill level.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
March 22, 2022 at 10:52 pm
From the Article:
"I'd love to be able to insert data into a table, have it not available as a live value until committed on other nodes, and avoid locking my table. "
Haven't you just described the "SWITCH" functionality of a partitioned table?
Only if I'm switching a partition. I'm thinking of inserting, or updating, a single row, or a value in that row. Once it commits, I can't easily prevent someone on this node from seeing the value, even if it fails to get added to another node.
There's some value in ensuring this across systems these days.
March 22, 2022 at 10:53 pm
"I'd love to be able to insert data into a table, have it not available as a live value until committed on other nodes, and avoid locking my table. I realize I'm asking for something that seems like a bit of magic, but I bet Microsoft could add this to the SQL Server relational engine."
Except for distributed transactions, isn't what you're describing above also how the existing two variations of snapshot isolation level have basically worked in SQL Server since 2005 ?
In a single table. Not across distributed nodes. Even with DTC, this creates locks, and it is limited in how well it scales beyond one system.
March 23, 2022 at 2:12 am
Jeff Moden wrote:From the Article:
"I'd love to be able to insert data into a table, have it not available as a live value until committed on other nodes, and avoid locking my table. "
Haven't you just described the "SWITCH" functionality of a partitioned table?
Only if I'm switching a partition. I'm thinking of inserting, or updating, a single row, or a value in that row. Once it commits, I can't easily prevent someone on this node from seeing the value, even if it fails to get added to another node.
There's some value in ensuring this across systems these days.
Heh... there's always been that value but a lot of people swear by the "eventually in sync" and "delayed durability", etc. methods. It's also going to be a problem forever because notification between nodes just isn't instantaneous. I suspect that's why Microsoft hasn't made an effort there. No matter how auto-magic you make it, there will always be latency between nodes. I'm reminded of old AppleTalk version 1.0. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply