it-swarm.com.de

Wann sollte eine separate Berichtsdatenbank erstellt werden?

Wir bauen eine Anwendung mit einer Datenbank (ja, ziemlich aufregend, oder :). Die Datenbank ist hauptsächlich transaktionell (um die App zu unterstützen) und führt auch ein bisschen "Berichterstellung" als Teil der App durch - aber nichts zu anstrengendes.

Darüber hinaus haben wir einige Berichtsanforderungen - aber sie sind im Moment ziemlich vage und hoch. Wir verfügen über ein internes Standard-Berichtstool, mit dem wir die "schwereren" Berichte erstellen, sobald sich die Anforderungen verfestigen.

Meine Frage lautet: Woher wissen Sie, wann eine separate Datenbank für die Berichterstellung erforderlich ist?

Welche Art von Fragen müssen gestellt werden? Aus welchen Gründen würden Sie entscheiden, dass eine separate Berichtsdatenbank erforderlich ist?

29
Adrian K

Im Allgemeinen gilt: Je geschäftskritischer die Transaktions-App und je anspruchsvoller die Berichtsanforderungen, desto mehr Splitting ist sinnvoll.

  1. Wenn die Transaktionsleistung von entscheidender Bedeutung ist.
  2. Wenn es schwierig ist, ein Wartungsfenster für die Transaktions-App zu erhalten.
  3. Wenn das Reporting die Ergebnisse nicht nur von dieser App, sondern von anderen Anwendungssilos korrelieren muss.
  4. Wenn die Berichte Trendberichte oder andere Arten von Berichten unterstützen müssen, die am besten für ein Star-Schema/eine Business Intelligence-Umgebung geeignet sind.
  5. Wenn die Berichte lange laufen.
  6. Wenn sich die Transaktions-App auf einer teuren Hardware-Ressource befindet (Cluster, Mainframe usw.)
  7. Wenn Sie Datenbereinigungs-/Extraktions-Transformations-Ladevorgänge für die Transaktionsdaten durchführen müssen (z. B. Zustandsnamen zu kanonischen Statusabkürzungen).

Dies fügt eine nicht triviale Komplexität hinzu, daher muss es einen guten Grund geben, sich zu trennen.

34
Rob

Normalerweise würde ich zunächst versuchen, aus der Transaktionsdatenbank zu berichten.

Stellen Sie sicher, dass alle Indizes, die Sie hinzufügen, um ein effizientes Reporting zu ermöglichen, häufig verwendet werden. Je mehr Indizes Sie hinzufügen, desto schlechter ist die Leistung bei Einfügungen und Aktualisierungen (wenn Sie Schlüssel ändern).

Wenn Sie zu einer Berichtsdatenbank wechseln, denken Sie daran, dass es nur ein paar Gründe gibt, warum Sie dorthin gehen:

Letztendlich besteht das wichtigste bei der Berichterstellung von Datenbanken darin, dass Sie Sperrenkonflikte aus der Datenbank OLTP entfernen. Wenn Ihre Berichtsdatenbank also eine direkte Kopie derselben Datenbank ist, verwenden Sie einfach verzögerte Momentaufnahmen, die die Produktionstransaktionen nicht beeinträchtigen.

Als Nächstes können Sie eine separate Indexierungsstrategie verwenden, um die Szenarien für die Berichterstellung zu unterstützen. Diese zusätzlichen Indizes können in der Berichtsdatenbank verwaltet werden, verursachen jedoch unnötigen Overhead in der Datenbank OLTP.

Nun können beide oben auf demselben Server (sogar dieselbe Instanz in einer separaten Datenbank oder auch nur in einem separaten Schema) ausgeführt werden und sehen dennoch Vorteile. Wenn CPU und IO vollständig verbunden sind, müssen Sie sich auf jeden Fall in einer separaten Box befinden (oder ein Upgrade Ihrer einzelnen Box durchführen).

