|
| 1 | +# Performance Tuning |
| 2 | + |
| 3 | +This guide covers performance tuning for Lance Trino operations in large-scale analytics scenarios. |
| 4 | + |
| 5 | +## Understanding Lance's Default Optimization |
| 6 | + |
| 7 | +Lance is **optimized by default for random access patterns** - fast point lookups, vector searches, and selective column reads. |
| 8 | +These defaults work well for ML/AI workloads where you frequently access individual records or small batches. |
| 9 | + |
| 10 | +For **large-scale batch ETL and scan-heavy OLAP operations** (writing millions of rows, full table scans, bulk exports), |
| 11 | +you can tune Lance's environment variables and connector properties to better utilize available resources. |
| 12 | + |
| 13 | +## Caching |
| 14 | + |
| 15 | +Lance Trino uses a multi-level caching strategy to minimize redundant I/O and improve query performance. |
| 16 | + |
| 17 | +### How Caching Works |
| 18 | + |
| 19 | +Lance Trino implements two levels of caching: |
| 20 | + |
| 21 | +1. **Session Cache** - Contains index and metadata caches: |
| 22 | + |
| 23 | + - **Index Cache**: Caches opened vector indices, fragment reuse indices, and index metadata |
| 24 | + - **Metadata Cache**: Caches manifests, transactions, deletion files, row ID indices, and file metadata |
| 25 | + |
| 26 | +2. **Dataset Cache** - Caches opened datasets by `(userIdentity, tablePath, version)` key. Since a dataset at a specific version is immutable, this ensures: |
| 27 | + |
| 28 | + - Each dataset is opened only once per worker |
| 29 | + - All workers read the same version for snapshot isolation |
| 30 | + - Schema and fragment metadata are reused from the cached dataset |
| 31 | + |
| 32 | +### Cache Configuration |
| 33 | + |
| 34 | +Configure caching behavior via connector properties in your catalog file: |
| 35 | + |
| 36 | +```properties |
| 37 | +# Session cache settings |
| 38 | +lance.cache.session.max_entries=100 # Maximum cached sessions (default: 100) |
| 39 | +lance.cache.session.ttl_minutes=60 # Session cache TTL in minutes (default: 60) |
| 40 | +lance.cache.session.index_cache_size_bytes=6442450944 # Index cache size: 6GB |
| 41 | +lance.cache.session.metadata_cache_size_bytes=1073741824 # Metadata cache size: 1GB |
| 42 | + |
| 43 | +# Dataset cache settings |
| 44 | +lance.cache.dataset.max_entries=100 # Maximum cached datasets (default: 100) |
| 45 | +lance.cache.dataset.ttl_minutes=30 # Dataset cache TTL in minutes (default: 30) |
| 46 | +``` |
| 47 | + |
| 48 | +| Property | Description | Default | |
| 49 | +|----------|-------------|---------| |
| 50 | +| `lance.cache.session.max_entries` | Maximum number of cached sessions | `100` | |
| 51 | +| `lance.cache.session.ttl_minutes` | Session cache TTL in minutes | `60` | |
| 52 | +| `lance.cache.session.index_cache_size_bytes` | Index cache size in bytes | Lance default (6GB) | |
| 53 | +| `lance.cache.session.metadata_cache_size_bytes` | Metadata cache size in bytes | Lance default (1GB) | |
| 54 | +| `lance.cache.dataset.max_entries` | Maximum number of cached datasets | `100` | |
| 55 | +| `lance.cache.dataset.ttl_minutes` | Dataset cache TTL in minutes | `30` | |
| 56 | + |
| 57 | +The index cache stores vector indices which can be large but provide significant speedup for vector search queries. |
| 58 | +Increase this if you frequently query tables with vector indices. |
| 59 | + |
| 60 | +The metadata cache stores manifests, file metadata, and other dataset metadata. |
| 61 | +Each column's metadata can be around 40MB, so increase this if your tables have many columns. |
| 62 | + |
| 63 | +## Lance Environment Variables |
| 64 | + |
| 65 | +Lance uses environment variables for low-level I/O tuning. Set these on your Trino coordinator and worker nodes. |
| 66 | + |
| 67 | +### Read Performance |
| 68 | + |
| 69 | +#### I/O Threads |
| 70 | + |
| 71 | +Set via environment variable `LANCE_IO_THREADS` (default: 64). |
| 72 | + |
| 73 | +Controls the number of I/O threads used for parallel reads from storage. |
| 74 | +For large scans, increasing this to match your CPU core count enables more concurrent S3 requests. |
| 75 | + |
| 76 | +```bash |
| 77 | +export LANCE_IO_THREADS=128 |
| 78 | +``` |
| 79 | + |
| 80 | +### Write Performance |
| 81 | + |
| 82 | +#### Upload Concurrency |
| 83 | + |
| 84 | +Set via environment variable `LANCE_UPLOAD_CONCURRENCY` (default: 10). |
| 85 | + |
| 86 | +Controls the number of concurrent multipart upload streams to S3. |
| 87 | +Increasing this to match your CPU core count can improve throughput. |
| 88 | + |
| 89 | +```bash |
| 90 | +export LANCE_UPLOAD_CONCURRENCY=32 |
| 91 | +``` |
| 92 | + |
| 93 | +#### Upload Part Size |
| 94 | + |
| 95 | +Set via environment variable `LANCE_INITIAL_UPLOAD_SIZE` (default: 5MB). |
| 96 | + |
| 97 | +Controls the initial part size for S3 multipart uploads. |
| 98 | +Larger part sizes reduce the number of API calls and can improve throughput for large writes. |
| 99 | +However, larger part sizes use more memory and may increase latency for small writes. |
| 100 | +Use the default for interactive workloads. |
| 101 | + |
| 102 | +!!!note |
| 103 | + Lance automatically increments the multipart upload size by 5MB every 100 uploads, |
| 104 | + so large file writes progressively use increasingly large upload parts. |
| 105 | + There is no configuration for a fixed upload size. |
| 106 | + |
| 107 | +```bash |
| 108 | +export LANCE_INITIAL_UPLOAD_SIZE=33554432 # 32MB |
| 109 | +``` |
| 110 | + |
| 111 | +### Environment Variables Summary |
| 112 | + |
| 113 | +| Variable | Description | Default | |
| 114 | +|----------|-------------|---------| |
| 115 | +| `LANCE_IO_THREADS` | Number of I/O threads for parallel reads | `64` | |
| 116 | +| `LANCE_UPLOAD_CONCURRENCY` | Number of concurrent S3 upload streams | `10` | |
| 117 | +| `LANCE_INITIAL_UPLOAD_SIZE` | Initial S3 multipart upload part size (bytes) | `5242880` (5MB) | |
| 118 | + |
| 119 | +## Index-Aware Split Planning |
| 120 | + |
| 121 | +Lance Trino optimizes split planning based on index availability. When a table has indexes on filtered columns, larger splits are used because index lookups are efficient. |
| 122 | + |
| 123 | +```properties |
| 124 | +# Rows per split when btree index is used (default: 100M) |
| 125 | +lance.index.btree.rows_per_split=100000000 |
| 126 | + |
| 127 | +# Rows per split when bitmap index is used (default: 10M) |
| 128 | +lance.index.bitmap.rows_per_split=10000000 |
| 129 | +``` |
| 130 | + |
| 131 | +| Property | Description | Default | |
| 132 | +|----------|-------------|---------| |
| 133 | +| `lance.index.btree.rows_per_split` | Row count threshold for btree-indexed splits | `100000000` (100M) | |
| 134 | +| `lance.index.bitmap.rows_per_split` | Row count threshold for bitmap-indexed splits | `10000000` (10M) | |
0 commit comments