I am new to SSAS tabular model and DAX. We are doing a POC to check which model we should use for our system. There are currently 2 models that we are evaluating: the SSAS Tabular Model and the Multidimensional Model.
My understanding is that the SSAS Tabular Model has some size limitations, i.e. it is good for data <= 1TB as on a single server but it is limited in terms of memory usage. Is this true?
Currently our requirements call for less than 1TB of data, but that may change in the future.
I find the SSAS Tabular Model attractive due to ease of use and faster development cycles, but I would like to get some input from the community on whether this is the right choice.
Thank you,
Atul.
If you have enough money to buy requisite hardware, go for Tabular model as it is almost always faster(exceptions aside). It has the new faster Vertipaq engine which does a better job at compressing data and retrieving results. But never trust just the size of data to decide the model. There could be cases where the calculations are so complex that it overwhelms the RAM. Finally there are good bit of features which are still unavailable on tabular model, so understand those very well before making the decisions. That said, there are a lot of factors in favor of multi dimensional model too and for many practical cases it doesn't make much sense to ditch it in favor of tabular. But adopting Tabular modelling surely is looking towards the future. Hope that helps. All the best.
Today multidimensional models perform better in scalability, security and stability and they have many advanced features that are not available in tabular.
For example implementing many-to-many relationships is easier in multidimensional (only workarrounds available in tabular mode).
Besides technicalities, tabular also requires more expensive SQL Server license.
These 3 resources give quite a comprehensive analysis of the situation:
http://richardlees.blogspot.ca/2012/05/sql-server-2012-tabular-versus.html
https://sqlserverbiblog.wordpress.com/2013/06/24/ssas-tabular-models-the-good-the-bad-the-ugly-the-beautiful/
http://blogs.technet.com/b/cansql/archive/2015/01/15/mvp-series-promoting-an-excel-tabular-model-to-ssas.aspx
Related
I hope you are doing well.
I'm working on a migration from an on premise ssas multidimensionnal cube to an azure analysis services tabular model.
Is there a way , a method or a tool to do it quickly and efficiently?
It's a large cube and it will take time to develop it from scratch with tabular model.
Thank you for your help
SSAS Multi Dimensional (MD) and Tabular are fundamentally different technologies, there is no quick method of converting one to the other, you will have to rebuild the model from scratch, and the measures etc.
Be aware that some of the things MD models are good at, like calculating up and down hierarchies, Tabular really struggles with. If the cube is fundamentally sound and has good performance, and you want to move it into the cloud service, use a VM in Azure, with SQL Server on it, it may work out cheaper that Azure AS, per month.
We know that over a decade ago with very limited compute power and storage available, the invention of multi-dimensional model (cube) was to solve the above problem, e.g.SSAS. However with recent cloud technology advancement, compute power and storage are cheap, I struggle to see the point of using multi-dimensional model (cube,) in a enterprise business analytic solution?
Anyone has any other thoughts to share please?
Thank you.
Per my opinion the greatest advantage of having SSAS model in an enterprise business analytic solution is that the end user can connect to it through Excel and just drag and drop measures and dimensions and create all kinds of useful reports with all kinds of calculations that are built in the cube (year to date, rolling 12, etc...), and without this model, they will have to rely on relational database to create much of complicated SQL calculations on their own, and first of all they will have to know SQL in details to do this, so they will probably have to rely on some kind of IT stuff to help them on daily basis to do this.
In SSAS, besides multidimensional there is also a tabular model, but the answer would be the same.
I was wondering if anyone here knows the exact differences for these 2 modes, more specifically:
What can we do in one model that we can't do with the other? (Multi-dimensional vs Tabular and vice versa)
How is the data stored in one model versus another?
If I am wring an SSRS / PowerBI / Excel report against this, what limitations does one model have over the other?
Does the tabular model have cubes? If not, what is the alternative storage medium and how does it differ from cubes (maybe provide for me
some background on what cubes are to begin with)
What are the differences in security considerations? As I understand, with the Multi-dimensional model, row-level, column, level
and even cell-level security can be applied - what is available with
this for the tabular model?
Also, as I understand SQL Server 2016 is moving to using the Tabular Model by default and that there may be some differences/improvements
over what is current in use (SQL Server 2014) - can you please provide
a list of what those are?
Thank you so much in advance.
A good place to start might be these articles which should be accurate as to the differences in SSAS 2014.
Advice on the decision points for choosing to build a Tabular or Multidimensional model
Paul Turley’s high-level description of Tabular strengths and weaknesses
Dimension relationships
Summary level presentation
Many-to-many relationships and writeback and scope statements and non-visual dimension security are some of the biggest missing features in SSAS 2014 Tabular in my opinion.
Tabular security is row based and just supports visual totals, not non-visual totals or cell security. But in many cases you don't want to use cell security for performance reasons.
Tabular uses in-memory columnar storage. Multidimensional uses disk-based row-based storage. So scanning a billion row fact table requires reading all columns from disk in Multidimensional and takes a minute or two to return a query on a fact table that large. If you optimize the Multidimensional model by building an aggregation then the query may take seconds. Tabular just scans the columns used in the query and simple queries or calculations even on a billion row table may return in under a second.
With SSAS 2016 Tabular the bidirectional relationship was added which was a very big deal for modeling flexibility and allowing many-to-many relationships. And parallel partition processing made loading large models feasible.
SQL 2017 installer for SSAS has Tabular as the default.
If you have the option for using SSAS 2016 Tabular or above it is highly recommended for performance and modeling flexibility. Here is what's new in SSAS 2016 and SSAS 2017.
I am wondering whether cubes or tabular models have any advantages over star schemas other than MDX/DAX query speed. Any feedback would be very much appreciated. Thanks.
Christian
When you say "advantages over star schemas", I am assuming that you mean a Star schema in a relational database? The primary difference is the potentially orders of magnatitude difference in speed, but in the area of self-service BI, a bigger advantage of Cubes or Models is that they implement an entirely new semantic layer. They give you the opportunity to rename fields that may have obscure names in the DB, to have more useful recognisable names for the business users and hide more technical fields, that are not useful to end users. You can define reuseable Named Sets and Hierarchies that enable easier, more effective and consistent reporting.
But the two biggies for me are the speed and the business user friendly semantic layer. JK.
I have done database optimization for dbs upto 3GB size. Need a really large database to test optimization.
Simply generating a lot of data and throwing it into a table proves nothing about the DBMS, the database itself, the queries being issued against it, or the applications interacting with them, all of which factor into the performance of a database-dependent system.
The phrase "I have done database optimization for [databases] up to 3 GB" is highly suspect. What databases? On what platform? Using what hardware? For what purposes? For what scale? What was the model? What were you optimizing? What was your budget?
These same questions apply to any database, regardless of size. I can tell you first-hand that "optimizing" a 250 GB database is not the same as optimizing a 25 GB database, which is certainly not the same as optimizing a 3 GB database. But that is not merely on account of the database size, it is because databases that contain 250 GB of data invariably deal with requirements that are vastly different from those addressed by a 3 GB database.
There is no magic size barrier at which you need to change your optimization strategy; every optimization requires in-depth knowledge of the specific data model and its usage requirements. Maybe you just need to add a few indexes. Maybe you need to remove a few indexes. Maybe you need to normalize, denormalize, rewrite a couple of bad queries, change locking semantics, create a data warehouse, implement caching at the application layer, or look into the various kinds of vertical scaling available for your particular database platform.
I submit that you are wasting your time attempting to create a "really big" database for the purposes of trying to "optimize" it with no specific requirements in mind. Various data-generation tools are available for when you need to generate data fitting specific patterns for testing against a specific set of scenarios, but until you have that information on hand, you won't accomplish very much with a database full of unorganized test data.
The best way to do this is to create your schema and write a script to populate it with lots of random(ish) dummy data. Random, meaning that your text-fields don't necessarily have to make sense. 'ish', meaning that the data distribution and patterns should generally reflect your real-world DB usage.
Edit: a quick Google search reveals a number of commercial tools that will do this for you if you don't want to write your own populate scripts: DB Data Generator, DTM Data Generator. Disclaimer: I've never used either of these and can't really speak to their quality or usefulness.
Here is a free procedure I wrote to generate Random person names. Quick and dirty, but it works and might help.
http://www.joebooth-consulting.com/products/genRandNames.sql
I use Red-Gate's Data Generator regularly to test out problems as well as loads on real systems and it works quite well. That said, I would agree with Aaronnaught's sentiment in that the overall size of the database isn't nearly as important as the usage patterns and the business model. For example, generating 10 GB of data on a table that will eventually get no traffic will not provide any insight into optimization. The goal is to replicate the expected transaction and storage loads you anticipate to occur in order to identify bottlenecks before they occur.