scylladb / scylladb/alternator-client-python

Shard-aware load balancing

Open
#58 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
0
Forks
4
Avg merge
2h 49m
Merged PRs (30d)
7

Description

Jira task: https://scylladb.atlassian.net/browse/DRIVER-698
Jira epic: https://scylladb.atlassian.net/browse/DRIVER-43

Copied from Jira epic DRIVER-43:

After we implement [#11|https://github.com/scylladb/alternator-load-balancing/issues/11], to route every single-partition request to a good node (one of the three replicas holding a copy of the the partition, possibly one on the right rack or the same replica to reduce LWT contention), the next step requested by this issue is to route the request to a good shard on that node.

We have such a feature in CQL - enable_shard_aware_drivers. It creates a shard-aware port: Client connections to this port are routed to a specific shard according to a formula based on the client-side port numbers. Clients open many sockets to the same node instead of just one socket to a node, and each of these sockets ends up connected to a different shard. The client calculates which shard it wants to send the request to, and uses the appropriate socket to reach that shard directly. The shard is selected such that it owns the tablet with the requested token (we can also do this with vnodes, but we probably don't care about vnode support any more).

The connection-per-shard approach suggested here will probably require some hacking on the client SDKs. The HTTP library used by these SDKs will normally open only one socket between the client and some remote node X, or more if more concurrent requests come in, but we want it to deliberately open many connections and pick one of them according to a formula based on the client-side port, and then keep all of these connections open for the next request.

Migrated from GitHub issue: https://github.com/scylladb/alternator-load-balancing/issues/129

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files or tests are named. Start by reviewing the existing Python client load-balancing work, the implementation referenced by issue #11, and the HTTP connection behavior described here; done means requests can select and retain connections that reach the appropriate shard on a replica node.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
distributed-systems, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.