Czy nginx/node.js/postgres to bardzo skalowalna architektura?

Question

mam aplikacja działa z:

• jednej instancji nginx jako nakładka (służących pliku statycznego)
• Klaster node.js zgłoszenia backend (stosując klastra i expressjs moduły)
• jedna instancja PostgreSQL jak DB

Czy ta architektura wystarczające, jeśli aplikacja wymaga skalowalność (to jest tylko dla żądań HTTP/rest) dla:

• 500 żądań na sekundę (każda prośba pobiera tylko dane z DB, dane te mogą być kilkoma ko, i bez dużych obliczeń potrzebnych po pobraniu).

• 20000 użytkowników podłączony jednocześnie

Gdzie może być wąskie gardła?

Answer 1

Dla określonego obciążenia (500 prostych żądań/sekundę), nie sądziłem, że będzie to zbyt duży problem. Przypuszczam, że klaster instancji węzła nie będzie nawet potrzebny.

Jednakże, ponieważ masz tylko jedną instancję, jeśli chodzi o skalowanie, najprawdopodobniej będzie to wąskie gardło. Masz również dodatkowy problem, który byłby twoim pojedynczym punktem awarii (nie jestem zaznajomiony z Postgresem, tutaj pracowałem z klastrem Oracle i dataguardem, co oznacza, że ​​mamy zapasowy klaster bazy danych, aby to złagodzić) .

Jeśli nie potrzebujesz relacyjnego modelu danych, wówczas opcja MongoDB może być bardziej skalowalnym wyborem.

Jeszcze jedna rzecz, o której należy pamiętać to infrastruktura sieci. Jeśli zamierzasz dodać klastry/węzły, upewnij się, że sieć może obsłużyć rozproszony ładunek.

Ostatnia rzecz: Zasadniczo niemożliwe jest określenie, czy aplikacja w architekturze może obsłużyć określone obciążenie bez testów wydajności/woluminu/obciążenia, więc odpowiedź brzmi "być może".

Answer 2

Powinieneś być w porządku z szybkością 500 operacji na sekundę. Przeprojektuj, jeśli spodziewasz się przejść do tysiąca operacji na sekundę.

Bez wiedzy o wiele więcej danych od ciebie, najprawdopodobniej twoje wąskie gardło będzie stanowiło dysk/I/O. Będzie to miało miejsce w bazie danych PostgreSQL z szybkością około 10 000 operacji na sekundę, jeśli jesteś I/O-em z dysku twardego na sprzęcie magazynowym, a także zwolnij, jeśli robisz JOIN w poleceniu SQL. Spowoduje to także spowolnienie bardziej jednoczesnych użytkowników, którzy próbują uzyskać dostęp do pojedynczego dysku. Twój czas szukania dysku oszaleje, ponieważ będziesz ciągle losowo uzyskiwał dostęp do dysku.

Powinieneś zbadać strukturę swoich danych i czy potrzebna jest relacyjna baza danych (czy musisz wykonać JOIN?). Rozwiązaniem może być rozwiązanie noSQL. Zawsze staraj się, aby twoje dyskowe operacje we/wy były jak najbardziej rozproszone i sekwencyjne.