INSERT Performance steigern/stabil halten
verwendetes Datenbanksystem: <SQL Server 2005>
Gibt es Möglichkeiten, das Inserten von Daten in DB zu steigern bzw. mit steigender DB nicht unbedingt linear Performanceverluste hinnehmen zu müssen?
z.B gab es einen Tipp, daß man immer explizit Transactions verwenden sollte, da implizit jedesmal eine Transaction aufgerufen wird und dies nicht besonders der Performance gut tut.
Ich bräuchte paar Tipps um INSERTS bis ca 1 Mrd Records stabil halten zu können.
Aktuelles Problem ist das Testen gegen das real existierende DB System mit noch wenig eingefügten Daten, deshalb wende ich mich an euch, die Erfahrung mit DBs haben, die selbst einen hohen Datendurchsatz haben.
*Der SQL-Server bietet Klassen für den BulkInsert von Daten an, vllt, wäre das was für dich *Um das Hinzufügen (und vor allem das Löschen) performant zu gestalten, ist es wichtig, das die Tabelle an sich schlank ist. Es zählt nicht die Anzahl der Datensätze sondern die Breite (Anzahl der Spalten). Was auch noch ein großer Faktor ist, sind Foreignd Keys sowie jede Art von Index. Halte diese auf ein minmum begrenzt *Transaktion auf jedenfall beibehalten. Wenn was zwischendrin passiert Rollback und du hast einen immernoch einen definierten Zustand deiner DB. Eventuell holst du etwas mehr Performance raus wenn du den Transaktionslevel änderst, ist aber nur ein eventuell.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Bei großen Inserts Indizes droppen und hinterher wieder erstellen. Ist meist schneller.
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!
YARRRRRR!
Danke für die Antworten.
@kleines_e
Um das Hinzufügen (und vor allem das Löschen) performant zu gestalten, ist es wichtig, das die Tabelle an sich schlank ist. Es zählt nicht die Anzahl der Datensätze sondern die Breite (Anzahl der Spalten). Was auch noch ein großer Faktor ist, sind Foreignd Keys sowie jede Art von Index. Halte diese auf ein minmum begrenzt
Diesen Zusammenhang verstehe ich nicht. Warum ist die Spaltenanzahl wichtiger? Die Tabelle hat eine bestimmte Breite. Nach dieser Logik müsste die Performance konstant bleiben, wenn wir keinen Index verwenden.
Tabellen schlank zu halten wird ein Problem, denn spätestens mit etlichen gejointen Tabellen wird das Auslesen schwerlastig (DB Design)
@GMLOD
Ist bereits implementiert. Trotzdem happert es schon bei ein paar Millionen Einträgen.
Schon? Was heisst schon? Reden wir von 5 Minuten? Von einer Stunde?
Das ist doch noch gar nichts.
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!
YARRRRRR!
Was ist das für ein Server (CPU, Ram, Festplatte, Raid), wie ist er Konfiguriert (Ram-Nutzung-Gesamt, Ram-Netzung pro Select) usw?
Um wieviel Millionen Einträge handelt es sich, wie lang wird dafür gebraucht?
Wie sieht die Tabelle überhaupt aus? (Tabellendefinition)
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hallo Sera,
Diesen Zusammenhang verstehe ich nicht. Warum ist die Spaltenanzahl wichtiger?
Dass eine fixe Vorgabe auch konstante Werte verursacht ist klar. Was die Frage ist: "kann man die Spaltenzahl verringern"? Denn wenn ja, dann wäre das ein Performancegewinn.
Tabellen schlank zu halten wird ein Problem, denn spätestens mit etlichen gejointen Tabellen wird das Auslesen schwerlastig (DB Design)
Das ist aber ein grundlegendes Problem, was z.B. auch Datenredundanz begründet / verwirft. Eien auf Einfügen getrimmte Tabelle wird immer langsamer zu lesen sein, als eine auf Lesen getrimmte und vice versa.
Entweder man entscheidet sich für eine Variante von beiden, oder man wählt einen Mittelweg auf Kosten der Leistung beider Operationen, das ist aber reine Design- und vor allem Anforderungsentscheidung.
Ein schnelles Lesen UND ein schnelles Einfügen bei diesen Datenmengen wird es nicht geben. (Wobei die Frage ist, was ist denn überhaupt schnell?) Ein SQL Server 2005 sollte auch deutlich unter einer Sekunde bei einstelligen Millionen Datensätzen bleiben, auch wenn man keine großen Optimierungen vornimmt und Designfehler verhindert.
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Ein SQL Server 2005 sollte auch deutlich unter einer Sekunde bei einstelligen Millionen Datensätzen bleiben, auch wenn man keine großen Optimierungen vornimmt und Designfehler verhindert.
Das erscheint mir eher wie ein Wunschtraum. Kannst du das irgendwie begründen/nachweisen? Setup, Insert Script/Procedure etc.
Denke nicht, dass sowas auf Real World Scenarios zutrifft, geschweige denn auf Fiktive.
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!
YARRRRRR!
Hier vllt. noch ein paar zusätzliche Links:
SQL Server Storage Engine (Table locks verwenden, kleine häppchen-Transktionen)
Inserting 25 millions records SQL server takes 3hrs. (Speicher-Einstellungen, sowie getrennte Festplatten für Daten und Transaktionslog)
http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=103124
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Was ist das für ein Server (CPU, Ram, Festplatte, Raid), wie ist er Konfiguriert (Ram-Nutzung-Gesamt, Ram-Netzung pro Select) usw?
Um wieviel Millionen Einträge handelt es sich, wie lang wird dafür gebraucht?
Wie sieht die Tabelle überhaupt aus? (Tabellendefinition)
CPU Quadcore 4x2,4
RAM 8 GB (wobei die RAM keine Rolle spielen, da Data Warehouse - denormalisert)
HD 2x 1 TB
Die Tabellen haben maximal 50 Spalten (nur wenige).
Einträge auf 2 Jahre - über 1 Mrd (6 Tabellen, Rest sind Fact Tables)
Hallo Sera,
Diesen Zusammenhang verstehe ich nicht. Warum ist die Spaltenanzahl wichtiger?
Dass eine fixe Vorgabe auch konstante Werte verursacht ist klar. Was die Frage ist: "kann man die Spaltenzahl verringern"? Denn wenn ja, dann wäre das ein Performancegewinn.Tabellen schlank zu halten wird ein Problem, denn spätestens mit etlichen gejointen Tabellen wird das Auslesen schwerlastig (DB Design)
Das ist aber ein grundlegendes Problem, was z.B. auch Datenredundanz begründet / verwirft. Eien auf Einfügen getrimmte Tabelle wird immer langsamer zu lesen sein, als eine auf Lesen getrimmte und vice versa.Entweder man entscheidet sich für eine Variante von beiden, oder man wählt einen Mittelweg auf Kosten der Leistung beider Operationen, das ist aber reine Design- und vor allem Anforderungsentscheidung.
Ein schnelles Lesen UND ein schnelles Einfügen bei diesen Datenmengen wird es nicht geben. (Wobei die Frage ist, was ist denn überhaupt schnell?) Ein SQL Server 2005 sollte auch deutlich unter einer Sekunde bei einstelligen Millionen Datensätzen bleiben, auch wenn man keine großen Optimierungen vornimmt und Designfehler verhindert.
Grüße
Norman-Timo
Definiton Schnelligkeit: Es soll schnell für den User sein, wenn er einen Eintrag durchführt und auf das Ergebnis wartet.
Ein SQL Server 2005 sollte auch deutlich unter einer Sekunde bei einstelligen Millionen Datensätzen bleiben, auch wenn man keine großen Optimierungen vornimmt und Designfehler verhindert.
Das erscheint mir eher wie ein Wunschtraum. Kannst du das irgendwie begründen/nachweisen? Setup, Insert Script/Procedure etc.
Denke nicht, dass sowas auf Real World Scenarios zutrifft, geschweige denn auf Fiktive.
Ich denke er meinst, daß der Insert eines einzigen Records diese Zeit beansprucht, was derzeit auch bei mir funktioniert.
Hallo zusammen,
als erstes einmal die Datenbank an sich auf eine deutlich höhere Dateigrösse stellen wie im Moment benötigt. Damit ersparst Du dir sine Fragmentierung der Datenbankdatei im Dateisystem des Servers und kostenintensive allokation von Festplattenspeicher (auch wenn das seltener vorkommt).
Zur Spaltenbreite: Es gibt da die magische Grenze von 8000 Bytes (+ ein paar zerquetschte) welche dafür sorgt, dass wenn eine Datenzeile größer als diese Menge ist, auch immer ein zusätzlicher Daten-Block benötigt wird.
Indizes: Clustered Indizes sortieren die Daten physisch, also wenn ein Clustered Index auf z.B. Spalte "Name" gelegt wäre, würde ein Datensatz Möller zwischen "Meier" und "Müller" eingefügt. NonClustered Indices sind zusätzliche Tabellen mit Verweis auf den entsprechenden Datensatz.
Man kann auch die Index- und Datentabellen in unterschiedliche Dateien schreiben lassen. Diese sollten dann aber auch auf unterschiedliche Plattenstapel verweisen.
Arbeitsspeicher: spielt immer eine Rolle, wenn z.B. zu wenig Speicher vorhanden ist, dann muss auch für einen Select auf die Platten zugegriffen werden (nicht alles im Cache) ansonsten nur für Insert/Update.
hmm, mehr fällt mir auf die schnelle nicht ein.
🙂
Xynratron
PS: Foreigen Keys mit Konsistenzprüfung und Trigger sind auch ein Punkt. Mach mal die Inserts als StoredProcedure, das gibt immer noch Performace.
Edit: Typos
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
huhu nochmal^^
Ich bräuchte paar Tipps um INSERTS bis ca 1 Mrd Records stabil halten zu können.
Hmm, nochmal lesen, Antwort präzisieren:
Eine Datenbank-Datei nur für diese Tabelle, Speicher sofort auf ungefähr die benötigte Größe festlegen. Clustered Index nur verwenden wenn der auf einer Identity-Spalte liegt. Jeder andere Index wird leider dafür sorgen, dass die Performance (langsam) mit steigender Zeilenanzahl sinkt. Ansonsten sollte die Performance relativ identisch sein. Deine Platten machen Dir evtl. noch einen strich durch die Rechnung, wenn der hintere Teil der Datenbank-Datei in einem langsameren Bereich der Platten liegt.
🙂
Xynratron
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
Ich denke er meinst, daß der Insert eines einzigen Records diese Zeit beansprucht, was derzeit auch bei mir funktioniert.
Super! Nur 277 Stunden für 1 000 000 Inserts!
[/IRONIE]
Nein, das hat er sicher nicht gemeint. Er ist wahrscheinlich sehr begeistert vom SQL Server aber hat ihn in dieser Hinsicht total überschätzt. Mal ehrlich, die Aussage ist utopisch.
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!
YARRRRRR!
Hallo GMLOD,
doch ich meinte selbstverständlich das Einfügen EINES Datensatzes, um genauer zu sein eigentlich das Selektieren EINES Datensatzes.
Das Einfügen von 1 Milliarde Datensätzen kann überhaupt nicht unter einer Sekunde liegen. Ohne das jetzt zu verifizieren, das wird wahrscheinlich schon nicht gehen, wenn es sich nur um Boolsche-Variablenwerte handeln würde.
Selbstverständlich ist da die Platte der Flaschenhals.
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Einträge auf 2 Jahre - über 1 Mrd (6 Tabellen, Rest sind Fact Tables)
2 Jahre sind rund 63 Millionen Sekunden. Dann müsste deine Datenbank bei gleichmässiger Insert Verteilung 31 Inserts pro Sekund schaffen. Ich denke das wird zu einem Problem führen, und bedarf sicherlich einer genaueren Datenanlyse. Es gibt viele Ecken, wo man an der Performance von Datenbank schrauben kann. Hier mal einige Punkte die unbedingt bei solchen Datenmengen zu beachten sind:*Soviel RAM reinpacken wie möglich *Ordentlicher Prozessor *Schnelles Disk RAID (nicht unbedingt ein RAID 5. Datensicherheit kannst du auch durch eine Clusterlösung erreichen) *Datenfile und Transaktionslog auf 2 getrennten RAIDs ablegen *Fixe Disks verwenden (z.B. FC), die auch nicht zu gross sind. Kleinere Disks sind wesentlich performanter als jetzt eine TB Platte reinzuhauen *Sich ordentlich Gedanken machen, welche Spalten indiziert werden müssen
Hallo GMLOD,
doch ich meinte selbstverständlich das Einfügen EINES Datensatzes, um genauer zu sein eigentlich das Selektieren EINES Datensatzes.
Das Einfügen von 1 Milliarde Datensätzen kann überhaupt nicht unter einer Sekunde liegen. Ohne das jetzt zu verifizieren, das wird wahrscheinlich schon nicht gehen, wenn es sich nur um Boolsche-Variablenwerte handeln würde.
Selbstverständlich ist da die Platte der Flaschenhals.
Grüße
Norman-Timo
Dann entschuldige bitte die Unterstellung, aber das war sehr missverständlich ausgedrückt.
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!
YARRRRRR!
Vllt. noch ein Hinweis, außer Raid 0 machen Raids auf Datenbank-Servern wenig Sinn, da in Datenbanken mit Schreibzugriffen immer die Platten der Flaschenhals sind.
Eine vernünftige Backup-Strategie ist immer besser, preiswerter und effizienter als unsummen in Platten und Raid-Controller reinzustecken. Es nützt zum Beispiel garnix, wenn man Raid 1, 10, 5, 50 oder 51 verwendet, wenn der Raidcontroller ein defekt hat, trotz das man viel Geld in Platten investiert hat.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hallo,
Dann müsste deine Datenbank bei gleichmässiger Insert Verteilung 31 Inserts pro Sekund schaffen. Ich denke das wird zu einem Problem führen
Das halte ich allerdings für ein Gerücht. Hier gerade an meinem langsamen Entwicklungsrecher getestet und ich schaffe 3000 Inserts/s.
Auch wenn meine Test-Tabelle natürlich ein Scherz (nur ein Autoinc + nvarchar für Daten) ist, selbst bei größeren Tabellen und mehreren Überprüfungen der Daten etc. denke ich dass eine entsprechende Maschine selbst bei 150 Inserts (= 1Mrd / 250 (tage) / 8 (Arbeitsstunden) / 60 / 60) sich dann doch nur langweilt.
🙂
Xynratron
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
Das halte ich allerdings für ein Gerücht. Hier gerade an meinem langsamen Entwicklungsrecher getestet und ich schaffe 3000 Inserts/s.
Ich ging auch davon aus, dass während der Zeit auch reges Lesen aus der Datenbank stattfindet. Und in deiner Testtabelle hast du sicherlich keine 1 Milliarde Datensätze drin. Gerade, wenn dann auch noch einige Indizes auf der Tabelle definiert sind, dauert ein Insert schon etwas länger.
Aber klar, ein Server sollte 35 Inserts/sec. locker wegstecken, auch bei grossen Datenmengen, aber man sollte sich dann doch ein gescheites Konzept überlegen, wie die Datenbank abgelegt werden soll.
Hallo,
Dann müsste deine Datenbank bei gleichmässiger Insert Verteilung 31 Inserts pro Sekund schaffen. Ich denke das wird zu einem Problem führen
Das halte ich allerdings für ein Gerücht. Hier gerade an meinem langsamen Entwicklungsrecher getestet und ich schaffe 3000 Inserts/s.
Auch wenn meine Test-Tabelle natürlich ein Scherz (nur ein Autoinc + nvarchar für Daten) ist, selbst bei größeren Tabellen und mehreren Überprüfungen der Daten etc. denke ich dass eine entsprechende Maschine selbst bei 150 Inserts (= 1Mrd / 250 (tage) / 8 (Arbeitsstunden) / 60 / 60) sich dann doch nur langweilt.
🙂
Xynratron
Interessant hier ist, wie lange deine 3000 Inserts/s linear bleiben.
Wie führst du die Inserts aus?
Wie schon gesagt wurde solltest du dich hinsichtlich Hardware erstmal richtig beraten lassen. Mit 2x 1TB wahrscheinlich noch sata platten geht da natürlich wenig voran.
Meine Tests haben ganz grob folgende Werte ergeben :
Einfügen von ca. 1 Mio. Datensätzen einzeln per Dataset : 36 h
Einfügen von ca. 1 Mio. Datensätzen auf einmal per Bulk Insert : 7 Minuten
Einfügen von ca. 1 Mio. Datensätzen auf einmal per Dataset und Transaktion : 3 h (achtung : hoher Hauptspeicherbedarf)
Ich benutze inzwischen die Lösung 3, da das Ganze auch bei Kunden laufen soll und ich beim Bulk Insert keine Fehlermeldungen bekomme wenn es schiefgeht (Sonderzeichen, Feldlänge etc.). Ausserdem klappt Lösung 3 auch bei MySQL und beim SQL Compact Server (da aber nicht so schnell).
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
Hallo,
als schnellere Alternative zu Festplatten könnte man HyperDrive einsetzen.
"In other words one would need to spread the data over a merely fifty hard disks to obtain the same performance as a single HyperDrive4. If we look back at the 2K OLTP performance one would need to stripe the OLTP database over roughly a hundred hard disks to get equal performance to a single HyperDrive4."
Viele Grüße,
moq
Einfügen von ca. 1 Mio. Datensätzen auf einmal per Dataset und Transaktion : 3 h (achtung : hoher Hauptspeicherbedarf)
Der hohe Speicherbedarf sind die Nachteile vom GC. Vor allem Strings werden erstellt, bearbeitet (neuerstellt) und zu einem späteren Zeitpunkt wieder freigegeben. Das trifft aber auch das Boxing-Verfahren von Werttypen. Der GC-Collect dauert anschließend bei mehreren 1.000 Objekte sehr lange. Optimieren lässt sich das durch die Verwendung von Zeigern und eventuell CommandBuilder
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Hallo,
ich habe gelesen Data Warehouse.
Wann sollen den die Inserts stattfinden? Mittem am Tag oder Nachts?
Ich arbeite selber an so einem Projekt. Bei mir finden alle inserts nacht statt.
Da hast du am wenigstens Last auf dem Server.
Das Projekt läuft auf einem SQL Server 2000.
Also verwende ich DTS Packete.
Mein gesamter ablauf benötigt gute 2,5 Stunden. In den 2,5 Stunden finden
viele Operationen statt. (rund 60 mio. datensätze)
- Tabellen dropen -> Neu holen und -> Index neu machen
- Andere Quelle (dbf Files 😁 ) -> Tabelle leeren -> reinladen in zwischentabelle
-> auf unterschiede Prüfen -> geänderte Datensätze in andere Tabelle schreiben -> geänderten Datensatz lösch und mit aktuellen wert befüllen (Funktioniert alles über binary_checksum braucht bestimmt auch einiges an rechenzeit).
Also ich kann nur empfehlen indexe dropen und vielleicht auch die transaktionlogs
zwischendurch zu sichern und dann zu leeren.
mfg phlekk
Huhu,
Das halte ich allerdings für ein Gerücht. Hier gerade an meinem langsamen Entwicklungsrecher getestet und ich schaffe 3000 Inserts/s.
Ich ging auch davon aus, dass während der Zeit auch reges Lesen aus der Datenbank stattfindet. Und in deiner Testtabelle hast du sicherlich keine 1 Milliarde Datensätze drin. Gerade, wenn dann auch noch einige Indizes auf der Tabelle definiert sind, dauert ein Insert schon etwas länger.Aber klar, ein Server sollte 35 Inserts/sec. locker wegstecken, auch bei grossen Datenmengen, aber man sollte sich dann doch ein gescheites Konzept überlegen, wie die Datenbank abgelegt werden soll.
Klar, Konzept ist eh das A und O - das rege lesen der Daten kann man mit genug Ram abfangen etc. Aber dazu habe ich ja weiter oben schon was geschrieben.
Interessant hier ist, wie lange deine 3000 Inserts/s linear bleiben.
Dazu hatte ich auch weiter oben schon was geschrieben. Am wichtigsten ist IMHO wohl als erstes die Datenbankdatei nicht zu fragemntieren und sie auf den schnellsten Bereichen der Platte zu haben. Dann noch mit den Indices aufpassen. Damit lässt sich der Performance-Verlust bei vielen Datensätzen minimieren, aber gänzlich ausschliessen kann man den nie.
🙂
Xynratron
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
Der hohe Speicherbedarf sind die Nachteile vom GC. Vor allem Strings werden erstellt
Der hohe Speicherbedarf kommt dadurch zustande, dass ich alle Datensätze auf einmal in ein Dataset lade.
Da bei einem Kunden die Meldung kam "Hauptspeicher nicht ausreichend" hab ich die maximale Datasetgröße nun auf 500 MB beschränkt.
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
@Xynratron
Wenn es nur um diese Eigenschaften geht, dann ist es schon ein bisschen heftig. Da kann man bis auf die Indizes auf diverse SQL Performance Gschichterln verzichten.
Der hohe Speicherbedarf sind die Nachteile vom GC. Vor allem Strings werden erstellt
Der hohe Speicherbedarf kommt dadurch zustande, dass ich alle Datensätze auf einmal in ein Dataset lade.
Da bei einem Kunden die Meldung kam "Hauptspeicher nicht ausreichend" hab ich die maximale Datasetgröße nun auf 500 MB beschränkt.
Grüße Bernd
Du lädst also zuerst alle für den Insert benötigten Daten in eine DataTable und führst somit den Insert als Gesamtes aus? Arbeitest du dabei mit dem TableAdapter?
@phlekk
Der Haupteil wird Nachts durchgeführt, was keinen stört. Am Tag jedoch befürchte ich Leistungseinbußen in Bezug auf die Benutzer. Und ein Insert kann schon bei diesen Datenmengen lästig sein, da asynchrones Arbeiten ohne Insertresultat unmöglich ist.
@Xynratron
Wenn es nur um diese Eigenschaften geht, dann ist es schon ein bisschen heftig. Da kann man bis auf die Indizes auf diverse SQL Performance Gschichterln verzichten.
Naja, oben hatte ich ja Eckpunkte aufgeführt. Ich würde an deiner Stelle mal ein Testsystem aufbauen und die wirklich auftretenden Performance-Unterschiede bei wenigen und vielen Daten ansehen und dann weiter entscheiden.
🙂
Xynratron
Edit: präziser formuliert
Herr, schmeiss Hirn vom Himmel - Autsch!
Die Erfahrung zeigt immer wieder, dass viele Probleme sich in Luft auslösen, wenn man sich den nötigen Abstand bzw. Schlaf gönnt.
Mir kommt mal so ne Idee.
Bist du sicher dass du die ganze Milliarde Daten immer brauchst zum Arbeiten, oder stellen die nur eine Art Archiv dar nach einer gewissen Zeit. Falls das der Fall, kannst du mit einer Archivierungstabelle arbeiten, die du nachts füllst. Die Benutzer arbeiten dann nur auf einer aktuellen Tabelle mit den Records der letzten x Tage. Wollen sie tiefer suchen, dann muss die Archivtabelle herangezogen werden und es dauert länger.
Vorteil: der Satz an Daten der letzten x Tage bleibt schlank, und du hast somit keine Performanceeinbussen. Dies ist ein Prinzip, das sehr oft verwendet wird bei grossen Datenmengen.
@Sera
Hmm. Sind den die Tabellen gleich aufgebaut, wie die Tabellen von den du die Daten holst?
Wenn ja, vielleicht wäre Replikation dafür geeignet.
Wenn nicht, würde ich den gleichen Weg, wie Jelly vorgeschlagen hat, angehen.
mfg phlekk
@Xynratron
Wenn es nur um diese Eigenschaften geht, dann ist es schon ein bisschen heftig. Da kann man bis auf die Indizes auf diverse SQL Performance Gschichterln verzichten.
Naja, oben hatte ich ja Eckpunkte aufgeführt. Ich würde an deiner Stelle mal ein Testsystem aufbauen und die wirklich auftretenden Performance-Unterschiede bei wenigen und vielen Daten ansehen und dann weiter entscheiden.
🙂
Xynratron
Edit: präziser formuliert
ja, testsystem aufzubauen mit altem datenbestand würde funktionieren, was ich wohl auch machen werde.
Mir kommt mal so ne Idee.
Bist du sicher dass du die ganze Milliarde Daten immer brauchst zum Arbeiten, oder stellen die nur eine Art Archiv dar nach einer gewissen Zeit. Falls das der Fall, kannst du mit einer Archivierungstabelle arbeiten, die du nachts füllst. Die Benutzer arbeiten dann nur auf einer aktuellen Tabelle mit den Records der letzten x Tage. Wollen sie tiefer suchen, dann muss die Archivtabelle herangezogen werden und es dauert länger.
Vorteil: der Satz an Daten der letzten x Tage bleibt schlank, und du hast somit keine Performanceeinbussen. Dies ist ein Prinzip, das sehr oft verwendet wird bei grossen Datenmengen.
Danke, gute Idee mit den Archivtabellen.
Und die Milliarden sind nur der gesamte Datenbestand. Geht nur darum, daß nicht paar Inserts pro Tag Schwierigkeiten machen sollen.
Und die Milliarden sind nur der gesamte Datenbestand. Geht nur darum, daß nicht paar Inserts pro Tag Schwierigkeiten machen sollen.
Dann ist die von mir vorgeschlagene Lösung eigentlich ganz brauchbar. Du hast zwar den Aufwand, aus deinem Programm heraus die 2 Tabellen zu verwalten, dafür bleibt deine Arbeitstabelle aber schön schlank und wird dir nie Sorgen bereiten. Über Nacht kannst du dann einen SQL Job laufen lassen, der ältere Records aus der Arbeitstabelle in die Archivetabelle schaufelt und dann die betroffenen Records in der AT löscht.
Um Daten abzufragen lass ich den Anwender zuerst in der AT suchen. Wenn er dort mit dem Sucheregebnis nicht zufrieden ist, dann mach ich die Abrfrage über den Gesamtbestand (also Archiv und AT). Und damit das leicht über die Bühne geht, bastel ich mir eine View zusammen die das Ganze über Union zusammenführt. Ich muss dann bei meiner 2. Abfrage nur noch den Tabellennamen durch den Viewnamen ersetzen. Oder du gehst gleich über eine SP.