Co szybsze? Postgres lokalnie na Dockerze czy na zewnętrznym serwerze?

0

Cześć.

Mały zarys tego co robię:
Odziedziczyłem pewien projekt po innym zespole - w skrócie Grafana robiąca wykresy z wielu baz danych (postgres, mysql) w tej samej korporacyjnej sieci. Poprzednicy założyli, że aby nie tracić na szybkości odczytu, to należy te bazy danych przepisywać do lokalnie (na serwerze aplikacji) postawionych baz na Dockerze. Wszystko fajnie ale:

  • duplikuje się dane z pewnego okresu
  • pojawia się problem, kiedy na naszym 2TB serwerze jednak skończy się miejsce na ten swoisty "cache"
  • Grafana i tak jest wolna jeśli zrobić jej skomplikowane zapytania z jakimiś obliczeniami.
    W skrócie schemat apki wygląda tak:
    screenshot-20200506114948.png

Jedyne plusy tego rozwiązania jakie widzę to:

  • w trakcie przepisywania danych z bazy do bazy można coś robic z tymi danymi, ale to raczej rzadki przypadek.

Ja myślałem na sam początek w ogóle pozbyć się tychże baz Dockerowych i jechać na "zewnętrznych" zwłaszcza, że moja firma zapewnia im support i backup.
Korzyści z przepisywania danych z bazy do bazy nie widzę, żeby tylko je później wyświetlić nie widzę.

Pytanie do Was :)
Czy widzicie tu jakis potencjalny wzrost szybkości odczytu z bazy przez tą biedną Grafanę?
Czy są jakieś lepsze rozwiązania - np. cache dla częstych zapytań zamiast tych dockerowych baz, które zapchają prędko mój biedny serwerek?

Pozdrawiam i z góry dzięki za wszelkie uwagi :)

0

Grafana niby nie wymaga Elastica, ale czy tu nie jest kejs żeby zamiast baz dockerowych wszystko było pchane do ElasticSearch własnie? Poza tym duże ilości danych, kilka serwisów i jeden serwerek na to? Na czym to stoi?

0
cmd napisał(a):

Grafana niby nie wymaga Elastica, ale czy tu nie jest kejs żeby zamiast baz dockerowych wszystko było pchane do ElasticSearch własnie? Poza tym duże ilości danych, kilka serwisów i jeden serwerek na to? Na czym to stoi?

No właśnie to jest druga rzecz, która przyprawia mnie o ból głowy - na czym to stoi.
No serwerek jakiś tam 64GB RAM 2TB Dysk i procesor sam już nie wiem. Niby "kozak" ale nie taki kombajn.
Docelowo ma być jakiś "cloud" z Kubernetesowymi node'ami, więc serwer ten pójdzie w zapomnienie.

A co do Elastica - chodzi o to, żeby nie płacić za autoryzację LDAP-em (w skrócie).
Elastic open-source nie posiada z tego co słyszałem modułu do LDAP-a (opcja płatna).
Plan jest taki, że zwykły użytkownik ma dostęp do danych tylko "read only" a zapisują do postgresów jedynie uprawnieni użytkowicy.

Natomiast Grafana niby tego LDAP-a ma "by default". Być może coś tu delikatnie pokręciłem... jeszcze nie do końca ogarnąłem założenia tego projektu.

Edit:
Note that our advanced security features — from single sign-on and Active Directory/LDAP authentication to field- and document-level security — remain paid features.

2

Podstawowa zaleta tego rozwiązania to zdjęcie obciążenia generowanego przez wykresiki/raporty z baz działających w trybie master/write. Bazy danych skaluje się ciężko, a przytoczona tu replikacja jest podstawowym sposobem na skalowanie baz danych. Jak usuniesz repliki, zwiększysz obciążenie na oryginalnych bazach danych, czy one to wytrzymają?

2
neves napisał(a):

Podstawowa zaleta tego rozwiązania to zdjęcie obciążenia generowanego przez wykresiki/raporty z baz działających w trybie master/write. bazy danych skaluje się ciężko, a replikacja jest podstawowym sposobem na skalowanie baz danych. Jak usuniesz repliki, zwiększysz obciążenie na oryginalnych bazach danych, czy one to wytrzymają?

Pytanie czy nie lepiej zamiast jakichś 'extractorów' które przepisują bazy (bo tak to wygląda na schemacie, może w rzeczywistości jest inaczej) skonfigurować repliki z prawdziwego zdarzenia (slave / hot-standby). Bo to wygląda tak, jakby jakieś workery wyciągały dane z jednej bazy i przepisywały do drugiej - no i pojawia się drugie pytanie, w jaki sposób to robią, bo jak piszą non-stop do tych lokalnych DB to też średnio ;)

