Максимизация производительности ScyllaDB

Здравствуйте!

Меня зовут Александр Андреев, я старший инженер данных. В своей первой статье на "Хабре" я хочу рассказать об оптимизации производительности NoSQL базы данных ScyllaDB.

Введение в ScyllaDB

ScyllaDB — это высокопроизводительная распределённая NoSQL база данных, совместимая с Apache Cassandra на уровне протокола, но предлагающая значительно более высокую пропускную способность и меньшую задержку. В отличие от Cassandra, которая написана на Java, ScyllaDB реализована на C++ с использованием фреймворка Seastar, что позволяет ей эффективно использовать все ресурсы современных многоядерных серверов без накладных расходов на сборку мусора.

ScyllaDB подходит для приложений, требующих обработки больших объёмов данных в реальном времени, таких как системы аналитики, IoT или платформы потоковой передачи данных.

Ключевые преимущества ScyllaDB:

• До 10x выше пропускная способность по сравнению с Cassandra

• До 5x ниже задержка, особенно на 99-перцентиле

• Полная совместимость с экосистемой Cassandra (CQL, драйверы, инструменты)

• Автоматическая настройка и управление

Почему оптимизация производительности ScyllaDB так важна? Даже при использовании высокопроизводительной базы данных неправильно спроектированная модель данных или неэффективные запросы могут создать серьезные узкие места. Результат – перегрузка памяти, неравномерное распределение нагрузки и повышенные задержки, что сводит на нет преимущества ScyllaDB.

Оптимизация производительности запросов к ScyllaDB критически важна для обеспечения низкой задержки и высокой пропускной способности. Неправильное моделирование данных или неэффективные запросы могут привести к узким местам, таким как горячие точки (hot spots) или перегрузка отдельных партиций. В этой статье мы рассмотрим ключевые аспекты оптимизации, включая архитектуру, моделирование данных, техники запросов, мониторинг и настройку оборудования.

Архитектура ScyllaDB и её влияние на производительность

Shard-Per-Core: ключ к производительности

Основа высокой производительности ScyllaDB — уникальная архитектура "shard-per-core", где каждое физическое ядро процессора работает с собственным изолированным шардом данных:

Ядро CPU 1 ──► Шард 1 ──► Выделенные память и дисковое пространство
Ядро CPU 2 ──► Шард 2 ──► Выделенные память и дисковое пространство
...
Ядро CPU N ──► Шард N ──► Выделенные память и дисковое пространство

Это "shared-nothing" подход, где ядра не делят данные, а обмениваются ими асинхронно, что позволяет:

1. Исключить блокировки и конкуренцию за ресурсы между потоками

2. Минимизировать переключения контекста

3. Оптимизировать работу кэша процессора

В отличие от Cassandra, где потоки виртуальной машины Java конкурируют за ресурсы CPU, архитектура ScyllaDB обеспечивает предсказуемую производительность даже при высоких нагрузках.

Tablets vs. vNodes: новый подход к распределению данных

Данные в ScyllaDB распределяются по узлам в виде виртуального кольца, используя виртуальные узлы (vNodes). Начиная с версии 6.0, ScyllaDB внедрила концепцию "Tablets" — более гибкую альтернативу традиционным виртуальным узлам:

vNodes (традиционный подход):

• Каждый узел содержит 256 виртуальных узлов по умолчанию

• Фиксированное количество vNodes с начальной привязкой к узлам

• Ограниченные возможности перебалансировки

Tablets (новый подход):

• Более мелкое дробление сегментов данных

• Динамическое перемещение между физическими узлами

• Автоматическая балансировка нагрузки в режиме реального времени

• Более эффективное восстановление при сбоях

# Пример проверки режима распределения данных в Python
from cassandra.cluster import Cluster

cluster = Cluster(['scylla-node-1', 'scylla-node-2'])
session = cluster.connect()

# Проверка использования режима Tablets
result = session.execute("SELECT tablets_enabled FROM system.local")
print(f"Tablets enabled: {result.one().tablets_enabled}")

Хранилище данных:

ScyllaDB использует memtable для хранения данных в памяти, commitlog для обеспечения долговечности и SSTables для постоянного хранения на диске. Это позволяет оптимизировать операции чтения и записи.

Пути чтения и записи: оптимизация всех уровней

