Where this gets interesting is when you have patterns of sparse data. Often a mix is best - AoS fails badly for partially-sparse rows, and SoA requires duplicating the key, but SoAoS only has to duplicate the key per struct, and SoAoSoA only has to duplicate it once per sequence of adjacent structs.
If you like this, you might enjoy: "Column-Stores vs. Row-Stores: How Different Are They Really?"
> The elevator pitch behind this performance difference is
> straightforward: column-stores are more I/O efficient for read-only
> queries since they only have to read from disk (or from memory)
> those attributes accessed by a query.
> This simplistic view leads to the assumption that one can ob-
> tain the performance benefits of a column-store using a row-store:
> either by vertically partitioning the schema, or by indexing every
column so that columns can be accessed independently. In this pa-
> per, we demonstrate that this assumption is false.
o11c|1 year ago
jakozaur|1 year ago
makmanalp|1 year ago
> The elevator pitch behind this performance difference is > straightforward: column-stores are more I/O efficient for read-only > queries since they only have to read from disk (or from memory) > those attributes accessed by a query.
> This simplistic view leads to the assumption that one can ob- > tain the performance benefits of a column-store using a row-store: > either by vertically partitioning the schema, or by indexing every column so that columns can be accessed independently. In this pa- > per, we demonstrate that this assumption is false.
https://faculty.cc.gatech.edu/~jarulraj/courses/4420-s19/pap...
bunderbunder|1 year ago
durner|1 year ago