How do I design a table in Cassandra for a TinyURL use case?

user_5058810 0
Viewed 61

Recently I came across a well-known design problem. 'Tiny URL'

What I found was people vouching for NoSQL DBS such as DynamoDB or Cassandra. I've been reading about Cassandra for a couple of days, and I want to design my solution around this DB for this specific problem.

  1. What would be the table definition? If I choose the following table definition:

Create table UrlMap(tiny_url text PRIMARY KEY, url text);

Wouldn't this result in a lot of partitions? since my partition key can take on around 68B values (using 6 char base64 strings)

Would that somehow affect the overall read/write performance? If so, what would be a better model to define the table.

cassandra
2 Answers

Lot's of partitions is fine, think of it as using c* as a key value store.

user_39579720

The primary principle of data modelling in Cassandra is to design one table for each application query.

For a URL shortening service, the main application query is to retrieve the equivalent full URL for a given tiny URI. In pseudo-code, the query looks like:

    GET long url FROM datastore WHERE uri = ?

Note that for the purpose of a service, we won't store the web domain name to make the app reusable for any domain. The filter (WHERE clause) is the URI so this is what you want as the partition key so we would design the table accordingly:

CREATE TABLE urls_by_uri (
    uri text,
    long_url text,
    PRIMARY KEY(uri)
)

If we want to retrieve the URL for http://tinyu.rl/abc123, the CQL query is:

    SELECT long_url FROM urls_by_uri WHERE uri = 'abc123'

As Phact and Andrew pointed, there is no need to worry about the number of partitions (records) you'll be storing in the table because you can store as many as 2^128 partitions in a Cassandra table which for practical purposes is limitless.

In Cassandra, each partition gets hashed into a token value using the Murmur3 hash algorithm (default partitioner). This implementation distributes each partition randomly across all nodes in the cluster. The same hash algorithm is used to determine which node "owns" the partition making retrieval (reads) very fast in Cassandra.

As long as you limit the SELECT queries to a single partition, retrieving the data is extremely fast. In fact, I work with hundreds of companies who have an SLA on reads of 95% between 6-9 milliseconds. This is achievable in Cassandra when you model your data correctly and size your cluster correctly. Cheers!

user_42695350
Related