Today I’m going to focus on a topic I suggested earlier without emphasizing: the new database architecture that uses vector processing on compressed columns to dramatically speed up performance.
The term “superinformatics” was coined to describe the extreme hardware and software optimization developed to analyze numbers in scientific applications. As these technologies developed supercomputing hardware evolving to take advantage of parallel microcomputers, software evolved to take better advantage of parallelism. Recently, microcomputers have started to incorporate specialized instructions that support advanced mathematical applications. These supercomputer instructions directly support vector algebra by manipulating bit strings, vectors, in a single instruction. Finally, application developers have recognized that these bit strings, these vectors, can be loaded into microprocessors more efficiently to optimize their applications on bare metal.
The effect of these optimizations accumulates for these applications when the vectors compress and use memory more efficiently, the vectors load more efficiently in the processor cache, and the vector instructions considerably exceed the entire instructions. The cumulative effect is that super-computer programs can be 10X-100X faster than commercial applications that provide the same result.
As this evolution progressed, a similar evolution changed the architecture of database technology. The databases actually exploited the microcomputers before the high performance space moved. But databases focused more on the benefits of massively parallel I / O than the benefits of parallel computing. The desire to minimize the cost of I / O eventually led database developers to implement column storage, and then a very interesting discovery was made. Engineers recognized that a highly compressed column, a bit string, could be treated as a vector.
Let’s see if we can make that 10X-100X number more than foam marketing. We can do this by roughly comparing the low-level processing of an entire data block and then in vector formats.
Let’s ignore the I / O processing and just focus on the internal elements. This simplification greatly favors our entire DBMS. Keep in mind that the vector DBMS will directly process the compressed vector data while the entire DBMS will spend resources to decompress the data and then take up 4 times more memory. This less efficient memory usage will increase the chances that I / O will be required and that I / O will be very expensive in the scenario we will be talking about. Even I / O over 1% of the time by the entire DBMS will provide a benefit of 1000X to 100000X for vector DBMS (see Figure 8 to assess latency on SSD or disk).
We will therefore start with whole uncompressed data compared to compressed vector data. We can assume that both databases are effective in filling the cache. But the advantage of 4X compression means that the vector processor is more likely to find data in the level 1 fast cache and in the mid-range L2 cache. Given the characteristics described in Figure 8, we could suggest that the vector database is 4X more likely to find data in the cache than the entire database and that if we assume the latency of the L2 cache as an estimate, this translates into a performance advantage of 15X-200X.
Since the data is in vector form, we can perform relational algebra and basic mathematics using vector algebra and vector addition. This gives another 8X-50X boost to the vector side.
When we combine these advantages, we see that a 10X-100X advantage is conservative. The result is clear. A columnar database that efficiently manages vectors in the cache and additionally uses super-computing instructions will greatly outperform a product based on whole numbers.
The era of database supercomputing has begun.
Leave A Comment