Cassandra
Тема дорожной карты · Backend разработчик
Apache Cassandra — высокодоступная, линейно масштабируемая распределённая NoSQL база данных, разработанная для обработки огромной пропускной способности записи в нескольких центрах обработки данных без единой точки отказа. Одноранговая архитектура Cassandra и настраиваемая модель согласованности — управляемая для каждого запроса через CONSISTENCY QUORUM или CONSISTENCY ONE — делают её естественным выбором для данных временных рядов, потоков IoT-событий и высоконагруженных бэкенд-нагрузок на запись, при которых PostgreSQL или MySQL станут узкими местами в масштабе. Язык запросов Cassandra (CQL) напоминает SQL и доступен через cqlsh или драйверы для Python, Java, Go и Node.js, обеспечивая простую интеграцию с существующими микросервисами. Apache Cassandra прозрачно реализует шардинг базы данных через согласованное хэширование по кольцу узлов — добавление узлов увеличивает ёмкость без простоя, делая горизонтальное масштабирование предсказуемым и операционно простым. Cassandra хорошо сочетается с Apache Kafka для конвейеров event sourcing, где Kafka обрабатывает приём данных, а Cassandra сохраняет результирующее состояние в большом объёме; она стандартно развёртывается в Kubernetes с операторами вроде k8ssandra.
Как это работает
Cassandra покрывает document (MongoDB, CouchDB), key-value (Redis, DynamoDB, etcd), wide-column (Cassandra, HBase, ScyllaDB), graph (Neo4j, ArangoDB), search (Elasticsearch, OpenSearch). Каждая торгует ACID-гарантиями за конкретное свойство производительности или масштаба. Redis — универсальный швейцарский нож в памяти (кеш, очередь, pub/sub, distributed lock). Elasticsearch доминирует в full-text. MongoDB подходит для гибких JSON-данных, но требует дисциплины денормализации.
Когда применять
Redis — для кеша + rate limit + простых очередей: окупается в большинстве стеков. Elasticsearch / OpenSearch — когда нужен full-text за пределами LIKE %x%. MongoDB или DynamoDB — только если access-паттерн реально не ложится в реляционную модель (высокая частота записи на айтем, очень разнородные документы). Избегайте NoSQL "ради масштаба" до измерения боттлнека в Postgres — преждевременная оптимизация тут реальна.
Типичные ошибки
Ловушки Cassandra: MongoDB для реляционных данных ("гибкая схема" прячет связи — joins становятся application-side N+1); Redis как единственное durable-хранилище (это в основном память; persistence с оговорками); Elasticsearch как primary-БД (медленные апдейты, нет транзакций — индексируйте из Postgres); выбор NoSQL по хайпу, а не по read/write-паттернам. Определяйте запросы до хранилища.