Um letztendlich die Flexibilität der Berichterstellung zu erreichen, denormalisieren Sie schließlich die Daten (normalerweise in ein Dimensionsmodell oder Sternschema), sodass die Berichtsdatenbank dieselben Daten in einem anderen Modell enthält. Die Berichterstellung großer Datenmengen (insbesondere Aggregate) ist in Dimensionsmodellen extrem schnell, da die Sternschemata dafür sehr effizient sind. Es ist auch effizient für eine größere Vielfalt von Abfragen ohne viel Neuindizierung oder Analyse, um die Indizes zu ändern, da das Dimensionsmodell sich besser für unvorhergesehene Verwendungsmuster eignet (die alte "Slice-and-Dice-Methode"). Sie könnten sich vorstellen, dass dies eine Art Mini-Data-Warehouse ist, bei dem Sie Data-Warehousing-Techniken verwenden, aber nicht notwendigerweise ein ausgewachsenes Data-Warehouse implementieren. Außerdem sind Sternschemas besonders leicht für Benutzer zu verstehen und Datenwörterbücher sind für BI-Tools oder Berichtstools aus Sternschemas viel einfacher und einfacher zu erstellen. Sie können dies auf derselben Box oder in einer anderen Box usw. tun, genau wie zuvor beschrieben.

27
Cade Roux

@Nordpol: 

Hoffentlich haben Sie nach fast 2 Jahren Ihre Antwort gefunden. Diese Frage erfordert Erfahrung statt Wissenschaft. 

Als BI-Architekt gehe ich bei der Gestaltung jeder BI-Lösung für meine Kunden sehr unterschiedlich vor. Ich gehe keine Checkliste durch. Es erfordert ein allgemeines Verständnis ihres Systems, seiner Berichtsanforderungen, seines Budgets und seiner Leistungsfähigkeit. 

Ich persönlich bevorzuge es, die Berichtsprozesse so weit wie möglich auf der Datenbankseite zu halten (Best Practice in der BI-Welt). BERICHTSWERKZEUGE SIND NUR ZUR ANZEIGE ZWECK (MAXIMAL FÜR KLEINE BERECHNUNGEN). Dieser Ansatz erfordert viel Vorverarbeitung von Daten, für die unterschiedliche Staging-Tabellen, Trigger usw. erforderlich sind.

als Sie sagten:

Ich arbeite an Projekten mit Hunderten von Millionen Zeilen mit Echtzeitberichten und Hunderten von Benutzern, die gleichzeitig auf die Anwendung/Datenbank zugreifen, ohne dass ein Problem auftritt.

Mit Ihrer Aussage stimmen einige Dinge nicht.

  1. Hunderte von Millionen Reihen sind eine Menge. Selbst die heutigen Speicher-Tools wie Cognos TM1 oder Qlikview haben Probleme, solche Ergebnisse zu erzielen. (Schauen Sie sich SAP HANA von SAP an an, um zu verstehen, wie große Unternehmen der Branche damit umgehen). 

  2. wenn Sie Hunderte Millionen Zeilen in der Datenbank haben, bedeutet dies nicht unbedingt, dass der Bericht all diese Datensätze durchlaufen muss. Vielleicht funktionierte der Bericht auf 1000er und nicht auf Millionen. wahrscheinlich hast du das gesehen.

  3. Transaktionsberichte unterscheiden sich stark von Dashboards. Die meisten Dashboard-Tools bereiten die Daten vor und speichern sie im Cache.

Ich weiß, dass ich zwei Jahre später antworte und meine Gedanken sind nicht gut organisiert, aber ich möchte sagen, dass es alles zu erleben ist, wenn ich entscheiden möchte, wann: 1. ein neues Schema entwerfen 2. Erstellen Sie eine semantische Datenbank 3. Arbeit an derselben Transaktionsdatenbank 4. oder sogar ein Berichterstellungs-Tool verwenden (Manchmal würden handgeschriebene Dashboards mit Java/JSF/Ajax/jQuery oder JSP für den Client funktionieren)

7
Misa J.

