PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Verbindungspooling für eine Android-App, die eine Verbindung zu einer Postgresql-Datenbank herstellt

Verbindungspooling durchführen

Jede Plattform hat eine andere Verbindungspooling-Schnittstelle. Sie müssen die Dokumentation für die spezifische Plattform lesen, die Sie verwenden (Ruby+Rails oder was auch immer), oder einen generischen Pooling-Midlayer wie PgBouncer verwenden.

Antworten zu einem Tool (z. B. PHP mit Zend Framework) haben nichts mit Antworten zu einem anderen Tool (wie Ruby on Rails) zu tun. Selbst wenn Sie sich für etwas wie PgBouncer entscheiden, gibt es immer noch Details darüber, wie die Plattform die Transaktionslebensdauer handhabt, den Pooling-Modus, der basierend auf den App-Anforderungen ausgewählt werden kann, usw.

Sie müssen also zuerst bestimmen, was Sie verwenden und was Sie damit tun müssen. Dann lernen Sie, wie Sie das Verbindungspooling einrichten. (Bei vielen Tools ist es einfach automatisch).

Wenn Sie immer noch nicht weiterkommen, nachdem Sie die Dokumentation für die von Ihnen gewählte Plattform gelesen haben , fragen Sie eine neue detaillierte und spezifische Frage entsprechend der Plattform getaggt.

Pooling und Middleware

Lassen Sie Ihre App nicht direkt mit PostgreSQL verbinden. Besonders wenn es über das Internet von zufälligen Clients ist.

Verwenden Sie einen Webserver in der Nähe des PostgreSQL-Servers und lassen Sie ihn Webdienstanfragen annehmen, um den Zugriff auf die Datenbank über eine gut definierte Web-API mit kurzen Transaktionen zu vermitteln, die so weit wie möglich auf Anfragen ausgelegt sind.

Dies ist nicht nur ein Fall von Weisheit - es gibt gute Gründe dafür und ernsthafte Probleme mit der Ausführung von PostgreSQL von zufälligen Geräten über das Internet.

Android-App, die direkt mit Pg kommuniziert

Zu den Problemen bei der direkten Kommunikation mit Pg über das Internet von vielen Clients gehören:

  • Jedes PostgreSQL-Backend hat Kosten, ob es sich im Leerlauf befindet oder nicht. PgBouncer im Transaktionspooling-Modus hilft dabei bis zu einem gewissen Grad.

  • Verbindungen gehen willkürlich verloren, wenn Sie über das Internet arbeiten. WLAN-Ausfälle, Änderungen der IP-Adresse bei dynamischen IP-Diensten, mobile Dienste, die ausfallen oder die Kapazitätsgrenze überschreiten oder einfach mit hohem Paketverlust schwanken. Dies lässt Sie mit vielen PostgreSQL-Verbindungen in unbestimmten Zuständen zurück, wahrscheinlich mit offenen Transaktionen, was Ihnen <IDLE> in transaction gibt Probleme und die Notwendigkeit, viel mehr Verbindungen zuzulassen, als wirklich funktionieren.

  • Es ist transaktional – wenn etwas nicht fertig gestellt wird, können Sie die Transaktion beenden und wissen, dass es keine Auswirkung hat.

Vorteile einer Mittelschicht

Ein Server, der auf HTTP-Webdienstanfragen von Ihrer App auf Android-Geräten antwortet, um als Broker für den Datenbankzugriff zu fungieren, kann ein großer Vorteil sein.

  • Sie können eine versionierte API definieren, sodass Sie alte Clients nicht beschädigen müssen, wenn Sie neue Funktionen einführen oder die API ändern müssen. Dies ist mit Pg möglich, indem gespeicherte Prozeduren oder viele Ansichten verwendet werden, kann aber klobig werden.

  • Sie kontrollieren streng den Umfang des Datenbankzugriffs und die Transaktionslebensdauer.

  • Sie können eine idempotente API definieren, bei der das mehrmalige Ausführen derselben Anforderung nur eine Auswirkung hat. (Ich empfehle dies wegen des nächsten Punktes dringend).

  • Alles ist zustandslos und kann kurze Auszeiten haben. Wenn etwas nicht funktioniert, versuchen Sie es einfach erneut.

  • Jede Datenbankverbindung geht über einen Pool, so dass Sie keine ungenutzten Sitzungen herumsitzen haben. Jedes Datenbank-Backend arbeitet hart für maximalen Durchsatz.

  • Sie können die Arbeit in die Warteschlange stellen, anstatt zu versuchen, Tonnen gleichzeitig zu erledigen und den Server zu verprügeln. (Sie können dies auch mit PgBouncer im Transaktions-Pooling-Modus tun).

... und bearbeiten Sie die Frage erneut, um die Bedeutung der Frage zu ändern:

Leistung

Ihre "Also"-Performance ist wirklich eine ganz andere Frage (und sollte vorzugsweise als solche gepostet werden). Die sehr kurze Version:Völlig unmöglich vorherzusagen ohne viel mehr Informationen über die Arbeitslast, wie Anzahl der DB-Anfragen pro Client-App-Anfrage, Art der Daten, Art der Abfragen, Größe der Daten, Häufigkeit der Abfragen, Praktikabilität des Caching, .. .... endlos. Jeder, der behauptet, diese Frage definitiv beantworten zu können, ist entweder der erste wahre Hellseher der Geschichte oder völlig voll davon.

Sie müssen ungefähr herausfinden, wie groß Ihre Datenmenge, Abfragemuster usw. sein werden. Finden Sie heraus, wie viel Sie sich leisten können, um in einem Midlayer-Cache wie Redis/Memcached zwischenzuspeichern, wie veraltet Sie es werden lassen können, welche Stufe der Cache-Invalidierung Sie benötigen. Bestimmen Sie, ob Ihr "heißer" Datensatz (auf den Sie häufig zugreifen) in den RAM passt oder nicht. Bestimmen Sie, ob die Indizes für häufig abgefragte Tabellen in den Arbeitsspeicher passen oder nicht. Finden Sie heraus, wie hoch Ihr ungefähres Lese-/Schreibgleichgewicht ist und wie viele Ihrer Schreibvorgänge wahrscheinlich Nur-Einfügen (Anhängen) oder regelmäßigeres OLTP (Einfügen/Aktualisieren/Löschen) sind. Erstellen Sie einen Dummy für einen Datensatz und einige Client-Arbeitslasten. Dann Sie können anfangen, diese Frage zu beantworten - vielleicht. Um es richtig zu machen, müssen Sie auch blockierte/verschwundene Clients usw. simulieren.

Sehen Sie, warum es nicht nur ein "Auch?" ist.