Baza kolumnowa (ang. wide-column store) to rodzaj bazy NoSQL, w której dane porządkujesz nie w sztywne wiersze i kolumny jak w SQL-u, tylko w tzw. rodziny kolumn (column families). Każdy wiersz ma swój klucz, a pod nim możesz trzymać dowolny, różny dla każdego wiersza zestaw kolumn. Brzmi jak tabela, ale w praktyce bliżej temu do gigantycznej, rozproszonej mapy klucz-wartość, gdzie wartością jest posortowany zbiór par kolumna-wartość.
Uwaga na pułapkę nazewniczą: baza kolumnowa (wide-column) to nie to samo co baza kolumnarna (columnar, np. ClickHouse czy Parquet), choć po polsku obie często wrzuca się do jednego worka. Kolumnarna trzyma dane fizycznie kolumna po kolumnie pod analitykę. Wide-column to model danych pod operacyjne, masowe zapisy i odczyty po kluczu.
Jak to działa i do czego to
Sercem zabawy jest model rozproszony. Dane dzielisz między wiele węzłów na podstawie partition key — to on decyduje, na której maszynie wyląduje wiersz. Dzięki temu dokładasz kolejne serwery i pojemność rośnie liniowo, bez jednego węzła-wąskiego-gardła. Stąd te bazy świetnie znoszą terabajty i petabajty danych oraz potężny strumień zapisów: logi, telemetria, zdarzenia IoT, feedy aktywności, time-series.
Cena za skalę? Projektujesz schemat pod konkretne zapytania, a nie pod ładny, znormalizowany model. Denormalizacja i duplikacja danych to tu norma, nie grzech. Większość takich baz oferuje też eventual consistency — po zapisie odczyt z innego węzła może przez chwilę zwrócić starą wartość.
Przykład z praktyki
Najpopularniejszy przedstawiciel to Apache Cassandra (inni z tej rodziny: HBase, ScyllaDB, Google Bigtable). Komunikujesz się z nią językiem CQL, łudząco podobnym do SQL-a:
CREATE TABLE zdarzenia (user_id uuid, ts timeuuid, akcja text, PRIMARY KEY (user_id, ts));
Tu user_id to partition key (rozkłada dane po klastrze), a ts to clustering key (sortuje zdarzenia w obrębie użytkownika). Odczyt SELECT * FROM zdarzenia WHERE user_id = ? LIMIT 50; jest błyskawiczny, bo trafia w jedną partycję. Pisze tu np. Netflix i Discord.
Częste błędy i mity
- Traktowanie tego jak SQL-a. Brak JOIN-ów, brak swobodnych
WHEREpo dowolnej kolumnie. Zaprojektujesz schemat źle = zapytanie albo nie zadziała, albo zrobi wolny full scan. - „NoSQL = zawsze szybsze”. Nie. Szybkie jest pod wzorzec dostępu, do którego je zaprojektowałeś.
- Hot partition. Zły partition key potrafi wepchnąć większość ruchu na jeden węzeł i zabić korzyść ze skalowania.
Pojęcia powiązane: NoSQL, klucz-wartość, partition key, denormalizacja, eventual consistency, CAP theorem, time-series, sharding.