Der Hauptgrund, warum Sie eine separate Datenbank für das Melden von Problemen benötigen, ist, wenn die Generierung der Berichte die Transaktionsverantwortlichkeiten der App beeinträchtigt. Z.B. Wenn für die Erstellung eines Berichts 20 Minuten erforderlich sind und 100% der CPU/Diskette usw. während einer Zeit hoher Aktivität verwendet werden, könnten Sie die Verwendung einer separaten Datenbank für die Berichterstellung in Betracht ziehen.

Für Fragen gibt es einige grundlegende Fragen:

  1. Kann ich die Berichte mit hoher Intensität auch außerhalb der Spitzenzeiten erstellen?
  2. Stört es die Benutzer, die das System verwenden?
  3. Wenn ja zu # 2, was sind die Kosten für die Interferenz Vs die Kosten für einen anderen Datenbankserver, den Refactoring-Code usw.?
1
Corith Malin

Grundsätzlich, wenn die Datenbanklast aus der App mit der Datenbanklast für die Berichterstellung nicht mehr kompatibel ist. Dies könnte folgende Ursachen haben:

  • Berichte, die übermäßig viele Datenbankserverressourcen verbrauchen, die sich auf die DB-Leistung der App auswirken. 

    Ein Teil dieser Kategorie besteht darin, dass die App-Datenbankarbeit aufgrund einer Sperrung auf eine äußerst langsame Berichtsabfrage warten muss, obwohl die Auflösung möglicherweise mit weniger einschneidenden Methoden wie der Sperrenabstimmung gelöst werden kann.

  • Das Melden von Abfragen ist mit App-Abfragen im Hinblick auf die Abstimmung sehr unverträglich (z. B. Indizes, aber nicht darauf beschränkt). Das dümmste Beispiel wäre so etwas wie ein Hotspot, der sich aufgrund des Index für Berichtszwecke auf App-Inserts auswirkt.

  • Zeitprobleme. Z.B. Die einzigen kleinen Fenster für die DB-Wartung (aufgrund der Anwendungsnutzung) sind die Zeiten, in denen umfangreiche Berichtsarbeiten anfallen

  • Das schiere Volumen der Berichtsdaten (z. B. Protokollierung, Überwachung, Statistiken) ist so groß, dass Ihre primäre DB-Serverarchitektur eine schlechte Lösung für solche Berichte darstellt (siehe Sybase ASE vs. Sybase IQ). Übrigens, das ist ein echtes Szenario - deshalb haben wir unser Leistungsreporting auf IQ verlagert.

1
DVK

Ich würde auch einen weiteren Grund hinzufügen, aus dem Sie eine Berichtsdatenbank verwenden könnten, und zwar: CQRS-Muster (Command Query Responsibility Separation).

Wenn Sie eine große Anzahl von Benutzern haben, die auf einen kleinen Datensatz zugreifen und darauf schreiben, sollten Sie dieses Muster in Betracht ziehen. Im einfachsten Fall bedeutet dies, dass alle Befehle (Erstellen, Aktualisieren, Löschen) in die Transaktionsdatenbank übertragen werden. Alle Ihre Abfragen (Lesen) stammen aus Ihrer Berichtsdatenbank. Auf diese Weise können Sie Ihre Architektur und die Aktualisierungsfunktion frei skalieren.

Es gibt VIEL mehr im Muster, ich habe gerade das Bit erwähnt, das aufgrund Ihrer Frage bezüglich der Berichtsdatenbank interessant war.

0
Deleo

Ich möchte auch hinzufügen, dass Transaktionsdatenbanken den aktuellen Status beibehalten sollen und dies oftmals als selbstverwaltend gelten. Sie möchten nicht, dass Transaktionsdatenbanken über ihre erforderlichen Mittel hinauswachsen. Wenn ein Workflow oder eine Transaktion abgeschlossen ist, verschieben Sie diese Daten in eine Berichtsdatenbank, die viel besser für historische Daten ausgelegt ist.

0
Fratt