Налаштування Apache Cassandra для високонавантажених веб-додатків

Конфігурація Apache Cassandra для веб-додатку потребує не просто встановлення пакета. Без грамотного проектування схеми та налаштувань кластера ви отримаєте повільні запити, гарячі партиції та нестабільну роботу під навантаженням. За 5 років роботи ми налаштували Cassandra для 30+ проектів: стрічки подій, метрики, логи. Найпоширеніша помилка — неправильний первинний ключ. Ігнорування компрессії та недостатня пам'ять для memtable призводять до падіння продуктивності в 2–3 рази. Правильне налаштування Cassandra з першого разу економить тижні переробок. Ділимося перевіреними прийомами.

Де Apache Cassandra незамінна

Часові ряди з мільйонами подій на секунду, стрічки активності, системи логування, IoT-телеметрія — там, де потрібно писати швидко та багато. Netflix, Discord, Apple використовують Cassandra саме для цього. Discord зберігає трильйони повідомлень. Для OLTP зі складними транзакціями — не підходить. Ми застосовуємо Cassandra для зберігання метрик та логів: вона дає лінійне масштабування запису та відмовостійкість без єдиної точки відмови.

Налаштування Cassandra 4.1: встановлення та конфігурація

Як встановити Cassandra 4.1?

1. Додайте репозиторій:

   echo "deb https://debian.cassandra.apache.org 41x main" > /etc/apt/sources.list.d/cassandra.sources.list
   

2. Імпортуйте ключ:

   curl https://downloads.apache.org/cassandra/KEYS | apt-key add -
   

3. Встановіть пакет:

   apt update && apt install -y cassandra
   

Після встановлення відредагуйте cassandra.yaml:

cluster_name: 'MyAppCluster'

# Мережа
listen_address: 10.0.0.1
rpc_address: 10.0.0.1
seeds: "10.0.0.1,10.0.0.2,10.0.0.3"

# Директорії
data_file_directories:
  - /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog  # окремий диск для швидкості
hints_directory: /var/lib/cassandra/hints
saved_caches_directory: /var/lib/cassandra/saved_caches

# Продуктивність
concurrent_reads: 32
concurrent_writes: 32
concurrent_counter_writes: 16
memtable_heap_space: 2048
compaction_throughput_mb_per_sec: 64

# Реплікація та консистентність
endpoint_snitch: GossipingPropertyFileSnitch

# JVM (в jvm11-server.options)
num_tokens: 256

Додатково налаштуйте JVM, щоб уникнути довгих GC-пауз:

# /etc/cassandra/jvm11-server.options
-Xms8G
-Xmx8G
-XX:+UseG1GC
-XX:G1RSetUpdatingPauseTimePercent=5
-XX:MaxGCPauseMillis=300
-XX:InitiatingHeapOccupancyPercent=70

Як вибрати стратегію компресії?

Порівняння стратегій ущільнення:

Вибір компрессії безпосередньо впливає на продуктивність читання та запису. Наприклад, TimeWindowCompactionStrategy зменшує кількість SSTable в 2–3 рази порівняно з SizeTieredCompactionStrategy при роботі з часовими рядами. Ми рекомендуємо TimeWindowCompactionStrategy для даних з TTL, а LeveledCompactionStrategy — для сценаріїв з інтенсивними оновленнями. Остання працює на 50% швидше за умови частих оновлень.

Орієнтуйтеся на характер даних. Якщо дані мають TTL і записуються з постійною швидкістю — TimeWindowCompactionStrategy. Для частих оновлень та видалень — LeveledCompactionStrategy. SizeTieredCompactionStrategy — безпечний вибір, якщо не впевнені.

Важливість правильного ключа партиціонування

Ключ партиціонування визначає розподіл даних по вузлах. Якщо він вибраний неправильно, одні вузли будуть перевантажені, інші простоюють. Наприклад, для таблиці user_events ми використовуємо user_id — це гарантує рівномірний розподіл. Для часових рядів (таблиця metrics) складений ключ (service, bucket, metric_name) дозволяє згрупувати метрики по сервісу та часовому вікну. Ніколи не використовуйте стовпці з малою кількістю унікальних значень (boolean або enum) — це призведе до гарячих партицій.

Схема даних — Query-driven design

-- Keyspace з реплікацією
CREATE KEYSPACE myapp
WITH replication = {
  'class': 'NetworkTopologyStrategy',
  'dc1': 3
} AND durable_writes = true;

USE myapp;

-- Стрічка подій користувача
CREATE TABLE user_events (
    user_id     uuid,
    occurred_at timestamp,
    event_id    uuid,
    event_type  text,
    payload     text,
    PRIMARY KEY ((user_id), occurred_at, event_id)
) WITH CLUSTERING ORDER BY (occurred_at DESC)
  AND compaction = {'class': 'TimeWindowCompactionStrategy',
                    'compaction_window_unit': 'DAYS',
                    'compaction_window_size': 7}
  AND default_time_to_live = 7776000;