0
superdurszlak napisał(a):
neves napisał(a):

Podstawowa zaleta tego rozwiązania to zdjęcie obciążenia generowanego przez wykresiki/raporty z baz działających w trybie master/write. bazy danych skaluje się ciężko, a replikacja jest podstawowym sposobem na skalowanie baz danych. Jak usuniesz repliki, zwiększysz obciążenie na oryginalnych bazach danych, czy one to wytrzymają?

Pytanie czy nie lepiej zamiast jakichś 'extractorów' które przepisują bazy (bo tak to wygląda na schemacie, może w rzeczywistości jest inaczej) skonfigurować repliki z prawdziwego zdarzenia (slave / hot-standby). Bo to wygląda tak, jakby jakieś workery wyciągały dane z jednej bazy i przepisywały do drugiej - no i pojawia się drugie pytanie, w jaki sposób to robią, bo jak piszą non-stop do tych lokalnych DB to też średnio ;)

@neves wyjaśniłeś mi trochę koncept, dlaczego moi poprzednicy coś takiego wymyślili. Docelowo chcieli oni w tego typu serwerkach (połączonych w jakiś Kubernetesowy cluster) przechowywać dane wszystkich klientów. Ja nie uważam tego za dobry pomysł, bo po prostu mając do utrzymania aplikację nie chce martwić się o bazy- backupy, replikacjie itp, zwłaszcza, że zespół mam mały, a w firmie mamy ludzi stricte od baz... co prawda w Indiach i troszkę to blokuje dogadanie się z bardziej zaawansowanymi sprawami.

@superdurszlak pewnie już większość wyjaśniłem tuż powyżej - przechodziło mi przez myśl :) czy możliwe jest korzystając z mechanizmu replikacji zrobić właśnie coś w stylu:

  • baza - write only
  • replika - read only
    Co prawda nie robiłem tego nigdy i czeka mnie zabawa, jeśli od naszych firmowych bazodanowców tego nie załatwię. Wydaje mi się to jednak najlepszym jak dotąd pomysłem.
2
rozacek napisał(a):

@superdurszlak pewnie już większość wyjaśniłem tuż powyżej - przechodziło mi przez myśl :) czy możliwe jest korzystając z mechanizmu replikacji zrobić właśnie coś w stylu:

  • baza - write only
  • replika - read only
    Co prawda nie robiłem tego nigdy i czeka mnie zabawa, jeśli od naszych firmowych bazodanowców tego nie załatwię. Wydaje mi się to jednak najlepszym jak dotąd pomysłem.

Raczej się da, z tego co kojarzę Postgres i MySQL da się oba skonfigurować tak, by działały jako replika read-only (w Postgres nazwali to chyba hot standby, w MySQL slave) choć szczerze mówiąc nigdy nie stawiałem tego od zera.

Po migracji do jakiegoś clouda powinno się dać dorzucać takie repliki z marszu, z poziomu jakichś konfiguracji / web console / CLI - w każdym razie w Amazon RDS się da, zakładam że u innych providerów również ;)

https://aws.amazon.com/blogs/database/scaling-your-amazon-rds-instance-vertically-and-horizontally/
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Integrating.AutoScaling.html

2

Replikacja może dojechać te bazy dockerowe.
a) nie wiadomo jaki jest ruch na źródle i jak często zachodzą zmiany
b) utrzymanie procesu replikacji nie zawsze jest proste. Co np. w przypadku odtwarzania bazy źródłowej z backupu? Co w przypadku czasowej niedostępności bazy docelowej? Jak długo mogą się kisić logi replikacyjne na źródle? Ile miejsca potrzeba na zachowanie logów na źródle? Jak szybko baza docelowa potrafi aplikować zmiany? Ile miejsca potrzeba na bazie docelowej na logi replikacyjne?

Wbrew pozorom takie rozwiązanie oparte na ekstrakcji z różnych źródeł nie jest złe.
a) masz możliwość zrobienia ekstrakcji w dogodnym czasie
b) baza źródłowa może nie być dostępna, bo ma nie pracuje w trybie 24/7, a np. 8/5
c) masz dane bliżej
d) masz możliwość ich obróbki przy okazji ekstrakcji (np. zbudowania jakichś agregatów)

Podstawowe pytanie, dlaczego Grafana przetwarza powoli? Na jakie aktywności rozkłada się ten czas przetwarzania?

1 użytkowników online, w tym zalogowanych: 0, gości: 1