sachin-j-joshi

Naming Convention

The chunk name follow <segment_name>.E-<epoch>-O-<start_offset>.<GUID>

Use case - simple segment

Recovery

1. Gather all chunks matching pattern <segment_name>*
2. Sort them by epoch and offset information
3. Remove zombie chunks using approach similar to this https://github.com/pravega/pravega/blob/master/segmentstore/storage/src/main/java/io/pravega/segmentstore/storage/chunklayer/SystemJournal.java#L1058

sachin-j-joshi

Version 0.9.1

Long Term Storage

We are simplifying the Long-Term Storage design and laying foundation for supporting more external storage adapters and more exciting features in future.

We continue improving the new storage layout and in this release we have fixed critical issues (like 5853,5456 etc.) as well as added important improvements ( like 5698, 5460 etc.).

For more details, please refer to PDP-34 SLTS.

sachin-j-joshi

Bootstrap

1. During Segment Store startup container metadata and storage metadata table segments are added as pinned segments inside SLTS.
2. During startup of the secondary services. Chunks for metadata and storage metadata table segments are discovered and metadata about them is populated in storage metadata segment. (This is done in order to avoid circular dependency.)

Why SLTS needs System Journal?

SLTS Storage System Segments.

SLTS stores metadata about all segments and their chunks in special metadata table segments. In this document we refer them as "Storage System Segments".

sachin-j-joshi

Background

Key Features

• SLTS operations do not immediately delete the chunks that are not needed.
• Instead Chunks to be deleted are are
  • First marked for deletion in metadata and that change is committed as part of SLTS operations (Eg during truncate, concat or write etc)
  • Name of the chunk is put into GC queue.
  • Each container has dedicated background thread that polls this GC queue and deletes the chunks and the associated metadata
  • The actual deletion task happens on storage thread.

sachin-j-joshi

Background

This Document discusses design for Unified Chunk Management Layer which is part of a larger effort Pravega Simplified Storage Subsystem (S3).

This also covers design for PDP 34: CRWD Tier 2. https://github.com/pravega/pravega/wiki/PDP-34:-Simplified-Tier-2

Motivation

Here are some of the problems we are facing today that are motivating this design

• Need to use complex fencing logic for HDFS making it slow and hard to maintain.
• Impedence mismatch between current model and the way Amazon S3 works.

sachin-j-joshi

Background

This Document discusses design for Unified Chunk Management Layer which is part of a larger effort Pravega Simplified Storage Subsystem (S3).

This also covers design for PDP 34: CRWD Tier 2. https://github.com/pravega/pravega/wiki/PDP-34:-CRWD-Tier-2

Motivation

Here are some of the problems we are facing today that are motivating this design

• Need to use complex fencing logic for HDFS making it slow and hard to maintain.
• Impedence mismatch between current model and the way Amazon S3 works.

sachin-j-joshi

Summary

Motivation

Support multiple “tiers”​

• Cloud storage tier - Amazon S3, Azure, GCP​
• Cold storage tier​
• Edge tier​
• Fast/Expensive tiers with fancy hardware (E.g. Optane)

Current situation

Prerequisite

This PDP requires implementing PDP-34

sachin-j-joshi

Background

This Document discusses design for .

Motivation

Here are some of the problems we are facing today that are motivating this design

• Problem 1
• Problem 2
• Problem 3

sachin-j-joshi

Background

This Document discusses design for Pravega Simplified Storage Subsystem (S3).

This also covers design for PDP 34: CRWD Tier 2. https://github.com/pravega/pravega/wiki/PDP-34:-CRWD-Tier-2

Design Objectives

Goals

• Support additional cloud storage options by simplifying the API contract and requirements on the tier-2 storage bindings.