Чтение в ScyllaDB обходит кэш Linux, используя собственный кэш на основе строк, а запись одновременно сохраняется в memtable и commitlog, что обеспечивает высокую производительность.

ScyllaDB оптимизирует как пути чтения, так и пути записи:

Путь записи:

1. Асинхронная запись в commitlog для долговечности

2. Параллельная запись в memtable для быстрого доступа

3. Периодический сброс memtable в SSTable на диск

4. Фоновая компактификация SSTables для оптимизации хранения

Путь чтения:

1. Поиск в memtable (в памяти)

2. Проверка row cache (кэш на уровне строк)

3. Чтение из SSTables с оптимизированным индексом Bloom фильтров

4. Интеллектуальное предсказание и предзагрузка данных

Оба процесса реализованы с использованием неблокирующих операций ввода-вывода, что исключает время ожидания и максимизирует пропускную способность.

Лучшие практики моделирования данных

Выбор ключей партиций: фундамент производительности

Ключ партиции — наиболее важное решение при проектировании таблиц в ScyllaDB, так как определяет распределение данных по кластеру.

Правило №1: Высокая кардинальность

Ключи партиции должны иметь большое количество уникальных значений, чтобы обеспечить равномерное распределение данных и избежать горячих точек.

Например, использование уникальных идентификаторов, таких как user_id или sensor_id, предпочтительнее, чем низкокардинальные значения, такие как state или event_type. Плохой выбор ключа может привести к неравномерной нагрузке на узлы.

-- Неэффективно: слишком мало уникальных значений (кардинальность)
CREATE TABLE user_events (
    event_type TEXT,  -- Всего ~10 типов событий
    event_time TIMESTAMP,
    user_id UUID,
    data TEXT,
    PRIMARY KEY (event_type, event_time, user_id)
);

-- Эффективно: высокая кардинальность ключа партиции
CREATE TABLE user_events (
    user_id UUID,
    event_type TEXT,
    event_time TIMESTAMP,
    data TEXT,
    PRIMARY KEY (user_id, event_time, event_type)
);

Правило №2: Равномерное распределение запросов

Ключи партиций должны выбираться не только для равномерного распределения данных, но и с учетом паттернов запросов. Идеальный ключ партиции имеет следующие свойства:

• Данные равномерно распределены по всем узлам

• Запросы равномерно распределены по всем партициям

• Доступ к данным происходит преимущественно по ключу партиции

Борьба с большими партициями: стратегия бакетирования

Большие партиции (>100MB или >100,000 строк) увеличивают задержки и давление на память и могут привести к таймаутам. Для ограничения их размера используйте технику бакетирования, добавляя, например, дату к ключу партиции.

Бакетирование по времени (здесь данные делятся по датам, что ограничивает размер партиций):

-- Бакетирование данных датчиков по дням
CREATE TABLE sensor_readings (
    sensor_id TEXT,
    date TEXT,  -- YYYY-MM-DD формат
    timestamp TIMESTAMP,
    temperature FLOAT,
    humidity FLOAT,
    pressure FLOAT,
    PRIMARY KEY ((sensor_id, date), timestamp)
);

Такая структура позволяет эффективно запрашивать данные за определенный день:

SELECT * FROM sensor_readings 
WHERE sensor_id = 'temp_sensor_1' AND date = '2025-05-01' 
AND timestamp > '2025-05-01 08:00:00' AND timestamp < '2025-05-01 09:00:00';

Бакетирование по диапазону значений:

-- Бакетирование пользовательских сообщений по 100
CREATE TABLE user_messages (
    user_id UUID,
    bucket_id INT,  -- вычисляется как message_id / 100
    message_id UUID,
    content TEXT,
    created_at TIMESTAMP,
    PRIMARY KEY ((user_id, bucket_id), message_id)
);

А вот как делать бакетирование на Python:

# Python-код для работы с бакетированием
def insert_message(session, user_id, message_id, content):
    # Вычисляем bucket_id на основе хеша message_id
    bucket_id = abs(hash(str(message_id))) % 1000
    
    query = """
    INSERT INTO user_messages 
    (user_id, bucket_id, message_id, content, created_at) 
    VALUES (%s, %s, %s, %s, toTimestamp(now()))
    """
    session.execute(query, (user_id, bucket_id, message_id, content))

