Baza klucz-wartość (ang. key-value store) to najprostszy model bazy NoSQL: dane trzymasz jako pary, gdzie unikalny klucz wskazuje na przypisaną mu wartość. Działa to dokładnie jak słownik (mapa, hash) w twoim ulubionym języku programowania — podajesz klucz, dostajesz wartość. Bez tabel, bez kolumn, bez relacji, bez JOIN. Klucz to zwykle string, a wartość może być czymkolwiek: liczbą, tekstem, JSON-em, a nawet serializowanym obiektem albo obrazkiem.
Jak to działa i do czego służy
Cała filozofia opiera się na trzech operacjach: zapisz wartość pod kluczem, pobierz wartość po kluczu, usuń. Baza nie zagląda do środka wartości i nie pozwala (zwykle) szukać po jej zawartości — interesuje ją tylko klucz. Dlatego pod spodem da się to zaimplementować jako wielką tablicę hashującą, co daje dostęp w praktyce w czasie stałym, O(1). To jest źródło legendarnej szybkości tego modelu.
Sprawdza się wszędzie tam, gdzie liczy się tempo, a nie skomplikowane zapytania: cache (pamięć podręczna), przechowywanie sesji użytkownika, liczniki, kolejki, rankingi czy feature flagi. Jeśli potrafisz wymyślić jednoznaczny klucz, pod którym schowasz dane — ten model jest dla ciebie.
Przykład z praktyki
Najpopularniejszym przedstawicielem jest Redis, baza trzymająca dane w pamięci RAM (in-memory), przez co bije rekordy szybkości. Klasyczne użycie to cache na sesje:
SET session:abc123 "user_42" EX 3600— zapisuje wartość pod kluczem i ustawia TTL na godzinę (po tym czasie klucz sam zniknie),GET session:abc123— odczytuje ją w ułamku milisekundy.
Inni gracze w tej kategorii to Memcached (czysty cache), Amazon DynamoDB czy etcd (konfiguracja klastrów Kubernetes).
Częste błędy i mity
Mit pierwszy: „skoro Redis trzyma dane w RAM, to je tracę po restarcie”. Nieprawda — Redis ma mechanizmy persystencji (RDB i AOF), choć faktycznie częściej używa się go jako cache niż jako jedyne źródło prawdy.
Pułapka druga: chęć wyszukiwania po wartości. Jeśli łapiesz się na tym, że chcesz pytać „daj mi wszystkich userów z miasta X”, to jest sygnał, że potrzebujesz innego modelu — relacyjnego albo dokumentowego. Tu projektujesz wokół klucza, nie wokół zapytań.
Trzeci grzech: brak konwencji nazewnictwa kluczy. Bez przemyślanego schematu typu obiekt:id:pole szybko utoniesz w chaosie.
Pojęcia powiązane: NoSQL, cache, TTL, baza dokumentowa, Redis, hash table, in-memory database.