Data modelling and DAX
An established modelling technique for a large numeric column you mostly SUM. Lower-cardinality components can reduce memory and loading costs, but smaller dictionaries do not guarantee cheaper queries. Here is the recipe and what to measure before keeping it.
An optimisation has shipped in the Power BI semantic model engine that cuts the time spent preparing a query that uses calculation groups. It happens before any data is read, so it will not speed up your scans. Some models will barely notice. Models with several calculation groups that reference each other could see a lot. Here is what was happening, why it was written that way, and how to work out which camp you are in.
DISTINCTCOUNT over a high cardinality transaction ID is one of the most expensive things you can ask the storage engine to do. If you understand which of your dimensions have a functional dependency on that ID, you can answer a large share of your queries with a plain COUNTROWS instead, and shrink the work for the ones that are left.
Row-level security quietly switches strategies once a table gets big enough. A recent default change moves that line from 128K rows to 512K, and the reason it is not 2 million is a nice bit of engineering.
