Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.
Is anyone familiar with the note below regarding the use of a single P2 Premium node in comparision to the use of two P1 Premium nodes that are provisioned as a single capacity?
https://docs.microsoft.com/en-us/power-bi/service-premium-what-is#capacity-nodes
"Note
Using a single larger SKU (e.g. one P2 SKU) can be preferable to combining smaller SKUs (e.g. two P1 SKUs). For example, you can use larger models and achieve better parallelism with the P2."
As I understood it per the below link, Premium nodes should just show up as an amount of vcores to allow for provisioning of capacities.
Is anyone familiar with the reasoning as to why this note suggests larger models and better parallelism would be better suited using larger sku's (P2 or P3) versus combining multiple P1s together as you scale?
Thanks Greg.
That makes sense if Microsoft is provisioning those resources upfront based on the size of node purchased rather than based on the capacity size chosen by the Power BI admin during the provisioning of the capacity. I was under the impression that each node purchase just added additional vcores to your vcore pool which you can then use to provision capacities in the admin portal, similiar to the snapshot image below.
It seems strange that the quantity and size of node (P1, P2, P3, etc.) is abstracted from the admin yet it could impact scalability and parallelism for data models that would exceed the memory capacity of a single P1 node.
Thanks Greg.
I guess my question still stands. Based on the information in the configure and manage link, it discusses provisioning of different size capacities (P1, P2, P3, EM1, EM2, EM3) from a pool a vcores. In some examples it shows 3 of 20 vcores used and in another it shows 8 of 17 vcores used, etc. so there is no clear definition of what was purchased in regards to node quantity or sizes, just a total vcore pool which is obviously comprised of a variety of node sizes that were purchased in order to equate to the odd vcore totals shown such as 20 and 17.
So my concern comes down to the fact that there is no way to keep track of the purchased node quantity and sizes in order to align that appropriately to provisioned capacity size. The scenario that I'm concerned with is that if I purchase a P1 (8 vcores) now and then another P1 (8 vcores) in the future due to scaling requirements, my expectation would be that if I resized my existing capacity to use both of these P1s together I would have a single capacity with 16 vcores yet from the original note that started this thread, it seems I would in fact be left with a capacity defined as 16 cores but behind the scenes Microsoft would have 2 - 8 vcore nodes supporting my single capacity. My expectation would be that provisioning the P1s together as a single capacity would yield the exact same resources as if I had purchased a P2 originally.
Looking back at old Guy-in-a-Cube videos, the below video discusses this exact topic. Adam Saxton discusses how purchasing Premium is just purchasing vcores which we then use to provision capacities in the Power BI admin portal.
https://www.youtube.com/watch?v=8AJbbdE0uKQ
Based on Adam's video, in my opinion the below note in the docs is not accurate. There should be no diffence when provisioning a single capacity using a single P2 purchase (16 vcores) vs. a single capacity that combines two P1 purchases together (8 vcores + 8 vcores)
https://docs.microsoft.com/en-us/power-bi/service-premium-what-is#capacity-nodes
"Note
Using a single larger SKU (e.g. one P2 SKU) can be preferable to combining smaller SKUs (e.g. two P1 SKUs). For example, you can use larger models and achieve better parallelism with the P2."
Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City
Check out the April 2024 Power BI update to learn about new features.
User | Count |
---|---|
60 | |
20 | |
18 | |
18 | |
9 |