wangyong9999 commented on PR #315: URL: https://github.com/apache/paimon-cpp/pull/315#issuecomment-5614548750
## Performance validation I completed a single-node point-lookup comparison against Parquet and a follow-up page-layout fairness audit. ### Setup - Code under test: `824939e5`; the follow-up `a0305ce4` only changes schema validation, build dependency tracking, an error-path release, and comments, not the successful lookup path. - 1,000,000 rows: non-null `INT64 id` + deterministic random 1 KiB `BINARY payload`. - Single NameNode/DataNode HDFS 3.3.6, replication 1, warm cache, exposed through identical FUSE paths because Lance 0.39 does not register an `hdfs://` object store. - 32 physical cores / 64 hardware threads. Sixteen FUSE client mounts point to the same DataNode and files so one FUSE client does not cap host throughput. - Each lookup opens the format reader, applies an exact row-id selection, reads both columns, and validates the returned id and payload length. Warm-up additionally validates every payload byte. - 5 s warm-up + 15 s measurement, 3 alternating repetitions per point; tables below use the median. All 48 primary samples completed with `errors=0`; maximum throughput CV was 1.36%. ### Native-default layout The files are nearly the same size (Parquet 1,038,726,714 bytes; Lance 1,040,012,235 bytes). Parquet used no compression and its default page index; the random payload is effectively incompressible. | Workload | Concurrency | Parquet lookups/s | Lance lookups/s | QPS delta | Parquet P99 | Lance P99 | P99 delta | |---|---:|---:|---:|---:|---:|---:|---:| | Single key | 1 | 64.6 | 77.6 | +20.1% | 20.2 ms | 15.4 ms | -23.7% | | Single key | 64 | 910.4 | 1,017.8 | +11.8% | 132.1 ms | 125.8 ms | -4.7% | | Single key | 256 | 958.4 | 1,115.0 | +16.3% | 578.2 ms | 576.1 ms | -0.4% | | 4-key request | 128 | 1,515.6 | 1,726.1 | +13.9% | 486.9 ms/request | 422.5 ms/request | -13.2% | | 4-key request | 256 | 1,568.5 | 1,825.2 | +16.4% | 1,729.5 ms/request | 847.3 ms/request | -51.0% | For the 4-key runs, host CPU busy was 97.31% / 97.45% at C128 and 95.87% / 98.27% at C256 for Parquet / Lance respectively. ### Page-layout fairness audit The initial files used the same 4,096-row input batches but not identical physical pages: - Parquet payload: 245 pages, up to 4,096 rows and about 4.21 MB per page. - Lance payload: 123 pages, up to 8,192 rows and about 8.45 MB per page. This favors Parquet for random reads because it has the smaller payload page. I therefore regenerated both formats with 8,192-row input batches. The dominant payload column then had 123 pages in both files, up to 8,192 rows and about 8.42/8.45 MB per page. File sizes differed by 0.14%. Native encoding of the small id column remains format-specific; forcing identical bytes there would no longer test the real readers. The page-matched single-key sensitivity run used the same methodology (30 samples, all `errors=0`): | Concurrency | Parquet lookups/s | Lance lookups/s | QPS delta | Parquet P99 | Lance P99 | P99 delta | |---:|---:|---:|---:|---:|---:|---:| | 1 | 48.3 | 73.2 | +51.5% | 28.5 ms | 15.8 ms | -44.8% | | 64 | 711.8 | 996.2 | +40.0% | 152.3 ms | 125.8 ms | -17.4% | | 256 | 747.0 | 1,108.4 | +48.4% | 624.4 ms | 562.4 ms | -9.9% | The direction is stable after matching the dominant page layout, and the native-default result is conservative rather than biased toward Lance. I am keeping the native-default CPU-saturation numbers as the primary result; the page-matched 4-key Parquet runs became I/O-bound before reaching the same CPU saturation, so I am not presenting them as an equal-CPU gain. Scope: this validates warm-cache file-reader point lookups on one host. It does not cover cold cache, remote multi-node HDFS, table planning, full scans, compaction, or writes. -- 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]
