Hyperdrive to zarządzana usługa pulowania połączeń (connection-pooling), która pozwala Workerom na bezpośrednią komunikację z bazami danych PostgreSQL – w tym z tymi korzystającymi z rozszerzenia pgvector do wyszukiwania wektorowego. Dzięki utrzymywaniu zestawu wielokrotnego użytku połączeń z bazą danych blisko serwera, Hyperdrive skraca narzut związany z procesem nawiązywania połączenia (handshake), który od dawna utrudnia obciążenia typu edge AI.
Dlaczego Workers i PostgreSQL kolidują
Cloudflare Workers działają jako krótkotrwałe funkcje JavaScript w dziesiątkach lokalizacji brzegowych (edge). Każde przychodzące żądanie rozpoczyna nowy proces, a standardowym wzorcem jest otwieranie nowego połączenia TCP z bazą danych backendową. PostgreSQL oczekuje jednak stabilnego połączenia dla każdego procesu klienta i ogranicza całkowitą liczbę jednoczesnych połączeń. Skutkuje to dwoma problemami:
- Wysoki koszt połączenia – nawiązanie połączenia wymaga kilku cykli komunikacji (round trips) w celu uwierzytelnienia i negocjacji protokołu. Te cykle dodają opóźnienia do każdego żądania.
- Limity połączeń – Workers mogą skalować się do tysięcy jednoczesnych wykonań, co szybko wyczerpuje pulę połączeń PostgreSQL i może doprowadzić do awarii bazy danych.
Jak Hyperdrive wypełnia tę lukę
Hyperdrive znajduje się pomiędzy Workerem a bazą danych, utrzymując pulę trwałych połączeń na serwerze, który pod względem sieciowym znajduje się blisko instancji PostgreSQL. Z punktu widzenia Workera jedyną zmianą jest nowy ciąg połączenia (connection string). Wewnętrznie proxy ponownie wykorzystuje istniejące połączenie dla każdego przychodzącego zapytania, eliminując koszt nawiązywania połączenia.
Konfiguracja jest celowo lekka:
- Uruchom interfejs CLI Wrangler (narzędzie wiersza poleceń Cloudflare), aby utworzyć instancję Hyperdrive, podając oryginalny adres URL bazy danych.
- Dodaj wygenerowane wiązanie (binding) Hyperdrive do pliku konfiguracyjnego
wrangler.toml. - Użyj kompatybilnego sterownika, takiego jak
node-postgres, w kodzie Workera; sterownik widzi punkt końcowy Hyperdrive jako zwykły serwer PostgreSQL.
Ponieważ hasło do bazy danych znajduje się wyłącznie w konfiguracji Hyperdrive, nigdy nie pojawia się w kodzie źródłowym Workera, co zmniejsza powierzchnię ataku.
Praktyczne wskazówki dotyczące wyszukiwania wektorowego
Obciążenia związane z wyszukiwaniem wektorowym przy użyciu pgvector obejmują duże tablice liczb zmiennoprzecinkowych, które mają tendencję do zmiany przy każdym zapytaniu. Domyślne zachowanie Hyperdrive obejmuje pamięć podręczną odczytu (read cache), co może kolidować z danymi, które stale ulegają zmianie. Aby zachować świeżość wyników, utwórz drugą konfigurację Hyperdrive z wyłączonym buforowaniem.
Długotrwałe transakcje to kolejna pułapka. Utrzymywanie połączenia z bazą danych podczas oczekiwania na odpowiedź zewnętrznego modelu AI zajmuje miejsce w puli i niweczy cel pulowania połączeń. Zalecany wzorzec to:
- Otwórz transakcję.
- Wykonaj zapytanie.
- Niezwłocznie zatwierdź (commit).
- Wywołaj model AI poza transakcją.
Dostrajanie parametrów pgvector (na przykład ustawienie hnsw.ef_search, które kontroluje dokładność wyszukiwania) można wykonać za pomocą instrukcji SET LOCAL wewnątrz krótkiej transakcji. Zapewnia to, że zmiana zostanie zastosowana tylko do bieżącego zapytania i nie wpłynie na inne Workery korzystające z tej samej puli.
Pozostające ograniczenia
Hyperdrive nie zmienia lokalizacji samej bazy danych. Jeśli serwer PostgreSQL znajduje się w odległym regionie chmurowym, opóźnienie nadal będzie ograniczone tym fizycznym dystansem. Funkcja „Smart Placement” od Cloudflare może pomóc, kierując Workery do najbliższego węzła brzegowego (edge node), który również posiada instancję Hyperdrive, ale nie może wyeliminować podstawowych cykli komunikacji sieciowej.
Warstwa buforowania, choć użyteczna przy statycznych odczytach, będzie często powodować niepowodzenia (cache miss) w przypadku danych wektorowych, które zmieniają się przy każdym żądaniu. Deweloperzy muszą rozważyć kompromis między trafieniami w pamięć podręczną (cache hits) a świeżością wyników wyszukiwania.
Kiedy wybrać alternatywę
Jeśli aplikacja potrzebuje wyłącznie czystego przechowywania wektorów bez złączeń relacyjnych, Cloudflare oferuje dedykowaną usługę o nazwie Vectorize. Vectorize przechowuje wektory bezpośrednio na brzegu sieci (at the edge) i eliminuje potrzebę posiadania backendu PostgreSQL. Hyperdrive pozostaje lepszym wyborem, gdy wektory muszą być łączone z istniejącymi tabelami relacyjnymi, takimi jak profile użytkowników czy historia transakcji.
Podsumowanie
Hyperdrive daje deweloperom rozwiązań brzegowych praktyczne narzędzie do przeprowadzania wyszukiwania wektorowego opartego na AI bez przekraczania limitów połączeń PostgreSQL. Skraca opóźnienia związane z nawiązywaniem połączenia, centralizuje poświadczenia i oferuje precyzyjną kontrolę nad buforowaniem oraz długością transakcji. Usługa nie eliminuje fundamentalnej odległości między brzegiem sieci a bazą danych, a niepowodzenia w pamięci podręcznej (cache misses) pozostają kwestią wymagającą uwagi, ale dla obciążeń wymagających zarówno złączeń relacyjnych, jak i podobieństwa wektorowego, Hyperdrive jest najprostszą drogą do skalowalnego stosu brzegowego o niskich opóźnieniach.