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.
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'm currently running an instance of MS SQL Server 2014 (12.1.4100.1) on a dedicated machine I rent for $270/month with the following specs:
Intel Xeon E5-1660 processor (six physical 3.3ghz cores +
hyperthreading + turbo->3.9ghz)
64 GB registered DDR3 ECC memory
240GB Intel SSD
45000 GB of bandwidth transfer
I've been toying around with Azure SQL Database for a bit now, and have been entertaining the idea of switching over to their platform. I fired up an Azure SQL Database using their P2 Premium pricing tier on a V12 server (just to test things out), and loaded a copy of my existing database (from the dedicated machine).
I ran several sets of queries side-by-side, one against the database on the dedicated machine, and one against the P2 Azure SQL Database. The results were sort of shocking: my dedicated machine outperformed (in terms of execution time) the Azure db by a huge margin each time. Typically, the dedicated db instance would finish in under 1/2 to 1/3 of the time that it took the Azure db to execute.
Now, I understand the many benefits of the Azure platform. It's managed vs. my non-managed setup on the dedicated machine, they have point-in-time restore better than what I have, the firewall is easily configured, there's geo-replication, etc., etc. But I have a database with hundreds of tables with tens to hundreds of millions of records in each table, and sometimes need to query across multiple joins, etc., so performance in terms of execution time really matters. I just find it shocking that a ~$930/month service performs that poorly next to a $270/month dedicated machine rental. I'm still pretty new to SQL as a whole, and very new to servers/etc., but does this not add up to anyone else? Does anyone perhaps have some insight into something I'm missing here, or are those other, "managed" features of Azure SQL Database supposed to make up the difference in price?
Bottom line is I'm beginning to outgrow even my dedicated machine's capabilities, and I had really been hoping that Azure's SQL Database would be a nice, next stepping stone, but unless I'm missing something, it's not. I'm too small of a business still to go out and spend hundreds of thousands on some other platform.
Anyone have any advice on if I'm missing something, or is the performance I'm seeing in line with what you would expect? Do I have any other options that can produce better performance than the dedicated machine I'm running currently, but don't cost in the tens of thousand/month? Is there something I can do (configuration/setting) for my Azure SQL Database that would boost execution time? Again, any help is appreciated.
EDIT: Let me revise my question to maybe make it a little more clear: is what I'm seeing in terms of sheer execution time performance to be expected, where a dedicated server # $270/month is well outperforming Microsoft's Azure SQL DB P2 tier # $930/month? Ignore the other "perks" like managed vs. unmanaged, ignore intended use like Azure being meant for production, etc. I just need to know if I'm missing something with Azure SQL DB, or if I really am supposed to get MUCH better performance out of a single dedicated machine.
(Disclaimer: I work for Microsoft, though not on Azure or SQL Server).
"Azure SQL" isn't equivalent to "SQL Server" - and I personally wish that we did offer a kind of "hosted SQL Server" instead of Azure SQL.
On the surface the two are the same: they're both relational database systems with the power of T-SQL to query them (well, they both, under-the-hood use the same DBMS).
Azure SQL is different in that the idea is that you have two databases: a development database using a local SQL Server (ideally 2012 or later) and a production database on Azure SQL. You (should) never modify the Azure SQL database directly, and indeed you'll find that SSMS does not offer design tools (Table Designer, View Designer, etc) for Azure SQL. Instead, you design and work with your local SQL Server database and create "DACPAC" files (or special "change" XML files, which can be generated by SSDT) which then modify your Azure DB such that it copies your dev DB, a kind of "design replication" system.
Otherwise, as you noticed, Azure SQL offers built-in resiliency, backups, simplified administration, etc.
As for performance, is it possible you were missing indexes or other optimizations? You also might notice slightly higher latency with Azure SQL compared to a local SQL Server, I've seen ping times (from an Azure VM to an Azure SQL host) around 5-10ms, which means you should design your application to be less-chatty or to parallelise data retrieval operations in order to reduce page load times (assuming this is a web-application you're building).
Perf and availability aside, there are several other important factors to consider:
Total cost: your $270 rental cost is only one of many cost factors. Space, power and hvac are other physical costs. Then there's the cost of administration. Think work you have to do each patch Tuesday and when either Windows or SQL Server ships a service pack or cumulative update. Even if you don't test them before rolling out, it still takes time and effort. If you do test, then there's a second machine and duplicating the product instance and workload for test.
Security: there is a LOT written about how bad and dangerous and risky it is to store any data you care about in the cloud. Personally, I've seen way worse implementations and processes on security with local servers (even in banks and federal agencies) than I've seen with any of the major cloud providers (Microsoft, Amazon, Google). It's a lot of work getting things right then even more work keeping them right. Also, you can see and audit their security SLAs (See Azure's at http://azure.microsoft.com/en-us/support/trust-center/).
Scalability: not just raw scalability but the cost and effort to scale. Azure SQL DB recently released the huge P11 edition which has 7x the compute capacity of the P2 you tested with. Scaling up and down is not instantaneous but really easy and reasonably quick. Best part is (for me anyway), it can be bumped to some higher edition when I run large queries or reindex operations then back down again for "normal" loads. This is hard to do with a regular SQL Server on bare metal - either rent/buy a really big box that sits idle 90% of the time or take downtime to move. Slightly easier if in a VM; you can increase memory online but still need to bounce the instance to increase CPU; your Azure SQL DB stays online during scale up/down operations.
There is an alternative from Microsoft to Azure SQL DB:
“Provision a SQL Server virtual machine in Azure”
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-provision-sql-server/
A detailed explanation of the differences between the two offerings: “Understanding Azure SQL Database and SQL Server in Azure VMs”
https://azure.microsoft.com/en-us/documentation/articles/data-management-azure-sql-database-and-sql-server-iaas/
One significant difference between your stand alone SQL Server and Azure SQL DB is that with SQL DB you are paying for high levels of availability, which is achieved by running multiple instances on different machines. This would be like renting 4 of your dedicated machines and running them in an AlwaysOn Availability Group, which would change both your cost and performance. However, as you never mentioned availability, I'm guessing this isn't a concern in your scenario. SQL Server in a VM may better match your needs.
SQL DB has built in availability (which can impact performance), point in time restore capability and DR features. You have the option to scale up / down your DB based on your usage to reduce the cost. You can improve your query performance using Global query (shard data). SQl DB manages auto upgrades and patching and greatly improves the manageability story. You may need to pay a little premium for that. Application level caching / evenly distributing the load, downgrading when cold etc. may help improve your database performance and optimize the cost.
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.
This is not a traditional scale-up or scale-out question.
Please bear with me, here first allow me give an example:
I created a Sql Azure server and create a 1GB database inside, cost $9.99 a month.
(It has a master database as well, 1G, but Microsoft not charge us for that)
Ok, here is my question comes, when I need another 1G database for my application. Why I need another 1GB database? You may ask me this because the azure can support database up to 50GB. My answer is distribution, I know the data will reach 50G eventually, so I create the data model distribute and spread the data in different database.
For all the sake of performance, which option I should use:
Create another database in same server
Create another server and create a new database inside
Both option cost same.
I guess option 2 will be better, isn't it?
I'm not sure there are strong (or any) performance implications, my understanding is that the consideration is mostly a management one as some entities, mostly around security, are defined at server level and some at database level.
Behind the scenes the model is quite different anyway, and a multi-tenant one, so having separate SQL Azure server does not actually mean you get a dedicated server per-se. theoretically separate servers or separate databases may end up looking exactly the same.
I know in Sql Server, Tables per database "Limited by number of objects in a database", "Database objects include objects such as tables, views, stored procedures, user-defined functions, triggers, rules, defaults, and constraints. The sum of the number of all objects in a database cannot exceed 2,147,483,647."
My question is, whats the max number for the tables I can create in one Sql Azure Databse?
Thanks
Remus is right!
And if you are on a study, better look for size limits, because the current maximum size of an SQL Azure database is 50 GB. Which means that if your database is larger than that, you'll have to wait for new bigger limits to become available. And this is defenitely something that is not changeble via a support ticket.
Other than that you can quickly check your database for SQL Azure compatability using the SQL Azure Migration Wizard from CodePlex - an easy to use SQL Server <-> SQL Azure migration tool.
If you find yourself asking this question, then your plan is flawed. No sane design will need 2 billion objects in a database, or anything close to that.
The official Guidelines and Limitation document mentions some of the limits supported (eg. 150 databases per server). The limit you are asking for is not documented.