nicht angemeldet
Auslastung Anfragen
Und zwar habe ich folgende Frage :
Wie reagiert ein DBMS auf diverse Abfragen.
a) ich mache gleichzeitig 1000 Selects in table a!
b) ich mache gleichzeitig 500 Selects in table a und 500 in table b!
Welche Möglichkeit belastet mein DBMS stärker ? Hängt es vom DBMS ab oder besteht einfach gar kein Unterschied da 1000 Anfragen, 1000 Anfragen sind unabhängig in welcher Tabel sie suchen.
mfg
Kris
-
a) ich mache gleichzeitig 1000 Selects in table a!
b) ich mache gleichzeitig 500 Selects in table a und 500 in table b!Welche Möglichkeit belastet mein DBMS stärker ?
Variante B natürlich.
Hängt es vom DBMS ab oder besteht einfach gar kein Unterschied da 1000 Anfragen, 1000 Anfragen sind unabhängig in welcher Tabel sie suchen.
Was willst Du "wirklich" wissen?
-
a) ich mache gleichzeitig 1000 Selects in table a!
b) ich mache gleichzeitig 500 Selects in table a und 500 in table b!Welche Möglichkeit belastet mein DBMS stärker ?
Variante B natürlich.
Nicht wirklich!
Sofern der query-cache greift...Reiner
-
a) ich mache gleichzeitig 1000 Selects in table a!
b) ich mache gleichzeitig 500 Selects in table a und 500 in table b!Welche Möglichkeit belastet mein DBMS stärker ?
Variante B natürlich.
Nicht wirklich!
Sofern der query-cache greift...Lies Dir mal irgendwo durch was passiert, wenn SELECTiert wird.
-
a) ich mache gleichzeitig 1000 Selects in table a!
b) ich mache gleichzeitig 500 Selects in table a und 500 in table b!Welche Möglichkeit belastet mein DBMS stärker ?
Variante B natürlich.
Nicht wirklich!
Sofern der query-cache greift...Lies Dir mal irgendwo durch was passiert, wenn SELECTiert wird.
wenn Du den Query-Cache aktiviert hast, den Befehl ein zweitesmal absetzt und zwischendurch kein delete/insert/update erfolgte, ist ziemlich egal, was der select gemacht hat.
Gruß
Reiner-
a) ich mache gleichzeitig 1000 Selects in table a!
b) ich mache gleichzeitig 500 Selects in table a und 500 in table b!Welche Möglichkeit belastet mein DBMS stärker ?
Variante B natürlich.
Nicht wirklich!
Sofern der query-cache greift...Lies Dir mal irgendwo durch was passiert, wenn SELECTiert wird.
wenn Du den Query-Cache aktiviert hast, den Befehl ein zweitesmal absetzt und zwischendurch kein delete/insert/update erfolgte, ist ziemlich egal, was der select gemacht hat.
Letztlich ist die Antwort auf die Frage "akademischer Art", es ist zwar offensichtlich, dass Variante B aufwendiger ist, aber das interessiert letztlich keine Sau. Mir ging es hauptsächlich darum Einfachheit als Erfolgsprinzip in der IT durchscheinen zu lassen.
(Es gab hier bspw. schon mal Fragen, ob man Daten identischer Struktur auf mehrere Tabellen verteilen sollte etc..)-
a) ich mache gleichzeitig 1000 Selects in table a!
b) ich mache gleichzeitig 500 Selects in table a und 500 in table b!Welche Möglichkeit belastet mein DBMS stärker ?
Variante B natürlich.
Nicht wirklich!
Sofern der query-cache greift...Lies Dir mal irgendwo durch was passiert, wenn SELECTiert wird.
wenn Du den Query-Cache aktiviert hast, den Befehl ein zweitesmal absetzt und zwischendurch kein delete/insert/update erfolgte, ist ziemlich egal, was der select gemacht hat.
Letztlich ist die Antwort auf die Frage "akademischer Art", es ist zwar offensichtlich, dass Variante B aufwendiger ist, aber das interessiert letztlich keine Sau. Mir ging es hauptsächlich darum Einfachheit als Erfolgsprinzip in der IT durchscheinen zu lassen.
(Es gab hier bspw. schon mal Fragen, ob man Daten identischer Struktur auf mehrere Tabellen verteilen sollte etc..)genau das ist meine Frage. Um meine Datenbank zu schonen lohnt es sich diverse tables zu splitten ?
-
(Es gab hier bspw. schon mal Fragen, ob man Daten identischer Struktur auf mehrere Tabellen verteilen sollte etc..)
genau das ist meine Frage. Um meine Datenbank zu schonen lohnt es sich diverse tables zu splitten ?
Es lohnt sich nicht.
Wenn Du allerdings verschiedene Wesen bearbeitest, wie bspw. Hunde und Menschen, die Hunde halten, dann empfiehlt es sich schon mit den zwei Tabellen "Hunde" und "Menschen" zu kommen. Wau.
-
(Es gab hier bspw. schon mal Fragen, ob man Daten identischer Struktur auf mehrere Tabellen verteilen sollte etc..)
genau das ist meine Frage. Um meine Datenbank zu schonen lohnt es sich diverse tables zu splitten ?
Es lohnt sich nicht.
doch, aber unter einer anderen Aufgabenstellung.
Nochmal: der Query-Cache würde greifen, wenn die 500/1000 Abfragen alle gleich aussehen.
Da das zwar sicher vorkommt, aber nicht unbedingt der Sinn der DB ist, stellt sich die Frage, was überhaupt erreicht werden soll.Das Splitten über mehrere Tabellen und Zusammensetzung per merge macht u.U. viel Sinn, weil dann "alte" Tabellen nicht mehr angefaßt werden und somit der Cache für diese nicht zerstört wird.
Gruß
Reiner-
Das Splitten über mehrere Tabellen und Zusammensetzung per merge macht u.U. viel Sinn, weil dann "alte" Tabellen nicht mehr angefaßt werden und somit der Cache für diese nicht zerstört wird.
Da würde ich aber dann doch eine vernünftige Archivierung der "Altdaten" anregen, statt einfach mehrere Tabellen anzulegen.
Vermutlich meinen wir dasselbe, hoffe ich zumindest. ;)
-
Das Splitten über mehrere Tabellen und Zusammensetzung per merge macht u.U. viel Sinn, weil dann "alte" Tabellen nicht mehr angefaßt werden und somit der Cache für diese nicht zerstört wird.
Da würde ich aber dann doch eine vernünftige Archivierung der "Altdaten" anregen, statt einfach mehrere Tabellen anzulegen.
Vermutlich meinen wir dasselbe, hoffe ich zumindest. ;)
Nein, ich rede nicht von Archivierung! Dafür wäre ein Backup zuständig.
Ich meine einen Fall, in dem Du Historien brauchst, genauer:
Aktienkurse, Dein Haushaltsbuch, Deine Emails(?) sind historische Daten, auf die man u.U. Zugriff haben möchte.
Da sich diese nicht ändern, können Sie in eine eigenständige Tabelle verschoben werden. Dazu wird eine neue aufgemacht:merge: tab
-|-->tab1tab1 abschließen und neue anlegen:
merge: tab
-|-->tab1
-|-->tab2Tab1 wird nicht mehr geändert. Abfragen laufen komplett über tab (der Mege-Tabelle). Wenn tab1 wirklich niemals mehr angefaßt (update, delete) werden muß, kann man aus ihr sogar eine read-only-Version machen, was die Abfragegeschwindigkeit nochmals erhöht.
Über merge wird wenig diskutiert, macht aber gerade bei großen Datenmengen bzgl. Geschwindigkeit - nach meiner Meinung - Sinn.Gruß
Reiner-
Moin!
Tab1 wird nicht mehr geändert. Abfragen laufen komplett über tab (der Mege-Tabelle). Wenn tab1 wirklich niemals mehr angefaßt (update, delete) werden muß, kann man aus ihr sogar eine read-only-Version machen, was die Abfragegeschwindigkeit nochmals erhöht.
Das sehe ich nicht so.
Die Abfragegeschwindigkeit einer read-only-Tabelle ist genauso schnell, wie bei einer normalen Tabelle, auf die keiner schreibend zugreift. Denn die Lesegeschwindigkeit wird nur dadurch gesenkt, dass Schreibzugriffe exklusive Locks benötigen.
Im Sinne einer effizienten Indizierung hingegen will man keine mehrfachen Tabellen mit identischem Datenaufbau, sondern nur eine einzige Tabelle. Der Suchaufwand steigt bei Indizes im allgemeinen logarithmisch zur Datensatzmenge. Und das ist nun mal unschlagbar. Bei einer Gesamtzahl von einer Million Datensätzen:
ld(1e+7) < 2*ld(1e+7/2)) < 4*(ld(1e+7/4)) < 10*(ld(1e+7/10))Der Suchaufwand, statt in einer Tabelle in zwei halb so großen zu suchen, verdoppelt sich in etwa. Die Indexsuchzeit sinkt in jeder kleineren Tabelle zwar, aber nur unwesentlich, er fällt aber für jede einzelne Tabelle an.
Es ist also immer effizienter, bei indizierter Suche und dem Fokus auf die Gesamtdatenmenge nur EINE Tabelle zu haben. Sofern man Datensätze aufteilen möchte nach "kleine Menge aktuelle, zu bearbeitende Datensätze" und "große Menge unveränderlicher historischer Datensätze", würde das aber dennoch bedeuten, dass die historische Tabelle nicht read-only sein kann, denn ihr werden ja fortlaufend (zumindest zu bestimmten Zeitpunkten) neue historische Datensätze hinzugefügt. Unter diesem Gesichtspunkt erscheint also das Konzept "historische Daten auslagern" schon gar nicht mehr so verlockend, die Daten sollten tatsächlich in einer einzelnen Tabelle verbleiben.
Sofern man dann Probleme mit konkurrierenden Lese- und Schreibzugriffen hat, gibt es auch andere Alternativen, um die Performance hinzukriegen.
Es hängt natürlich davon ab, was man mit den Daten wirklich machen will.
- Sven Rautenberg
--
"Love your nation - respect the others."-
Der Suchaufwand, statt in einer Tabelle in zwei halb so großen zu suchen, verdoppelt sich in etwa.
Mal erläutern, die binäre Suche sollte in etwa gleich schnell sein, wenn die Tabellen exakt halbiert worden sind (wie der TO andachte).
Sofern man dann Probleme mit konkurrierenden Lese- und Schreibzugriffen hat, gibt es auch andere Alternativen, um die Performance hinzukriegen.
"andere Alternativen" gibt es nicht. ;)
Es hängt natürlich davon ab, was man mit den Daten wirklich machen will.
Es geht Reiner möglicherweise darum unter bestimmten Umständen Tabellen zu splitten und Performancegewinne zu erzielen. Die genauen Umstände blieben mir bisher allerdings noch verborgen.
-
-
Da würde ich aber dann doch eine vernünftige Archivierung der "Altdaten" anregen, statt einfach mehrere Tabellen anzulegen.
Vermutlich meinen wir dasselbe, hoffe ich zumindest. ;)
Nein, ich rede nicht von Archivierung! Dafür wäre ein Backup zuständig.
Oder auch Archivierungstabellen (Stichwort:Historisierung).
Ich meine einen Fall, in dem Du Historien brauchst, genauer:
Aktienkurse, Dein Haushaltsbuch, Deine Emails(?) sind historische Daten, auf die man u.U. Zugriff haben möchte.
Da sich diese nicht ändern, können Sie in eine eigenständige Tabelle verschoben werden. Dazu wird eine neue aufgemacht:Das verstehe ich nicht, ein vernünftiges Datendesign setzt doch voraus, dass bestimmte Entitäten ihre eigenen Tabellen bekommen.
Über merge wird wenig diskutiert, macht aber gerade bei großen Datenmengen bzgl. Geschwindigkeit - nach meiner Meinung - Sinn.
Was meinst Du mit "merge", hast Du wirklich vor ein und dieselbe Entität über mehrere Tabellen nachzubilden um Performancevorteile zu erzielen? Bitte mal (schnellstens) erläutern, werde bereits unruhig. ;)
-
-
-
-
-
-
-
-
-
-