Docs
  • 0.38.1latest
  • 0.37.1
  • 0.37.0
  • 0.36.2
  • 0.36.1
  • 0.36.0
  • 0.35.3
  • 0.35.2
  • 0.35.1
  • 0.35.0
  • 0.34.4
  • 0.34.3-beta
  • 0.34.2-beta
  • 0.34.1-beta
  • 0.34.0-beta
  • 0.33.4-beta
  • 0.33.3-beta
  • 0.33.2-beta
  • 0.33.1-beta
  • 0.33.0-beta
  • 0.32.0-beta

Switching a client by its address

A Kafka client or a RESP client already in your code connects to TessariDB when you change the address it dials. Nothing else in the application changes.

An application that already produces to Kafka, or keeps sessions and counters through a RESP client, can move onto TessariDB by changing one setting: the address its client connects to. The client library stays. The code that calls it stays. The node speaks the two protocols itself, on their usual ports, and puts what arrives into the store's own topics and spaces.

your application Kafka client bootstrap = node:9092 RESP client host = node, port 6379 one TessariDB node :9092 Kafka protocol → a topic :6379 RESP → a space :9080 TessariQL reads both What changed in the application: two addresses. What runs behind them: the store's own engines.
Where an existing client's traffic goes once its address points at a node. Both arrows are the protocols the clients already speak.

What you change

ClientSetting you changeSet it to
any Kafka client — producer, consumer, adminbootstrap.serversthe node's Kafka address, host:9092
any RESP client — RESP2 or RESP3its host and port, or its connection URLthe node's RESP address, host:6379

Then sign in as a store user, the way the client already signs in anywhere else: SASL PLAIN for Kafka, AUTH or HELLO … AUTH for RESP. If the client already uses TLS, it keeps using it: the node serves both protocols under the same certificate as its other surfaces.

Turning the two surfaces on

Neither protocol is served until you give it an address:

tessaridb ./data \
  --serve 0.0.0.0:9080 --http 0.0.0.0:8000 \
  --kafka 0.0.0.0:9092 --kafka-database shop.orders \
  --resp 0.0.0.0:6379 --resp-space shop.orders.cache

The container image takes the same settings as variables (TESSARIDB_KAFKA, TESSARIDB_RESP and the rest) and exposes ports 9092 and 6379 next to 9080 and 8000.

FlagVariableWhat it does
--kafka <host:port>TESSARIDB_KAFKAserves the Kafka protocol over the store's topics
--kafka-database <ns>.<db>TESSARIDB_KAFKA_DATABASEwhere a bare topic name such as payments is read; without it a Kafka topic is named <namespace>.<database>.<topic>
--kafka-advertise <host:port>TESSARIDB_KAFKA_ADVERTISEthe address Kafka clients are told to reconnect to — set it when a port mapping or a proxy stands between them and the node
--resp <host:port>TESSARIDB_RESPserves RESP2 and RESP3 over a space
--resp-space <ns>.<db>.<space>TESSARIDB_RESP_SPACEthe space a RESP connection starts in; without it a connection chooses one with TESSARIDB.USE

INFO FOR NODE lists what the node is listening on under clients.listeners, one row per surface with the address it bound, and the console's This node page shows the same rows.

What you get by switching

What arrives over either protocol is data in the store, not in a server beside it:

  • One transaction for everything. A Kafka record lands in a topic, and a RESP key in a space. A TessariQL script can read the topic, update an order and set a cache key in the same BEGIN … COMMIT.
  • Every reader agrees. A message produced by a Kafka client is read by READ FROM in TessariQL and by a topic consumer that writes it into a table. A message appended by TessariQL, or by a RESP client's XADD, is fetched by a Kafka consumer.
  • One set of users. The protocols sign in against the store's own users and grants, so a viewer can fetch but cannot produce, on every surface alike.
  • One backup, one cluster. Topics and durable spaces are in the store's snapshot, replicate with it and fail over with it. A space declared IN MEMORY is the cache-server case: held by the node leading it, never written to disk or a backup, and empty after a restart or a failover.

Where the protocols and the store differ

Each page lists what a client may notice, but the short version is:

  • A Kafka topic is a TessariDB topic, so it keeps every message in commit order. Transactions (transactional.id) and SCRAM sign-in are refused, and the idempotent producer is honoured until the node restarts.
  • A RESP connection works on one space, chosen by the node or by TESSARIDB.USE. SELECT 0 is accepted and any other index is refused. Scripting, bit fields, geo commands and the administrative commands are not served; TessariQL does that work.

Next

  • Kafka clients — names, partitions, groups, offsets, sign-in and the API keys served.
  • RESP clients — the space a connection works on, the value types, every command family, streams and pub/sub.