|
Aplikacje oparte na danych obejmują szeroki zakres złożoności, od prostych mikrousług po systemy sterowane zdarzeniami w czasie rzeczywistym przy znacznym obciążeniu. Jednak, jak potwierdzi każdy zespół programistów i/lub DevOps, którego zadaniem jest poprawa wydajności, tworzenie szybkich aplikacji opartych na danych na całym świecie jest „nietrywialne”.
Nowoczesne architektury aplikacji, takie jak JAMstack, wymuszają oddzielenie problemów poprzez przeniesienie wymagań dotyczących danych i trwałości do interfejsu API. Czyste oddzielenie zawartości statycznej, logiki biznesowej i trwałości danych pozwala na niezależne skalowanie i zarządzanie nimi.
Wiele przedsiębiorstw koncentruje się również na oddzieleniu swoich monolitycznych aplikacji w celu wykorzystania mikrousług i często wdraża je w środowiskach bezserwerowych. To przesunięcie w kierunku większego oddzielenia w celu lepszej izolacji środowiskowej może również zapewnić lepszą elastyczność regionalną w odniesieniu do miejsca wdrażania logiki biznesowej i sposobu jej skalowania. Aplikacje można teraz wdrażać globalnie w ramach jednej czynności CI/CD.
Warstwa danych jest jednak bardziej złożona. Istnieją praktyczne wyzwania, takie jak spójność transakcyjna, wysoka dostępność i wydajność zapytań pod obciążeniem. Istnieją ograniczenia, takie jak przestrzeganie wymogów umożliwiających identyfikację i zgodność. Są też granice nie do pokonania, takie jak te, które prawa fizyki nakładają na opóźnienie.
Buforowanie aplikacji
Wiele zespołów programistycznych korzysta z buforowania, aby rozwiązać te problemy w warstwie aplikacji, wspartej warstwami trwałości, takimi jak Redis lub własne systemy. Koncepcja jest prosta:przechowuj dane żądane przez klienta przez pewien czas, a jeśli zobaczymy je ponownie, mamy je gotowe do obsłużenia następnego żądania bez uciekania się do bazy danych pochodzenia. Zaprojektowanie dobrej strategii buforowania wiąże się z własnym zestawem wyzwań:jakie dane należy buforować, jak je buforować i kiedy. A może ważniejsze, co, jak i kiedy eksmitować dane z pamięci podręcznej. Strategia buforowania musi być dobrze zdefiniowana, zrozumiana i zastosowana dla każdego nowego zestawu funkcji dodawanego do aplikacji przez programistów i potencjalnie zespoły departamentów. Czas i złożoność opracowania to koszt.
Repliki do odczytu bazy danych
Alternatywnie wiele przedsiębiorstw rozwiązuje wyzwania związane z opóźnieniami i skalowaniem za pomocą replik odczytu bazy danych. Repliki do odczytu są wystąpieniami tylko do odczytu podstawowej bazy danych i są automatycznie synchronizowane (asynchronicznie) w miarę wprowadzania aktualizacji w podstawowej bazie danych. Zaprojektowanie solidnej strategii odczytu-repliki jest zniechęcającym zadaniem pełnym własnych subtelnych i nie tak subtelnych kosztów i złożoności.
Większość tej złożoności można okiełznać dzięki ScaleGrid. W pełni zarządzane repliki do odczytu można wdrożyć jednym kliknięciem ze ScaleGrid (z obsługą HA) we wszystkich głównych chmurach i regionach, przy czym kluczową zaletą jest to, że dane są automatycznie synchronizowane z podstawową bazą danych.
Jednak repliki do odczytu nie mogą uniknąć konieczności uruchamiania wielu, być może wielu, serwerów baz danych i związanych z nimi kosztów.
Inne podejście:pamięć podręczna krawędzi PolyScale.ai
PolyScale to pamięć podręczna krawędzi bazy danych, która przyjmuje inne podejście. Pamięć podręczna PolyScale zapewnia dwie podstawowe korzyści:zwiększone opóźnienie zapytań i zmniejszone obciążenie bazy danych. Rozłóżmy to trochę:
Opóźnienie regionalne jest rozwiązany podobnie jak CDN; PolyScale zapewnia globalną sieć brzegową punktów obecności (PoP) i przechowuje odpowiedzi na zapytania bazy danych blisko pierwotnego klienta, znacznie przyspieszając odpowiedzi.
Wydajność zapytań odczytu jest znacznie ulepszony, ponieważ PolyScale obsłuży każde żądanie buforowanej bazy danych w czasie <10 ms, bez względu na złożoność zapytania. Dodatkowo, biorąc pod uwagę, że żądania odczytu są obsługiwane z PolyScale, to obciążenie nigdy nie wpływa na początkową bazę danych.
Implementacja
PolyScale można zaimplementować bez pisania kodu lub wdrażania serwerów w ciągu kilku minut. Po prostu zaktualizuj klienta bazy danych (czy to aplikacji internetowej, mikroserwisu czy narzędzia BI, takiego jak Tableau) za pomocą nazwy hosta PolyScale. Ruch bazy danych przejdzie wtedy przez sieć brzegową i będzie gotowy do buforowania.
Dzięki kompatybilności z MySQL i Postgres, PolyScale jest całkowicie przezroczysty dla klientów baz danych, dlatego nic się nie zmienia w obecnej architekturze. Bez migracji, bez zmian w transakcyjności i bez zmian w bieżącym języku zapytań. Prawdziwie podłącz i graj.
Jak to działa?
Globalne sieciowe serwery proxy PolyScale i buforują natywne protokoły przewodowe bazy danych, dzięki czemu są niewidoczne dla każdego klienta bazy danych. Zapytania są sprawdzane i odczytywane (SQL SELECT ) można buforować geograficznie blisko źródła żądającego w celu przyspieszenia wydajności. Cały pozostały ruch (INSERT , UPDATE i DELETE ) płynnie przechodzi do źródłowej bazy danych.
Sztuczna inteligencja PolyScale jest na drodze do pełnej automatyzacji. Zamiast konfigurować pamięć podręczną zgodnie z potrzebami, platforma będzie mierzyć przepływ ruchu i stale dostosowywać właściwości pamięci podręcznej, aby zapewnić optymalną wydajność. Możesz przeczytać więcej o modelu buforowania PolyScale AI tutaj.
Wnioski
PolyScale.ai zapewnia nowoczesne podejście typu plug and play do wydajności i skalowania w warstwie danych. Platforma PolyScale jest na ścieżce do pełnej automatyzacji, gdzie po podłączeniu będzie inteligentnie zarządzać buforowaniem danych w celu uzyskania optymalnej wydajności.
Biorąc pod uwagę, że PolyScale jest przewodowo kompatybilny z bieżącą bazą danych, żadne zmiany nie są konieczne, aby globalnie skalować odczyty w kilka minut. Spróbuj!
