As per title, I am confused with the new service tiers for azure SQL.
I understand that the current pricing for Web and Business is actually calculated based on the actual size stored on the server. But I am confused with the new service tiers, which is basic,standard and premium.
As from here, http://azure.microsoft.com/en-us/pricing/details/sql-database/#basic-standard-and-premium, they are saying, for example, a STANDARD tier database will cost me ~$20(preview price with 50% discount).
My question is, if I create two database with STANDARD tier(which can support up to 250GB), but with 5GB each, will it be billed as $20/DB(which will cost me $40) or $20 for two DB(since its not exceeding the limit of 250GB)? ps. I do used the pricing calculator that provided here, http://azure.microsoft.com/en-us/pricing/calculator/?scenario=data-management. but it just sound weird and ridiculous to me if I created a database with only 1-2gb but paying $20(which may be increased to $40) for each DB. I just need some clarification. thanks.
Cheaper and much slower. Azure SQL Database just became not useful for small databases that want high performance.
You will pay 2 x $20 so $40 (preview price). It is largely no longer based on database size but other performance metrics. For low usage databases you could use the basic tier which is cheaper.
Related
I have to decide to use an Azure SQL Data Warehouse or a SQL Data warehouse based on Microsoft SQL Server virtualized on a VM.
The problem what i do not understand is the MAX CONCURRENT QUERIES LIMITATION TO 32. The same for the Azure SQL Database is 6400.
To be honest when i want to use the Azure Data Warehouse in an Enterprise environment the 32 concurrent queries are laughable or i do not understand it.
Lets assume a company with 10.000 Employees worldwide and i set up a Azure Data Warehouse for reporting purpose where lets assume 250 permanently are querying from or additional 250 employees are working with a business app which uses data from the Data Warehouse. How should this work without extreme performance lacks?
This isn't the issue that you might think.
First, the limit is now 128. (https://learn.microsoft.com/en-us/azure/sql-data-warehouse/memory-and-concurrency-limits#gen2-1)
Second, this is well above the concurrency of the next most concurrent single cluster warehouse. I've often wondered what marketing mistake was made by Microsoft that concurrency is seen as a limitation on ASDW, but rarely mentioned for less concurrent competitors.
Third, the best way to serve thousands of concurrent query users (ie, dashboards) is through PowerBI hybrid queries, and (potentially) Azure Analysis Services. This gives extremely high concurrency and interactivity.
Perhaps the best evidence I can give is that I work with Azure SQL Data Warehouse customers on a daily basis. I often get questions like this when a customer is first exposed to ASDW, but I never get questions about concurrency by the time they're in production. In other words, the issue of "concurrency" just isn't important for most customers.
I am working on a solution architecture and am having hard time choosing between Azure SQL DB or SQL DW.
The current scope involves around developing real-time BI reporting solution which is based on multiple sources. But in the long run the solution may be extended into a full fledged EDW and Marts.
I initially thought of using SQL DW so that for future scope the MPP capabilities could be used. But when I spoke to a mate who recently used SQL DW, he explained that the the development in SQL DW is not similar to SQL DB.
I have worked previously on Real Time reporting with no scope for EDW and we successfully used SQL DB. With this as well we can create Facts and Dimension and Marts.
Is there a strong case where I should be choosing SQL DW over SQL DB?
I think the two most important data points you can have here is the volume of data you're processing and the number of concurrent queries that you need to support. When talking about processing large volume data, and by large, I mean more than 3tb (which is not even really large, but large enough), then Azure SQL Data Warehouse becomes a juggernaut. The parallel processing is simply amazing (it's amazing at smaller volumes too, but you're paying a lot of money for overkill). However, the one issue can be the simultaneous query limit. It currently has a limit of 128 concurrent queries with a limit of 1,000 queries queued (read more here). If you're using the Data Warehouse as a data warehouse to process large amounts of data and then feed them into data marts where the majority of the querying takes place, this isn't a big deal. If you're planning to open this to large volume querying, it quickly becomes problematic.
Answer those two questions, query volume and data volume, and you can more easily decide between the two.
Additional factors can include the issues around the T-SQL currently supported. It is less than traditional SQL Server. Again, for most purposes around data warehousing, this is not an issue. For a full blown reporting server, it might be.
Most people successfully implementing Azure SQL Data Warehouse are using a combination of the warehouse for processing and storage and Azure SQL Database for data marts. There are exceptions when dealing with very large data volumes that need the parallel processing, but don't require lots of queries.
The 4 TB limit of Azure SQL Database may be an important factor to consider when choosing between the two options. Queries can be faster with Azure SQL Data Warehouse since is a MPP solution. You can pause Azure SQL DW to save costs with Azure SQL Database you can scale down to Basic tier (when possible).
Azure SQL DB can support up to 6,400 concurrent queries and 32k active connections, where Azure SQL DW can only support up to 32 concurrent queries and 1,024 active connections. So SQL DB is a much better solution if you are using something like a dashboard with thousands of users.
About developing for them, Azure SQL Database supports Entity Framework but Azure SQL DW does not support it.
I want also to give you a quick glimpse of how both of them compare in terms of performance 1 DWU is approximately 7.5 DTU (Database Throughput Unit, used to express the horse power of an OLTP Azure SQL Database) in capacity although they are not exactly comparable. More information about this comparison here.
Thanks for you responses Grant and Alberto. The responses have cleared a lot of air to make a choice.
Since, the data would be subject to dash-boarding and querying, I am tilting towards SQL Database instead of SQL DW.
Thanks again.
I am trying to migrate my ASP (IIS) +SQLServer application from SQL Server Express Edition to Azure SQL database. Currently, we only have one dedicated server with both IIS and SQL express edition on it. The planned setup will be ASP (IIS) on an Azure virtual machine and Azure SQL database.
Per my search on google, it seems SQL server Express Edition has performance issues which are resolved in standard and enterprise edition. The DTU calculator indicates that I should move to 200 DTUs. However, that is based on test run on SQL Express edition setup with IIS on the same dedicated server.
Some more information:
The database size is around 5 GB currently including backup files.
Total users are around 500.
Concurrent usage is limited, say around 30-40 users at a time.
Bulk usage happens for report retrieval during a certain time frame only by a limited number of users.
I am skeptical to move to 300DTUs given the low number of total users. I am initially assuming 100 DTUs is good enough but looking for some advice on someone who has dealt with this before.
Database size and number of users isn't a solid way to estimate DTU usage. A poorly indexed database with a handful of users can consume ridiculous amounts of DTUs. A well-tuned database with lively traffic can consume a comparatively small number of DTUs. At one of my clients, we have a database that handles several million CRUD ops per day over 3,000+ users that rarely breaks 40DTUs.
That being said, don't agonize over your DTU settings. It is REALLY easy to monitor and change. You can scale up or scale down without interrupting service. I'd make a best guess, over-allocate slightly, then move your allocated DTUs up or down based on what you see.
it seems SQL server Express Edition has performance issues
This is not correct.There are certain limitations like 10GB size,one core CPU and some features are disabled ..
I am initially assuming 100 DTUs is good enough but looking for some advice on someone who has dealt with this before.
I would go with the advice of DTU calculator,but if you want to go with 100 DTU's,i recommend going with it ,but consistently evaluate performance..
Below query can provide you DTU metrics in your instance and if any one of the metrics is consistently over 90% over a period of time,i would try to tune that metric and finally upgrade to new tier,if i am not successfull
DTU query
SELECT start_time, end_time,
(SELECT Max(v)
FROM (VALUES (avg_cpu_percent), (avg_physical_data_read_percent), (avg_log_write_percent)) AS value(v)) AS [avg_DTU_percent]
FROM sys.resource_stats
WHERE database_name = '<your db name>'
ORDER BY end_time DESC;
-- Run the following select on the Azure Database you are using
SELECT
max (avg_cpu_percent),max(avg_data_io_percent),
max (avg_log_write_percent)
FROM sys.resource_stats
WHERE database_name = 'Database_Name'
For Azure SQL Database pricing, the pricing is mentioned as $x/hour
Question: Let's say that 'x' is $2/hour. If I create 10 different user databases for my application, will I pay 10 times the hourly cost i.e. $20/hour or will I pay just $2/hour since the cost is for a database server?
I am not sure if I will be charged for each user-created database i.e. each of these 10 databases or just for one database server.
You will be charged for each user-created database i.e. each of these 10 databases depending of their pricing tier.
http://azure.microsoft.com/en-us/pricing/details/sql-database/
A new service plan was announced 04/2015, called SQL Azure Elastic database pool. As of today, it is still in preview mode, but pricing is available here -- make sure you click on Elastic Database button to see the prices.
With Elastic database pool the pricing model is as follows. First, you pay per pool, based on number of performance units you reserve for the pool (DTUs). Then you pay additionally for each database, which is part of the pool. The per-database price is quite small (currently around $1.26/mo), so most of your expenses will be a payments for DTUs, that are shared across all databases of your pool.
UPDATE:
As of May 2016, Azure SQL Database elastic pool is generally available. The pricing details are also updated. As of today, you can get up to 200 databases in Basic Tier for $149/month, which boils down to $0.745 per month per database.
The pricing for Azure SQL Database is per database. This means you would be paying for each of the 10 databases. You can learn more about Azure SQL Database pricing here.
We want to create multitenant application with shared database table structure.
Currently with standard SQL Server we could achieve that with providing TenantID for each table.
Could we achieve the same on Windows Azure, but without TenantIDs?
Best regards,
Alexey Zakharov
I would think you'd want to do the same thing (use a TenantID column in SQL Azure or in Windows Azure tables).
I concur with the answer smarx gave you, but also consider this: If you have multiple tenants and this drives you above a SQL Azure size limit (say, 1GB or 10GB), you'd need to make a jump to the next-larger database, and this could increase your cost beyond what you want:
1GB: $10 monthly
10GB: $100 monthly
50GB: being released in June, presumably 5x10GB cost
So in the case where you're under the 1GB limit with one tenant, but over 1GB with, say, 2-5 tenants, it would be more cost-effective to set up separate 1GB databases for each tenant, and then manage this sharding in your business tier, based on TenantID.
The question was about another thing. I want to know if Azure SQL provide multi tenant database with shared schema as a feature. – Alexey Zakharov May 21 at 6:00
The short answer is that it doesn't. SQl Azure is essentially (a large subset of) SQL Server.