Performance impact of the three typical storage models(Projectivity=0.01) -The execution time when running workload 1(left) and workload 2(right).

Performance impact of the three typical storage models(Projectivity=0.01) -The execution time when running workload 1(left) and workload 2(right).

Source publication
Preprint
Full-text available
Large-scale data-intensive applications need massive real-time data processing.Recent hybrid DRAM-PM main memory database systems provide an effective approach by persisting data to persistent memory (PM) in an append-based manner for efficient storage while maintaining the primary database copy in DRAM for high throughput rates.However, they can n...

Contexts in source publication

Context 1
... Fig. 1, we demonstrate previous research [37]. We create a database containing a single table RT(a 0 ,a 1 ,a 2 ,...,a 500 ) that consists of 500 attributes. Each attribute a k holds a random integer value. During initialization, we load 1 million records. Two types of queries are considered: scan(select a 0 ,a 1 ,a2,...,ak from R where a 0 < ...
Context 2
... depicted in Fig. 1(left), the row-store storage model demonstrates superior performance compared to the column-store layout, achieving up to a 1.2× ...
Context 3
... as the number of insert queries increases, the performance gap increases. This is because the column-store must split a record's attributes during each insert operation and store them in separate memory locations. For the scan queries, the results are shown in Fig. 1(right). We see that column-store executes the scan query up to 1.6× faster than row-store. The better performance is attributed to the column-store's enhancement of cache efficiency and bandwidth utilization through the exclusion of unnecessary ...
Context 4
... level. Compared with Stock-Level, it reads more heavily. In this transaction, we set the ratio of CH-Q2 at 50% to measure the overall throughput and latency. In addition, because the majority of accesses of Stock-Level and CH-Q2 are in the item table and stock table, those transactions will frequently conflict with New-Order and each other. In Fig. 10, this experiment examines how the four storage models perform on the three most important workloads in practice: point lookup, update, and scan. Fig. 10 shows the throughput of the systems in these workloads with 20 threads. We see that Index-Organized outperforms the other three storage models in all workloads. Row-layout, ...
Context 5
... In addition, because the majority of accesses of Stock-Level and CH-Q2 are in the item table and stock table, those transactions will frequently conflict with New-Order and each other. In Fig. 10, this experiment examines how the four storage models perform on the three most important workloads in practice: point lookup, update, and scan. Fig. 10 shows the throughput of the systems in these workloads with 20 threads. We see that Index-Organized outperforms the other three storage models in all workloads. Row-layout, column-layout, and row+column all implement a heap-based organization that absorbs more writes, resulting in poor read performance. For range scan, Index-Organized ...
Context 6
... Fig. 11, we measure the overall throughput and abort rate in TPC-C with one warehouse and 20 warehouses, respectively, using 20 threads. Note that IndexOrganized achieves up to 2× higher throughput than the other storage models. New Order transactions are dominated by primary key accesses, i.e., lookup and update operations. Index-Organized ...
Context 7
... section provides a high-level view of the system's performance on different workloads. It shows that Index-Organized can perform well in all representative workloads because it minimizes the number of random memory accesses. Fig. 12 shows the impact of read and write workloads on Index-Organized and other storage models. The number of concurrent threads is 20. As expected, for all storage models, the throughput is lower with more write operations. This is because we adopt the "first-updater-wins" rule; the majority of write conflicts are identified when the ...
Context 8
... section examines the scalability of Index-Organized and conventional storage models (i.e., row-store, column-store, and row+column) with YCSB and TPC-Chybrid workloads. Fig.13 uses the YCSB workloads and varies the number of work threads. ...
Context 9
... write-intensive workloads, conventional storage models suffer from central memory heap management, achieving 1.5× lower throughput than Index-Organized. Fig.14 shows the overall throughput and abort rate of TPC-C-hybrid workloads when varying the number of work threads. ...
Context 10
... this section, we perform latency analysis. Fig. 15 shows the latency of TPC-CH-Q2 over a varying number of warehouses with 20 work threads. We calculated the average transaction latency within a run and presented the median value from three runs in the figure. At the low warehouse count, Index-Organized has a similar latency performance to the conventional storage models. This is ...
Context 11
... as the number of active versions increases, index-only scans gain importance because they can reduce unnecessary main memory accesses. However, for conventional storage models, each version access may incur more than four random main memory accesses (tree searches, indirection searches, mapping table searches, and version chain searches). Fig. 16 shows the flamegraph [63] of the Index-Organized for the TPC-C-RC workload. Tree index searches take roughly 70% of the time, involving multiple inner node searches and one leaf node search. Searching the leaf node first loads the record meta for keys, then binary searches the keys to find the request key, and finally searches the ...
Context 12
... requiring only one memory access. The version chain searches use only 10.5% of the time. This is because an update transaction (New-Order) does not need to access version chains, while a long-running transaction (CH-Q2) can benefit from cache prefetching, spending less time accessing main memory. row-store column-store row-column index-organized Fig. 16 Time spent on different components of Index-Organized-Recreated from the flamegraph for better ...
Context 13
... seen in 4.6, the versions accumulate quickly over time, slowing down the readers. Fig.17 shows that the scan time of the CH-Q2 query thread is highly affected by concurrent New-Order transaction threads. ...
Context 14
... shown in Fig. 18, the overall throughput peaks when the duration is 10 s. This is because the server's memory utilization reaches 50% due to new versions being inserted continually. The memory usage contention becomes the limitation of the system's overall performance. In logging-PM mode, the Index-Organized 's throughput keeps growing slowly until the ...

Similar publications

Preprint
Full-text available
In this paper, we propose a compact data structure to store labeled attributed graphs based on the k2-tree, which is a very compact data structure designed to represent a simple directed graph. The idea we propose can be seen as an extension of the k2-tree to support property graphs. In addition to the static approach, we also propose a dynamic ver...