Complexity Tamed

Complexity Tamed

Ancelus isn’t limited by a pre-defined storage structure. The logical structure of an Ancelus schema is the entity-relation diagram, even if it maps to n-dimensional hypercubes. The physical storage model of Ancelus is…well, it’s complicated. But the limits imposed on the logical model by the physical model are gone. The good news is you don’t need to worry about it.

In structured data storage of all kinds, your job is to map the transform between the real world and the two-dimensional table (or column) structures. This transform drives most scale and performance problems. Since there can be only one in these systems, you pick the least worst…not a ringing technology endorsement.

Ancelus lets you deploy multiple definitions in the same structure. If streaming and query need different logical models, do that. No need to have the normalization debate to decide what to compromise.

In fact, there are 15 development tasks that Ancelus developers simply skip. They’re automated, integrated or eliminated.

Find Your Hardest Problem And Skip it!!

Tasks Ancelus developers DON’T DO:

• No table design step (optional)
• No add-on data marts, secondary schemas, master data management
• No normalization debate, 100% normalized + 100% de-normalized at the same time
• No “where-used” search
• No data duplication for foreign keys or concatenated keys
• No insert vs. retrieval performance trade. Eliminates “no-schema” patch
• No column compression to reduce scarcity
• No downtime for garbage collection
• No downtime for maintenance
• No downtime for re-indexing
• No downtime to re-balance the binary tree
• No downtime for schema changes
• No downtime for re-sharding
• No downtime for re-defining or reloading hypercubes
• No downtime for distributed data re-synchronization