Kann es eine gute Idee sein, für jeden Client einer Webanwendung eine neue Tabelle zu erstellen?


10

Dies ist halbhypothetisch, und da ich keine Erfahrung im Umgang mit massiven Datenbanktabellen habe, habe ich keine Ahnung, ob dies aus irgendeinem Grund schrecklich ist. Weiter zur Situation:

Stellen Sie sich eine webbasierte Anwendung vor - beispielsweise eine Buchhaltungssoftware - mit 20.000 Clients und jedem Client mit mehr als 1000 Einträgen in einer Tabelle. Das sind 20 Millionen Zeilen, von denen ich weiß, dass sie komplexe Abfragen sicherlich verlangsamen können.

Ist es in einem solchen Fall sinnvoller, für jeden Client eine neue Tabelle in der Datenbank zu erstellen? Wie reagieren Datenbanken auf 20.000 (oder mehr!) Tabellen?

Antworten:


15

Im Allgemeinen, nein, es macht keinen Sinn, eine Tabelle (ich denke, Sie meinen hier tatsächlich Datenbank) pro Kunde zu haben. 20 Millionen Zeilen sind für eine Datenbanktabelle relativ klein. Die Abfragegeschwindigkeit dagegen sollte kein Problem sein, solange die Datenbank ordnungsgemäß optimiert (indiziert) und die Abfragen korrekt zusammengestellt sind. Welchen Nutzen Sie davon erwarten, dass sie getrennt werden, wird durch die zusätzliche Komplexität der Verwaltung von 20.000 einzelnen Datenbanken ausgeglichen. Was passiert zum Beispiel, wenn Sie die Tabellenstruktur ändern möchten? Sie müssen es jetzt 20.000 Mal tun!

Schlimmer noch, wenn Sie irgendwann feststellen, dass die Datenbankgröße zu einem Problem wird, können Sie sie anschließend jederzeit in separate Datenbanken aufteilen.


Nein, ich meinte wörtlich Tabellen innerhalb der Datenbank. Ich kann mir keinen Grund vorstellen, eine Datenbank pro Client zu erstellen. Und wenn 20 Millionen Zeilen klein sind, was ist dann groß? Und was machst du zu diesem Zeitpunkt?
Will

1
@ChrisF, genau - es gibt viele Fälle, in denen die Technologie oder das Geschäftsmodell separate DBs pro Client erfordert. Aber ich kann mir keinen Grund für separate Tabellen innerhalb derselben Datenbank vorstellen.
Großmeister

1
@GrandmasterB - Ich denke, @Will stellt die falsche Frage.
ChrisF

1
@ Will: Wechseln Sie nach Möglichkeit zu einer Oracle User Group-Besprechung oder zu einer anderen High-End-Datenbank. Sie werden feststellen, dass Ihre Vorstellungen von "klein" und "groß" viel Nachjustierung erfordern. Es ist mir passiert. Hinweis: Wenn es auf eine Festplatte passt, ist es nach DBA-Standards nicht groß.
David Thornley

1
@Gorton, InnoDB wird allgemein als besser für Zuverlässigkeit und Gleichzeitigkeit angesehen, MyISAM für Geschwindigkeit. Sie müssen also die verschiedenen Speicher-Engines basierend auf der erwarteten Datenbanknutzung Ihrer spezifischen Anwendung bewerten.
Großmeister

5

Klingt nach einer schlechten Idee.

Versuchen Sie nicht, die Datenbank mit solchen exotischen Konstruktionen zu überlisten. Datenbank-Engines wurden mit vielen Optimierungen für große Datenmengen entwickelt. Zum Beispiel klingt das, was Sie beschreiben, einem Versuch, Indizes manuell zu implementieren, sehr nahe. Verwenden Sie einfach die von der DB Engine bereitgestellten Indizes. Sie sind viel besser implementiert, als Sie es wahrscheinlich alleine können, und erfordern nicht so viel Wartung.

