Ich habe einen Kumpel, der eine Web-App für Leute betreibt, die Autos zum Verkauf anbieten. 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, reden Leute darüber, dass es nötig ist zu sharden oder einen separaten Datenbankserver für große Benutzer einer Web-App zu bekommen. Warum ist das? Ist es wirklich so ineffizient, eine große Datenbank mit vielen oder Zeilen zu haben? Soll ich Cassandra oder etwas verwenden, oder kann ich mich darauf verlassen, dass Postgres gut skaliert?
Ich persönlich denke nicht, was Sie beschrieben haben, ist diese 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 größer werden.
Bevor ich irgendeine Art von Switch einsetze, schaue ich einfach auf die Archivierung nutzloser Daten und die Optimierung von Abfragen, wenn Performance-Probleme auftreten.
Der Grund für sharding und getrennte db-Server ist, dass es irgendwann günstiger sein wird, 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.
Sie sollten kein Problem mit 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.
Normalerweise teilen Sie Komponenten auf verschiedenen Servern auf, um Zeit, Ausfallsicherheit und Leistung einfacher zu verwalten.
Es ist sicher durchaus möglich, einen Monster-Computer zu haben, der alles erledigt, aber dann brauchen Sie vielleicht einen anderen Monster-Computer, falls Ihr Motherboard stirbt oder Ihr Datencenter nicht verfügbar ist.
Durch das Aufteilen einer Website oder Anwendung auf verschiedene Server ist es einfacher, billigere Maschinen und mehr davon zu bekommen. So können Sie Widerstandsfähigkeit aufbauen und keine Komponenten mit ähnlichen Anforderungen an Hardware-Kollisionen 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 von Backups in dieser Zeit 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 sind. (Wir haben ein paar Maschinen mit dieser Kapazität / Verwendung, die überhaupt nicht kämpfen.).
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, ist zu groß so groß, dass es Probleme verursacht. Und wenn es beginnt, Probleme zu verursachen, hängt von der Tabellenstruktur und Ihren Leistungsanforderungen ab.
Datenbanken sind äußerst effizient beim Speichern und Abrufen von relationalen Daten (d. h. Daten, die strukturiert sind und Verweise auf andere Daten enthalten) - dafür sind sie konzipiert. 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, vor allem, 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 / Wert-Daten haben oder keine Konsistenz benötigen oder aus Redundanz heraus sharden möchten, kann es sich lohnen, dies zu untersuchen.
Wenn Sie nicht eine extrem beliebte Website sind, können Sie wahrscheinlich mit einem anständigen Datenbankserver zurecht kommen - wechseln Sie nicht, bis Sie festgestellt haben, warum Sie wechseln müssen. Switching ist in Ordnung, nur stellen Sie sicher, dass Sie wechseln, weil es Ihren Bedürfnissen besser dient, und nicht , weil es das "coole Web-Maßstab-Ding zu tun ist"
Tags und Links database database-performance scalability