Was ist eine angemessene Abfragezeit für zugehörige Tabellen mit sehr großen Datensätzen?

Question

Im Stackoverflow Podcast Nr. 19, Joe beschreibt Fogcreeks Entscheidung, zu haben Eine Datenbank pro Client Anstatt von Eine Datenbank für alle Clients. Das lässt mich über Folgendes nachdenken.

1. Angenommen, ich habe 1000 Benutzer.
2. Jeder Benutzer hat 100 Kunden.
3. Jeder Kunde hat 1000 Produkte.

Das heißt also, ich werde haben 1000 x 100 x 1000 = 100.000.000 Produkte, die mit Benutzern verbunden sind. Wenn ich nun eine Abfrage für einen Benutzer und alle Produkte seines Kunden mache, was sollte eine angemessene Menge an Abfragezeit sein, wenn ich zu diesem Zweck nur eine einzige Datenbank verwende?

AKTUALISIEREN

Vielleicht war ich in meiner Frage nicht klar genug. Angenommen, ich muss alle Arten von funky Abfragen (min, max, Gruppe usw.) mit den Datensätzen von oben beschrieben ausführen, wäre es langsam (oder nicht) bis zu dem Punkt, dass es besser sinnvoll ist, mehrere Datenbankstrategie z. . 1 dB/Client, Datenbank Sharding usw.

Answer 1

Ich stelle mir vor, die Antwort hängt von Ihrer Auswahl an DBMs ab. Mit Oracle wäre beispielsweise 1 große Datenbank definitiv vorzuziehen, tatsächlich wären 1000 identische Datenbanken absurd und unüberschaubar.

Müssen Sie auch nie Anfragen zwischen Benutzern ausführen? Finden Sie den Benutzer mit den meisten Produkten. Oder sind diese wirklich 1000 diskrete "private" Datenbanken und niemand hat einen Gesamtzugriff auf die Daten? Selbst dann bietet Oracle beispielsweise "virtuelle private Datenbank" an, um diese in einer einzelnen Datenbank zu sorgen.

Answer 2

Die Hauptgründe für eine Ein-Database-pro-Client-Strategie sind Sicherheit und Verwaltbarkeit. Während das Konzept der Sicherung/Wiederherstellung in einer einzelnen Datenbank anstelle von 100 clientspezifischen DBs einen Sieg erzielt, hat es einige Nachteile. Einige der Probleme mit einer gemeinsam genutzten Datenbank sind:

• Benutzer können die Datenbank nicht direkt ohne eine zusätzliche Sicherheitsmaßnahme (wie z. B. Ansichten) melden, um zu verhindern, dass sie die Daten der anderen sehen. Bei sensiblen Daten wird dies auch zu einem Einhaltungsproblem.

• Die gesamte Anwendung muss sich des Sicherheitsmodells bewusst sein, das ein gewisses Maß an Komplexität ergibt. Wiederum hat dies mit sensiblen Daten Auswirkungen auf die Compliance.

• Systemwartungs- oder Support -Ticket -Aufgaben mit Daten eines Kunden haben ein Risiko, dass ein Fehler die Daten anderer beeinflusst.

Die inhärente Kompartimentierung mehrerer Datenbanken vereinfacht die Anwendung und beseitigt die gesamten Probleme der Fehlerkonfiguration und Sicherheit. Wenn Sie die Anwendung erstellen, ist sie für das automatisierte Konfigurationsmanagement und die Bereitstellung in mehreren Umgebungen zugänglich, können Sie etwas erreichen, das selbst bei mehreren Instanzen ziemlich einfach zu pflegen ist.

Darüber hinaus können Sie mit den Datenvolumina und den Arten der Berichterstattung, die Sie beschreiben, möglicherweise besser als eine Art von Subsystem oder Data Mart erstellen, der die Berichterstattung vom Produktionsserver verschiebt. Analytische Berichte dieser Art sind für Sternschemata viel effizienter als die Art des normalisierten Schemas, das Sie in einer Transaktionsdatenbank verwenden würden.

Answer 3

Sie sollten in den meisten Fällen Benutzer und/oder Client als Teil der PK haben, sodass Ihre Leistung im Multi-Mandanten-Szenario nicht viel anders als der Einzelmieter-Fall beeinflusst werden sollte.

Answer 4

Wenn Sie all das, alle Spalten und Zeilen, ohne Filterung oder Aggregation erhalten möchten, müssen Sie sehr lange warten. Ich glaube nicht, dass es eine angemessene Zeit gibt, die Sie hier als Benchmark verwenden können. Du musst nur warten :)

Diese Arten von Abfragen passieren jedoch selten (es sei denn, Sie migrieren Ihre Daten - immer noch Alternativen). Normalerweise gibt Sie eine Teilmengezeilen oder eine Seite mit Zeilen, eine Auswahl von Spalten oder Aggregaten zurück. In diesem Fall hängt der "angemessene Betrag" von der Art der Abfrage und den damit verbundenen Berechnungen ab.