Умное использование коллекций и счетчиков

Замороженные коллекции для статических данных:

Коллекции (списки, множества, словари) следует использовать для небольших объёмов данных. Для статических данных предпочтительны замороженные (FROZEN) коллекции, чтобы избежать накладные расходы (overhead) на сериализацию.

-- Использование FROZEN для неизменяемых атрибутов
CREATE TABLE products (
    product_id UUID,
    name TEXT,
    attributes FROZEN<MAP<TEXT, TEXT>>,  -- FROZEN важен для производительности
    PRIMARY KEY (product_id)
);

CREATE TABLE sensor_data (
    sensor_id uuid,
    record_time timestamp,
    events FROZEN<map<text, text>>,
    PRIMARY KEY (sensor_id, record_time)
);

Использование счетчиков в отдельных таблицах:

-- Таблица со счетчиками
CREATE TABLE post_stats (
    post_id UUID,
    views COUNTER,
    likes COUNTER,
    comments COUNTER,
    PRIMARY KEY (post_id)
);

# Интенсивное обновление счетчиков
def increment_view(session, post_id):
    query = "UPDATE post_stats SET views = views + 1 WHERE post_id = %s"
    # Уровень согласованности ONE для счетчиков уменьшает нагрузку
    session.execute(query, [post_id], consistency_level=ConsistencyLevel.ONE)

Предотвращение горячих точек с использованием PPRL

Горячие точки возникают при частом обращении к одним и тем же ключам. Для их устранения используйте бакетирование, добавляйте монотонно возрастающие компоненты (например, временные метки) или устанавливайте ограничения скорости на уровне партиций (Per-Partition Rate Limit).

ScyllaDB Enterprise предлагает уникальную функцию ограничения скорости на уровне партиций (Per-Partition Rate Limiting, PPRL), которая защищает от перегрузки отдельных партиций:

-- Ограничение в 1000 запросов в секунду на партицию
ALTER TABLE users WITH per_partition_rate_limit = {'max_read_size' : 1000, 'max_write_size' : 500};

Эта функция особенно полезна для защиты от:

• DDoS-атак на конкретные партиции

• Непредсказуемых всплесков трафика к популярным данным

• Перегрузки при обновлении часто запрашиваемых записей

Техники оптимизации запросов

Подготовленные запросы: основа высокой производительности

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

1. Кэшируются в ScyllaDB

2. Устраняют накладные расходы на разбор запроса

3. Защищают от SQL-инъекций

Пример:

session.prepare("SELECT * FROM users WHERE user_id=?")

# Неоптимальный подход
def get_user_bad(session, user_id):
    query = f"SELECT * FROM users WHERE user_id = {user_id}"
    return session.execute(query)

# Оптимальный подход с подготовленным запросом
def get_user_good(session, user_id):
    # Подготовленный запрос кэшируется при первом использовании
    prepared = session.prepare("SELECT * FROM users WHERE user_id = ?")
    return session.execute(prepared, [user_id])

Пагинация запросов: защита от перегрузки памяти

Для больших наборов данных используйте параметр fetch_size, чтобы ограничить объём возвращаемых данных за один запрос.

Пример:

SimpleStatement(query, fetch_size=10)

# Эффективная пагинация для обработки больших наборов данных
def process_all_users(session):
    query = "SELECT user_id, name, email FROM users"
    statement = SimpleStatement(query, fetch_size=100)
    
    result = session.execute(statement)
    page_num = 1
    
    for row in result:
        # Автоматическая подгрузка следующих страниц
        process_user(row)
        
        # Для отладки - вывод номера страницы
        if result.current_rows_index == 0 and result.has_more_pages:
            print(f"Processing page {page_num}")
            page_num += 1

Важно правильно выбрать размер страницы (fetch_size):

• Слишком маленький размер увеличит количество сетевых запросов

• Слишком большой размер может привести к перегрузке памяти

• Оптимальное значение обычно между 100 и 1000 строк

Правильное использование уровней согласованности

Выбор уровня согласованности влияет на баланс между производительностью и согласованностью данных:

from cassandra import ConsistencyLevel

# Запрос с высокой производительностью (низкая согласованность)
def quick_read(session, key):
    query = "SELECT * FROM cache WHERE key = %s"
    return session.execute(query, [key], consistency_level=ConsistencyLevel.ONE)

