Hallo zusammen,
ich stehe vor der Aufgabe ein Maschinengewehr für eine Datenbank zu entwicklen 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 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
Hootch