CDS - Performance
What is the access performance when using Core Data Services, can you make mistakes?
Table of contents
In this article we take a look at the performance of CDS views and how they behave when accessing the data. The HANA database is very fast, but not in every case. Let's take a closer look at these points.
Non HANA System
Core Data Services can be used since 7.40 SP5, including the "old" ECC systems without a HANA database. If you work on such a system, you should be careful about the performance when building data models based on CDS. A code pushdown should still be avoided here, and you should also work a lot with the keys of the table, regardless of whether they are primary keys or secondary indexes. A performance analysis is also worthwhile on such a system, since complex CDS views can quickly be slower than table accesses from the application layer.
Complexity
The complexity should be kept in mind when designing the view structure. Consumption views are mostly tailored to their application and are not intended for reuse in other applications. In such cases, a new CDS view should be defined for each application that precisely represents the application.
Furthermore, it should be ensured that the consumption view is based on interface views that have been properly implemented. So based on a table if possible and make their links available via association. Basic views with joins should be avoided because unnecessary data is read at runtime.
Calculated Fields
Calculated fields can consist of calculations or functions and do not exist in the database. You should be careful with such fields if you want to filter on them, since a lot of performance is lost here, since all records in the database must first be calculated before the filter is applied. Fields that also exist in the database are best.
The simplest example is the business partner, where the first and last name are stored in two different fields. A combined field can now be made available in the view. which the two fields provide in a full name. If the user now goes into the application and limits the quantity via this calculated field because he wants to have all surnames with "*Smith", then all data records in the database must be read, linked and evaluated. If the filter "Smith" goes to the Last Name field, then the rows with the match can be returned directly.
Authorization
We have not yet discussed the authorization concept in our series, but this also has an impact on access performance. The more complex and diverse the queries of the authorization objects are, the slower the data acquisition can be. We will go into the authorization concept in a later article.
Fast access
Why is access to a HANA database so fast, even though we may not be addressing the database key at all? You have to know that on the HANA database, every column of a table is an index as long as the table is defined as a "column store". This means that every access is against the key and is automatically fast. This is the big difference to the classic line-based database, which does not run in memory.
Conclusion
Accessing a table or a CDS view on a HANA database is incredibly fast, but as a developer you should still give some thought to building complex view structures. Just as the users end up using your application.