การจัดการข้อมูลอนุกรมเวลา

Time-series data is information collected over a period of time, often at regular intervals. Think of it as a sequence of data points indexed by time.

Examples include:

• System logs: Events happening on a server.
• IoT sensor readings: Temperature, humidity from devices.
• Financial data: Stock prices over days or hours.

This data is typically append-only and usually immutable once recorded.

Elasticsearch is an excellent choice for managing time-series data due to its:

• Scalability: Handles massive volumes of data.
• Speed: Fast indexing and search capabilities.
• Analytics: Powerful aggregations for insights.
• Flexibility: Can store structured and unstructured data.

It's particularly strong for use cases like log analytics, metric monitoring, and security event management.

Data streams are a core feature in Elasticsearch designed specifically for time-series data. They simplify management by automatically rolling over to new indices as needed.

When you index data into a data stream, it always writes to the current write index. Queries, however, search across all backing indices transparently. This makes managing large, continuously growing datasets much easier.

To create a data stream, you first need an index template that defines its structure and points to a data stream.

Then, simply indexing a document into the stream's name will create it automatically based on the template:

Index Lifecycle Management (ILM) is a powerful feature that automates the management of your indices through various phases of their life.

For time-series data, ILM helps you:

• Automatically roll over indices when they reach a certain size or age.
• Move older, less frequently accessed data to cheaper storage.
• Delete data that is no longer needed.

ILM policies define actions for indices across four main phases:

• Hot: Indices are actively being written to and frequently queried. Requires fast storage.
• Warm: Indices are no longer being written to, but are still queried. Can be read-only and potentially on slower storage.
• Cold: Indices are rarely queried and often stored on very cheap, slow storage.
• Delete: Indices are no longer needed and are safely removed from the cluster.

Here's an example of an ILM policy that defines rollover, forcemerge (for warm phase), and deletion stages for time-series data:

A Hot-Warm-Cold architecture optimizes resource utilization and cost for time-series data by using different types of nodes for different ILM phases.

• Hot nodes: Use fast CPUs, SSDs for high indexing and query throughput.
• Warm nodes: Use less powerful CPUs, HDDs (or slower SSDs) for older, read-only data.
• Cold nodes: Use very cheap, high-capacity storage, potentially even object storage, for rarely accessed data.

You can configure nodes to serve specific roles (hot, warm, cold) by setting node.attr in their elasticsearch.yml configuration file.

ILM policies then use these attributes to automatically move indices to the appropriate node types as they transition through phases.

Great job! You've explored how Elasticsearch is optimized for time-series data.

We covered:

• Data Streams: Simplifying index management and rollovers.
• ILM (Index Lifecycle Management): Automating index transitions through hot, warm, cold, and delete phases.
• Hot-Warm-Cold Architectures: Optimizing cluster resources and costs by assigning different node types to specific ILM phases.

These features are essential for building scalable and cost-effective time-series solutions with Elasticsearch.