Apache Cassandra – big data NoSQL dla aplikacji o wysokiej dostępności

Dlaczego Apache Cassandra jest ważna w erze big data

W 2018 roku przedsiębiorstwa borykają się z eksplozywnym wzrostem danych – od IoT po social media, objętość generowanych informacji rośnie wykładniczo. Tradycyjne relacyjne bazy danych osiągają swoje limity skalowalności, szczególnie przy zapisie milionów rekordów dziennie. Apache Cassandra została zaprojektowana właśnie z myślą o tych wyzwaniach – oferuje linearną skalowalność i wysoką dostępność bez kompromisów.

Czym jest Apache Cassandra i dlaczego powstała

Apache Cassandra to open-source’owa rozproszona baza danych NoSQL, pierwotnie stworzona przez Facebook w 2008 roku do obsługi inbox search. Obecnie jest używana przez Netflix, Apple, Spotify i setki innych firm do zarządzania petabajtami danych.

Kluczowe zalety Cassandry w kontekście big data:

• Liniowa skalowalność: dodanie nowego węzła zwiększa wydajność proporcjonalnie
• Wysoka dostępność: brak centralnego punktu awarii dzięki architekturze peer-to-peer
• Geograficzna replikacja: dane mogą być replikowane między data centers
• Tunable consistency: możliwość dostosowania poziomu spójności do potrzeb aplikacji
• Optimized for writes: doskonała wydajność zapisu, kluczowa dla aplikacji big data

Architektura Cassandry – peer-to-peer bez master węzłów

Jedną z największych innowacji Cassandry jest całkowite odejście od architektury master-slave znanej z MySQL czy MongoDB. Wszystkie węzły w klastrze Cassandry są równorzędne.

Consistent Hashing i Token Ring

Cassandra wykorzystuje consistent hashing do dystrybucji danych. Każdy węzeł odpowiada za określony zakres tokenów w pierścieniu, co zapewnia równomierne rozłożenie danych:

// Przykład: jak Cassandra determinuje lokalizację danych
public class TokenExample {
    // Partition key: user_id = "12345"
    // Hash MD5: 5994471abb01112afcc18159f6cc74b4
    // Token: 118059168096963894540361804555486654644
    // Węzeł odpowiedzialny: node-3 (token range: 113...142...)
    
    String partitionKey = "user_id:12345";
    long token = consistentHash(partitionKey);
    Node responsibleNode = tokenRing.findNode(token);
}

Replikacja i Fault Tolerance

Cassandra automatycznie replikuje dane na wiele węzłów zgodnie z konfiguracją replication factor. Domyślny RF=3 oznacza, że każdy rekord jest przechowywany na trzech różnych węzłach.

Kiedy wybrać Cassandrę – przypadki użycia w 2018

Cassandra nie jest rozwiązaniem uniwersalnym. Sprawdza się idealnie w określonych scenariuszach big data:

Porównanie z innymi bazami NoSQL (stan na 2018)

Modelowanie danych w Cassandrze – query-first approach

Największa różnica między SQL a Cassandrą to podejście do modelowania danych. W SQL normalizujemy dane i piszemy queries. W Cassandrze najpierw określamy queries, potem modelujemy tabele.

Praktyczny przykład – system blogowy

Załóżmy, że budujemy system blogowy obsługujący miliony postów dziennie. Kluczowe queries:

-- Query 1: Najnowsze posty użytkownika
SELECT * FROM posts WHERE user_id = ? ORDER BY created_at DESC LIMIT 10;

-- Query 2: Posty z określonej kategorii
SELECT * FROM posts WHERE category = ? ORDER BY created_at DESC LIMIT 20;

-- Query 3: Post details
SELECT * FROM posts WHERE post_id = ?;

Na podstawie tych queries projektujemy tabele w Cassandrze:

-- Tabela dla Query 1: posty użytkownika
CREATE TABLE posts_by_user (
    user_id UUID,
    created_at TIMESTAMP,
    post_id UUID,
    title TEXT,
    content TEXT,
    category TEXT,
    PRIMARY KEY (user_id, created_at, post_id)
) WITH CLUSTERING ORDER BY (created_at DESC);

-- Tabela dla Query 2: posty z kategorii  
CREATE TABLE posts_by_category (
    category TEXT,
    created_at TIMESTAMP,
    post_id UUID,
    user_id UUID,
    title TEXT,
    content TEXT,
    PRIMARY KEY (category, created_at, post_id)
) WITH CLUSTERING ORDER BY (created_at DESC);

