heimoshuiyu
046a59461e
- 创建了关于PostgreSQL JSONB性能优化的完整演示文稿 - 包含TOAST阈值问题分析、JSONB操作符性能比较 - 讨论部分更新挑战和高级优化技术 - 对比PostgreSQL JSONB与MongoDB的性能表现 - 添加了相关图表和演讲者注释
122 lines
6.8 KiB
HTML
122 lines
6.8 KiB
HTML
<!doctype html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="utf-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
|
|
|
|
<title>reveal.js</title>
|
|
|
|
<link rel="stylesheet" href="dist/reset.css">
|
|
<link rel="stylesheet" href="dist/reveal.css">
|
|
<link rel="stylesheet" href="dist/theme/black.css">
|
|
|
|
<!-- Theme used for syntax highlighted code -->
|
|
<link rel="stylesheet" href="plugin/highlight/monokai.css">
|
|
</head>
|
|
<body>
|
|
<div class="reveal">
|
|
<div class="slides">
|
|
<!-- Slide 1: Title -->
|
|
<section>
|
|
<h1>PostgreSQL JSONB Performance Optimization</h1>
|
|
<h2>A Comprehensive Survey</h2>
|
|
<p>
|
|
<small>陈永源 225002025</small>
|
|
</p>
|
|
<aside class="notes">
|
|
"Hello everyone! Today we will talk about PostgreSQL JSONB performance optimization.
|
|
Nowaday jsonb is a very import driver of PostgreSQL, postgresql became the most popular database
|
|
when the jsonb was asdd. most programming language support json. developer likes to use json.
|
|
Howevery when you trys to store json in trad database, you need to defind the schma, the relationship.
|
|
and there alwasy will be conflict between developer and DBA.
|
|
when storeaged in jsonb, you don't need to worry about the schema, That's why developer love to use json database. and we needs to understand the perform of jsonb.
|
|
</aside>
|
|
</section>
|
|
|
|
<section>
|
|
<h2>The TOAST Threshold Problem</h2>
|
|
<img src="paper/1.png" alt="TOAST Performance Degradation" style="height: 400px; margin: 0 auto;">
|
|
<div class="r-vstack">
|
|
<p><strong>The 2KB Critical Threshold</strong></p>
|
|
<ul>
|
|
<li>Before TOAST: Constant access time</li>
|
|
<li>After TOAST: Linear degradation</li>
|
|
<li>3 additional buffer reads per access</li>
|
|
</ul>
|
|
</div>
|
|
<aside class="notes">
|
|
"Let's talk about one of the most important concepts in JSONB performance: the TOAST threshold. TOAST stands for 'The Oversized-Attribute Storage Technique' - it's PostgreSQL's way of handling large data. The key thing to understand is the 2KB threshold. When your JSONB document is smaller than 2KB, access time remains constant regardless of size. But once it crosses 2KB, PostgreSQL moves the data to TOAST storage, and performance degrades linearly. Each access now requires 3 additional buffer reads: two for the TOAST index and one for the actual data. This explains why developers often report sudden performance drops when their JSON documents grow beyond this threshold."
|
|
</aside>
|
|
</section>
|
|
|
|
<section>
|
|
<h2>JSONB Operator Performance</h2>
|
|
<img src="paper/2.png" alt="JSONB Operator Performance" style="height: 900px; margin: 0 auto;">
|
|
<aside class="notes">
|
|
"This chart shows the performance characteristics of different JSONB operators in PostgreSQL. There are several ways to access data in JSONB: the arrow operator (->), the hash arrow operator (->>), subscripting, and JSON path functions. What we see here is very interesting: for small JSONB documents under 2KB, the arrow operator performs well at the root level. But as document size increases and nesting levels go deeper, performance varies significantly. Subscripting tends to be the fastest for large documents, while JSON path functions are the slowest but most flexible for complex queries. The key takeaway is that your choice of operator matters, especially for large, nested JSONB documents."
|
|
</aside>
|
|
</section>
|
|
|
|
<section>
|
|
<h2>Partial Update Challenges</h2>
|
|
<div class="r-vstack">
|
|
<div class="fragment fade-up">
|
|
<h3>Current Limitations</h3>
|
|
<ul>
|
|
<li>TOAST treats JSONB as atomic BLOB</li>
|
|
<li>Full document rewrites for small changes</li>
|
|
<li>WAL write amplification</li>
|
|
</ul>
|
|
</div>
|
|
<div class="fragment fade-up">
|
|
<h3>Emerging Solutions</h3>
|
|
<ul>
|
|
<li>Partial decompression: 5-10x faster</li>
|
|
<li>In-place updates: 10-50x improvement</li>
|
|
<li>Shared TOAST: 90% WAL reduction</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
<aside class="notes">
|
|
"One of the biggest challenges with JSONB today is partial updates. Currently, PostgreSQL treats JSONB as an atomic BLOB from TOAST's perspective. This means even if you want to update just one small key in a large JSONB document, PostgreSQL has to rewrite the entire document. This causes significant WAL write amplification - you generate much more write-ahead logging than necessary. The good news is that there are emerging solutions. Partial decompression can give us 5-10x performance improvements. In-place updates can provide 10-50x improvements. And something called shared TOAST can reduce WAL traffic by up to 90%. These optimizations are crucial for making JSONB truly efficient for OLTP workloads."
|
|
</aside>
|
|
</section>
|
|
|
|
<section>
|
|
<h2>Advanced Optimization Techniques</h2>
|
|
<img src="paper/3.png" alt="JSONB Optimization Techniques" style="height: 900px; margin: 0 auto;">
|
|
<aside class="notes">
|
|
"This slide shows various optimization techniques being developed for JSONB. The graph demonstrates performance improvements through different approaches. Key techniques include partial decompression - where only the parts of JSONB you need are decompressed rather than the entire document. Sorted-keys means sorte the key by their length, so the access time of a key is O(logN), not linear. Array slicing optimizate read of large slice. After adding these optimization, we most access pattern execution time reduce a lot.
|
|
</aside>
|
|
</section>
|
|
|
|
<section>
|
|
<h2>PostgreSQL JSONB vs MongoDB</h2>
|
|
<img src="paper/4.png" alt="PostgreSQL vs MongoDB Performance" style="height: 900px; margin: 0 auto;">
|
|
<aside class="notes">
|
|
"Now let's compare PostgreSQL JSONB with MongoDB, MongoDB is the most popular document database. The results here are quite interesing. First they start at time same level. After applying these optimization. the execution time is halfed. After turn on parallel processing, postgresql is significant faster than MongoDB. But we know mongodb is very memory hungry. So we give more memory to mongodb, we increase the memory from 4G to 16G, the mongodb perfrom better but still, postgresql win."
|
|
</aside>
|
|
</section>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<script src="dist/reveal.js"></script>
|
|
<script src="plugin/notes/notes.js"></script>
|
|
<script src="plugin/markdown/markdown.js"></script>
|
|
<script src="plugin/highlight/highlight.js"></script>
|
|
<script>
|
|
// More info about initialization & config:
|
|
// - https://revealjs.com/initialization/
|
|
// - https://revealjs.com/config/
|
|
Reveal.initialize({
|
|
width: 1920,
|
|
height: 1080,
|
|
hash: true,
|
|
|
|
// Learn about plugins: https://revealjs.com/plugins/
|
|
plugins: [ RevealMarkdown, RevealHighlight, RevealNotes ]
|
|
});
|
|
</script>
|
|
</body>
|
|
</html> |