Was ist zu groß für eine Datenbank?

Question

Ich habe einen Kumpel, der eine Web-App für Leute führt, die Autos zum Verkauf auflisten. Es gibt ein paar tausend Kunden, die es verwenden, und jeder Kunde hat Hunderte und manchmal Tausende von Zeilen in der Datenbank (einige sind seit 5 Jahren mit Hunderten von Autos pro Monat verkauft, und 10s Reihen pro Verkauf (Kommentare, Nachrichten, etc)). Er hat dieses System in einer einzigen SQL Server-Datenbank in einem physischen Server mit 20 GB oder RAM und ein paar Prozessoren für die ganze Zeit, ohne Probleme ausgeführt. Ist das eine Art Wunder?

Genau wie die meisten Programmierer, bin ich kein DBA und komme einfach dank ORMs, etc. Überall wo ich hinschaue, sprechen Leute über die Notwendigkeit zu shard oder einen separaten Datenbankserver für große Benutzer einer Web-App . Warum ist das? Ist es wirklich so ineffizient, eine große Datenbank mit vielen oder Zeilen zu haben? Soll ich Cassandra oder so verwenden, oder kann ich mich darauf verlassen, dass Postgres gut skaliert?

Answer 1

Ich persönlich denke nicht, was Sie beschrieben haben, ist das eine große Datenbank. Der Server (20 Gigs von Ram?;)) Klingt anständig. Es geht mehr um Nutzung und Design. Wenn die Datenbank indiziert und gut gestaltet ist, kann sie auf der aktuellen Hardware viel, viel größer werden.

Bevor ich irgendeine Art von Switch austrage, würde ich einfach die Archivierung von nutzlosen Daten und die Optimierung von Abfragen betrachten, wenn ich Angst vor Performance-Problemen habe.

Answer 2

Sie sollten kein Problem in SQL Server, Oracle oder einer modernen relationalen oder nicht-relationalen Datenbank haben. Ich habe Datenbanken mit 100 Millionen von Datensätzen und Terabytes an Daten verwaltet.

Answer 3

In meinem Kopf ist das nichts. Zig Millionen Zeilen in mehreren Tabellen mit einer Datenbankgröße von mehr als 10 GB haben für MS SQL Server keine Probleme verursacht. Natürlich ist es nicht so schnell mit so vielen Daten, aber ansonsten funktioniert es gut.

Und um die Frage zu beantworten, zu groß ist so groß, dass es Probleme verursacht. Und wenn es anfängt, Probleme zu verursachen, hängt von der Tabellenstruktur und Ihren Leistungsanforderungen ab.

Answer 4

Datenbanken sind extrem effizient beim Speichern und Abrufen von relationalen Daten (d. H. Daten, die strukturiert sind und Verweise auf andere Daten enthalten) - dafür wurden sie entwickelt. Ehrlich gesagt, 99% der Leute, die über Schlüssel-Wert-Läden und Kassandra spucken und was nicht wissen, was sie tun. Ein Datenbankserver eignet sich hervorragend zum Speichern großer Datenmengen, insbesondere wenn Sie etwas Feinarbeit leisten möchten.

Das heißt, es gibt Anwendungsfälle für Cassandra et. al. - Wenn Sie größtenteils unstrukturierte Schlüssel-/Wertdaten haben oder keine Konsistenz benötigen oder aus Redundanz heraus sharden möchten, ist es möglicherweise eine Untersuchung wert.

Wenn Sie nicht eine extrem beliebte Website sind, können Sie wahrscheinlich mit einem anständigen Datenbankserver gut durchkommen - wechseln Sie nicht, bis Sie festgestellt haben, warum Sie wechseln müssen. Schalten ist in Ordnung, nur stellen Sie sicher, dass Sie wechseln, weil es Ihren Bedürfnissen besser dient, und nicht, weil es die "coole Web-Maßstab Sache zu tun"

Answer 5

Der Grund für Sharding und separate Db-Server ist, dass irgendwann Es wird billiger sein, mehrere billigere Maschinen als eine teure zu verwenden. Der Hardwarepreis wird nicht linear mit der Leistung skaliert, und sobald Sie einen bestimmten Punkt erreicht haben, ist es viel billiger, doppelt so viele Maschinen zu erhalten, als eine Maschine, die doppelt so schnell ist.

Answer 6

Normalerweise teilen Sie Komponenten auf verschiedenen Servern auf, um Zeit, Ausfallsicherheit und Leistung einfacher zu verwalten.

Es ist sicherlich durchaus möglich, ein Monstergerät zu haben, das alles erledigt, aber dann brauchen Sie vielleicht ein anderes Monstergerät, falls Ihr Motherboard stirbt oder Ihr Datacenter nicht verfügbar ist.

Durch die Aufteilung einer Website oder Anwendung, unter verschiedenen Servern ist es einfacher, billigere Maschinen und mehr von ihnen zu bekommen. So können Sie Widerstandsfähigkeit aufbauen und haben keine Komponenten, die ähnliche Anforderungen an Hardwarekonflikte haben.

Es ist auch wichtig, über Wiederherstellungszeiten für Server und Wiederherstellungspläne nachzudenken.
Was passiert, wenn Ihre Maschine stirbt, können Sie sie in der vereinbarten Zeit ersetzen? Können Sie in dieser Zeit aus Sicherungen wiederherstellen?

SQL Server oder andere Datenbanken der Unternehmensklasse sollten keine Probleme mit Datenbanken mit 10 oder 100 GB haben, solange sie nicht zu schlecht entworfen wurden. (Wir haben ein paar Maschinen mit dieser Kapazität/Verwendung, die überhaupt nicht kämpfen.).