Google zbudowało zegar, który odpowiada przedziałem: „czas jest gdzieś pomiędzy tymi wartościami”
Spanner, globalna baza Google, potrzebuje mocnych gwarancji kolejności transakcji pomiędzy centrami danych. Zamiast udawać, że zegary są idealnie zsynchronizowane, Google stworzyło TrueTime — API jawnie pokazujące niepewność czasu. Wywołanie nie zwraca jednej liczby, lecz przedział, w którym z gwarancją ma znajdować się aktualny czas. Spanner wykorzystuje tę niepewność przy nadawaniu znaczników transakcjom. To wyjątkowo elegancki pomysł: niedoskonałość zegara nie zostaje ukryta pod pozorem dokładności, lecz staje się formalną informacją używaną przez algorytm.
Globalna baza potrzebuje czegoś więcej niż lokalnego zegarka
Spanner rozdziela dane po wielu lokalizacjach, a mimo to ma oferować transakcje z bardzo silną własnością zwaną external consistency. Jeśli jedna transakcja zakończy się przed rozpoczęciem drugiej, ich kolejność w bazie ma to odzwierciedlać. Przy zwykłych, niezależnych zegarach serwerów trudno byłoby oprzeć na timestampach tak silną gwarancję.
TrueTime nie mówi „jest dokładnie 12:00:00.123”
API zwraca dwa końce przedziału: najwcześniejszy i najpóźniejszy możliwy czas. Wielkość niepewności zależy od jakości synchronizacji. Artykuł Spanner opisuje infrastrukturę wykorzystującą m.in. GPS i zegary atomowe oraz synchronizację serwerów czasu. Kluczowe jest jednak nie to, że czas staje się idealny, lecz że system zna ograniczenie swojego błędu.
Niepewność staje się częścią kontraktu
Jeżeli aplikacja otrzymuje pojedynczy timestamp, łatwo zapomnieć, że on także ma błąd. TrueTime wymusza inną mentalność: każda decyzja oparta na czasie może uwzględnić zakres niepewności. To podobne do pomiaru laboratoryjnego, w którym wynik podaje się wraz z błędem pomiaru zamiast udawać nieskończoną precyzję.
Spanner wykorzystuje przedział do porządkowania transakcji
Przy commitowaniu transakcji koordynator wybiera timestamp zgodny z ograniczeniami TrueTime. Następnie może odczekać tak, aby wybrany timestamp był już na pewno w przeszłości według granicy niepewności. Dzięki temu system może powiązać logiczny porządek commitów z czasem rzeczywistym w sposób potrzebny do external consistency.
To odwrócenie typowego podejścia do błędu
Zwykle inżynier próbuje zmniejszyć błąd i ukryć go przed resztą systemu. TrueTime robi coś bardziej dojrzałego: zmniejsza błąd, ale jednocześnie go eksponuje. Dzięki temu wyższa warstwa wie, kiedy może podjąć bezpieczną decyzję. Niedoskonałość staje się danymi wejściowymi algorytmu zamiast niewidzialnym ryzykiem.
TrueTime oddziela precyzję od pewności
Najbardziej niezwykłe jest to, że przedział może być szerszy lub węższy, ale jego sens pozostaje formalny. System nie obiecuje „nasz zegar prawdopodobnie myli się najwyżej tyle”, lecz buduje protokół wokół granicy niepewności. To ważna różnica inżynierska: algorytm opiera bezpieczeństwo na znanym kontrakcie czasu, a nie na statystycznej nadziei, że zegary zwykle są blisko.
Lepsza infrastruktura czasu poprawia wydajność bazy
Jeśli niepewność TrueTime jest mniejsza, Spanner może krócej czekać w operacjach zależnych od tej granicy. Oznacza to, że fizyczna infrastruktura synchronizacji czasu staje się elementem performance engineering bazy danych. Zegar atomowy i GPS, zwykle kojarzone z metrologią, wpływają pośrednio na latencję transakcji aplikacji biznesowej. To wyjątkowe połączenie warstwy fizycznej z semantyką baz danych.
TrueTime pokazuje też różnicę między „synchronizujemy zegary” a „wiemy, jak dobrze są zsynchronizowane”. Druga własność jest znacznie mocniejsza dla algorytmu. Jeśli serwer tylko wierzy, że jego zegar jest dokładny, błąd może pozostać niewidoczny. Jeśli ma jawny przedział niepewności, może zachować bezpieczeństwo, nawet gdy przedział chwilowo się powiększy. System może wtedy zapłacić większym oczekiwaniem zamiast cicho złamać gwarancję kolejności.
To podejście ma znaczenie także dla awarii infrastruktury czasu. Jeśli źródła synchronizacji chwilowo stają się mniej pewne, właściwą reakcją nie musi być natychmiastowe zwrócenie błędnego „dokładnego” czasu. System może powiększyć granicę niepewności, co zwiększy koszt operacji zależnych od czasu, ale zachowa ich poprawność. Jest to bardzo charakterystyczna filozofia systemów niezawodnych: degraduj wydajność w kontrolowany sposób, zamiast ukrywać utratę pewności.