![]() In that case, the value of SSAS is the semantic layer (i.e., if you have users connecting to the data source and developing their own reports, it is significantly easier for users to navigate an SSAS model where everything is organized and no joins are required). If you've invested time creating clustered columnstore indexes, partitions, or other query tuning efforts in the underlying database engine, you may be inclined to utilize the source database for live query activity. Relational Database Highly Tuned for Ad Hoc Queries. In the absence of model processing, SSAS would have much less CPU and memory demands when running in DirectQuery mode (and conversely, the underlying DB engine needs to be beefier). Therefore, for large datasets that are difficult to fit in memory, DirectQuery can be appealing. The rule of thumb for storing data in a Tabular in-memory model is to have 2.5x memory, so if your in-memory model size is 50GB, you would require about 125GB of RAM on the server. Another situation to consider DirectQuery is if your server doesn't have enough memory to store all of the data. Large Datasets Which Exceed Memory Available. ![]() In this situation, you'll want to plan for how to handle contention of read and write activity. Because there's no processing time associated with populating data in SSAS, there's less delay in making data available. Low latency for data availability is the primary use case for DirectQuery. However, there are some specific situations where DirectQuery is a viable option. Most SSAS Tabular models do run in In-Memory mode. Use Cases for SSAS Tabular in DirectQuery Mode Note that the entire SSAS Tabular model is specified as one of the two modes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |