샤드와 복제본 이해하기

Welcome to a crucial lesson on scaling and reliability in Elasticsearch! As your data grows, a single server might not be enough.

Today, we'll explore two fundamental concepts: Sharding and Replicas. They are essential for handling large datasets and ensuring your search service stays online.

Imagine your application becomes super popular, and you're collecting millions of documents every day. A single Elasticsearch server (called a node) has limits:

• Storage Capacity: It can only hold so much data.
• Processing Power: Searching through huge amounts of data takes time.
• Single Point of Failure: If that one server goes down, your search is offline!

We need a way to distribute data and ensure constant availability.

Sharding is how Elasticsearch handles horizontal scaling. Think of it like breaking a very large book into several smaller, independent books.

Each 'smaller book' is called a shard. When you index documents, Elasticsearch distributes them across these shards. This allows you to store more data and process queries faster by using multiple servers.

When you create an index, you define a certain number of primary shards. Every document you add to that index will belong to one of these primary shards.

These shards are distributed across the nodes in your Elasticsearch cluster. This means that if you have 3 primary shards and 3 nodes, each node could hold one primary shard, spreading the load.

You define the number of primary shards when you create an index. Once an index is created, you cannot change the number of primary shards for it.

Here's how to create an index with 3 primary shards:

Sharding helps with scaling, but what about reliability? If one node (and its primary shard) fails, you lose part of your data and your search service might become incomplete or unavailable.

This is where replicas come in. They are copies of your primary shards, designed to provide high availability and fault tolerance.

A replica shard is an exact copy of a primary shard. If a node hosting a primary shard fails, a replica shard can be promoted to become the new primary, preventing data loss and downtime.

Replicas also serve another purpose: they can handle read requests! This means you can scale your search throughput by having multiple copies of your data ready to respond to queries.

You can define the number of replica shards when creating an index, or you can change it later for an existing index. A common setup is to have 1 replica (meaning 2 copies of your data in total: 1 primary + 1 replica).

Here's how to create an index with 3 primary shards and 1 replica per primary shard:

Elasticsearch smartly distributes primary and replica shards across different nodes. This is crucial for resilience!

• A primary shard and its replicas are never placed on the same node.
• If a node fails, Elasticsearch can use a replica on another node to keep your data available.
• This setup ensures high availability and allows your cluster to continue operating even with node failures.

You've learned about the core concepts of sharding and replicas. Let's see if you can identify their primary roles.

Great job! In this lesson, we demystified sharding and replicas, two vital concepts for any robust Elasticsearch deployment.

• Sharding (primary shards) allows you to break your data into smaller pieces, enabling horizontal scaling for storage and processing.
• Replicas (replica shards) are copies of primary shards that provide fault tolerance (high availability) and boost read performance.

Together, they make your Elasticsearch cluster scalable, resilient, and performant!