Trino with VAST DataBase

Applies to VAST Cluster 5.5.

These recommendations help you plan a Trino cluster that reads and writes VAST DataBase tables through the VAST connector: the network, the catalog's endpoints and splits, Trino node sizing, and table design for Trino queries. They are starting points from field deployments. Measure with your own data and queries before you rely on them.

Each recommendation says which versions it applies to. Unless it says otherwise, that's VAST Cluster 5.5 with Trino 478 and VAST connector 478, the pairing in version compatibility.

For how the connector works, what each catalog property does and how to check pushdown, see Trino. This page doesn't repeat it.

Network

Use a non-blocking network between Trino and the cluster. Every active Trino worker reads from VAST DataBase at the same time, and shuffles between workers during joins and aggregations. On a larger production deployment, plan a non-blocking fabric with enough bandwidth to the virtual IP pool that serves VAST DataBase, and high-speed links (100GbE or faster) between Trino nodes. The connector needs a low-latency, high-bandwidth network connection to the cluster: see Installing and configuring the VAST connector for Trino.
Applies to: any Trino version; VAST Cluster 5.5. Field guidance; no test setup stated.

Keep the path direct. Avoid firewalls and proxies between Trino workers and the cluster's CNodes.
Applies to: any version. Field guidance.

Validate the network before you tune Trino. Measure throughput between your Trino nodes and the cluster with a multi-threaded tool such as iperf (one thread can't fill a 100 Gb/s link). Running the test against CNodes needs your platform team or VAST support. Check that MTU settings match on hosts and every switch port: in the field, mismatched MTU is a common cause of poor throughput. Jumbo frames are recommended where your network supports them end to end.

If the endpoint is wrong or unreachable, statements hang rather than fail: the connector retries the connection for several minutes before it reports an error. An unreachable address in data_endpoints doesn't fail the query either: the connector retries those requests and the query only runs slower, so a dead VIP in the list is easy to miss. Check that every Trino node can reach endpoint and each data_endpoints address before you look for a slow query.
Applies to: any version (the retry behaviour: connector 478). Field guidance; presales to confirm.

Use DNS, not /etc/hosts, for the cluster's addresses.
Applies to: any version.

On dual-homed nodes, keep Trino on the data network. If Trino nodes have a management interface and a high-speed data interface, set node.internal-address in each node's node.properties to the data interface's address. Otherwise Trino can pick the slower management network for traffic between nodes (Trino node properties). The catalog's endpoint and data_endpoints must also be reachable over the data network.
Applies to: Trino 478 (the property exists in earlier releases too).

Endpoints

List every virtual IP of the database pool in data_endpoints. The connector spreads its requests over the addresses you list, so you don't need an external load balancer for VAST DataBase traffic. Ask your platform team for all the VIPs of the pool that serves VAST DataBase, and list them all. A pool that contains only the CNodes that serve database work keeps database workloads and other cluster services from affecting each other (performance). Even a single table scan sends requests to every address listed. If you leave data_endpoints out, the connector sends all its requests to endpoint.
Applies to: VAST Cluster 5.5, connector 478. Field guidance.

Spread the VIPs evenly across CNodes. If you see one VIP or CNode much busier than the others, check that every Trino catalog file lists the full set.
Applies to: VAST Cluster 5.5.

Splits and sub-splits

num_of_splits and num_of_subsplits control the connector's parallelism. What each one does is in Trino catalog properties and read path.

Start from num_of_splits=64 and num_of_subsplits=10 for a Trino cluster that runs outside the VAST cluster. Set both in the catalog file: if it doesn't set num_of_splits, connector 478 uses a single split per table, which is much slower. Change one at a time and compare query times. Both are also session properties, so you can compare values per session with SET SESSION vast.num_of_splits = … and SET SESSION vast.num_of_subsplits = … instead of editing the catalog file. The new value applies from the next query. Compare on your own cluster: a single-node lab setup can't tell you which value is best.

Applies to: VAST Cluster 5.5, connector 478 (the managed Trino application uses different values; see Trino).

Make num_of_splits a multiple of the number of Trino workers, so that splits divide evenly across them.
Applies to: connector 478. Field guidance.

Run ANALYZE on the tables you query often. The connector sizes its splits from the table's row statistics. Without them, a plain table gets num_of_splits splits whatever its size, so a small table gets as many splits as a large one. After ANALYZE, small tables and selective filters use fewer splits (a 4-row table uses one), and Trino's cost-based optimizer has statistics for joins. The statistics survive a Trino restart. Run it again after large loads. Sorted and partitioned tables already get fewer splits for selective filters without it.

ANALYZE vast."my-db/my_schema".my_table;
SHOW STATS FOR vast."my-db/my_schema".my_table;

The connector stores the statistics as an object in the table's database bucket, so the catalog's user needs to be able to write and read objects there (s3:PutObject, s3:GetObject).
Applies to: connector 478.

Trino cluster sizing

Trino keeps intermediate results in memory, so size it memory first. These are starting points; Trino's own guidance is in Memory management properties.

Keep workers identical, so splits and shuffles stay balanced.
Use a dedicated coordinator in production (node-scheduler.include-coordinator=false).
Prefer fewer, larger workers to many small ones. VAST DataBase filters rows before they reach Trino, so the memory a join needs depends on what's left after the pushed-down filters; larger workers shuffle less.
Plan 4 GB to 8 GB of RAM per vCPU on workers.
Remove query.max-total-memory-per-node if you start from an older sample configuration. Trino 478 no longer has it and refuses to start: Defunct property 'query.max-total-memory-per-node' … cannot be configured. Use query.max-memory and query.max-memory-per-node.

Applies to: Trino 478; VAST Cluster 5.5. Field guidance; presales to confirm the ratio and test setup.

Separate workloads

Don't mix short interactive queries with long batch jobs on one Trino cluster without controls. Long queries hold memory and queue short dashboard queries. Use resource groups to cap concurrency and memory per workload, or run separate clusters against the same tables. For long batch jobs that can exceed memory, consider fault-tolerant execution.
Applies to: Trino 478. Trino-generic guidance.

Table design for Trino queries

The choices are explained in data modeling; these are the ones that matter most for Trino workloads.

Point lookups and selective filters on a key: use a sorted table sorted by that key.
Large tables queried by date, region or another common filter: use a partitioned table on those columns, so that Trino skips partitions and can join tables partitioned the same way without a shuffle (partition pruning).
Write filters that push down, and check with EXPLAIN (querying). A function on a column, such as upper(region) = 'EU', stays in Trino; compare the column itself.
Keep Trino's dynamic filtering on (the default) for joins of a large table with a small, filtered one. The connector passes the join keys to VAST DataBase, so the large table's scan returns only matching rows.

Check the effect on your own cluster with EXPLAIN and query times: a pushed-down predicate shows in the table scan, and a function on a column shows as a Trino filter.

Applies to: VAST Cluster 5.5, connector 478.

Row and column security

Use one service catalog with end-user impersonation when different people need different rows or columns. With impersonation, each query runs as the person who submitted it, so the cluster applies their row filters and column masks, and you don't need a catalog and key per team. What the catalog's user needs, and how rules show up in Trino, are in Trino: row and column security and security.

In connector 478 the catalog file turns this on with three properties, spelled with underscores:

enable_access_control=true
enable_row_column_security=true
enable_end_user_impersonation=true

The hyphenated spellings (enable-access-control and so on) are rejected, and the catalog doesn't load.

The connector passes the Trino user name to the cluster as the end user, so Trino user names must match VAST user login names. A Trino user with no matching VAST user gets an access-denied error. If Trino authenticates users, the authenticated name is the one that counts.

The catalog's user needs s3:EndUserImpersonation and s3:TabularGetRowColumnSecurity (not s3:GetRowColumnSecurity, which some samples show: with it, every query on the catalog fails with an access-denied error).

Don't rely on per-user keys without these properties. In a catalog that uses a person's own key but doesn't turn on row and column security, the cluster still removes denied columns, but their row filters aren't applied: they see every row.

Admin task: send to your platform team. Setting up the directory, identity policies and row and column security is in the KB: Row and column security.
Applies to: VAST Cluster 5.5, connector 478.

Keys

Protect the Trino server log like the catalog file. When connector 478 loads a catalog, it writes the catalog's configuration to the server log, including secret_access_key. Failed requests are also logged with their headers, which include the access key ID. Limit who can read the log and where it's shipped, and rotate the key if the log leaks.
Applies to: connector 478.

Watch both sides

When a query is slow, look at Trino and the cluster together. Trino's query details (CPU against wall time, blocked time, bytes read against rows returned) show whether the time goes into Trino or into reading. The cluster's VAST DataBase metrics (rows scanned per second, bandwidth, running queries) show the other side; your platform team can see them (Monitoring VAST databases). Many bytes read for few rows returned usually means a filter didn't push down. See monitoring your workload.
Applies to: VAST Cluster 5.5, Trino 478.