-- Tabela dla Query 3: detale postu
CREATE TABLE posts_by_id (
    post_id UUID PRIMARY KEY,
    user_id UUID,
    title TEXT,
    content TEXT,
    category TEXT,
    created_at TIMESTAMP,
    tags SET
);

Implementacja z Java i Spring Boot

W 2018 roku najstabilniejszą opcją integracji Cassandry z Spring Boot jest wykorzystanie Spring Data Cassandra w wersji 2.0.

Konfiguracja projektu

    
        org.springframework.boot
        spring-boot-starter-data-cassandra
        2.0.5.RELEASE
    
    
        com.datastax.cassandra
        cassandra-driver-core
        3.6.0
    

# application.yml
spring:
  data:
    cassandra:
      contact-points: 
        - 127.0.0.1
        - 127.0.0.2
        - 127.0.0.3
      port: 9042
      keyspace-name: blog_system
      local-datacenter: datacenter1
      username: cassandra
      password: cassandra
      consistency-level: LOCAL_QUORUM
      serial-consistency-level: LOCAL_SERIAL

Model danych i Repository

@Table("posts_by_user")
public class PostByUser {
    
    @PrimaryKeyColumn(name = "user_id", type = PrimaryKeyType.PARTITIONED)
    private UUID userId;
    
    @PrimaryKeyColumn(name = "created_at", type = PrimaryKeyType.CLUSTERED, 
                     ordering = Ordering.DESCENDING)
    private LocalDateTime createdAt;
    
    @PrimaryKeyColumn(name = "post_id", type = PrimaryKeyType.CLUSTERED)
    private UUID postId;
    
    @Column("title")
    private String title;
    
    @Column("content")
    private String content;
    
    @Column("category")
    private String category;
    
    // konstruktory, gettery, settery
}

@Repository
public interface PostByUserRepository extends CassandraRepository {
    
    @Query("SELECT * FROM posts_by_user WHERE user_id = ?0 LIMIT ?1")
    List findRecentPostsByUser(UUID userId, int limit);
    
    @Query("SELECT * FROM posts_by_user WHERE user_id = ?0 AND created_at >= ?1")
    List findPostsByUserSince(UUID userId, LocalDateTime since);
}

Service layer z obsługą błędów

@Service
@Slf4j
public class BlogService {
    
    private final PostByUserRepository postByUserRepository;
    private final PostByCategoryRepository postByCategoryRepository;
    private final PostByIdRepository postByIdRepository;
    
    @Retryable(value = {DriverException.class}, maxAttempts = 3)
    public void createPost(CreatePostRequest request) {
        UUID postId = UUID.randomUUID();
        LocalDateTime now = LocalDateTime.now();
        
        try {
            // Zapisujemy do wszystkich trzech tabel - denormalizacja
            PostByUser postByUser = new PostByUser(
                request.getUserId(), now, postId, 
                request.getTitle(), request.getContent(), request.getCategory()
            );
            postByUserRepository.save(postByUser);
            
            PostByCategory postByCategory = new PostByCategory(
                request.getCategory(), now, postId, request.getUserId(),
                request.getTitle(), request.getContent()
            );
            postByCategoryRepository.save(postByCategory);
            
            PostById postById = new PostById(
                postId, request.getUserId(), request.getTitle(),
                request.getContent(), request.getCategory(), now
            );
            postByIdRepository.save(postById);
            
            log.info("Post created successfully: {}", postId);
            
        } catch (DriverException e) {
            log.error("Failed to create post: {}", e.getMessage());
            throw new BlogServiceException("Unable to create post", e);
        }
    }
    
    public List getUserRecentPosts(UUID userId, int limit) {
        return postByUserRepository.findRecentPostsByUser(userId, limit);
    }
}

Konfiguracja klastra produkcyjnego

Przejście z single-node development do klastra produkcyjnego wymaga przemyślenia kilku kluczowych aspektów.

Topology i replication strategy

-- Keyspace z replikacją multi-datacenter
CREATE KEYSPACE blog_system 
WITH REPLICATION = {
    'class': 'NetworkTopologyStrategy',
    'DC1': 3,  -- 3 repliki w głównym DC
    'DC2': 2   -- 2 repliki w backup DC
};

