Azure SQL Database has two similar flavors - Managed Instance and Elastic pools. Both flavors enables placing multiple databases that share the same resources and in both cases can be changed cpu/storage for entire group of database within the instance/pool. What is the difference between them?
Azure SQL Database Elastic Pool is a shared resource model for Single Azure SQL PaaS databases to achieve higher resource utilization efficiency, and all the databases within an elastic pool share predefined resources within the same elastic pool. The emphasis of this offering is on a simplified database-scoped programming model for multi-tenant SaaS apps where the workload pattern is well defined and delivers high cost-effectiveness when serving many tenants.
SQL Database Managed Instance offers a simplified instance-scoped programming model that is like an on-premises SQL Server instance. The databases in Managed Instance share the resources allocated to the Managed Instance, and the Managed Instance also represents the management grouping for these databases. The emphasis of this offering is on high compatibility with the programming model of on-premises SQL Server and out-of-box support for the large majority of SQL Server features and accompanying tools/services.
Some high-level guidelines might be:
Use Elastic pools if you need to group a large number of single
database that don't need all instance Transact-SQL functionalities
that exist in SQL Server.
Use Managed Instance if you want to migrate
a large number of SQL Server database that heavily use instance level
features such as CLR, Service Broker, SQL Agent, etc.
See more info in Azure SQL IaaS vs PaaS Comparison Table
Related
I am trying to understand the differences between the new CockroackDB and other distributed SQL databases as compared to a cloud-managed database like Azure SQL Database.
It seems there is no difference in the use cases between them:
Like various NOSQL databases SQL (in general) allows partitioning keys.
I can add cores in Azure to increase the performance as needed, I can also switch to Hyper-scale if I have an elastic workload.
I can have read replication across multiple nodes over multiple availability zones (geo-locations)
I can configure data replication in Azure SQL Database too.
It seems to me that a cloud SQL database covers all the use cases the newer distributed databases cover, so why would I want to use a newer product ?
Isn't Azure SQL Database basically a distributed database server ?
Am I missing something ?
Is Azure SQL Server a Distributed SQL database?
No.
Like various NOSQL databases SQL (in general) allows partitioning keys.
Partitioning in NoSQL databases like Cassandra (and Azure Table Storage) is about distributing partitions to physically distinct nodes, and requires rows to have an explicitly set partition-key value.
Cassandra nodes are physically different machines that can run independently, which gives it excellent resiliency.
Partitioning in SQL Server, Azure SQL, and Azure SQL Managed Instance is about dividing data up into row-groups that exist in the same server for performance, not resiliency.
On on-prem MS SQL Server, these row-groups (well, partitions) can exist in different FILEGROUPs, which means they can exist in different storage volumes to avoid IO bottlenecks, but Azure SQL does not support multiple FILEGROUPs.
The benefits of implementing partitioning, including on Azure SQL, are documented online - and the article explains how it's about performance, not resilience.
I can add cores in Azure to increase the performance as needed, I can also switch to Hyper-scale if I have an elastic workload.
This fact has absolutely nothing to do with distributed databases.
I can have read replication across multiple nodes over multiple availability zones (geo-locations).
I can configure data replication in Azure SQL Database too.
Replication isn't the same thing as a true distributed database:
In Cassandra and other distributed databases, all clients can connect to all nodes and accomplish the same tasks; and you can arbitrarily add and remove nodes while the system is running.
In SQL Server and Azure SQL's replication feature, the replica is strictly a "secondary" that is subordinate to your primary server.
Clients can connect to either the secondary or the primary, but the secondary server can only perform read-only queries, whereas if a client wants to do DML (INSERT/UPDATE/DELETE/MERGE) or DDL (CREATE/ALTER) then the client must connect to the primary server.
It seems to me that a cloud SQL database covers all the use cases the newer distributed databases cover, so why would I want to use a newer product?
It can't: because Azure SQL is not a distributed database it cannot allow any client to read and write to any node or endpoint and have that change replicated to all other nodes (using an eventual consistency model). Instead, Azure SQL requires writes to be performed by the single primary "server".
Note that an Azure SQL "server" or logical server is largely an abstraction that hides what Azure SQL really is: a distinct build of SQL Server's engine that runs in a high-availability Azure Service Fabric environment (which is how cores/RAM can be added and removed while it's running and provides for some kind of local resilience against hardware failure) in a single Azure datacenter.
I would like to know what extra benefits one get by choosing Azure SQL Managed Instance compared to Azure SQL DB PaaS. I know SQL Managed Instance is offered as a vCore based purchasing model only. Apart from this what is the extra add on and benefits that one gets over the other. Any reply would be appreciated.
With Azure SQL Managed Instance, you essentially get a full fledged SQL Server that you can control any way you want, just like you would control a locally configured SQL Server. All the power and access and customization you want.
With, Azure SQL DB PaaS, you are essentially getting a database service, so, you give up a lot of control.
For example, take server collation. With the database service, SQL_Latin1_General_CP1_CI_AS , is all you get. With the Managed Instance, its your server. So, go ahead and select whatever collation you want, just like how you would select the collation at the time of creatoin.
Another issue is with auditing, if that is something that is important to your setup. with SQL Managed Instance, auditing happens at server level, because, you are getting the full database server. With the database service, it only database, because, you are only getting a database.
These are just the main details that I found. more details here at this Azure doc - https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Of course, Managed is going to cost you more because you are paying for the license of the SQL server too.
Lastly, for me, this is the almost (not the exact same thing) like you running your own File Server on a Windows VM on Azure (Managed Instance) versus, just using Blob Storage. In both cases, you are just trying to store some files, but its how much control you have.
I would say think about Azure SQL DB vs Azure SQL Managed Instance (MI) as
Azure SQL DB = Resources dedicated to individual DBs like a container. They are grouped under a Azure SQL Server but that SQL Server is just for grouping.
Azure SQL MI = Almost same as on-prem SQL Server except you don't have to worry about OS, backups, high availability.
Here is a good comparison.
https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Hopefully this will help
Azure SQL Database - The usual PaaS way. You have vCore, DTU, and Serverless billing mode. And Elastic pool support.
Azure SQL Managed Instance - Similar as below. When you want to use instance-scoped features of Azure SQL Managed Instance like Service Broker, CLR, SQL Server Agent, and Linked servers. As if you have an SQL Server on premise, Azure is responsible for patching, upgrading version etc.
SQL Server on Azure Virtual Machines - Similar as above. But you are responsible for OS and SQL server upgrade.
I've always thought Azure SQL DB is a single product and hence a single resource on Azure.
However i noticed that when creating an Azure SQL DB instance, it creates a SQL Server resource and a SQL Database resource in my resource group.
What's the relationship between them?
Any documentations on this?
You have to create an Azure SQL server resource in order to have the SQL Database resource (since one is dependent on the other).
You can create a new instance or reuse existing instance. things like firewalls, backups, etc are tied to the db instance to some extent
I was unable to find a specific document that talks about this, but the topic covering creating a database covers the server as well: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-single-database-get-started?tabs=azure-portal
For example, this article covers single server limits: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-resource-limits-database-server#maximum-resource-limits
Link to documentation on understanding the relationship between SQL server (parent) and SQL database resources on Azure: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-servers
In Azure PAAS , When I create a SQL Database , it asks me to create a SQL Server why is this? Also as there are elastic pools why need a SQL Server?
Azure SQL Database and SQL Server PAAS - why need both?
Before answer this, let's see what is an Azure SQL logical server.For more information about Azure SQL logical server, please refer to this tutorial.
A logical server acts as a central administrative point for multiple single or pooled databases, logins, firewall rules, auditing rules, threat detection policies, and failover groups. A logical server can be in a different region than its resource group. The logical server must exist before you can create the Azure SQL database. All databases on a server are created within the same region as the logical server.
So the Azure SQL server is the dependency of the azure database. If you want to create an Azure sql database, an existing Azure SQL server is required. It is similar to a SQL Server instance that you may be familiar with in the on-premises world.
I have a "pay as you go" Azure subscription. I am trying to keep costs down.... Do I need the resource "SQL Server" when using the SQL database resource? As I read all the supporting documents SQL Server will be used on Azure VMs to extend on-premises SQL Server. I am not doing this, I am hosting a web application on the Cloud services (Classic) resource that is connecting to the Azure SQL database.
Thanks for the help!
Azure SQL Database gives you most of the functionalities of a "Standard" SQL Server database and is (in most cases) the choise with the lower costs.
It also provides you a set of additional functionalities (some of them needs to be enabled first or are part of the higher service tiers) like an out of the box 3-node failover cluster, geo-redundancy, automated backups, etc.
If you need additional SQL Server features like SQL Server Analysis Services, which are not part of Azure SQL DB or aren't provided as another Azure service, you need to create a Virtual Maschine with a real SQL Server installed.
The "SQL Server", which is hosting your Azure SQL DB, is just a wrapper and provides you only minimal features like user and role management or your firewall settings.
If your application is connecting only to Azure SQL database and using its features, you don't need SQL Server license. You just need to have the Azure subscription and pay for the SQL database(s) that you are using. However when you create an Azure SQL database, it will prompt you to create a "Server" resource which acts as a logical group for all of your SQL databases that you create within that "server". This server is NOT charged separately and just provides a logical grouping as well as a common connection point for your SQL databases. Your billing is always based on the SQL Database(s) that you create and use.
hope this helps.
Srini Acharya