Piotr Sarna, Software Engineer at Turso Understanding and tapping your driver’s performance potential. Piotr Sarna discusses how to get the most out of a driver, particularly from the performance perspective, and select a driver that’s a good fit for your needs.

1. Drivers
Piotr Sarna
piotr@sarna.dev sarna@turso.tech

2. Piotr Sarna
● Wrote a few patches for the Linux kernel
● Ex-maintainer of ScyllaDB and Seastar
● Staff @Turso
● Maintainer of libSQL

3. Drivers
3
Communication tools for database users
● binary protocols
● HTTP
● gRPC

4. Clients vs Servers
4

5. Clients vs Servers
Clients:
● want stuff done as fast as possible
● don’t usually care much about other clients
Servers:
● want to have things to do all the time
● but not too many things
● cooperate with other fellow servers
5

6. Workload types
a.k.a. types of annoying clients
6
interactive:
“webpage users”
batch:
“Spark job”

7. Throughput vs Goodput
Throughput:
measure of how much data you can squeeze through
Goodput:
measure of much useful data you can squeeze through
7

8. Throughput vs Goodput
Throughput:
1MiB of data, retried 10 times, 10MiB worth of error logs => 20 MiB/s!
Goodput:
1MiB of data, retried 10 times, 10MiB worth of error logs => 1 MiB/s
8
(nobody cares)

9. Timeouts
User-side timeouts: “whew, they finally gave up trying”
Server-side timeouts: “I’m tired, boss”
9

10. User-side timeouts
Tricky.
A server doesn’t necessarily know the user gave up.
May trigger a retry, which just makes the load worse.
Drivers can’t assume the servers know.
10

11. Server-side timeouts
Not tricky.
A nice backpressure mechanism.
Server should clearly inform why the request was refused.
11

12. Context
12

13. Topology
Some databases expose their topology, some don’t.
For those who do, drivers should track topology changes.
13

14. Topology
Ways of learning topology
● polling servers for topology information
● subscribing to topology change events
● taking part in the topology change process
○ gossiping
○ consensus algorithms
14

15. Metadata
15
● load statistics
○ current load
○ historical load
● priority
○ prefer servers with faster disks
○ prefer servers with more memory
● physical distance

16. Caching
16

17. Caching
■ prepared statements
■ query results
■ topology
17

18. Caching prepared statements
Example algorithms:
■ LRU
○ with multiple pools to avoid thrashing
■ LFU
Do not prepare oneshot statements.
18

19. Caching query results
Local cache -> relaxed consistency guarantees
Usually better to be done in the app, not in the driver
19

20. Caching topology & schema
Clients cannot assume they are up-to-date with topology or schema.
On failed assumption:
● client tries to contact a dead node
● client contacts a node that doesn’t have certain data anymore
● client contacts a node that is not yet up-to-date with all data
Server reaction:
● refuse to execute, ask to refresh topology and/or schema
● refuse to execute, reroute to the right node
● refuse to execute, send updated topology/schema info
● act as proxy
20

21. Retries
21

22. Retries
a.k.a. clients being even more annoying than usual
To retry, or not to retry?
● timeouts
○ read timeouts
○ write timeouts
● temporary errors
○ overload
○ dead node
○ schema mismatch
● permanent errors
○ bad syntax
○ authentication error
○ authorization error
22

23. Idempotence
Can a query be safely executed multiple times?
23
Query OK to retry?
SELECT * FROM t; yep
CREATE TABLE IF NOT EXISTS t(v int PRIMARY KEY); sure
INSERT INTO T(v) VALUES (42) USING TIMESTAMP 123; ok*
UPDATE t SET v = v + 42; nnnope*

24. Retry policies
● do not retry
● retry on the same server
● retry on another server
● retry after some delay
● retry speculatively
24

25. Paging
25

26. Paging
26
Serving results in smaller bits.
● protects server memory
● protects clients' memory
● improves overall latency
● can be hidden behind driver API: e.g. result streams
● users can tweak parameters: page size

27. Concurrency
27

28. Concurrency
Doing multiple things at a time.
High == good, but to a degree.
Modern hardware loves concurrency.
28

29. Keep in touch!
Piotr Sarna
Staff @Turso
piotr@sarna.dev
sarna@turso.tech
@sarna_dev