159250e776
* refactor: concurrent table planning in InfluxRPC Some InfluxRPC can scan multiple tables. Prior to this PR we were always scanning the tables in sequence, adding up potential latencies (catalog, ingester, object store). There is no reason we need to do this, "ordinary" SQL queries would not serialize this way either. So let's scan tables concurrently. This add concurrency to: - read filter - read group - read window aggregate There are other query types that could benefit from a similar treatment. They will be changed in a follow-up. * docs: improve Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org> * test: explain `Send` assertion * refactor: change `CONCURRENT_TABLE_JOBS` to 10 Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org> |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
README.md
IOx Query Layer
The IOx query layer is responsible for translating query requests from different query languages and planning and executing them against Chunks stored across various IOx storage systems.
Query Frontends
- SQL
- Storage gRPC
- Flux (possibly in the future)
- InfluxQL (possibly in the future)
- Others (possibly in the future)
Sources of Chunk data
- ReadBuffer
- MutableBuffer
- Parquet Files
- Others (possibly in the future, like Remote Chunk?)
The goal is to use the shared query / plan representation in order to avoid N*M combinations of language and Chunk source.
Thus query planning is implemented in terms of traits, and those traits are implemented by different chunk implementations.
Among other things, this means that this crate should not depend directly on the ReadBuffer or the MutableBuffer.
┌───────────────┐ ┌────────────────┐ ┌──────────────┐ ┌──────────────┐
│Mutable Buffer │ │ Read Buffer │ │Parquet Files │ ... │Future Source │
│ │ │ │ │ │ │ │
└───────────────┘ └────────────────┘ └──────────────┘ └──────────────┘
▲ ▲ ▲ ▲
└───────────────────┴─────────┬──────────┴─────────────────────┘
│
│
┌─────────────────────────────────┐
│ Shared Common │
│ Predicate, Plans, Execution │
└─────────────────────────────────┘
▲
│
│
┌──────────────────────┼─────────────────────────┐
│ │ │
│ │ │
│ │ │
┌───────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ SQL Frontend │ │ gRPC Storage │ ... │ Future Frontend │
│ │ │ Frontend │ │ (e.g. InfluxQL) │
└───────────────────┘ └──────────────────┘ └──────────────────┘
We are trying to avoid ending up with something like this:
┌─────────────────────────────────────────────────┐
│ │
▼ │
┌────────────┐ │
│Read Buffer │ ┌────────────────────────┤
┌──────────┼────────────┼─────┬────────────┼────────────────────────┤
│ └────────────┘ │ ▼ │
▼ ▲ │ ┌──────────────┐ │
┌───────────────┐ │ │ │Parquet Files │ │
│Mutable Buffer │ │ ├───▶│ │... │
│ │◀────────┼───────────┤ └──────────────┘ ┌─────────────┼┐
└───────────────┘ │ │ ▲ │Future Source││
▲ │ ├────────────┼─────────▶│ ││◀─┐
│ │ │ │ └─────────────┼┘ │
│ │ │ │ │ │
│ │ │ │ │ │
│ ┌──────────┘ │ │ │ │
│ │ │ │ │ │
│ ├──────────────────────┼────────────┘ │ │
└──────┤ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
┌───────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ │
│ SQL Frontend │ │ gRPC Storage │ ... │ Future Frontend │ │ │
│ │ │ Frontend │ │ (e.g. InfluxQL) │──┴───┘
└───────────────────┘ └──────────────────┘ └──────────────────┘