2014-02-18 22 views
37

Ich arbeite an dem Design für ein RoR-Projekt für mein Unternehmen, und unser Entwicklungsteam ist bereits in eine Debatte über das Design, speziell die Datenbank geraten.Wie groß ist zu groß für eine PostgreSQL-Tabelle?

Wir haben ein Modell namens Message, das beibehalten werden muss. Es ist ein sehr, sehr kleines Modell mit nur drei db-Spalten anders als die ID, aber wahrscheinlich wird es eine Menge dieser Modelle geben, wenn wir in Produktion gehen. Wir suchen bis zu 1.000.000 Insertionen pro Tag. Die Modelle werden immer nur von zwei Fremdschlüsseln durchsucht, die indiziert werden können. Außerdem müssen die Modelle nie gelöscht werden, aber wir müssen sie auch nicht behalten, wenn sie erst drei Monate alt sind.

Wir fragen uns also, ob die Implementierung dieser Tabelle in Postgres ein erhebliches Leistungsproblem darstellt? Hat jemand Erfahrung mit sehr großen SQL-Datenbanken, um uns zu sagen, ob dies ein Problem sein wird oder nicht? Und wenn ja, mit welcher Alternative sollten wir gehen?

+0

mit einer guten Cache-Layer und ein wenig Konfiguration in PG sollten Sie in Ordnung sein. Sie sollten Leistungsprobleme von Fall zu Fall angehen und eine Voroptimierung vermeiden. Das heißt, Partitionierung und Replikation sind immer großartige Optionen, die Sie nutzen können, sobald Sie auf Engpässe stoßen. –

+1

Verwandte Frage [hier] (http://stackoverflow.com/questions/13639626/database-columns-in-select-or-create-statements/13639920#13639920) und [hier] (http://stackoverflow.com/ Fragen/12606842/Was ist die maximale Anzahl von Spalten in einer Postgresql-Select-Abfrage). –

+1

Wir verarbeiten etwa 30 Millionen Nachrichten pro Tag in einer 5+ TB PostgreSQL-Datenbank, funktioniert gut. –

Antwort

41

Zeilen pro Tabelle sind kein eigenständiges Problem.

Also grob gesagt 1 Million Zeilen pro Tag für 90 Tage ist 90 Millionen Zeilen. Ich sehe keinen Grund, warum Postgres damit nicht umgehen kann, ohne alle Einzelheiten zu wissen, was Sie tun.

Abhängig von Ihrer Datenverteilung können Sie eine Mischung aus Indizes, gefilterten Indizes und Tabellenpartitionierung verwenden, um die Geschwindigkeit zu erhöhen, sobald Sie sehen, welche Leistungsprobleme auftreten können oder nicht. Ihr Problem wird bei allen anderen RDMS, die ich kenne, gleich sein. Wenn Sie nur 3 Monate im Wert von Datenentwurf in einem Prozess benötigen, um die Daten, die Sie nicht mehr benötigen, zu beschneiden. Auf diese Weise haben Sie eine konsistente Datenmenge auf dem Tisch. Ihr Glück, Sie wissen, wie viele Daten existieren werden, testen Sie es für Ihr Volumen und sehen Sie, was Sie bekommen. eine Tabelle Testen mit 90 Millionen Zeilen kann so einfach sein wie:

select x,1 as c2,2 as c3 
from generate_series(1,90000000) x; 

http://www.postgresql.org/about/

Limit Value 
Maximum Database Size  Unlimited 
Maximum Table Size   32 TB 
Maximum Row Size   1.6 TB 
Maximum Field Size   1 GB 
Maximum Rows per Table  Unlimited 
Maximum Columns per Table 250 - 1600 depending on column types 
Maximum Indexes per Table Unlimited 
+9

Ich stimme zu, dass 90 Millionen Zeilen kein Problem für PostgreSQL sein werden. Aber es könnte ein Problem für ein ORM mit PostgreSQL * sein. (Ein ORM mit irgendeinem dbms, eigentlich.) –

+0

@ MikeSherrill'Catcall 'Guter Punkt, ich war nur auf "Wie groß ist zu groß für einen PostgreSQL-Tisch?" – Kuberchaun

+0

@ MikeSherrill'CatRecall 'Warum könnte es ein Problem für ein ORM sein? :) – yeyo

20

Eine weitere Möglichkeit, Ihre Anfragen deutlich mit> 100 Millionen Zeilen auf einen Tisch zu beschleunigen ist im Off-Cluster Stunden Die Tabelle auf dem Index, die am häufigsten in Ihren Abfragen verwendet wird. Wir haben eine Tabelle mit> 218 Millionen Zeilen und 30x Verbesserungen gefunden.