-- Статистика по користувачах
CREATE TABLE user_stats (
    user_id     uuid PRIMARY KEY,
    total_orders counter,
    total_spent  counter,
    last_active  timestamp
);

-- Часові ряди метрик
CREATE TABLE metrics (
    service     text,
    bucket      timestamp,
    metric_name text,
    ts          timestamp,
    value       double,
    PRIMARY KEY ((service, bucket, metric_name), ts)
) WITH CLUSTERING ORDER BY (ts DESC)
  AND compaction = {'class': 'TimeWindowCompactionStrategy',
                    'compaction_window_unit': 'HOURS',
                    'compaction_window_size': 1};

Як інтегрувати Cassandra з Node.js?

import cassandra from 'cassandra-driver'

const client = new cassandra.Client({
  contactPoints: ['10.0.0.1', '10.0.0.2', '10.0.0.3'],
  localDataCenter: 'dc1',
  keyspace: 'myapp',
  credentials: { username: 'cassandra', password: process.env.CASSANDRA_PASSWORD! },
  pooling: {
    coreConnectionsPerHost: {
      [cassandra.types.distance.local]: 3,
      [cassandra.types.distance.remote]: 1
    }
  },
  socketOptions: { readTimeout: 12000 }
})

await client.connect()

const insertEvent = await client.prepare(`
  INSERT INTO user_events (user_id, occurred_at, event_id, event_type, payload)
  VALUES (?, ?, ?, ?, ?)
`)

const selectEvents = await client.prepare(`
  SELECT * FROM user_events
  WHERE user_id = ? AND occurred_at >= ? AND occurred_at <= ?
  ORDER BY occurred_at DESC
  LIMIT ?
`)

async function writeEvents(events: UserEvent[]) {
  const batch = events.map(e => ({
    query: insertEvent,
    params: [
      cassandra.types.Uuid.fromString(e.userId),
      new Date(e.occurredAt),
      cassandra.types.TimeUuid.now(),
      e.eventType,
      JSON.stringify(e.payload)
    ]
  }))
  await client.batch(batch, { prepare: true, logged: false })
}

async function* fetchEvents(userId: string, from: Date, to: Date) {
  const options = { prepare: true, fetchSize: 1000 }
  let pageState: Buffer | undefined
  do {
    const result = await client.execute(selectEvents,
      [cassandra.types.Uuid.fromString(userId), from, to, 1000],
      { ...options, pageState })
    yield result.rows
    pageState = result.pageState as Buffer | undefined
  } while (pageState)
}

Рівні консистентності

const { types: { consistencies } } = cassandra

await client.execute(insertEvent, params, { consistency: consistencies.localQuorum })
await client.execute(selectEvents, params, { consistency: consistencies.one })
await client.execute(criticalQuery, params, { consistency: consistencies.quorum })

Моніторинг та діагностика

nodetool status
nodetool tpstats
nodetool cfstats myapp.user_events
nodetool compactionstats
nodetool cleanup myapp

Увімкніть повільні запити в cassandra.yaml: slow_query_log_timeout_in_ms: 500.

Типові помилки та їх вирішення

• Гарячі партиції через неправильний ключ: використовуйте складені ключі з високою кардинальністю. Уникайте стовпців з малою кількістю значень.
• Високе споживання пам'яті: зменшіть memtable_heap_space або перемкніть G1GC на ParallelGC. Економія пам'яті до 30%.
• Повільний запис: перевірте диск для commitlog — використовуйте окремий SSD. Збільшіть concurrent_writes.

Практичні аспекти та варіанти співпраці

Типовий проект з трьома вузлами та інтеграцією займає 2–3 тижні. Включає аудит вимог, проектування схеми, розгортання кластера, оптимізацію конфігурації та написання адаптера для бекенда. Складні кластери з кількома дата-центрами можуть потребувати до 5 тижнів. Отримайте точну оцінку під вашу задачу — напишіть нам.

Ми виконали понад 30 проектів з Cassandra, включаючи системи метрик для рекламної платформи (100 млн подій на добу) та стрічки активності для SaaS-сервісу. У кожному проекті ми гарантуємо стабільну роботу кластера протягом місяця після здачі. Наші інженери мають 5+ років досвіду з Cassandra та суміжними технологіями. Зв'яжіться з нами для консультації — обговоримо вашу архітектуру безкоштовно.

Що входить в роботу

• Аудит поточної архітектури та вимог до навантаження
• Проектування схеми даних (query-driven design)
• Розгортання кластера (bare-metal / хмара / Docker)
• Оптимізація cassandra.yaml, JVM та мережевих налаштувань
• Інтеграція з бекендом (Node.js, Python, Go)
• Документація схеми та інструкції з експлуатації
• Навчання команди та рекомендації з експлуатації
• Гарантія стабільної роботи кластера протягом місяця після здачі

Замовте налаштування Cassandra під вашу задачу — отримайте консультацію інженера з 5-річним досвідом. Вартість типового проекту — від €2000.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.