-- Konfiguracja dla single datacenter
CREATE KEYSPACE blog_system_dev
WITH REPLICATION = {
    'class': 'SimpleStrategy',
    'replication_factor': 3
};

Tuning parametrów JVM i Cassandry

# cassandra-env.sh - optymalizacja dla maszyn 32GB RAM
MAX_HEAP_SIZE="8G"
HEAP_NEWSIZE="2G"

# Dodatkowe parametry JVM dla produkcji
JVM_OPTS="$JVM_OPTS -XX:+UseG1GC"
JVM_OPTS="$JVM_OPTS -XX:MaxGCPauseMillis=200"
JVM_OPTS="$JVM_OPTS -XX:+UnlockExperimentalVMOptions"
JVM_OPTS="$JVM_OPTS -XX:+UseCGroupMemoryLimitForHeap"

# cassandra.yaml - kluczowe ustawienia
concurrent_reads: 32
concurrent_writes: 32  
memtable_allocation_type: heap_buffers
commitlog_sync: periodic
commitlog_sync_period_in_ms: 10000

Monitoring i troubleshooting

W środowisku produkcyjnym monitoring Cassandry jest kluczowy dla wczesnego wykrywania problemów.

Kluczowe metryki do monitorowania

• Read/Write latency: P95, P99 czasów odpowiedzi
• Pending tasks: backlog w thread pools
• Compaction: liczba pending compactions
• GC performance: czas i częstotliwość garbage collection
• Disk space: wykorzystanie per-node i per-keyspace
• Network: dropped messages między węzłami

# Przydatne komendy nodetool dla diagnostyki
nodetool status                    # Status wszystkich węzłów
nodetool tpstats                   # Thread pool statistics  
nodetool compactionstats           # Status kompakcji
nodetool cfstats blog_system       # Column family statistics
nodetool netstats                  # Network statistics
nodetool proxyhistograms           # Latency histograms

# Monitoring z JMX
nodetool sjk ttop -o PID,STATE,CPU,TIME,NAME | head -20

Najczęstsze problemy i rozwiązania

Performance i optymalizacja dla big data

Przy obsłudze rzeczywistych obciążeń big data, kilka praktyk może znacząco wpłynąć na wydajność:

Batch operations

// Efektywne batch processing
@Service
public class BatchInsertService {
    
    private final CassandraTemplate cassandraTemplate;
    private final int BATCH_SIZE = 100;
    
    public void processBulkInsert(List posts) {
        List> batches = Lists.partition(posts, BATCH_SIZE);
        
        for (List batch : batches) {
            BatchStatement batchStatement = new BatchStatement(BatchStatement.Type.UNLOGGED);
            
            for (PostByUser post : batch) {
                Statement insert = cassandraTemplate.createInsertQuery("posts_by_user", post);
                batchStatement.add(insert);
            }
            
            cassandraTemplate.execute(batchStatement);
        }
    }
}

Async queries dla wysokiej przepustowości

@Service
public class AsyncBlogService {
    
    private final CassandraTemplate cassandraTemplate;
    
    public CompletableFuture> getUserPostsAsync(UUID userId) {
        String query = "SELECT * FROM posts_by_user WHERE user_id = ? LIMIT 50";
        
        return cassandraTemplate.selectAsync(query, PostByUser.class, userId)
                .toCompletableFuture()
                .exceptionally(throwable -> {
                    log.error("Failed to fetch user posts: {}", throwable.getMessage());
                    return Collections.emptyList();
                });
    }
    
    // Paralelne zapytania do wielu tabel
    public CompletableFuture getUserDashboard(UUID userId) {
        CompletableFuture> posts = getUserPostsAsync(userId);
        CompletableFuture> comments = getUserCommentsAsync(userId);
        CompletableFuture stats = getUserStatsAsync(userId);
        
        return CompletableFuture.allOf(posts, comments, stats)
                .thenApply(v -> new UserDashboard(
                    posts.join(), comments.join(), stats.join()
                ));
    }
}

Przydatne zasoby:

• Oficjalna dokumentacja Apache Cassandra
• DataStax Java Driver 3.6 Documentation
• Spring Data Cassandra Reference
• Nodetool Command Reference
• The Last Pickle – Cassandra Best Practices

Czy masz doświadczenie z bazami NoSQL? Jakie największe wyzwania widzisz przy migracji z systemów relacyjnych do Cassandry? Podziel się swoimi przemyśleniami w komentarzach!