Auch als allgemeine Faustregel. Ich empfehle, eine Datenbank nicht so zu erstellen, dass während der normalen Verwendung der Anwendung eine Manipulation oder Erstellung von Datenbankstrukturen (Tabellen, Felder) erforderlich ist. Dies macht die Leistungsoptimierung zu einem Problem und zwingt Sie häufig dazu, Benutzern zu viele Berechtigungen für Routineaufgaben zu erteilen, wodurch möglicherweise Sicherheitslücken entstehen.


Ich würde für jeden Ihrer beiden Absätze einmal eine positive Bewertung abgeben, wenn dies zulässig ist.
David Thornley

3

Hier ist ein Artikel, den die Leute immer lesen sollten, wenn sie diese Frage stellen:

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html


Ich hatte keine Ahnung, dass eine Datenbank eine tatsächliche Datei pro Tabelle erstellt = x
Will

1
Dies kann vom tatsächlich verwendeten RDBMS abhängen. MySQL macht das (bis zu drei Dateien pro Tabelle, wenn Sie MyISAM verwenden). Andere vielleicht nicht.
Mchl

Die Enterprise-Version von SQL Server führt dies aus, wenn Sie es auf diese Weise entwerfen, jedoch nicht automatisch.
JeffO

Oracle macht das definitiv nicht.
user281377

Oracle kann es tun, die gleiche Art und Weise , dass SQL Server kann es tun, aber ich kann mir nicht vorstellen , warum Sie jemals Ihr Schema eine Datei pro Tabelle haben entwerfen würde. Das Aufteilen einer Datenbank in mehrere Dateien ist sinnvoll, jedoch nicht eine Datei pro Tabelle.
Dean Harding

1

IMHO sollte eine einzelne Tabelle kein Problem sein, also erstellen Sie kein Problem, bei dem es noch keine gibt. Sie können viel tun, um die Leistung zu verbessern. Sie können eine einzelne Tabelle basierend auf der Client-ID oder einem Datumsfeld in mehrere Dateien partitionieren, um die E / A zu unterstützen. Ihre Datenbank muss nicht 20.000 verschiedene SQL-Anweisungen für jede Abfrage, die Ihre Site benötigt, verfolgen, optimieren und zwischenspeichern. Sie können nach Client-ID indizieren. 20.000 Kunden können für viel Hardware bezahlen.

Für diesen Tabellentyp könnte eine NoSQL-Datenbank vom Typ db verwendet werden.

Bei 20.000 Clients ist die Datenbank möglicherweise nicht das schwächste Glied. Warum also so viel Komplexität einführen?


"Sie können eine einzelne Tabelle basierend auf der Client-ID oder einem Datumsfeld in mehrere Dateien aufteilen, um die E / A zu unterstützen." - Sie sind sich nicht sicher, was Sie damit meinen. Irgendeine Klarstellung?
Will

Mehrere Dateien auf dem Betriebssystem. Ein Server kann mehr als nur eine Datei lesen / schreiben.
JeffO

Ich denke, ich meinte: Ich habe noch nie von so etwas gehört. Wo finde ich weitere Informationen dazu? :-) Aber ich werde google ~
Will

msdn.microsoft.com/en-us/library/ms345146(v=sql.90).aspx Sie können auf Probleme mit der Sicherungsleistung stoßen, wenn sich die Indizes auf anderen Dateien als den von ihnen indizierten Tabellen befinden (oder möglicherweise auf Laufwerken?).
JeffO

0

Das ist wirklich ein schlechter Ansatz.

Partitionieren Sie die Tabelle vertikal, 2 Datenbankserver, einer für ungerade Benutzer-IDs und einer für gerade, sollten gut funktionieren (die Daten sind nicht zwischen Benutzern verknüpft).

Sortieren Sie die Daten nach user_id und wenn dies nicht möglich ist, besorgen Sie sich eine große Menge an RAM- oder SSD-Festplatten.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.