jojochuang commented on code in PR #10335: URL: https://github.com/apache/ozone/pull/10335#discussion_r3531967949
########## hadoop-hdds/docs/content/design/efficient-snapdiff.md: ########## @@ -0,0 +1,254 @@ +--- +title: Snapshot Diff Optimization +summary: Describe proposal for an optimized snapshot diff that uses mostly sequential reads and batch puts +date: 2025-05-22 +jira: HDDS-9154 +status: draft +author: Saketa Chalamchala +--- +<!-- + Licensed under the Apache License, Version 2.0 (the "License"); + you may not use this file except in compliance with the License. + You may obtain a copy of the License at + http://www.apache.org/licenses/LICENSE-2.0 + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. See accompanying LICENSE file. +--> + +## 1. Introduction +This document outlines the technical design, architectural choices, and algorithmic improvements to optimize Ozone's Snapshot Diff feature. The design addresses performance bottlenecks in both the **Full Diff** and **DAG-based Diff** paths. The primary goals are to reduce random I/O, minimize CPU overhead from deserialization, and streamline the classification of differences. + + ## Goals + - Reduce random I/O. + - Minimize CPU cost of deserializing KeyInfo and DirectoryInfo for comparisons. + - Keep baseline diff semantics for CREATE/DELETE/RENAME/MODIFY where possible. + +--- + +## 2. Core Design Choices & Optimizations + +### 2.1. Sequential Reads & Table Iterators +**Baseline Issue:** Baseline full diff enumerates keys via SST readers (plus per-key `db.get` lookups), and the DAG-based diff relies heavily on random point lookups (`db.get()`) against the snapshot RocksDB instances to fetch the old and new states of keys identified in the delta SST files. For buckets with millions of keys, this random I/O degrades performance and thrashes the OS page cache. Review Comment: Our learned lesson is that even with high speed SSD, random db seek is a performance killer, and warrants a redeisgn. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
