Tecniche di sharding dei database

As a SaaS application grows, a single database often becomes a bottleneck. Traditional scaling, known as vertical scaling, involves upgrading to a more powerful server (more CPU, RAM, storage).

However, vertical scaling has limits and can become very expensive. For SaaS, which serves many tenants, we need a way to scale our data horizontally across multiple database instances.

Database sharding is a technique to horizontally partition data across multiple database instances. Think of it like splitting a very large book into several smaller books, each stored on a different shelf.

• Each 'smaller book' is called a shard.
• Each shard is a complete database instance, holding a subset of the total data.
• Together, these shards form the complete logical database.

Sharding helps distribute load, improve performance, and manage massive datasets for SaaS.

While similar, sharding and partitioning are different:

• Partitioning: Divides a large table into smaller, more manageable pieces within a single database instance. This can be vertical (splitting columns) or horizontal (splitting rows).
• Sharding: Divides the entire database into smaller, independent database instances (shards) that are often hosted on separate servers. Each shard contains a portion of the data.

Sharding is essentially horizontal partitioning that spans across multiple physical database servers.

To decide which data goes into which shard, we use a shard key. This is a column (or set of columns) in your database tables that determines how data is distributed.

Choosing the right shard key is critical for effective sharding:

• It should ensure an even distribution of data.
• It should minimize queries that need to access multiple shards.
• For multi-tenant SaaS, the tenant_id is often an ideal shard key.

Range-based sharding distributes data based on a range of shard key values. For example, customers with IDs 1-1000 go to Shard A, 1001-2000 to Shard B, and so on.

• Pros: Simple to implement, good for range queries (e.g., 'all customers added last month').
• Cons: Can lead to hot spots if data isn't evenly distributed across ranges (e.g., new customers always go to the last shard). Rebalancing can be complex.

Hash-based sharding applies a hash function to the shard key, and the resulting hash value determines which shard the data belongs to. For example, hash(tenant_id) % num_shards.

• Pros: Generally provides a more even distribution of data, reducing hot spots.
• Cons: Range queries become difficult as related data might be spread across many shards. Adding or removing shards can require re-hashing and data movement.

Directory-based sharding uses a lookup service (the 'directory') to map each shard key to its corresponding shard. When an application needs data, it first queries the directory to find the correct shard.

• Pros: Highly flexible, making it easier to add, remove, or rebalance shards without changing the hashing logic.
• Cons: The directory service itself can become a single point of failure or a performance bottleneck if not designed for high availability.

For multi-tenant SaaS, sharding by tenant_id is a common and powerful strategy. Each tenant's data resides entirely within one shard.

This offers several benefits:

• Data Isolation: Strong separation of tenant data, enhancing security.
• Performance: Queries for a single tenant only hit one shard, improving speed.
• Scaling: Allows individual tenants or groups of tenants to be moved to different shards as their data grows, without affecting others.

While powerful, sharding introduces complexity:

• Cross-Shard Joins: Queries requiring data from multiple shards are difficult and inefficient. Application design should minimize these.
• Data Rebalancing: As data grows or shrinks, shards can become uneven. Moving data between shards is a complex operational task.
• Distributed Transactions: Ensuring data consistency across multiple shards during a transaction is challenging and often requires special patterns (e.g., two-phase commit).
• Operational Overhead: Managing multiple database instances instead of one increases administrative burden.

In this lesson, we explored database sharding as a critical technique for horizontally scaling SaaS applications. We learned that sharding distributes data across multiple database instances using a shard key.

We covered different strategies like range, hash, and directory-based sharding, and highlighted the importance of using tenant_id for multi-tenant SaaS. While powerful, sharding introduces challenges like complex cross-shard operations and rebalancing, which must be carefully considered in your architecture.