Rozdzielenie dużej bazy na kilka mniejszych. Za duży commit

0

Witam

Potrzebuję porady, a dokładniej nakierowania na poprawne podejście do tematu :)
Mam bazę danych na około 70 tabel, niektóre po kilkanaście milionów rekordów. Chciałbym ją teraz podzielić na kilka mniejszych baz, po jednej dla każdego dużego klienta i jedna główna dla mniejszych klientów(przy okazji też przenosząc część danych do nosqla). Z racji dużej ilości skomplikowanych często relacji kopiowałem dane wyłączając chwilowo triggery sprawdzające poprawność kluczy. O ile dla mniejszych ilości danych wszystko było ok, to już przy kopiowaniu danych jednego z większych klientów mam problem java heap size, czasem gc out of memory.
Mógłbym zwiększyć max heap size ale chyba nie tędy droga.
Teraz wygląda to mniej więcej tak:
Pobieram po pewnym id dane z każdej tabeli, która jest w jakikolwiek sposób powiązana z klientem. Zapisuje/updatuje te dane do drugiej bazy danych. Updatuje sekwencje. Flush i clear na sesji i następna tabela, ten sam proces i następna itd.
Próbowałem rozdzielić odczyt i kopiowanie na mniejsze porcje, zamiast ciągnąć wszystkie dane z tabelki ale wywala się dokładnie w tym samym momencie.

I tutaj pytanie o jakąś poradę jak do tego podejść. Głównym problemem jest zapewne to, że próbuje skopiować setki tys dużych daych w jednym commicie, ze względu na wyłączenie triggerów i włączenie ich ponownie przed samym commitem.
Dodam, że ten proces będzie wykonywanywany kilka razy na początku i później już okazyjnie co jakiś czas. Nie jest jakaś standardowa akcja w aplikacji.

0

jakies dziwne podejscie
exportujesz dane klienta, ale nie javą tylko jakims narzedziem do exportu od bazy danych, ewenutalnie toolem do db ala query to file i pozniej wylaczasz fk importujesz zakladasz fk itp

1

a teraz jeszcze napisz, że próbujesz tą tabelę kilkanaście milionów rekordów wrzucić do pamięci w javie i potem zapakować do innej bazy...
Dzielenie na mniejsze bazy to nie jest rozwiązanie. W postgresie masz np. partycjonowanie tabel. Jeśli problemem są wolne zapytania to najpierw wypadało by przejrzeć plany zapytań i poprawić indeksy. Oczywiście odpowiednia (jak zwykle im więcej tym lepiej) ilość RAMu nie zaszkodzi.

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