Работал ли с NoSQL

А, ну это же моя любимая тема — NoSQL в продакшене! Ты знаешь, это как собрать зоопарк из экзотических тварей: каждый требует своего корма, своего вольера, а если что не так — сразу дохнет или сбегает. Овердохуища мороки, но когда всё летает — красота.

Вот на чём руки обломал:

• MongoDB: Это ж, бля, целая эпопея. Разворачивать шардированные кластеры — это вам не хуй с горы скатился. Репликасеты, конфиг-серверы, mongos-роутеры... Чуть порты напутал или хостам в DNS имена кривые дал — и всё, приехали. А ещё эта их аутентификация, где можно так наворотить ролей, что сам потом от себя охуеешь. Бэкапы через mongodump на терабайтах данных — это отдельная песня, на время выполнения которой можно сходить, выпить, вернуться и понять, что всё накрылось медным тазом из-за нехватки места. Но когда приложуха шпарит запросы по отбалансированным шардам — волнение ебать, красиво.

• Redis: А вот это, ёпта, наш парень. Быстрый, как укус гадюки. Но и подколов полно. Использовал и как кэш, и как брокер. Sentinel настраивал для отказоустойчивости — вроде просто, но если кворум потеряли, начинается пиздец, все ноды друг друга предателями считают. А Redis Cluster — это вообще хитрая жопа: данные по слотам разбросаны, клиент должен быть умным, чтобы не тыкаться в не тот узел. И главное — память! Забудешь политику вытеснения (eviction policy) настроить, он тихо так сожрёт всю оперативку и спокойно ляжет, сука. Мониторинг использования памяти стал моей второй религией.

• Elasticsearch: О, это король логов. Развернуть кластер для ELK — это как построить небольшой город. JVM-настройки — отдельный вид искусства: дашь мало памяти — он будет постоянно GC устраивать, дашь много — ОС его прибьёт. А настройка индексов и ILM-политик, чтобы старые логи сами архивировались и удалялись... Это нужно делать аккуратно, а то можно влететь так, что все данные за последний месяц хуй найдёшь. Но когда в Kibana всё красиво графиками рисуется — терпения ноль ебать, прямо гордость берёт.

• Cassandra / ScyllaDB: Вот тут уже серьёзная лига, распределённые кластеры. Настраивать стратегии репликации, чтобы данные не потерялись, если дата-центр чихнёт. Seed-ноды — это такие заводилы, без них кластер не соберётся. А мониторинг задержек и согласованности... Тут доверия ебать ноль к дефолтным настройкам, всё надо перепроверять и тестировать под нагрузкой.

Вот, смотри, как мы в кубере Redis впихиваем (упрощённо, конечно):

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis-headless
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:7-alpine
        command: ["redis-server", "/etc/redis/redis.conf"]
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: redis-config
          mountPath: /etc/redis/
        - name: redis-data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: redis-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

А вообще, суть DevOps-работы с этим добром: не просто развернуть. Это автоматизировать всё это хозяйство через Helm или Terraform, чтобы не руками тыкать. Это придумать, как их бэкапить, пока они работают. Это мониторить каждую их метрику, чтобы предсказать, когда память/диск/процессор упрётся в потолок (capacity planning это называется, звучит умно, а по факту — гадание на кофейной гуще, когда закупиться железом). В общем, весело, бля. Никогда не скучно.