# Запрос с гарантированной согласованностью (средняя производительность)
def consistent_read(session, user_id):
    query = "SELECT * FROM users WHERE user_id = %s"
    return session.execute(query, [user_id], consistency_level=ConsistencyLevel.QUORUM)

# Запись с гарантированной долговечностью (низкая производительность)
def critical_write(session, transaction_id, data):
    query = "INSERT INTO transactions (id, data) VALUES (%s, %s)"
    return session.execute(query, [transaction_id, data], 
                          consistency_level=ConsistencyLevel.ALL)

Общие рекомендации по выбору уровня согласованности:

• ONE: Для некритичных записей или кэш-данных (самая высокая производительность)

• QUORUM: Для большинства операций чтения и записи (хороший компромисс)

• LOCAL_QUORUM: Для мультицентровых кластеров с локальными запросами

• ALL: Только для критических финансовых транзакций (самая низкая производительность)

Выбирайте уровень согласованности, такой как QUORUM, для баланса между производительностью и надёжностью. Избегайте ALL, так как он увеличивает задержки, и ONE, если требуется высокая доступность.

Пример: Для фактора репликации = 3 QUORUM требует ответа от двух узлов, что оптимально для большинства случаев.

Избегание смертельных антипаттернов

1. ALLOW FILTERING

Операция ALLOW FILTERING сканирует всю таблицу, что неэффективно. Вместо этого используйте индексы или проектируйте запросы так, чтобы они опирались на первичные ключи

-- НИКОГДА не используйте в продакшене:
SELECT * FROM users WHERE age > 21 ALLOW FILTERING;

Вместо этого создайте вторичную таблицу или индекс:

-- Вторичная таблица для фильтрации по возрасту
CREATE TABLE users_by_age (
    age INT,
    user_id UUID,
    name TEXT,
    email TEXT,
    PRIMARY KEY (age, user_id)
);

2. Использование множественных IN в запросах

-- Очень неэффективный запрос
SELECT * FROM users 
WHERE user_id IN (uuid1, uuid2, ..., uuid100) 
AND date IN ('2025-05-01', '2025-05-02', ..., '2025-05-10');

Вместо этого выполните несколько отдельных запросов или используйте пакетные запросы:

# Более эффективный подход - пакетный запрос
batch = BatchStatement(consistency_level=ConsistencyLevel.QUORUM)
for user_id in user_ids:
    stmt = session.prepare("SELECT * FROM users WHERE user_id = ?")
    batch.add(stmt, [user_id])
results = session.execute(batch)

3. Чрезмерное использование материализованных представлений

Материализованные представления добавляют накладные расходы на запись, поэтому их следует использовать с осторожностью:

-- Используйте только когда действительно необходимо
CREATE MATERIALIZED VIEW users_by_email AS
SELECT * FROM users
WHERE email IS NOT NULL AND user_id IS NOT NULL
PRIMARY KEY (email, user_id);

4. Использование BYPASS CACHE

Для редких запросов, которые не выигрывают от кэширования, используйте BYPASS CACHE, чтобы напрямую обращаться к диску:

SELECT * FROM users BYPASS CACHE;

Мониторинг и профилирование запросов

Настройка ScyllaDB Monitoring Stack

Для выявления узких мест используйте ScyllaDB Monitoring Stack, который включает Prometheus и Grafana с кастомными дашбордами (CQL Optimization Dashboard). Этот инструмент позволяет:

• Отслеживать состояние узлов кластера.

• Анализировать производительность запросов, выявляя неэффективные операции, такие как неподготовленные запросы или запросы с ALLOW FILTERING.

• Мониторить междатацентровые запросы, которые могут увеличивать задержки.

# docker-compose.yml для развертывания ScyllaDB Monitoring Stack
version: '3'
services:
  prometheus:
    image: prom/prometheus:v2.45.0
    volumes:
      - ./prometheus/:/etc/prometheus/
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
    ports:
      - '9090:9090'
    
  grafana:
    image: grafana/grafana:10.0.3
    volumes:
      - ./grafana/provisioning/:/etc/grafana/provisioning/
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=scylla
    ports:
      - '3000:3000'
    depends_on:
      - prometheus

В дополнение к стандартным дашбордам особенно полезны следующие:

