Reputation: 40022
Would partitioning a SQL Server database across separate page blobs (Azure Data Disks) have a performance impact when querying partition 1
if partition 2
is under heavy load?
I understand the page blobs aren't necessary separate physical disks, so I'm wondering about the performance.
Context edit: Basically I want to partition old (archive) data away from the live data (so everything over 3 months old) to reduce the database and index size. But this archive data must still be queryable.
Upvotes: 0
Views: 519
Reputation: 2210
This is definitely an "it depends" answer and will take some testing on your part.
The 2012 Scalability Targets show a blob at about 60 MB/sec while the VM sizes show an Extra Large instance gets 800 Mb/sec - the target throughput is obviously dependent on your usage, so you may or may not be able to get close to that figure and if you can, you're probably saturating your allotted bandwidth so absolutely no point going any further.
I'd be inclined to go with a basic configuration of each database instance getting 1 drive for data, 1 drive for logs. If you still have any headroom on your network then you can look at partitioning further as appropriate.
Alternatively, you could perhaps look at using Data Compression if your issue is with how fast you're able to retrieve data from the blob underlying your azure drive...
Upvotes: 1
Reputation: 5249
If your query doesn't need to fetch data from Partition 2 I suspect the impact would be minimal. However if your objective is to improve performance did you consider creating a RAID 0 (stripe) with blobs?
Upvotes: 1