"Cassandra: установка на VPS"

MAATRIX

Если вы ищете, как поставить Cassandra на сервер, скорее всего у вас уже есть проект с большим потоком записи или требование к отказоустойчивости без единой точки сбоя. Ниже — рабочая установка на одном VPS: пакетом или через Docker, с базовой конфигурацией и первым запросом. Заодно честно разберём, когда одна нода Cassandra вообще имеет смысл, а когда лучше сразу смотреть в сторону PostgreSQL или MySQL.

Что такое Cassandra и зачем она вообще нужна

Apache Cassandra — распределённая NoSQL база данных с архитектурой без единой точки отказа (масштабируется, реплицируется между нодами и продолжает работать, если часть узлов недоступна. Разработана в Facebook, сейчас развивается Apache Foundation.

Ключевые особенности:

• Peer-to-peer архитектура. Все ноды кластера равноправны, нет выделенного мастера — в отличие от классической схемы master-replica в PostgreSQL или MySQL.
• Линейная масштабируемость. Добавили ноду — увеличили и объём хранения, и пропускную способность записи. Без переразбиения на шарды вручную.
• Модель данных wide-column. Таблицы с гибкой схемой колонок, партиционированием по ключу и кластеризацией внутри партиции — не реляционная модель, JOIN'ов нет.
• Настраиваемая консистентность. На каждый запрос можно задать уровень (ONE, QUORUM, ALL) — компромисс между скоростью и надёжностью выбираете сами.
• Оптимизация под запись. LSM-based storage engine (аналогично RocksDB) — Cassandra особенно хорошо переваривает большие объёмы вставок и обновлений.

Типичные сценарии: временные ряды (метрики, логи, IoT-телеметрия), каталоги с огромным числом записей, системы сообщений и уведомлений, любые нагрузки с очень высокой интенсивностью записи и предсказуемыми запросами по ключу.

Cassandra на одном VPS: честно о плюсах и ограничениях

Прежде чем ставить — важный момент, который часто замалчивают в мануалах. Cassandra спроектирована для кластера из нескольких нод. Именно репликация между узлами даёт отказоустойчивость и горизонтальное масштабирование — то, ради чего люди вообще выбирают эту базу.

На одном VPS вы получаете:

• Тот же формат хранения и язык запросов (CQL), что и в продакшен-кластере — удобно для разработки и тестирования схемы данных.
• Модель данных, ориентированную на запись, если она вам действительно нужна.
• Возможность позже добавить ноды и превратить одиночный сервер в полноценный кластер.

Но при этом теряете главное преимущество — отказоустойчивость и распределённую нагрузку. Одна нода Cassandra — это единая точка отказа, притом с более тяжёлым потреблением ресурсов (JVM, компакция, репейр), чем у классической реляционной БД на сравнимой нагрузке.

Честный вывод: если вам нужен один сервер под одно приложение — почти всегда разумнее взять PostgreSQL или MySQL, они легче, экономнее по памяти и проще в администрировании на единственной машине. Cassandra оправдана, когда вы реально планируете распределённую инфраструктуру — 3+ ноды, репликацию между дата-центрами или zones, нагрузку, которая не влезает в одну машину. Если сомневаетесь, посмотрите сравнение PostgreSQL и MySQL — для большинства проектов этого достаточно.

Если решение принято и Cassandra действительно нужна — переходим к установке.

Требования к серверу и подготовка VPS

Cassandra работает на JVM и заметно требовательнее к памяти, чем реляционные базы. Минимальные и рекомендуемые параметры:

Диск обязательно SSD/NVMe — Cassandra активно пишет в commit log и периодически выполняет compaction, на HDD она задыхается уже на небольшой нагрузке.

Подготовка сервера — обновление, часовой пояс, файервол:

sudo apt update && sudo apt upgrade -y
sudo timedatectl set-timezone UTC
sudo apt install -y ufw
sudo ufw allow OpenSSH
sudo ufw allow 9042/tcp   # клиентский порт CQL
sudo ufw enable

Если сервер смотрит в интернет напрямую, порт 9042 (и тем более 7000/7001 для межнодового трафика) лучше не открывать наружу вообще — ограничьте доступ конкретными IP или держите Cassandra в приватной сети. Базовые шаги по укреплению системы описаны в статье про защиту сервера от взлома с нуля.

Установка Cassandra: официальный пакет vs Docker

Два рабочих пути. Первый ставит Cassandra как системный сервис — подходит, если планируете использовать её постоянно. Второй — Docker-образ — быстрее для теста и проще для изоляции, но следить за диском и памятью в контейнере тоже придётся.

Вариант 1: официальный APT-репозиторий (Ubuntu/Debian)

# Java обязательна — ставим OpenJDK 17
sudo apt install -y openjdk-17-jdk
java -version

# добавляем официальный ключ и репозиторий Apache Cassandra
curl -fsSL https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o /usr/share/keyrings/cassandra-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/cassandra-archive-keyring.gpg] https://debian.cassandra.apache.org 41x main" | sudo tee /etc/apt/sources.list.d/cassandra.sources.list

sudo apt update
sudo apt install -y cassandra

