Deep Engineering

MEASUREMENT

bench/valkey-cluster/runs/databases.txt

The script that produced the numbers in the article, and the record of the run. The file is read from the repository at build time — this is the code that was run, not a copy of it.

Cited in
/en/system-design/caching/valkey-clustering

The run below is recorded in Russian. It is a lab record, kept in the language it was written in; the numbers, the tables and the code read the same either way.

Record of the run

This measurement has no recorded run — only the script.

Script

90 lines
Valkey 9.1.2 · один хост, процессы на случайных портах
два кластера, отличающиеся одной строкой конфига: cluster-databases 1 и 16

14. СКОЛЬКО БАЗ В КЛАСТЕРЕ, РЕШАЕТ НАСТРОЙКА, А НЕ РЕЖИМ
----------------------------------------------------------------------
  кластер А: cluster-databases            1
  кластер Б: cluster-databases            16

  кластер А (по умолчанию): SELECT 0      OK
  кластер А (по умолчанию): SELECT 1      ERR DB index is out of range
  кластер А (по умолчанию): SELECT 15     ERR DB index is out of range
  кластер А (по умолчанию): SELECT 16     ERR DB index is out of range

  кластер Б (16 баз): SELECT 0            OK
  кластер Б (16 баз): SELECT 1            OK
  кластер Б (16 баз): SELECT 15           OK
  кластер Б (16 баз): SELECT 16           ERR DB index is out of range


  Два кластера отличаются одной строкой конфига, и ответы на одну и ту
  же команду у них разные. Значит, `ERR DB index is out of range` в
  кластере А — не «в кластере баз не бывает», а «в ЭТОМ кластере база
  настроена одна».
  
  Разница между этими двумя прочтениями и есть содержание блока. Первое
  — правило Redis и Valkey до 9.0, и оно до сих пор кочует по статьям.
  Второе — то, что на самом деле происходит на Valkey 9.
  
  Обратите внимание и на то, что НЕ изменилось: значение по умолчанию
  осталось единицей. Кластер, поднятый обычным способом, ведёт себя
  по-старому, и именно поэтому старое правило так долго выглядит
  верным.

15. НОМЕР БАЗЫ НЕ УЧАСТВУЕТ В ВЫЧИСЛЕНИИ СЛОТА
----------------------------------------------------------------------
  узел-владелец слота ключа foo           127.0.0.1:51799

  в базе 0: SET foo db0                   OK
  в базе 1: SET foo db1                   OK

  в базе 0: GET foo                       db0
  в базе 1: GET foo                       db1

  в базе 0: CLUSTER KEYSLOT foo           12182
  в базе 1: CLUSTER KEYSLOT foo           12182

  Один ключ, два значения, один слот. Это и есть модель данных Valkey 9:
  адресация по-прежнему двухшаговая — ключ в слот, слот в узел, — а база
  добавляется ТРЕТЬИМ измерением уже внутри узла и на выбор узла не
  влияет вовсе.
  
  Практическое следствие приятное: разнести окружения по базам в
  кластере можно, и раскладка данных по узлам от этого не изменится ни
  на ключ. Практическое следствие неприятное — в следующем блоке.

16. ЧТО НЕ ИЗМЕНИЛОСЬ: ЗАПРЕТЫ И ГРАНИЦА ВИДИМОСТИ
----------------------------------------------------------------------
  SWAPDB 0 1                              ERR SWAPDB is not allowed in cluster mode

  в базе 1 записаны три ключа, разошедшиеся по трём узлам:
      CLUSTER KEYSLOT foo                 12182
      CLUSTER KEYSLOT bar                 5061
      CLUSTER KEYSLOT user:1              10778

  что отвечает DBSIZE в базе 1 на каждом узле:
      узел 37191                          1
      узел 50991                          1
      узел 51799                          1

  SCAN в базе 1 на узле-владельце         0 foo
  SCAN в базе 1 на узле 37191             0 bar

  Три вещи разом, и все три — против обратного мифа «раз базы появились,
  они работают как в одиночном узле».
  
  Первое: SWAPDB как был запрещён, так и остался, и текст отказа прямо
  называет причину — режим. Обменять базы на одном шарде значило бы
  рассогласовать его с остальными.
  
  Второе и главное: DBSIZE и SCAN считают не базу целиком, а её часть НА
  ТОМ УЗЛЕ, куда пришла команда. Три ключа записаны в одну базу и
  разошлись по трём узлам — и ни один узел не видит всех трёх. То же
  касается FLUSHDB.
  
  Отсюда правило, которое стоит унести: нумерованная база в кластере —
  это пространство имён, а не отдельное хранилище. Она не даёт ни
  изоляции ресурсов, ни общего на кластер представления о своём
  содержимом.