Skip to main content
Announcements
NEW: Seamless Public Data Sharing with Qlik's New Anonymous Access Capability: TELL ME MORE!
cancel
Showing results for 
Search instead for 
Did you mean: 
Ameya09
Partner - Contributor III
Partner - Contributor III

Benefit of each data management levels

I was going QDC documents and found below info regarding data levels. I have few questions regarding it.

Managed stores entire data in QDC as well as metadata

Registered stores only sample data and the metadata in QDC

Addresses stores only the metadata and does not provide profiling and validation metadata.

 

Questions:

What is the benefit of storing entire data in QDC as in managed?

When should registered be preferred over managed? If client has lower configuration(8 core,32 gb ram) ,only then registered should be suggested?Or is it based on pattern of usage of QDC ?

What are the use cases of addressed data level? What are its benefits over the other two levels?

 

Thanks,

Ameya

 

Labels (1)
1 Solution

Accepted Solutions
Christopher_Ortega

Ameya,

Great observations and questions.  You are correct about the attributes of entities stored at each level.

Managed - Data, profile, and sample all in Catalog

Registered - Profile and sample in Catalog

Addressed - Technical metadata (schema) in Catalog

The benefit of having data at each of these levels is that an organization can Catalog and document ALL of their data assets without incurring the burden of keeping a resident copy of it all in the Catalog.  For infrequently utilized sources, addressed can be an option.  A good example might be tables that are needed once a year for audit purposes.  These can be promoted to managed when needed and then demoted when you are done.  They are still in the Catalog but the data isn't resident.

Registered is an enhancement between addressed and fully managed, allowing you to keep a profile and sample data to further enhance end users' understanding of the entity.  When utilized for a publish or prepare activity these registered entities are temporarily promoted to managed in order to operate on them.  As such, the consideration between keeping something registered or managed comes down to how often they are utilized.  If there are lots of requests to use a registered entity you may want to consider making it a managed entity so that you can load it once and use it often.

Of course, depending on the usage patterns and the mix of registered and managed entities, system configuration and storage need to be taken into account.

I hope this helps.

View solution in original post

2 Replies
Christopher_Ortega

Ameya,

Great observations and questions.  You are correct about the attributes of entities stored at each level.

Managed - Data, profile, and sample all in Catalog

Registered - Profile and sample in Catalog

Addressed - Technical metadata (schema) in Catalog

The benefit of having data at each of these levels is that an organization can Catalog and document ALL of their data assets without incurring the burden of keeping a resident copy of it all in the Catalog.  For infrequently utilized sources, addressed can be an option.  A good example might be tables that are needed once a year for audit purposes.  These can be promoted to managed when needed and then demoted when you are done.  They are still in the Catalog but the data isn't resident.

Registered is an enhancement between addressed and fully managed, allowing you to keep a profile and sample data to further enhance end users' understanding of the entity.  When utilized for a publish or prepare activity these registered entities are temporarily promoted to managed in order to operate on them.  As such, the consideration between keeping something registered or managed comes down to how often they are utilized.  If there are lots of requests to use a registered entity you may want to consider making it a managed entity so that you can load it once and use it often.

Of course, depending on the usage patterns and the mix of registered and managed entities, system configuration and storage need to be taken into account.

I hope this helps.

balbasorus
Contributor
Contributor

Luckily it's much simpler than that. I just see it pop up a lot as part of the whole data management space but I don't know why or when it would be appropriate. That said, I've never worked in enterprise...