Pula połączeń dla aplikacji na Androida, która łączy się z bazą danych Postgresql

Jak zrobić łączenie połączeń

Każda platforma ma inny interfejs puli połączeń. Musisz przeczytać dokumentację dla konkretnej platformy, której używasz (Ruby+Rails lub cokolwiek) lub użyć ogólnej warstwy pośredniej, takiej jak PgBouncer.

Odpowiedzi odnoszące się do jednego narzędzia (powiedzmy PHP z Zend Framework) nie będą miały nic wspólnego z odpowiedziami odnoszącymi się do innego narzędzia (takiego jak Ruby on Rails). Nawet jeśli wybierzesz coś takiego jak PgBouncer, nadal istnieją szczegóły dotyczące sposobu, w jaki platforma obsługuje okresy istnienia transakcji, tryb pulowania do wyboru w zależności od potrzeb aplikacji itp.

Musisz więc najpierw określić, czego używasz i co musisz z tym zrobić. Wtedy dowiedz się, jak skonfigurować pulę połączeń. (Z wieloma narzędziami jest to po prostu automatyczne).

Jeśli nadal utkniesz, po przeczytaniu dokumentacji wybranej platformy , zapytaj o nowe szczegółowe i konkretne pytanie oznaczone odpowiednio dla platformy.

Połączenie i oprogramowanie pośredniczące

Twoja aplikacja nie łączy się bezpośrednio z PostgreSQL. Zwłaszcza jeśli jest przez Internet od losowych klientów.

Użyj serwera internetowego w pobliżu serwera PostgreSQL i pozwól mu akceptować żądania usług internetowych, aby pośredniczyć w dostępie do bazy danych za pośrednictwem dobrze zdefiniowanego internetowego interfejsu API z krótkimi transakcjami, które są ograniczone do żądań w jak największym stopniu.

Nie jest to tylko przypadek otrzymanej mądrości - są ku temu dobre powody i poważne problemy z uruchamianiem PostgreSQL z losowych urządzeń przez Internet.

Aplikacja na Androida rozmawia bezpośrednio z Pg

Problemy z rozmową z Pg bezpośrednio przez Internet od wielu klientów obejmują:

• Każdy backend PostgreSQL ma swój koszt, niezależnie od tego, czy jest bezczynny, czy nie. PgBouncer w trybie łączenia transakcji pomaga w pewnym stopniu.

• Połączenia są losowo tracone podczas pracy przez Internet. Spadki Wi-Fi, zmiany adresu IP w dynamicznych usługach IP, usługi mobilne, które zanikają lub osiągają maksymalną przepustowość lub po prostu opóźniają się wraz z dużą utratą pakietów. To pozostawia wiele połączeń PostgreSQL w nieokreślonych stanach, prawdopodobnie z otwartymi transakcjami, co daje ci <IDLE> in transaction problemy i potrzeba umożliwienia znacznie większej liczby połączeń niż w rzeczywistości.

• To transakcyjne - jeśli coś się nie skończy, możesz zakończyć transakcję i wiedzieć, że nie przyniesie to efektu.

Zalety posiadania warstwy środkowej

Dużą zaletą może być serwer odpowiadający na żądania usług internetowych HTTP z Twojej aplikacji na urządzeniach z Androidem, działający jako pośrednik w dostępie do bazy danych.

• Możesz zdefiniować wersjonowany interfejs API, więc gdy wprowadzasz nowe funkcje lub musisz zmienić interfejs API, nie musisz przerywać starych klientów. Jest to możliwe w przypadku Pg przy użyciu procedur zapisanych w bazie lub wielu widoków, ale może być niezgrabne.

• Ściśle kontrolujesz zakres dostępu do bazy danych i czas życia transakcji.

• Możesz zdefiniować idempotentny interfejs API, w którym wielokrotne uruchamianie tego samego żądania ma tylko jeden efekt. (Zdecydowanie polecam to zrobić ze względu na następny punkt).

• Wszystko jest bezpaństwowe i może mieć krótkie przerwy. Jeśli coś nie działa, po prostu spróbuj ponownie.

• Każde połączenie z bazą danych przechodzi przez pulę, więc nie masz bezczynnych sesji. Każdy backend bazy danych ciężko pracuje, aby uzyskać maksymalną przepustowość.

• Możesz pracować w kolejce, zamiast próbować robić tony jednocześnie i niszczyć serwer. (Możesz to również zrobić z PgBouncer w trybie łączenia transakcji).

... i ponownie dokonaj edycji, aby zmienić znaczenie pytania:

Wydajność

Twoje ponowne wykonanie "Również" to naprawdę zupełnie inne pytanie (i najlepiej, aby zostało opublikowane jako takie). Bardzo krótka wersja:całkowicie niemożliwa do przewidzenia bez większej ilości informacji o obciążeniu, takich jak liczba żądań bazy danych na żądanie aplikacji klienckiej, rodzaj danych, rodzaj zapytań, rozmiar danych, częstotliwość zapytań, praktyczność buforowania, .. .... bez końca. Każdy, kto twierdzi, że ostatecznie odpowiada na to pytanie, jest albo pierwszym prawdziwym medium w historii, albo całkowicie nim.

Musisz z grubsza określić, jaki będzie rozmiar danych, wzorce zapytań itp. Dowiedz się, ile możesz sobie pozwolić na buforowanie w pamięci podręcznej warstwy pośredniej, takiej jak redis/memcached, jak nieaktualny możesz na to pozwolić, jaki poziom unieważnienia pamięci podręcznej potrzebujesz. Określ, czy twój „gorący” zestaw danych (do którego często uzyskujesz dostęp) zmieści się w pamięci RAM, czy nie. Określ, czy indeksy dla często odpytywanych tabel zmieszczą się w pamięci RAM, czy nie. Dowiedz się, jakie jest twoje przybliżone saldo odczytu/zapisu i ile twoich zapisów prawdopodobnie będzie tylko wstawianiem (dołączanie) lub bardziej regularnym OLTP (wstawianie/aktualizacja/usuwanie). Wymyśl zestaw danych i niektóre obciążenia klienta. Wtedy możesz zacząć odpowiadać na to pytanie - może. Aby zrobić to dobrze, musisz również zasymulować zatrzymanych/zniszczonych klientów itp.

Zobacz, dlaczego to nie jest tylko „Też?”.