Local Table Data Service

The Local Table Data Service (LTDS) is an optional Deephaven process (db_ltds) that exposes intraday table data from a server's local storage over the table data service (TDS) protocol. It is no longer started as part of the default installation, but the process is still available for deployments that need to publish local data as a network service or offload read traffic from other table data providers.

Role in the architecture

  • The LTDS reads intraday table data directly from the /db/Intraday/<namespace>/<tableName> directories on the host where it runs.
  • It serves read requests for local intraday data that is not managed by a Data Import Server (DIS, db_dis), or where you need an alternative TDS provider alongside DIS and the Table Data Cache Proxy (TDCP, db_tdcp).
  • Consumers such as query servers or merge processes can treat LTDS as just another TDS provider, alongside DIS instances and TDCP.
  • In current default deployments, LTDS is rarely required but remains supported for specialized use cases.

Configuration overview

LTDS participates in the same TDS configuration model as other table data services.

  • The db_ltds process loads its routing configuration from the tableDataServices section, using either:
    • its process.name (db_ltds), or
    • property LocalTableDataServer.routingConfigurationName.
  • In the routing YAML, LTDS is configured as a provider under tableDataServices, just like DIS or TDCP.
  • The process typically listens on the local table data port (by default TCP 22014, referenced as default-localTableDataPort), unless you override the port in the routing configuration.

See the YAML configuration guide for configuration instructions.

When LTDS is configured as a TDS provider, any consuming process (query server, merge process, or proxy such as TDCP) can be pointed at the named tableDataServices entry, just as it would be for a DIS-backed service.

When to use LTDS

LTDS is intended for specialized scenarios where a local, host-specific table data provider is needed. Examples include:

  • Serving local intraday data
    • You have intraday tables on a particular host that are not managed by a DIS, but still need to be exposed to query or merge processes via TDS.
  • Reducing load on DIS
    • You want to offload some table data read-only traffic while DIS focuses on data ingestion.
  • Publishing local data as a service
    • You have locally maintained tables (for example, test or ad hoc data sets) that you want to make available to other Deephaven processes over the network without routing them through DIS.
  • Legacy or transitional deployments
    • You are maintaining an older cluster that already uses LTDS, and you prefer not to update the data routing configuration.

Operational considerations

  • Process lifecycle
    • LTDS is managed like other Deephaven processes (for example, via monit on traditional installations).
    • Existing runbooks and restart guides treat db_ltds similarly to DIS and other long-lived services and recommend periodic restarts to release cached resources.
  • Data locality and mounts
    • Because LTDS serves data from the local /db/Intraday/... directories, verify that the appropriate intraday mounts are present on the host running db_ltds.
    • LTDS does not change the underlying storage layout; it simply exposes those locations over TDS.
  • Routing and filters
    • As with any TDS provider, you must configure filters so that each table location is served by exactly one source (DIS, TDCP, LTDS, or another TDS provider).
    • Misconfigured filters can lead to overlapping table locations and TableDataExceptions at query time.