Performance & Hardware - Wie ermittle ich TPS mit Standards?

Hallo zusammen,

ich stehe vor der Aufgabe ein Maschinengewehr für eine Datenbank zu entwicklen :slight_smile: Das soll heissen, ich muss 50k requests/sec verarbeiten können. Die Select Anweisung bezieht sich wahrscheinlich nur auf eine Tabelle mit wenigen Spalten (ca. 10). Für die schnelle Ausführung sind 50% der Daten auf numerische Werte mit Indexierung ausgelegt, um einen schnellen Zugriff zu ermöglichen. Jetzt kommt die Frage auf: “Welches Blech kommt da hin?” Wie bestimmt man nun eine geeignete Hardware für eine solche Anforderung? Ich hab mich im Internet umgesehen und bin auf den Begriff TPS (transaction per second) gekommen. Viele sagen einfach die Performance für TPS ist abhängig von der verfügbaren Hardware und der eigentlich Ausführungszeit (SQL Aktionen) auf der Datenbank.

Das hab ich soweit verstanden, ich suche noch Daten die ein Beispiel haben wie: “Wir haben mit Kiste xy in 1 sec x TPS Aktionen geschafft”. Vielleicht kann ich mit solchen Infos einen ungefähren Bedarf ermitteln plus Risikofaktor und eine Hardwarelösung finden. Eine Skalierung über PgProxy, Cluster etc. möchte ich erstmal klein halten. Die Grundanforderung ist erstmal KISS (keep it simple and stupid).

Folgende Fragen beschäftigen mich zu diesem Thema:

  • Erfahrungswerte zur Einschätzung von Performance & Hardware
  • Wieviel TPS schafft man auf Kiste xy (Schätzwerte)
  • Welche Umgebung ist für eine PG sinnvoll? (CPU, HDD, RAM)
  • Wie geht PG mit Concurrent Connnections < 1000 und > 1000 um ?
  • Was muss bei so vielen Verbindungen in der Konfiguration von PG beachtet werden?

Zusätzlich bin ich eher PG Newbie, d.h. ich kann zwar die Datenbank bedienen und kann ganz gut mit SQL umgehen. Doch Fragen zu Performance, Thread Handling und eine gute Einstellung für Postgres sind für mich noch ein Buch mit sieben Siegeln :slight_smile: Die andere Überlegung war, ob eine Alternative NoSQL DBs wie MongoDB möglich wäre. Laut diversen Benchmarks schenkt sich der Unterschied von SQL vs. NoSQL auf einer einzelnen Maschine nicht viel, sondern kommt erst bei einer horizontalen Skalierung zum Tragen.

Noch ein Hintergrund zu App:
Um die Last der DB zu reduzieren sollen die Applikationsknoten nur alle x Sekunden die Daten aktualisieren und die Auslieferung der Daten wird im Knoten vorgehalten. Der Knoten übernimmt somit den meisten Traffic der Daten, die ihm zum Zeitpunkt bekannt sind. Die Anzahl der Knoten ist n und greift in t (1-3 sec) auf die PG Instanz(en) zu.

Für ein paar Tips oder Hinweise auf wichtige Themen in der Dokumentation wäre ich dankbar.

Vielen Dank :slight_smile:
Hootch

Im allgemeinen sind bei einem Datenbankserver RAM und Festplatten wichtig. Vor allem wenn die Datenbank so groß wird, dass sie nicht mehr in den Hauptspeicher passt, werden die Festplatten wichtig. High-End Systeme haben mehrere hundert Festplatten in einem RAID System (typischerweise RAID 10 oder RAID 01) um die I/O Leistung zu erhöhen.

Ohne eine konkrete “Kiste” ist das unmöglich zu beantworten. Um ein Gefühl für die Leistungsfähigkeit des Servers zu bekommen, kannst Du mit pg_bench einen einfachen TPS Benchmark laufen lassen.

Siehe oben. Je mehr desto besser. Lieber mehr RAM/Festplatten als schnellerer CPUs. Und lieber mehr CPUs als schnellerer

Mehr als 1000 Connections sind selten sinnvoll und werden von Postgres auch nicht gut verkraftet (oder jedem anderen DBMS). Typischerweise werden bei Anwendungen mir vielen Benutzern connection pools eingesetzt. Entweder im Application Server (z.B. der Tomcat JDBC Pool) oder durch einen externen Pooler wie pgPool oder pgBouncer.

Siehe oben: connection pool.

Horizontal skalieren kann Postgres auch. Nicht ganz so einfach wie die NoSQL “Gemeinde” aber auch ziemlich gut. Mit Boardmitteln z.B. über zusätzliche Hot-Standby Server die Read-Only Abfragen bedienen können. pgPool kann z.B. in einem load balancing Modus laufen bei dem lesende Anfragen automatisch auf die Slaves verteilt werden, schreibende dagegen immer auf den Master

Eine weitere Alternative wäre z.B. Postgres-XC

Wir betreiben z.B. einen Webshop der ohne Probleme 500 page views pro Sekunden mit einem einzigen (aktiven) Postgres Server verkraftet.

Warum ist der noch nicht bei uns gehostet?

Weil wir die (Software) Entwicklung machen und der Kunde das selber betreibt (alle unsere Kunden betreiben sowohl application server als auch DB Server selber in ihren Rechenzentren)

Ah ja. Na gut, die nächsten schickst halt zu uns, falls die kein eigenes RZ haben :wink: