Optymalizacja aplikacji wykorzystującej kilka baz danych

0

taki case:
jest sobie aplikacja x przetwarzająca pewne dane z różnych źródeł (csv, xml, zewnętrzne api) i zapisująca je w bazie danych mysql. Dla uproszczenia przyjmijmy że w aplikacji user tworzy projekt i ma on swoje źródło danych, projekty nie mają ze sobą żadnych powiązań i dane pobierane są przynajmniej raz dziennie. Projektów do przetworzenia jest coraz więcej i zaczynają się problemy z wydajnością. W pierwszej kolejności zamiast pojedynczej bazy danych robimy bazę per projekt, przynosi to spory wzrost wydajności (baza była wąskim gardłem), później migrujemy aplikację na większy serwer i zwiększamy liczbę przetwarzanych na raz projektów. Następnie dokładamy drugi serwer bazodanowy i tu zaczyna się problem. Na ten moment mamy dwa serwery bazodanowe i jeden backendowy. Proces pobierania danych wygląda następująco:

  1. żądanie pobrania leci do kolejki (sqs w AWS)
  2. proces uruchomiony na serwerze backendowym bierze wiadomość, pobiera dane i zapisuje w konkretnej bazie danych.

Jak najlepiej zbalansować obciążenie serwerów bazodanowych? Zakładając że na backendzie mamy uruchomione 100 procesów, w kolejce jest 1000 wiadomości - 500 wiadomości dotyczy projektów z serwera bazodanowego 1 i 500 wiadomości serwera 2, może nastąpić sytuacja że najpierw będzie obrobione 500 z serwera 1 a potem 500 z serwera 2, chciałbym tego uniknąć.

To co na ten moment mam w głowie to zrobić osobne kolejki per serwer bazy i do każdej z nich osobna pula procesów obrabiających dane. Ewentualnie przejść na kolejki fifo i grupować wiadomości po serwerze. Docelowo będziemy zwiększać liczbę serwerów backendowych i bazodanowych więc pewnie zrobienie na sztywno: serwera bazodanowego, serwera backendowego i obsługującej tą parę kolejki nie byłoby złym rozwiązaniem. Planujemy tez zrezygnować z sqs na rzecz rabbitMQ.

Może jest jakieś oczywiste rozwiązanie tego problemu tylko ja się tak zakręciłem że go nie widzę?

0
mm1492 napisał(a):

W pierwszej kolejności zamiast pojedynczej bazy danych robimy bazę per projekt, przynosi to spory wzrost wydajności (baza była wąskim gardłem), później migrujemy aplikację na większy serwer i zwiększamy liczbę przetwarzanych na raz projektów.

Mam mocne przeświadczenie, ze podział per projekt dał efekt przejściowy / warunkowy / w teście z targetem na jeden.
Bo da efekt, baza mniejsza, mniej cachowania itd, zwłaszcza przy pracy rzadko uruchamianej. ... i da fatalny efekt, gdy bazy-projekty będą sie
przełączać. Ta, która wypadła z pamięci, dostanie fatalny czas

... później migrujemy aplikację na większy serwer ... czyli był problem z RAM ? A dlaczego był to drugi etap, a nie pierwszy ?

Tak/nie/zależy. To może być srodkiem optymalizacji. Moze też dać mocny cios w brzuch i to za niedługi czas. Zbyt łatwe rozszczepainie baz danych niesie skutki w zasobach, securitowe, backupowe, zarządzania. Zostawiłbym decyzję o rozdzieleniu baz na poziomie analizy logicznej (w tym "multitenant"), a nie jako (głowny) środek optymalziacji

mm1492 napisał(a):

Może jest jakieś oczywiste rozwiązanie tego problemu tylko ja się tak zakręciłem że go nie widzę?

Czego nie ma w tym poście

Co to jest ten "projekt", ile ich jest, ile ich przybywa w skali miesiaca / wieloletniej. Skończona i dająca sie oszacować liczba, czy nielimitowana. Czy dynamiczny okres życia "projektu" zamiera i staje się (mniej czy bardziej) archiwalny.

Liczb brakuje. Zarówno w dziedzinie "projektu", jak i systemowo-hardwarowych

Jestem mocno nieprzekonany, że wcześniej wyczerpano "klasyczne" środki dobrego prowadzenia projektu (he he , w innym sensie) bazodanowego. Indeksy, relacje, strojenie MySQL-a, w tym transakcyjność. (defaulty ma umiarkowane)

Każesz domniemywać, że problem jest aktualizacja, i proponujesz lekarstwo jedynie na aktualizację. Jakieś analizy na to wskazują ?

Ślub z tym MySQL brałeś ? Jeśli to jest naprawdę wielkie dzieło (ale trochę przeczy studencki post), rozproszone bazy cloudowe też istnieją

2

Metryki, metryki i jeszcze raz metryki

Potem możemy rozmawiać.

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