• Per-Server Metrics Dashboard

• Scylla Detailed Dashboard

Ключевые метрики производительности

Наиболее важные метрики для мониторинга:

1. Latency (задержка операций):

   • scylla_storage_proxy_coordinator_write_latency_99p - p99 (99-перцентиль) задержки записи

   • scylla_storage_proxy_coordinator_read_latency_99p - p99 задержки чтения

2. Throughput (пропускная способность):

   • scylla_cql_reads - CQL операции чтения

   • scylla_cql_writes - CQL операции записи

3. Resource Utilization (использование ресурсов):

   • scylla_reactor_utilization - загрузка ядер CPU

   • node_filesystem_avail_bytes - доступное место на диске

4. Cache Performance (производительность кэша):

   • scylla_cache_row_hits - попадания в row cache

   • scylla_cache_row_misses - промахи row cache

Выявление проблемных запросов

ScyllaDB предлагает несколько инструментов для выявления неэффективных запросов:

-- Запрос для просмотра самых медленных запросов
SELECT * FROM system_traces.sessions 
WHERE duration > 5000000 
ALLOW FILTERING;

-- Просмотр детализированных трейсов
SELECT * FROM system_traces.events 
WHERE session_id = uuid('trace-id-from-previous-query');

Для более глубокого анализа используйте трассировку запросов в коде:

# Трассировка медленных запросов в Python
from cassandra.query import SimpleStatement

def trace_slow_query(session, query, params=None):
    statement = SimpleStatement(query, trace=True)
    result = session.execute(statement, params)
    trace = result.get_query_trace(max_wait=10.0)
    
    print(f"Трассировка запроса (общая задержка: {trace.duration/1000.0} мс):")
    for event in trace.events:
        print(f"{event.elapsed/1000.0} мс: {event.description}")

Настройка оборудования и конфигурации

Выбор оптимального оборудования

ScyllaDB характеризуется высокой эффективностью использования оборудования, но определенные конфигурации работают лучше других:

Рекомендованное оборудование:

• CPU: Минимум 8 физических ядер, предпочтительно Intel Xeon или AMD EPYC

• RAM: 64GB+ (минимум 16GB на один узел)

• Диск: NVMe SSD с высокими IOPS (>100000) для рабочих нагрузок с интенсивным вводом-выводом

• Сеть: 10+ Gbps для кластеров с высокой нагрузкой

В AWS:

• i4i.2xlarge или i4i.4xlarge для большинства рабочих нагрузок

• i4i.8xlarge для рабочих нагрузок с очень интенсивными операциями ввода-вывода

В GCP:

• n2-standard-8 с локальными SSD для сбалансированных рабочих нагрузок

• c3-standard-8 с локальными SSD для вычислительно-интенсивных нагрузок

Автоматическая настройка с помощью scylla_setup

ScyllaDB предоставляет скрипт scylla_setup для автоматической оптимизации различных параметров системы:

# Автоматическая настройка системы
sudo /opt/scylladb/scripts/scylla_setup --nic eth0 --setup-nic

# Проверка текущей конфигурации
sudo /opt/scylladb/scripts/scylla_config_check

Этот скрипт настраивает:

• Параметры ядра Linux (sysctl)

• Планировщик задач CPU

• Параметры I/O планировщика

• Настройки сети и прерываний

• Распределение прерываний по ядрам CPU

Тонкая настройка конфигурации ScyllaDB

Ключевые параметры конфигурации в /etc/scylla/scylla.yaml:

# Оптимизация для рабочей нагрузки с преобладанием операций чтения
row_cache_size_in_mb: 4096    # Увеличьте для рабочих нагрузок с интенсивным чтением
commitlog_segment_size_in_mb: 64

# Оптимизация для рабочей нагрузки с преобладанием операций записи
compaction_throughput_mb_per_sec: 256  # Увеличьте для мощных серверов
concurrent_writes: 128                  # 16 * количество ядер CPU

# Оптимизация для очень больших таблиц
compaction_strategy: LeveledCompactionStrategy
sstable_size_in_mb: 160

Тестирование производительности с помощью cassandra-stress

Регулярное тестирование производительности помогает выявить проблемы и оценить влияние изменений:

# Базовый тест производительности записи
cassandra-stress write n=10000000 -rate threads=50 -node scylla-node1,scylla-node2

