Klaster Amazon Redshift (używający węzłów zarezerwowanych) doświadcza sporadycznych, intensywnych obciążeń procesora spowodowanych złożonymi zapytaniami odczytu, podczas gdy zespół przeprowadza szczegółowy audyt. Klaster musi przez cały czas obsługiwać zapytania odczytu i zapisu. Która opcja zapewnia wymaganą pojemność burst w NAJBARDZIEJ opłacalny sposób?

Włączenie Concurrency Scaling dla klastra Amazon Redshift jest najbardziej opłacalnym rozwiązaniem. Concurrency Scaling automatycznie dodaje tymczasowe klastry w celu obsługi zwiększonego obciążenia zapytań odczytu, gdy główny klaster jest przeciążony, bez konieczności ręcznego skalowania lub utrzymywania dodatkowych zasobów. Płacisz tylko za dodatkowe minuty użycia, co jest idealne dla sporadycznych, intensywnych obciążeń. Uruchomienie klastra Amazon EMR jest kosztowne i wymaga przeniesienia danych oraz zarządzania dwoma systemami. Klasyczna zmiana rozmiaru klastra Redshift jest operacją offline, która wymaga przestoju, co jest niedopuszczalne, gdy klaster musi działać cały czas. Elastyczna zmiana rozmiaru klastra Redshift jest operacją online, ale jest bardziej odpowiednia do długoterminowych zmian pojemności, a nie do sporadycznych skoków obciążenia, i może być droższa niż Concurrency Scaling dla krótkotrwałych potrzeb.