3 ms·
>>if you can describe your access patterns as consisting mostly of table scans (or at least large index scans), rather than seeks, you will likely be able to fi
by ljw1001 10y ago
>>if you can describe your access patterns as consisting mostly of table scans (or at least large index scans), rather than seeks, you will likely be able to find benefit from a columnstore engine.
I think this is very accurate for first generation column stores, but some of the newer research systems are addressing this issue with technologies like behind-the-scenes indexing.
- greggyb 10y agoThis is interesting to me. What is the indexing strategy that is utilized? To me the challenge is that the values making up a row are stored non-contiguously. The best case scenario is that a row of N fields requires N data accesses. This is assuming that you can index directly into an array or similar structure with constant access time. Row-based storage means that you get all fields for "free"when accessing a single row, since the DB engine accesses a page at a time. This is my understanding of the problem - I am very interested to learn what I'm missing if you have any good articles to share.
- neeleshs 10y agoHBase + Phoenix is the closest I know of. Though, the cost of covered indexes is duplication. Phoenix also provides local/global indexes, giving an optimization choice b/w read heavy vs write heavy patterns
- greggyb 10y agoInteresting. Do you have any articles to point to explaining the strategy? If not, I can go digging myself now with direction. Thanks!