# Тест производительности чтения с распределением Гаусса
cassandra-stress read n=1000000 cl=QUORUM -pop dist=gaussian\(1..10000000,5000000,1000000\) -node scylla-node1,scylla-node2

# Расширенный тест со смешанной рабочей нагрузкой
cassandra-stress mixed ratio\(write=1,read=3\) n=1000000 cl=QUORUM -pop dist=uniform\(1..10000000\) -schema keyspace=keyspace1 -mode native cql3 -rate threads=100 -node scylla-node1,scylla-node2

Для более реалистичных тестов создайте пользовательский профиль YAML, который моделирует вашу схему данных и паттерны запросов.

Устранение распространенных проблем производительности

Решение проблемы горячих партиций

Признаки горячей партиции:

• Высокие задержки для определенного набора запросов

• Перегрузка отдельных узлов

• Предупреждения о таймаутах в логах

# Скрипт для выявления горячих партиций
from cassandra.cluster import Cluster
from cassandra.query import named_tuple_factory
import time

cluster = Cluster(['node1', 'node2', 'node3'])
session = cluster.connect()
session.row_factory = named_tuple_factory

def find_hot_partitions(keyspace, table, min_requests=1000):
    query = """
    SELECT token_range, count, mean, 
           99p, max, total_latency, table_name
    FROM system_traces.scylla_node_rates
    WHERE keyspace_name = %s AND table_name = %s
    """
    results = session.execute(query, [keyspace, table])
    
    for row in results:
        if row.count > min_requests:
            print(f"Потенциальная горячая партиция: {row.token_range}")
            print(f"Запросов: {row.count}, Средняя задержка: {row.mean} мс")
            print(f"p99 задержка: {row.99p} мс, Макс. задержка: {row.max} мс")
            print("---")

# Пример использования
find_hot_partitions('mykeyspace', 'mytable', 5000)

Решение проблемы томбстоунов

Томбстоуны (маркеры удаленных данных) могут значительно снизить производительность чтения:

-- Поиск таблиц с большим количеством томбстоунов
SELECT keyspace_name, table_name,
       tombstone_scanned, 
       tombstone_scanned_ratio
FROM system.tombstone_histogram
WHERE tombstone_scanned > 1000
ALLOW FILTERING;

Решения:

1. Уменьшение TTL для данных

2. Регулярная компактификация (nodetool compact)

3. Переосмысление модели данных для минимизации удалений

4. Использование режима "компактного хранения" для старых данных

Оптимизация компактификации

Компактификация — ресурсоемкий процесс, который может влиять на производительность:

# Проверка текущих задач компактификации
nodetool compactionstats

# Настройка приоритета компактификации (в непиковые часы)
nodetool setcompactionthroughput 500

# Запуск основной компактификации в запланированное время
nodetool compact mykeyspace mytable

Рекомендации по стратегиям компактификации:

• SizeTieredCompactionStrategy: Для таблиц с преобладанием операций записи

• LeveledCompactionStrategy: Для таблиц с преобладанием операций чтения

• TimeWindowCompactionStrategy: Для временных рядов с окнами TTL

Заключение

Оптимизация производительности ScyllaDB — это многогранный процесс, охватывающий моделирование данных, настройку запросов, мониторинг и конфигурацию оборудования. Ключевые принципы:

1. Правильное моделирование данных:

   • Выбирайте ключи партиций с высокой кардинальностью

   • Используйте бакетирование для больших партиций

   • Проектируйте таблицы под конкретные запросы

2. Эффективные запросы:

   • Всегда используйте подготовленные запросы

   • Применяйте пагинацию для больших результатов

   • Выбирайте оптимальный уровень согласованности

3. Мониторинг и профилирование:

   • Настройте ScyllaDB Monitoring Stack

   • Отслеживайте задержки на высоких процентилях

   • Выявляйте и оптимизируйте проблемные запросы

4. Конфигурация оборудования:

   • Используйте быстрые NVMe диски

   • Обеспечьте достаточно RAM (минимум 16GB на узел)

   • Запустите scylla_setup для автоматической настройки системы

Следуя этим принципам, вы сможете полностью раскрыть потенциал ScyllaDB и обеспечить исключительную производительность для ваших приложений даже при экстремальных нагрузках.