Schema Design
Schema Design Flexibility
There is no need to design a specialized schema to work with Vector. Vector does not require materialized views or projections to deliver exceptional query performance so there is also no need to design these.
You can choose to use a star schema or a snowflake schema, but you can also choose the following other extreme cases that are often not feasible with other relational databases:
• Denormalize all columns into a single wide table.
• Do not make any changes to the schema you currently use and simply load the data and run queries against it.
The vectorised in-cache processing of Vector benefits computations as well as table joins. Other data access optimizations Vector transparently provides include:
• Column-based storage: queries only access relevant table columns.
• Min-max indexes: based on the query’s filter criteria, either explicit as part of the query definition, or implicit based on table joins or sub-select statements, Vector identifies candidate data blocks. If there is a correlation between the order in which data is added to the database and the data values (time-based data is an obvious example) then the min-max indexes may filter large amounts of data blocks very efficiently. In extreme cases min-max indexes provide the same performance benefit that partition elimination provides for other databases.
• Compression: by default, data is stored in a compressed format so that it takes less time to read the data from disk.
The combination of column-based access and min-max indexes can make queries against a single large denormalized table extremely efficient for some workloads. Because of efficient data compression, the storage overhead caused by denormalization may be minimal depending on the data.