perf(query): narrow glob pruning, cache footprint and trace-candidate reads
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tái cấu trúc
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- go
- Lĩnh vực
- databases, observability, performance
Hướng nghiên cứu
Start with internal/query/file_snapshot.go and the review threads linked from issue #281, then trace the read_trace_parts and read_trace_candidates paths described in the issue. Measure glob file reads, cache size and trace-read cost under the stated workloads before choosing an approach. Done means the four review follow-ups are addressed, parity coverage is added where requested, and the measured trade-offs are documented.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
PR #272 review follow-ups from the e818a8db review (https://github.com/labstack/fanout/pull/272#pullrequestreview-5385883605). None of these affect correctness. Each item below links its original thread.
-
Captured-ID glob filter does not prune files (medium, measured): https://github.com/labstack/fanout/pull/272#discussion_r4160763194
internal/query/file_snapshot.gofilters the broad-selection glob withsubstr(filename, …) IN (ids). DuckDB's multi-file reader does not push that down, so every file matching the glob is opened and scanned. With 100 batches and 80 selected, profiles show 101 files read (explicit list: 80;filename IN ('<full path>', …): 81). This path also loses newest-first ordering for top-N reads. Options: filter on full paths, or raise the explicit-list threshold, and measure statement size against files read. -
Read-cache catalog is about as large as the Parquet data (medium-low, measured): https://github.com/labstack/fanout/pull/272#discussion_r4160763216
After a 300 s run at 120k offered rows/s (telemetrygen, two spans per trace),catalog.duckdbwas 762 MiB against 529 MiB of Parquet: about 474 MiB of used blocks and 288 MiB free.read_trace_partsandread_trace_candidateseach held about 3.6M rows. Document that cache size scales with trace count and that free blocks are not returned without a rebuild, and consider compaction of the cache file. -
Trace candidates re-aggregate every overlapping part when any cached file straddles the window (low, plausible): https://github.com/labstack/fanout/pull/272#discussion_r4160763233
Under continuous ingest the newest cached file usually straddles the window end, so most trace reads groupread_trace_partsfor all overlapping batches instead of readingread_trace_candidates. Restrict the parts aggregation totrace_id IN (partial)and take fully contained traces from the index, as the other branch does. Add a parity test and measure trace read cost as retention grows. -
The candidate index is evaluated twice in the contained-files branch (low): https://github.com/labstack/fanout/pull/272#discussion_r4160763241
The branch added in e7dbc79a readsindexonce for the fully contained rows and again insidepartial. On scoped reads with mixed-scope traces this repeats theread_trace_partsunion. Results are unaffected. Bind it once, or share it with the rewrite in item 3.
Related: #277 (ingest CPU per row), #278 (sustained read capacity and peak RSS).
- Ngôn ngữ chính
- HTML
- Star
- 6
- Fork
- 0
- Merge trung bình
- 2 giờ 25 phút
- Pull request đã merge (30 ngày)
- 25
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của labstack/fanout
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 42/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của labstack/fanout
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
peasant-labs/village#293 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 3 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
major/MySQLTuner-perl#1007 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
status: waiting-for-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
format.sort does not sort the Parents column (ParentRelations are sorted by the child table name)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100