Версию в строке репозитория (41x для ветки 4.1.x) уточните на официальной странице загрузок Apache Cassandra на момент установки — ветки время от времени меняются, а зашитый в мануал номер быстро устаревает.

После установки сервис стартует автоматически:

sudo systemctl status cassandra
sudo systemctl enable cassandra

Первый запуск занимает время — JVM инициализирует систему хранения, создаёт токен-кольцо для одной ноды. Проверить, что нода поднялась и видит себя в кольце:

nodetool status

Статус UN (Up/Normal) в выводе — нода жива и готова принимать запросы.

Вариант 2: Docker-образ

Если нужен быстрый тест без установки Java и системного сервиса — официальный образ на Docker Hub:

docker run -d \
  --name cassandra \
  -p 9042:9042 \
  -e CASSANDRA_CLUSTER_NAME=MyCluster \
  -v cassandra-data:/var/lib/cassandra \
  cassandra:latest

Именованный volume (cassandra-data) обязателен — без него данные исчезнут при пересоздании контейнера. Если Docker на сервере ещё не стоит, разверните его по инструкции установка Docker с нуля на Ubuntu 24.04.

Проверка, что контейнер запустился и нода готова:

docker logs -f cassandra
# ждём строку "Starting listening for CQL clients"
docker exec -it cassandra nodetool status

Для теста Docker-вариант удобнее — поднял, проверил, снёс docker rm -f cassandra без следов в системе. Для постоянной эксплуатации на выделенном сервере пакетная установка даёт больше контроля над JVM-параметрами и системными лимитами (ulimits, swap).

Базовая конфигурация cassandra.yaml

Основной конфиг лежит в /etc/cassandra/cassandra.yaml (пакетная установка) или монтируется в контейнер при Docker-установке. Для одной ноды достаточно поправить несколько параметров:

# имя кластера — должно совпадать на всех нодах, если их несколько
cluster_name: 'MyCluster'

# сколько данных хранит эта нода при добавлении новых узлов
num_tokens: 16

# адрес, на котором нода слушает межнодовый трафик (gossip)
listen_address: <внутренний_IP_сервера>

# адрес для клиентских подключений (cqlsh, драйверы)
rpc_address: 0.0.0.0
broadcast_rpc_address: <внешний_или_внутренний_IP>

# каталоги хранения — вынесите на быстрый диск
data_file_directories:
    - /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog

# seed-ноды — при одной ноде указываем саму себя
seed_provider:
    - class_name: org.apache.cassandra.locator.SimpleSeedProvider
      parameters:
          - seeds: "<внутренний_IP_сервера>"

Важные нюансы:

• listen_address не должен быть localhost — Cassandra использует его для внутрикластерного gossip-протокола, даже если нода одна. Укажите реальный внутренний IP сервера.
• Если сервер видит только один сетевой интерфейс, можно заменить listen_address на listen_interface: eth0 — тогда Cassandra сама возьмёт IP интерфейса.
• Значение num_tokens: 16 — разумный дефолт для новых кластеров на современных версиях Cassandra (используется схема виртуальных нод). Для совсем маленького теста можно не трогать.
• JVM-память настраивается отдельно, в /etc/cassandra/jvm-server.options (или jvm11-server.options в старых версиях) — параметры -Xms и -Xmx. По умолчанию Cassandra сама вычисляет их от объёма RAM, но на VPS с 4 ГБ лучше явно ограничить heap, например, -Xms2G -Xmx2G, чтобы оставить памяти операционной системе и кэшу страниц.

После изменения конфига — перезапуск:

sudo systemctl restart cassandra
sudo systemctl status cassandra

Подключение через cqlsh и первый запрос

cqlsh — интерактивная консоль для CQL (Cassandra Query Language), синтаксически похожего на SQL, но без JOIN и подзапросов — модель данных здесь принципиально другая.

Для пакетной установки утилита уже в системе:

cqlsh <IP_сервера> 9042

Для Docker-контейнера:

docker exec -it cassandra cqlsh

Создаём keyspace (аналог схемы/базы в реляционном мире) и таблицу:

CREATE KEYSPACE demo
  WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 1};

USE demo;

CREATE TABLE users (
  user_id UUID PRIMARY KEY,
  email TEXT,
  created_at TIMESTAMP
);

INSERT INTO users (user_id, email, created_at)
  VALUES (uuid(), 'test@example.com', toTimestamp(now()));

SELECT * FROM users;

Обратите внимание на replication_factor: 1 — это осознанное решение для одной ноды. Как только (и если) вы добавите вторую и третью ноду в кластер, фактор репликации нужно будет повысить (обычно до 3) и выполнить nodetool repair, иначе новые ноды не получат существующие данные автоматически.

Полезные команды для диагностики уже работающей ноды:

nodetool status          # состояние кольца и нод
nodetool info            # heap, uptime, load
nodetool compactionstats # идущие фоновые компакции
nodetool tablestats demo.users  # статистика по конкретной таблице

Если после установки нода не поднимается или зависает на старте — почти всегда причина в нехватке памяти под JVM heap или в неверно указанном listen_address. Проверяйте логи первым делом:

sudo journalctl -u cassandra -f
# или для Docker:
docker logs -f cassandra

Частые вопросы