Hi
Ich hab nun eine Datenbank über Klimamessung mit MariaDB erstellt, mit
etwa 50 Millionen Zeilen und 10 Spalten (Eintragsnummer, Datum, Uhrzeit,
Temperatur Ort 1, Temperatur Ort 2 usw.). Das ganze dient nur zum Testen
momentan, hab noch kaum Erfahrung mit SQL
1. Ich kann nun mit z.B. PHPmyAdmin darauf zugreifen und Einträge
suchen. Jegliche Abfrage dauert über 2 Minuten. Ist dies normal bei so
vielen Einträgen? Kann man dies beschleunigen?
2. Die Abfrage über PHPmyAdmin ist relativ bequem, man kann unter
"Search" z.B. im Feld "Datum" einen Wert eingeben, und erhält die
Messwerte dieses Datums. Bei DBeaver vermisse ich eine ähnliche
Möglichkeit, hab ich was übersehen?
> Jegliche Abfrage dauert über 2 Minuten.
Da musst du dich in das Thema "create index" einarbeiten. Und wenn es
dann immer noch so lange dauert in das Thema "explain" bzw. "describe".
In einer SQL Datenbank legst du mehrere Indes Tabellen an, und die
Datenbank benutzt dann beim "select" den passendsten Index. Zumindest
meistens.
Man muß die Features halt sinnvoll einsetzen, bei der Struktur der
Datenbank genauso wie bei den Suchabfragen. Aber das ist nicht in ein
paar Minuten erklärt, da braucht man etwas Zeit für und es wäre auch
sinnvoll, wenn man die Struktur der Tabelle und ein paar Beispieldaten
kennt. Oder wonach später vorwiegend gesucht werden soll.
Ben B. schrieb:> wenn man die Struktur der Tabelle und ein paar Beispieldaten> kennt.
also
Eintragsnummer
Datum
Uhrzeit
Temperatur a
Temperatur b
Lichtstärke a
Lichtstärke b
Spannung a
Spannung b
Strom a
Strom b
Wie erwähnt, ich hab die DB nur erstellt um mich mit den Grundlagen von
SQL vertraut zu machen. Alle Spalten sind momentan als bigint definiert.
Gebe ich nun eine bestimmte Eintragsnummer ein, wird nach 140 sekunden
das eine Resultat angezeigt. Gebe ich ein Datum ein, werden alle Werte
des jeweiligen Datums, ebenfalls nach 140 Sekunden angezeigt.
Was ich momentan erreichen will, ist zum Beilspiel Einträge zu erhalten,
bei den die Spannung zwischen x und y beträgt.
Bei tatsächlich 50 Mio Datensätzen ist die Bedeutung von Indices nicht
zu unterschätzen, sonst wird bei jedem select ein sog. "full table scan"
fällig, d.h. die database engine muss sich tatsächlich jeden einzelnen
Datensatz "ansehen" um zu entscheiden, ob der nun zur Ergebnismenge
gehört oder nicht.
Es gibt DBMS, die "merken" automatisch, auf welche Spalten suchend
zugegriffen wird und legen Indices automatisch an (z.B. Filemaker Pro),
aber MySQL bzw. MariaDB gehören m.W. icht dazu.
Wenn man einen SQL-Kurs beginnt, hat man für gewöhnlich einige dutzend
Datensätze an denen man sich dann mit SQL abarbeiten kann. Da spielt ein
Index zunächst überhaupt keine Rolle, das Ergebnis wäre nicht mal
messbar.
Aber quasi als Einstieg mit 50 Mio ... das finde ich schon sportlich
oder konkreter ausgedrückt, nicht so vorteilhaft.
Frank E. schrieb:> Aber quasi als Einstieg mit 50 Mio ... das finde ich schon sportlich> oder konkreter ausgedrückt, nicht so vorteilhaft.
Andererseits vermeidet man so die Fehler von Softwarebuden, ein
"fertiges" Produkt abzuliefern, das nur mit kleinen Testdaten brauchbar
funktioniert.
Okay, fangen wir mal mit den Optimierungen an.
Zeit und Datum ist für einen Computer das Gleiche, da braucht man keine
zwei BigInt-Spalten. MySQL und seine Abkömmlinge bieten dafür den Typ
"datetime" an. Damit sparst Du eine Spalte ein und kannst die
Optimierungen nutzen, die der Datenbankserver für die Arbeit mit
Zeitangaben kann.
Wenn Du oft nach Eintragsnummern suchst, musst Du über die Spalte einen
Index anlegen, dann sollte das deutlich schneller gehen. Für sowas macht
ein Index am meisten Sinn, das ist sozusagen der Idealfall.
Der Rest wird schon schwerer zu optimieren, weil das meiner Ansicht nach
nur noch eine Suche in den Daten ist und ein Index über die komplette
Tabelle nicht viel Sinn macht. Das wird sowieso immer eine Suche in der
kompletten Tabelle solange keine Kriterien verwendet werden, die den
Suchbereich durch indexierbare Spalten eingrenzen. Beispielsweise wenn
man alle Spannungen zwischen x und y, aber nur für einen bestimmten Tag
haben möchte.
Wenn Du immer eine Suche über den kompletten Datensatz möchtest, bei
einer so großen Tabelle, wird das immer ordentlich Rechenleistung
verlangen. Ob das sinnvoll ist oder ob man z.B. mit einer Begrenzung auf
einen bestimmten Zeitraum Rechenleistung einsparen kann, musst Du selbst
wissen. Das hängt davon ab was Du brauchst oder was Du möchtest.
Und verpasse der Datenbank ein AUTO-ID-Feld.
Automatisch vergeben von der DB.
Ich kenne zwar MariaDB nicht, aber ich habe die Feststellung gemacht das
DB mit Auto-ID-Feld immer schneller sind. Besonders wenn sie Indexiert
sind.
Danach noch 1-2 Indexe. FERTIG.
50.000.000 Datensätze?
Klingt viel, sehr viel.
MariaDB, HeidiSQL usw würd' ich bleiben lassen. Denn: auch ich kenne
mich kaum aus und wenn man sich nicht auskennt, wäre es schon cool, ein
Werkzeug zu nutzen, was man mit sql-Statements verwenden kann und nicht
noch n speziellen Dialekt lernen muss oder sich mit fehermeldungen
rumärgern muss, die unsinnig sind und wo man im Netz keine Erklärungen
findet.
Ich kann dein "Gram" also gut nachvollziehen.
> Und verpasse der Datenbank ein AUTO-ID-Feld.
Auto-ID? Was meinst Du damit?
> Ich kenne zwar MariaDB nicht,
Ist eine direkte Abspaltung von MySQL.
> aber ich habe die Feststellung gemacht das DB mit Auto-ID-Feld> immer schneller sind. Besonders wenn sie Indexiert sind.
Liegt wahrscheinlich daran, daß Du auto_increment meinst, dafür ein
Index erforderlich ist und Du sonst noch nie Indexes benutzt hast...
> Aber quasi als Einstieg mit 50 Mio ... das finde ich schon> sportlich oder konkreter ausgedrückt, nicht so vorteilhaft.
Ich finde es gar nicht sooo schlecht. Dadurch lernt man gleich die
Limits kennen und das Projekt hat eigentlich eine geringe Komplexität.
Jedenfalls noch.
Ich z.B. habe mit PHP/MySQL angefangen, indem ich ein MMOG geschrieben
habe. Das war als Einsteigerprojekt sicherlich auch nicht optimal
geeignet, aber hat ganz gut geklappt und vielen Leuten Spaß gebracht.
Vorher hatte ich alle Daten selbst in eigenen Dateien abgelegt, das MMOG
war das erste Projekt, welches eine "echte" Datenbank verwendete.
Eine Datenbank ist auch genau der falsche Ansatz. Denn die Daten sind
gut strukturiert, heisst es sind Zahlen, die koennen viel besser in
einem 1 dimensionalen Array of Record gespeichert werden.
Dann kannst du auch den ganzen Haufen im RAM lagern, und die Zugriffe
gehen mit fast lichtgeschwindigkeit.
Datenbanken sind gut fuer gemischte Geschichten mit verschieden langen
Strings,
Äxl schrieb:> 50.000.000 Datensätze?> Klingt viel, sehr viel.
MySQL/MariaDB ist auch für weitaus grössere Fälle brauchbar. Nur ist
Design von Datenbanken dann keine triviale Angelegenheit mehr. Egal ob
MySQL oder Oracle.
Pandur S. schrieb:> Eine Datenbank ist auch genau der falsche Ansatz. Denn die Daten> sind> gut strukturiert, heisst es sind Zahlen, die koennen viel besser in> einem 1 dimensionalen Array of Record gespeichert werden.> Dann kannst du auch den ganzen Haufen im RAM lagern, und die Zugriffe> gehen mit fast lichtgeschwindigkeit.>> Datenbanken sind gut fuer gemischte Geschichten mit verschieden langen> Strings,
Du solltest nachrechnen, bevor du soche Statements abgibst.
Oben sind 11 Spalten angegeben, ich setze mal kurzerhand 10 Byte pro
Spalte an. Das sind bei 50 Mio Datensätzen über 5GB. Sportlich.
Und wie will man da vernünftig nach etwas suchen? Wie sortieren? Dafür
sind DB-Engines optimiert ...
> MariaDB, HeidiSQL usw würd' ich bleiben lassen.
MariaDB würde ich noch gelten lassen. Das stammt von MySQL ab, wird von
früheren MySQL-Entwicklern betreut, hat inzwischen eine recht große
Nutzergemeinde und bei MySQL ist man sich manchmal nicht so sicher, was
Oracle damit vor hat, z.B. ob das zukünftig kostenlos nutzbar bleibt
oder nicht. Die haben jedenfalls schon klar gesagt, daß sie kein
Interesse an einer Open-Source Datenbank haben und die Differenzen
zwischen der kostenlosen und kostenpflichtigen Version werden immer
größer. Wahrscheinlich buddeln sie gerade das Grab für kostenloses
MySQL, es ist nur eine Frage der Zeit bis es tief genug ist.
Zum Thema alles im RAM speichern... mal rechnen. 50 Mio. Einträge, 11
Felder BIGINT, also 8 Bytes... ungefähr 4,3GB Daten. Könnte man im RAM
halten, eigener Server vorausgesetzt, ist aber sehr sperrig und
erfordert weitere Maßnahmen beim Start des Servers oder bei Änderungen
an den Datensätzen.
Aber mit Lichtgeschwindigkeit geht eine Suche über 50 Mio. Datensätze
auch im RAM nicht, das dauert einfach seine Zeit.
Pandur S. schrieb:> Eine Datenbank ist auch genau der falsche Ansatz.
Kommt auch auf das Ziel an. Geht es in erster Linie darum, die genannten
Messdaten zu verwalten? Oder geht es darum, anhand einer konkreten
Aufgabe den Umgang mit SQL Datenbanken zu lernen?
Eine Datenbank, die aus einer einzigen grossen Tabelle besteht, ist
allerdings nicht unbedingt die Kerndomäne von SQL-DBs. Die adressieren
eigentlich komplexere Datenstrukturen.
Also Leute... so wild ist das nun auch nicht. Keine Views, keine Joins,
nur eine große Tabelle. Große Datenbanken rechnet man in Terra, nicht in
Mega.
Erst mal mit Indices und Datentypen experimentieren. Ist doch ein gutes
Beispiel, um sich in das Thema einzuarbeiten.
Wenn es dann immer noch nicht schnell genug ist, die verschiedenen
Sorrage Engines ausprobieren.
Ben B. schrieb:> Liegt wahrscheinlich daran, daß Du auto_increment meinst, dafür ein> Index erforderlich ist und Du sonst noch nie Indexes benutzt hast...
DOCH. Sonst würden meine Datenbanken (4.5 Mio die eine, 8 Mio die
andere) bei der Abfrage auf meinen PC ewig brauchen.
UND JA, ich meine auto_increment. Und auch JA da ist ein Index drauf.
Allerdings gebe ich zu, das ich diese Erkenntnis gewonnen habe als ich
mit Access-Datenbanken gearbeitet habe. Die haben bei meiner Version ein
2 GB Limit und das lief dann schnell gegen die Wand.
Aktuell benutze ich SQLite . Ich finde das ist ok für mich. Und lt.
einiger Seiten nur von Limit der Festplatte begrenzt.
Die 8.5 Mio. Einträge sind allerdings Ansichtsache.
Grund. Die hocken zwar alle in der Datenbank-Datei. ABER sie sind in 15
Tabellen (je Jahr eine) unterteilt, weil ich die Abfrage selten auf
ältere Jahre brauche.
Bei der 4.5 Mio-DB (eine Tabelle indiziert) dauert auf meinen PC (DB auf
SSD) eine LIKE-Abfrage (in VB Programmiert) ca. 30-40 Sekunden. Kann ich
mit leben.
Also 'ne LIKE-Abfrage, am besten noch mit "%blah%" oder so, sollte man
dringendst vermeiden wenn man Performance will. So eine Volltextsuche
ist jedes Mal ein full table scan wenn man nicht noch andere Kriterien
angibt, womit die DB engine das Suchfenster evtl. etwas eingrenzen kann.
Ansonsten muß man eben überlegen wie man die Dinge anders speichern
könnte. Oder ob man sich mehrere Tabellen macht, vielleicht sowas wie
eine Langzeit-Tabelle nur zum Archivieren und eine Kurzzeit-Tabelle zur
normalen Arbeit.
Oder ob man sich einen Gesamtstatus extra speichert und updatet. Das
wäre hinreichend genau, man müsste ihn nur von Zeit zu Zeit mit der DB
abgleichen und ggf. Abweichungen korrigieren. Als Beispiel wäre wenn ich
aus der großen Tabelle berechnen will, wieviel kWh über die 50 Mio.
Einträge zusammengekommen sind. Der Datenbankserver kann das machen, mit
einer einzigen Abfrage. Aber er wird hochjubelnd in die Hände klatschen
und anschließend in Kleinarbeit die gesamten 4,3GB durchrödeln um das
Ergebnis zusammenzuaddieren. Da ists besser, die kompletten kWh in einer
zweiten Tabelle zu speichern und dort gleich immer aufzuaddieren wenn
ein neuer Datensatz kommt.
Prinzipiell muß man überlegen welches Ergebnis man im Endeffekt haben
will. Also bei solchen Daten z.B. was für Graphen will ich daraus
generieren, wie hoch sollen die aufgelöst sein. Ich muß nur alle Daten
speichern, die ich dafür brauche. Alles was ich darüber hinaus
speichere, müllt mir ohne jeden Nutzen die Datenbank zu.
Äxl schrieb:> 50.000.000 Datensätze?> Klingt viel, sehr viel.
Viel? Im Jahr 2022?
Ben B. schrieb:> ungefähr 4,3GB Daten. Könnte man im RAM> halten, eigener Server vorausgesetzt, ist aber sehr sperrig
Sperrig? Gute 4GB Daten sind sperrig? Im Jahr 2022?
Mein 2 Jahre altes Handy hat 6GB RAM. Heutige Mittelklasse-Handy haben
etwa 8GB RAM. Aktuelle fette Handys haben 16GB RAM. Selbst irgendwelche
Aldi-Notebooks haben 8GB oder 16GB RAM.
Mal den Realitätsdetektor neu justieren...
> Aber mit Lichtgeschwindigkeit geht eine Suche über 50 Mio. Datensätze> auch im RAM nicht, das dauert einfach seine Zeit.
Naja... Auch hier scheint es keine Vorstellung zu den Realitäten zu
geben:
RAM-Bandbreite aktueller Systeme ist etwa 20 GB/s oder mehr. Geht man
von einem Feld-Wald-Wiesen-PC aus, kann man mit etwa 15 GB/s rechnen.
D.h. eine lineare Suche würde im RAM mit dieser nicht optimieren
Struktur keine 0,3 Sekunden dauern.
Mit einfachsten Änderungen wäre man bei ca. 0,1 Sekunden...
Ramona schrieb:> Alle Spalten sind momentan als bigint definiert.
Dürfte völlig unnötig sein.
> Eintragsnummer> Datum> Uhrzeit
Wie schon weiter oben beantwortet, kann man "Datum" und "Uhrzeit"
zusammenfassen. Kann man aber auch so lassen. Die "Eintragsnummer" kann
man ziemlich sicher wegwerfen. "Datum" und "Uhrzeit" sind bei Deinen
Daten ein natürlicher Primary-Key. Es gibt keinen Grund für einen
künstlichen Primary-Key.
D.h. PRIMARY KEY (Datum, Uhrzeit) setzen, oder eben PRIMARY KEY
(Zeitstempel), wenn Datum und Uhrzeit zusammengefasst werden.
Dazu dann für die Spalten noch passende Datentypen, und auch wichtig,
überall "NOT NULL" hinzufügen.
Dann muss man vermutlich die Einstellungen von MariaDB so anpassen, dass
die Software auch den vorhanden RAM nutzt. Die meisten Voreinstellungen
bei Datenbanken sind viel zu schüchtern und RAM wird nicht ausgenutzt.
Man kann sich mit MariaDB durchaus auch tiefgründiger beschäftigen.
Interessanter Aspekt ist z.B. die Auswahl einer
Nicht-Standard-Storage-Engine beim Anlegen einer Tabelle.
Die Storage-Engine ist jenes Modul eines DBMS, welches das physikalische
Handling der Daten realisiert. Normalerweise wird hier "InnoDB"
standardmäßig als guter Kompromiss gewählt. Aber es gibt noch ne ganze
Menge "Spezialvarianten" u.a. auch eine, die die Daten bevorzugt im RAM
hält.
https://mariadb.com/kb/en/storage-engines/https://mariadb.com/kb/en/memory-storage-engine/
Ramona schrieb:> Das ganze dient nur zum Testen> momentan, hab noch kaum Erfahrung mit SQL
In meinen Augen ein komplett falscher Ansatz. SQL ist eine durchaus
interessante Materie, weil sie mit vielen Datenbänken funktioniert. Zum
Lernen sind 50.000.000 Einträge aber vollkommener Unfug. Du testest eine
SQL-Abfrage und wartest dann jeweils 140 sec., ob die Abfrage
funktioniert hat??
Ramona schrieb:> Was ich momentan erreichen will, ist zum Beilspiel Einträge zu erhalten,> bei den die Spannung zwischen x und y beträgt.
Wie überprüfst Du das, ob alle relevanten Daten rausgefiltert wurden??
Gleichst Du auf dem Bildschirm mit Deinen Augen Millionen Daten in der
Tabelle ab, um zu sehen, ob Deine SQL-Abfrage alle gesuchten Einträge
gefunden hat??
Nein, nehme zum Testen eine Tabelle mit 20...30 Datensätzen, *nicht
mehr*, und übe daran. Die Stärke spielen Datenbanken und SQL außerdem
aus, wenn Du die Tabellen relational verknüpfst. Beispiel Kundendatei.
In einer Tabelle "Verkäufe" tauchen Kunden mehrfach auf. Dann ist es
zweckmäßig, in dieser Tabelle nur den Kundennamen und ggfls. eine
eindeutige Kunden-ID einzutragen und die übrigen Kundendaten wie
Anschrift, Bankverbindung etc. in einer eigenen Tabelle. Mit SQL
filterst Du aus beiden (oder mehr) Tabellen die gewünschten Daten
heraus.
Das kann hier aber das Forum nicht leisten, Dir die Grundlagen zu
vermitteln. Google ist Dein Freund. Oder kaufe Dir ein Buch über SQL.
Ja, SQL lernst Du nicht in einer Woche.
Rainer Z. schrieb:> Das kann hier aber das Forum nicht leisten, Dir die Grundlagen zu> vermitteln. Google ist Dein Freund. Oder kaufe Dir ein Buch über SQL.> Ja, SQL lernst Du nicht in einer Woche.
Hier noch ein unterhaltsames schräges Übungsbeispiel abseits des
Verkauf/Kunden Thema
https://mystery.knightlab.com/
SQL-Gerümpel ist für sowas auch nicht die erste Wahl, das spielt in
einem solchen Einsatzzweck nicht seine Stärken aus. Das geht zwar auch,
wenn man weiss was man tut, aber das ist ja hier das Hauptproblem.
Für Messdaten gibts spezielle DBs, da muss man dann auch kein Experte
sein umd die Daten dort schnell wieder herauszuziehen.
Vielleicht reicht ja schon rrdtool.
Ramona schrieb:> Ich hab nun eine Datenbank über Klimamessung mit MariaDB erstellt, mit> etwa 50 Millionen Zeilen und 10 Spalten (Eintragsnummer, Datum, Uhrzeit,> Temperatur Ort 1, Temperatur Ort 2 usw.). Das ganze dient nur zum Testen> momentan, hab noch kaum Erfahrung mit SQL
Schwierig, schwierig, schwierig... Sagen wir mal so: in diesem Forum
geht es dem Namen zufolge primär um Mikrocontroller. Das sind in der
Regel eher winzige Geräte, von denen die meisten keine Möglichkeiten
bieten, größere Datenmengen zu speichern. Da Mikrocontroller aber häufig
zur Sammlung von Daten benutzt werden, sind hier einige Nutzer bereits
über Datenhaltungsthemen gestolpert und haben sie mal mehr und leider
auch mal weniger gut durchdrungen. Das zeigt dann leider auch dieser
Thread, in dem alles von hahnebüchenem Unfug bis hin zu sehr klugen
Aussagen zu finden ist. ;-)
Nun, in Deinem Fall fallen die Daten in periodischen Abständen an, und
werden nach ihrer Erstellung bzw. Erfassung nurmehr gelesen oder
gelöscht. Solche Daten können natürlich in einem Relationalen
Datenbank-Managementsystem wie MySQL, MariaDB oder PostgreSQL
gespeichert werden, aber die Garantien, die ein RDBMS liefert, brauchen
diese Daten im Grunde gar nicht. Genau diese Garantien sind es aber, die
ein RDBMS ziemlich "teuer" im Sinne von langsam und ressourcenintensiv
machen. Ein RDBMS ist daher zwar quasi eine Art "eierlegende
Wollmilchsau der Datenhaltung", aber nicht immer die beste Wahl.
Für Daten wie Deine gibt es spezialisierte Systeme, die Fachworte
"append-only log" und "Zeitseriendatenbank" sind bereits gefallen. Für
solche Daten benutze ich heute trotzdem gerne ein bestimmtes RDBMS,
nämlich PostgreSQL, allerdings mit einer ganz bestimmten Erweiterung
namens "TimescaleDB". Diese Erweitung ist genau für solche Daten gemacht
und nach meinen Erfahrungen sogar deutlich performanter als auf diese
Art von Daten spezialisierte Zeitserien-Datenbanken wie InfluxDB,
Prometheus oder Graphite. Zusätzlich bietet TimescaleDB noch weitere
nützliche Features, aber der meiner Ansicht nach größte Vorteil ist, daß
die Funktionalität von PostgreSQL und somit auch die (mehr oder weniger
bekannte) Sprache SQL weiterverwendet wird. Ob es ähnliche Erweiterungen
auch für MySQL oder MariaDB gibt, weiß ich leider nicht, ich mache seit
langer Zeit einen Bogen um diese RDBMS.
Ben B. schrieb:> Wenn Du oft nach Eintragsnummern suchst, musst Du über die Spalte einen> Index anlegen, dann sollte das deutlich schneller gehen. Für sowas macht> ein Index am meisten Sinn, das ist sozusagen der Idealfall.
Na das wäre ja einfach... also... wäre es, wenn es zuträfe. Tatsächlich
ist es aber leider so, daß Indizes die Schreibperformance verringern --
weil ja zusätzlich zu den Tabellen auch die Indizes aktualisiert werden
müssen -- und daß sie zudem den Speicherverbrauch erhöhen, denn ein
ordentliches RDBMS versucht natürlich, die meistgenutzten Indizes im
Arbeitsspeicher zu halten.
Auch ansonsten... naja, sagen wir mal so: die meisten RDBMS, die ich
kenne, werden mit eher konservativen Konfigurationen ausgeliefert. Wenn
ich mich Recht entsinne, ist etwa die Standardkonfiguration von
PostgreSQL auf 512 MB RAM ausgelegt. Und da kann man mit wenigen
Handgriffen ([1]) schon eine ganze Menge machen...
[1] https://pgtune.leopard.in.ua/> Der Rest wird schon schwerer zu optimieren, weil das meiner Ansicht nach> nur noch eine Suche in den Daten ist und ein Index über die komplette> Tabelle nicht viel Sinn macht. Das wird sowieso immer eine Suche in der> kompletten Tabelle solange keine Kriterien verwendet werden, die den> Suchbereich durch indexierbare Spalten eingrenzen. Beispielsweise wenn> man alle Spannungen zwischen x und y, aber nur für einen bestimmten Tag> haben möchte.
Ach, mit einem RDBMS wie PostgreSQL geht da noch was, Stichworte
"Partitionierung" und in diesem Zusammenhang auch "Vererbung"... ;-)
Schlaumaier schrieb:> Und verpasse der Datenbank ein AUTO-ID-Feld.>> Automatisch vergeben von der DB.>> Ich kenne zwar MariaDB nicht, aber ich habe die Feststellung gemacht das> DB mit Auto-ID-Feld immer schneller sind. Besonders wenn sie Indexiert> sind.>> Danach noch 1-2 Indexe. FERTIG.
Meine Güte... Du bastelst mit SQLite und hast laut eigener Aussage exakt
zwei eher winzige Datenbanken, jetzt überträgst Du Deine "Erfahrungen"
mit dieser Flatfile-DB auf richtige RDBMS und gibst auf dieser
"Wissensbasis" auch noch Empfehlungen ab?!
> Zum Lernen sind 50.000.000 Einträge aber vollkommener Unfug.
Hmmm. 50.000.000 Einträge finde ich ideal.
Einerseits muss man sich Gedanken um die Grenzen und Probleme der real
existierenden Datenbanken machen. Die elegante Theorie reicht nicht aus.
Andererseits muss man nur 2 Minuten warten, wenn die Versuche zur
Optimierung fehl schlagen.
Nächster Schritt wäre dann ein Join über 3 solcher Tabellen...
Aber spaetestens wenn Du mit einem Qualitaetsprodukt des Marktfuehrers
(vulgo Microsoft) mit Access, Excel oder einer eigenen Applikation auf
die Datenbank zugreifen willst, hast Du eine deutlich bessere
Performance wenn Du einen Primary Key hast (identifikation des Satzes
fuer den Edit).
Keiner hat gefragt, was abgefragt werden soll: Z.b. Daten eines Tages
(der Index (datum, Zeit) ist schon hilfreich). Das hilft natuerlich
nicht, wenn die Temperatur-Maxima/Minima eines Tages erstellt werden
sollen.
Wenn es sich um MySQL/MariaDB handelt, und keine ACID-Transaktionen
noetig sind, ist das MyISAM unschlagbar schnell (InnoDB hat
ACID-Transaktionen, d.h. man oder frau braucht einen sehr schnell
Massenspeicher fuer InnoDB).
Gruesse
Th.
(prx) A. K. schrieb:> Frank E. schrieb:>> Aber quasi als Einstieg mit 50 Mio ... das finde ich schon sportlich>> oder konkreter ausgedrückt, nicht so vorteilhaft.>> Andererseits vermeidet man so die Fehler von Softwarebuden, ein> "fertiges" Produkt abzuliefern, das nur mit kleinen Testdaten brauchbar> funktioniert.
Da ist definitiv was dran. Wobei "kleine Softwarebuden" gelegentlich
auch mal recht groß sein können...
> Andererseits vermeidet man so die Fehler von Softwarebuden, ein> "fertiges" Produkt abzuliefern, das nur mit kleinen Testdaten brauchbar> funktioniert.> Da ist definitiv was dran. Wobei "kleine Softwarebuden" gelegentlich> auch mal recht groß sein können...
Da fällt mir bei ein - vor ewigen Zeiten hatte ich einen
Abstraktionslayer für die damals verbreiteten Datenbanken geschrieben.
Damals legte der Oracle Installer die Datenbank so an, dass man sie nur
für kleine Testdaten benutzen konnte. Damit man überhaupt ein
Produktivsystem installieren konnte, musste man erst mal die Oracle
Schulungen besuchen.
Ausgerechnet Oracle hat sich durchgesetzt, die anderen sind inzwischen
verschwunden.
Finde ich gut dass du dir mal ein ordentliches Projekt gesucht hast. Ich
hasse langsame Datenabfragen wie die Pest.
Da waren jetzt viele lustige Vorschläge dabei, aber lass uns doch
einfach ein Beispiel durchmachen:
Erstelle eine Tabelle die ausgibt wie lange die Temperatur im Bereich
-20 bis -19°C ; -19 bis -18 usw war. Und das für beliebige Zeiträume.
Wie würdest du die Daten organisieren und wie würdest du die Anfrage
aufbauen?
Sg
Im Zweifel als Faustregel: über alle Spalten und Kombinationen aus
Spalten, über die du suchen willst, gehört jeweils ein Index, um den
ständigen Full-Table-Scan zu vermeiden. Dazu auch die (impliziten)
Spaltenkombinationen aus eventuellen Joins mit betrachten. Genaueres
verrät dir dann ggfs EXPLAIN für deine konkreten Abfragen.
can't edit :(
s/join/autojoin/
Indezes über mehrere Tabellen sind AFAIK nicht vom Standard abgedeckt,
auch wenn die ein oder andere DB das über Indexed Views wohl kann.
Als SQL Anfänger? Lass es, das geht schief.
> Mal den Realitätsdetektor neu justieren...
Mein Realitätsdetektor sagt, da hat Einer vom Betrieb realer
Datenbankserver so überhaupt keine Ahnung. Wenn da jeder ankommt und
seine Gigabyte-große Datenbank im RAM vorhalten möchte, gibts bald einen
RAM-Chipmangel.
> [..] daß Indizes die Schreibperformance verringern
Tun sie, allerdings sieht die Schreibperformance aufgrund ziemlich
seltener Updates für mich nicht problematisch aus. Das sind dann auch
nur einfache Inserts an das Ende der Tabelle, das sollte schnell gehen
auch wenn ein großer Index aktualisiert werden muß.
Ben B. schrieb:> Wenn da jeder ankommt und> seine Gigabyte-große Datenbank im RAM vorhalten möchte
SAP ist vielleicht nicht jeder, aber die sind diesen Weg gegangen. Weg
von Oracle, hin zur in-memory DB HANA. Und da gehts schon um leidlich
grosse Datenbestände. Aber auch um leidlich grosse Geldbeträge.
gibt es für MariaSQL/mySQL auch einen Profiler? Das wäre ein Werkzeug um
Indizies zu optimieren. Kenne sowas von MSSql, war sehr hilfreich für
den Einstieg bzw. Optimierung.
Ben B. schrieb:> Mein Realitätsdetektor sagt, da hat Einer vom Betrieb realer> Datenbankserver so überhaupt keine Ahnung. Wenn da jeder ankommt und> seine Gigabyte-große Datenbank im RAM vorhalten möchte, gibts bald einen> RAM-Chipmangel.
Schwätzer.
Das Gigabyte ECC RAM kostet aktuell gerade mal grob 6,- €.
Uwe schrieb:> Rainer Z. schrieb:>> Das kann hier aber das Forum nicht leisten, Dir die Grundlagen zu>> vermitteln. Google ist Dein Freund. Oder kaufe Dir ein Buch über SQL.>> Ja, SQL lernst Du nicht in einer Woche.>> Hier noch ein unterhaltsames schräges Übungsbeispiel abseits des> Verkauf/Kunden Thema>> https://mystery.knightlab.com/
Hübscher Link!
Messdaten brauchen ja nicht dauernd bearbeitet zu werden, und dann
moechte man auch etwas sehen. Wenn man sich zB alle Tage mit unter X
Grad zeigen lassen will, muessen eh alle records gelesen werden. Da ist
die ganze Reihe am Besten im RAM, als Records, Ist ja nicht viel, dafuer
geht's schnell. Was soll denn sortiert werden ?
Pandur S. schrieb:> Wenn man sich zB alle Tage mit unter X> Grad zeigen lassen will, muessen eh alle records gelesen werden.
Nein, auch das ist per Index möglich. Ob es sinnvoll ist, ist eine Frage
der Datenverteilung, sowie der Grösse des Resultats, der Gesamtdaten und
weiteren Faktoren wie Sortierung. Manche Query Optimizer können anhand
von Statistiken automatisch den sinnvollsten Weg wählen.
Ramona schrieb:> 1. Ich kann nun mit z.B. PHPmyAdmin darauf zugreifen und Einträge> suchen. Jegliche Abfrage dauert über 2 Minuten. Ist dies normal bei so> vielen Einträgen? Kann man dies beschleunigen?
ich hab nun einen Index über eine Spalte gelegt. Die Suche eines
bestimmten Begriffes dauert nun nur einige Millisekunden. Wähle ich als
Suchoption jedoch "LIKE %...%" dauert die Suche immer noch etwa eine
Minute. Kann ich dies noch optimieren?
Eine LIKE Abfrage mit Wildcard vorne erlaubt prinzipbedingt keine
Vorselektion über einen sortiertem Index. Wenn man es derart drauf
anlegt wie du, kann man immer einen vollständigen Scan erzwingen. Zu
einer grossen Datenbank gehört immer auch das Verständnis, was man damit
nicht tun sollte.
(prx) A. K. schrieb:> Eine LIKE Abfrage mit Wildcard vorne erlaubt prinzipbedingt keine> Vorselektion über einen sortiertem Index. Wenn man es derart drauf> anlegt wie du, kann man immer einen vollständigen Scan erzwingen. Zu> einer grossen Datenbank gehört immer auch das Verständnis, was man damit> nicht tun sollte.
Manche RDBMS wie PostgreSQL enthalten eine, einige nicht-relationale
DBMS wie Elasticsearch / OpenSearch sind im Kern sogar
Volltext-Suchmaschinen. Damit würde das schon gehen... allerdings stellt
sich mir die Frage, warum in einem Append-Only-Log zur Erfassung von
Meßdaten überhaupt solche Queries notwendig sein sollten.
Wir arbeiten auch mit Datenbanken.
HeidiSQL ist richtig gut, du kannst direkt sehen welche Anfragen du
brauchst, zum einstieg reicht das, auf Youtube gibts einige Tutorials.
Primary Key sollte IMMER eindeutig sein daher ist Zeit nicht brauchbar
selbe wie Datum, am besten ein Integer.
Zur Performance, PHP ist nicht wirklich "schnell" daher dauert das
etwas, C++ oder Rust würden dir dabei helfen, braucht aber etwas bis man
die Sprache kann. C# ist ein guter Anfang um anschließend zu C++ oder
Rust zu gehen.
Um auf deine letzte Frage einzugehen wonach möchtest du genau suchen?
Natürlich macht das einen unterschied ob du die Abfrage in PHP oder C++
API machst, sofern dir die Performance wichtig ist. PHP verbraucht halt
mal bis zu 29x so viel Energie und 27x soviel Zeit.
Mach Dich mal lieber schlau wie SQL-Server funktionieren bevor Du
solchen Quark schreibst. Das riecht doch schon wieder ganz schwer nach
Troll-Alarm hier. Und das schon am Dienstag.
Nur_ein_Typ schrieb:> Meine Güte... Du bastelst mit SQLite und hast laut eigener Aussage exakt> zwei eher winzige Datenbanken, jetzt überträgst Du Deine "Erfahrungen"> mit dieser Flatfile-DB auf richtige RDBMS und gibst auf dieser> "Wissensbasis" auch noch Empfehlungen ab?!
naja, ich finde 4.6 bzw. ca. 9 Mio. Datensätze pro Datenbank nicht
gerade winzig. Aber es gibt sicher größere Datenbanken auf den Plani.
Davon abgesehen erfolgt die Abfrage (und das füttern) über ein
Zusatzverweis den ich in VB integriert habe.
Und ja der Tipp wirkt bei mir.
seere schrieb:> über alle Spalten und Kombinationen aus> Spalten, über die du suchen willst, gehört jeweils ein Index, um den> ständigen Full-Table-Scan zu vermeiden.
Dazu möchte ich etwas ergänzen. Mindestens bei MySQL und MariaDB gibt es
die Besonderheit, dass die DB kombinierte Indexe auch für weniger
Spalten linksbündig benutzen kann.
Beispiel:
Du hast auf einer Adress-Tabelle einen kombinierten Index auf
Postleitzahl+Straße+Name.
1
ALTERTABLEadresseADDINDEXixd1(plz,strasse,name);
Dann kannst du auch performant nur nach Postleitzahl oder
Postleitzahl+Strasse suchen ohne dafür weitere Indexe anlegen zu müssen.
Aber eine Suche nur nach Straße oder Straße+Name oder nur nach Name geht
damit nicht. 3 Indexe auf die einzelnen Spalten wären flexibler nutzbar,
aber langsamer.
Martin U. schrieb:> Primary Key sollte IMMER eindeutig sein daher ist Zeit nicht brauchbar> selbe wie Datum, am besten ein Integer.
Genau deshalb ein ID Feld. Das setze ich Integer und Automatisch Hoch
zählend.
Bei einer Sammlung von Messdaten würde ich ein Index auf den Zeit-Wert
(Datum-Uhrzeit) setzen.
Dann kann man auch eine Like-Abfrage damit Kombinieren da der Index eine
schnelle Vorsortierung macht.
Durch das ID-Feld (Logo indiziert) habe ich ein sichere Kennung des
Datensatzes und kann Änderungen schnell zurückschreiben.
Ach und nur so nebenbei.
Ich habe vor ein paar Tagen ein Prg. geschrieben was Access-Datenbanken
in SQL umwandeln soll. Dabei ist mir ein pöser Fehler/Bug/Wunsch von MS
aufgefallen. Wenn die Access-DB kein Primärschlüssel hat, funktionieren
einige Funktionen des OLEDB Datenelement nicht, bzw. man erhält eine
Fehlermeldung. Hat mich einige Stunden Google gekostet, weil ich in der
Test-Db ausnahmsweise den Primärschlüssel vergessen habe.
Schlaumaier schrieb:> Ach und nur so nebenbei.> Ich habe vor ein paar Tagen ein Prg. geschrieben was Access-Datenbanken> in SQL umwandeln soll. Dabei ist mir ein pöser Fehler/Bug/Wunsch von MS> aufgefallen. Wenn die Access-DB kein Primärschlüssel hat, funktionieren> einige Funktionen des OLEDB Datenelement nicht, bzw. man erhält eine> Fehlermeldung. Hat mich einige Stunden Google gekostet, weil ich in der> Test-Db ausnahmsweise den Primärschlüssel vergessen habe.
Mal davon abgesehen, dass ein fehlender (eindeutiger!) Primary Key ein
ganz grober Administrationsfehler ist, lässt Access es überhaupt nicht
zu, dass Datensätze in einer derartigen Tabelle bearbeitet werden. Des
weiteren werden ggf. Doubletten zu sehen sein, wo gar keine sind. Auch
wird auch das Betrachten der Datensätze ggf. merklich langsamer. Alles
in allem kann ein fehlender Key nur ein Versehen sein. Wer sowas bewusst
auf die Menschheit loslässt, gehört in die schule zurückgeschickt. Ich
fass jedenfalls keine Tabelle an, wo kein PK vorhanden ist.
Schlaumaier schrieb:> Nur_ein_Typ schrieb:>> Meine Güte... Du bastelst mit SQLite und hast laut eigener Aussage exakt>> zwei eher winzige Datenbanken, jetzt überträgst Du Deine "Erfahrungen">> mit dieser Flatfile-DB auf richtige RDBMS und gibst auf dieser>> "Wissensbasis" auch noch Empfehlungen ab?!>> naja, ich finde 4.6 bzw. ca. 9 Mio. Datensätze pro Datenbank nicht> gerade winzig. Aber es gibt sicher größere Datenbanken auf den Plani.
Natürlich ist das viel. Je nach Größe + Inhalt der Tabellen schon fast
ein Fall für SQL-Server. Wenn bei solchen Tabellen die Schlüssel nicht
durchdacht sind, läuft gar nichts mehr. Dann kann man nicht nur Kaffee
kochen gehen, sondern Mittagessen kochen.
Justus schrieb:> Alles> in allem kann ein fehlender Key nur ein Versehen sein.
Wie bereits geschrieben war es ein Versehen. Denn ich nutze den Key
IMMER um Datensätze zu identifizieren, bzw. Änderungen am Satz zurück zu
schreiben.
Mich haben nur die Gravierenden Probleme von "ohne Primärkey" gewundert.
OK war Schlamperei da es nur ein Übungsdatei war die ich extra zum
versauen schnell man angelegt habe. Mich haben die Daten nicht
Interessiert sondern nur die saubere Erkennung Tabellen und der
Feldtypen in den Tabellen.
Justus schrieb:> Natürlich ist das viel. Je nach Größe + Inhalt der Tabellen schon fast> ein Fall für SQL-Server.
Ok. ;) Danke das du meiner Meinung bist. Da es sich dabei nur um eine
Private Datenbank handelt reicht es aus wenn sie auf meiner SSD am PC
läuft.
Justus schrieb:> Wenn bei solchen Tabellen die Schlüssel nicht> durchdacht sind, läuft gar nichts mehr. Dann kann man nicht nur Kaffee> kochen gehen, sondern Mittagessen kochen.
Da gebe ich dir zu 100% Recht. Hab da einiges genüsselt bis das
vernünftig SCHNELL läuft. Eine Like-Suche mit NoCase (muss leider sein)
in der 4.6 Mio Datensätze DB hat am Anfrage fast 6 min gedauert. Da
hocken auch alle Datensätze in einer Tabelle. Durch eine Indizierte
Hilfsanfrage (Zeitraum eingegrenzt) ging es dann auf 10-15 sek runter.
Die andere Datenbank (9 Mio) ist schon allein deshalb in 16 Tabellen
aufgeteilt. Wobei jede Tabelle für ein Jahr steht. Ältere Daten werden
von mir so gut wie nie abgefragt. Aber es kann vorkommen. Weshalb ich
das aufgeteilt habe, um selbst den Index zu entlasten.
Nachtrag: Ich bin bei den 2 großen Datenbanken sogar extra wegen der
Größe auf SQLite umgestiegen weil mir die 2 GB-Access-Datei-Grenze um
die Ohren geflogen ist.
Die 9 Mio Sätze Datei verbraucht fast genau 8 GB auf der Platte.
ps.: Ich habe keine moderne Access-Version sondern nur 2003. Und mir
geht Access eh auf die Nerven. War aber schon immer so.
Manchmal wenn ich nostalgisch werde vermisse ich mein gutes altens
DBASE-IV.
Ein Befehl bei den . eingegeben und viele Probleme waren gelöst. Schei**
klicki-Bunti bei Datenbanken.
Schlaumaier schrieb:> Ich habe vor ein paar Tagen ein Prg. geschrieben was Access-Datenbanken> in SQL umwandeln soll.
Nachts ist es kälter als draußen.
Schlaumaier schrieb:> Ok. ;) Danke das du meiner Meinung bist. Da es sich dabei nur um eine> Private Datenbank handelt reicht es aus wenn sie auf meiner SSD am PC> läuft.
OK, erwischt, ich hatte nicht alles gelesen. Aber freut mich, dass wir
einer Meinung sind :-)
LIKE macht m.W. einen Full Table Scan. Besser ist es - wenn möglich -
die "zu LIKE-nden Datensätze" vorher per richtigem Key einzugrenzen,
eventuell mit einem Hilfsschlüssel ... und sofort wird man ggf. über die
(ungeliebte) Redundanz stolpern. Redundanzen sind oft der einzige Weg zu
richtiger High Speed Datenverarbeitung. Außerdem muss man sich von dem
Gedanken befreien, immer alles in einer einzigen Abfrage erledigen zu
wollen (Stichwort Stored Procedures). Arbeite mit der Engine, nie gegen
sie. Je mehr der Engine auf die Schultern gepackt wird, desto größer
wird der Hauptspeicherbedarf, und irgendwann wird ausgelagert ... Ende
der freundlichen Datenbank!
Schlaumaier schrieb:> Die andere Datenbank (9 Mio) ist schon allein deshalb in 16 Tabellen> aufgeteilt. Wobei jede Tabelle für ein Jahr steht. Ältere Daten werden> von mir so gut wie nie abgefragt. Aber es kann vorkommen. Weshalb ich> das aufgeteilt habe, um selbst den Index zu entlasten.
Ja genau. Das ist zwar nicht nötig. Aber wenn es schematisch die
Datenlage und Konsistenz nicht stört, ist es ok. Zum einmischen oder
löschen von Daten geht es oft um Welten besser, wenn man die NICHT zu
löschenden DS in eine neue Tabelle schreibt, die alte löscht und der
neuene Tabelle den Namen der alten gibt. Das bedarf zum Zeitpunkt der
Transaktion aber exklusicer Tabellenrechte.
Schlaumaier schrieb:> Nachtrag: Ich bin bei den 2 großen Datenbanken sogar extra wegen der> Größe auf SQLite umgestiegen weil mir die 2 GB-Access-Datei-Grenze um> die Ohren geflogen ist.
Ja klar. Über 2GB musst du mit verknüpften Tabellen arbeiten, was die
Performance Features der Access Engine "wertlos" macht. Access von Hause
aus ist an dieser Stelle am Ende. Ohne serverseitiges PASS THROUGH SQL
gibt es keine Steigerung. Ich weiß nicht, deine Tools PASS THROUGH (bzw.
stored Procedures) können, habe nur mit SQL-Server zu tun.
Die Erstellung einer wirklich rasend schnellen Datenbank macht es ab
einer bestimmten Größe erforderlich, DB und Server-Admin zu sein. Denn
nichts macht eine Datenbank schneller langsam als fragmentierte
Datenstrukturen. Die Fragmente entstehen kaskadiert. Zum einen kann das
OS fragmentierte Files enthalten (also die Datei der Datenbank ist
fragmentiert), zum zweiten kann die (auf Filesystem fragmentierte)
Datenbank innerhalb ihrer eigenen Strukturen auch noch mal fragmentiert
sein. Und wenn man mit Verschlüsselung oder Komprimierung arbeitet, wird
es ganz fies: Auch da entstehen Fragmentierungen. Dann (vierte Ebene)
gibt es innerhalb desganzen auch noch komprimierte Datenfelder (Access
bietet sowas an). Mit dem Endeffekt, dass die Datensätze nicht mehr
genau untereinander angeordnet werden können, der Tablescan muss also
rechnen, anstatt von DS zu DS zu springen. Löschen von Datensätzen
erzeugt weitere Fragmentierungen. Wenn man in der wenig glücklichen
Zwangslage ist, keines der Probleme selbt beheben zu können, wird man
über kurz oder lang einem Daten-Parkplatz voller Löcher und
Maulwurfshügel haben. Mit der entsprechenden "Einpark"-Geschwindigkeit.
Mir wurden schon Datenbanken vorgesetzt, da lief einer Verarbeitung 48
Stunden !! Als die Systeme bereinigt waren, war der Lauf nach ein paar
Minuten durch. Nurmal so am Rande bemerkt, was da möglich ist. 95% aller
Kollegen haben diesen "Löcher und Maulwurfshügel-Parkplatz". Weil sie
das entweder nicht wissen oder (das ist viel öfter der Fall) ihnen der
nötige Sinn vor einer sauberen Datenbasis fehlt. Das fängt wie o.g. auf
Betriebssystem-Ebene an, geht über die Anordnung der Datensätze in der
DB (worum sich ein "normaler Programmierer" überhaupt nicht schert) und
endet in einer vernünftigen PERFORMANTEN Verarbeitung. SQL macht Spaß.
Wer aber denkt, er kann eine C++ oder VBA-Denke anwenden, der kriegt
graue Haare.
Justus schrieb:> nichts macht eine Datenbank schneller langsam als fragmentierte> Datenstrukturen
Bei HDDs ist das aber deutlich wichtiger als bei SSDs, soweit das
Speichermedium involviert ist.
Eine Datenbank bereinigen heißt NICHT, den fast immer vorhandenen
Menüpunkt "komprimieren" anzuwenden. Ich hatte zum Glück bisher immer
fähige DB-Admins. Eine Datenbank bereinigen heißt, eine NEUE leere
Festplatte zu nehmen, darauf eine neue (leere) Datenbank der alten
Strukturen anzulegen und dann die Daten von der alten in die neue Welt
umzuziehen. Auch bei der Vergrößerung der Datenbank geht man diesen Weg.
Alles andere ist Frickelei.
Ich rede aber nur von wirklicher Großdatenverarbeitung. Beim üblichen
Hausgebrauch bringt das keine Geschwindigkeitsvorteile.
(prx) A. K. schrieb:> Bei HDDs ist das aber deutlich wichtiger als bei SSDs, soweit das> Speichermedium involviert ist.
Ja klar! Es gibt natürlich auch Spezialisten, die SSD defragmentieren
Hergott schmeiß Verstand vom Himmel
Justus schrieb:> Auch bei der Vergrößerung der Datenbank geht man diesen Weg.> Alles andere ist Frickelei.
Die Zeit, in der in Unternehmensumgebungen noch einzelne Platten auf
Anwendungsebene sichtbar sind, ist schon eine ziemliche Weile vorbei.
Das abstrahiert mittlerweile gerne auf einigen Ebenen: Wenn die
Tables/Tablespaces der DB-Server auf einem Filesystem aufsetzen, das in
einem Image-File einer VM liegt, das wiederum lediglich ein File in
einem Speichersystem ist.
Noch schöner wirds, wenn das Speichersystem mit CoW arbeitet, mit dessen
inhärenter Fragmentierung bei random writes, und untenrum dann SSDs mit
wear levelling sitzen.
Justus schrieb:> Ja klar! Es gibt natürlich auch Spezialisten, die SSD defragmentieren
Wer es eilig hat, und heute für DBs noch HDDs verwendet, der wär als
Ziel deiner Wurfaktionen auch gut geeignet. Insofern veralten manche
Kenntnisse dann doch etwas.
(prx) A. K. schrieb:> Bei HDDs ist das aber deutlich wichtiger als bei SSDs, soweit das> Speichermedium involviert ist.
SSD ist kein Allheilmittel. Trotz SSD kann die Datenbank fragmentiert
sein, können die Tabellen fragmentiert sein und ungleich große Felder
derselben Tabelle (String oder Text, mit und ohne Komprimierung) sind
nicht mehr direkt untereinander angeordnet. Geometrie (Alignment) heißt
das Zauberwort. Fängt schon bei SSD an. Wenn mit dem falschen Tool
partitioniert wird, fängt der Block bei Adresse "1" an (wie HDD). Die
SSD-Geometrie muss aber bei "0" anfangen, um volle Geschwindigkeit zu
liefern. Wer es falsch macht, hat sofort 50% Verlust, weil der
OS-Blockreader pro Block 2x zugreifen muss.
Dasselbe, auf DB-Ebene, gilt auch bei Zugriff auf Tabellenfelder. Hier
potenziert sich ein falsches Allignment über mehrere Ebenen hoch. Wenn
die Felder nicht blockgerecht addresiert sind (z.B. weil Datenfelder in
falsch verstandenem Optimierungswillen "komprimiert" sind), muss sich
die DB-Engine den Datensatz aus verschiedenen Speicherstellen
"zusammenpicken". Wenn die DB selbst noch fragmentiert ist, geht es an
die Substanz. Auch der Hauptspeicherbedarf wächst immens, DS vermehrt
gepuffert werden müssen.
usw. usf. Das ist aber nur Profi Wissen, was die meisten nie brauchen.
Bei 50 Millionen Zeilen und 10 Spalten ist das aber angezeigt und ohne
dieses Wissen wird man sich immer mehr quälen, je älter (und daher
fragmentierter) die Datenbank wird ... und irgendwann geht gar nichts
mehr.
(prx) A. K. schrieb:> Justus schrieb:>> Auch bei der Vergrößerung der Datenbank geht man diesen Weg.>> Alles andere ist Frickelei.>> Die Zeit, in der in Unternehmensumgebungen noch einzelne Platten auf> Anwendungsebene sichtbar sind, ist schon eine ziemliche Weile vorbei.> Das abstrahiert mittlerweile gerne auf einigen Ebenen: Wenn die> Tables/Tablespaces der DB-Server auf einem Filesystem aufsetzen, das in> einem Image-File einer VM liegt, das wiederum lediglich ein File in> einem Speichersystem ist.
Wenn ich eine ressourchenkritische Datenbank programmiere, bestimme ICH,
auf welchem Medium diese Datenbank liegt. Wenn das die Administration
verweigert (ist mir noch nie passiert), lege ich die Arbeit nieder. Wer
Leistung will, muss selbst auch bereit sein, die Voraussetzungen zu
schaffen. SO sieht das in der Praxis aus!
Justus schrieb:> Das ist aber nur Profi Wissen, was die meisten nie brauchen.
Yep. Zum Problem gehört, dass es immer mehr Ebenen dieser Art gibt.
Innerhalb der DB, des Betriebssystems, der Virtualisierung, des
Speichersystems und des Speichermediums. Der Versuch, hier noch wirklich
durchzublicken, wird immer schwerer und es verteilt sich u.U. auf mehr
teure Köpfe. Welcher DB-Spezialist hat schon eine Vorstellung davon, was
unterhalb seiner Ebene der Tablespaces im Storage abgeht, und auch von
den meisten Sysadmins kann man das nicht (mehr) erwarten.
Justus schrieb:> Wenn ich eine ressourchenkritische Datenbank programmiere, bestimme ICH,> auf welchem Medium diese Datenbank liegt.
Sobald du althergebrachte nichtvirtualisierte Server mit lokalem Storage
verlässt, sondern es bei der real existierenden Kundschaft mit
virtualisierten Systemen im bestehenden nicht von dir designten SAN zu
tun bekommst, verweigerst du die Arbeit?
Klar, es gibt DB-Szenarien, in denen man allein für eine bestimmte
Anwendung eine gesamte separate Infrastruktur beschafft. Mit allen
Nachteilen, die das nebenbei mitbringt, nicht nur die € mit den vielen
Nullen. Die Regel ist das aber nicht. Nicht heute, bei den paar
Milliönchen Datensätzen, von denen hier die Rede ist.
(prx) A. K. schrieb:> Sobald du althergebrachte nichtvirtualisierte Server mit lokalem Storage> verlässt, sondern es bei der real existierenden Kundschaft mit> virtualisierten Systemen im bestehenden nicht von dir designten SAN zu> tun bekommst, verweigerst du die Arbeit?
Ich weiß, das das Glück ist, wo man landet. Bisher habe ich aber
gekriegt, was ich wollte. Die Option wäre gewesen, dass die Verarbeitung
VIELLEICHT nicht so performant wie gewünscht läuft. Das aber wollte dann
die Projektleitung bzw. der Kunde nicht :-)
(prx) A. K. schrieb:> Justus schrieb:>> nichts macht eine Datenbank schneller langsam als fragmentierte>> Datenstrukturen>> Bei HDDs ist das aber deutlich wichtiger als bei SSDs, soweit das> Speichermedium involviert ist.
Da das beruhigt mit etwas. Weil ich da sonst kaum Möglichkeiten auf
einen PC
sehe. Besonders nicht auf einer SSD.
Die Datenstruktur der DB selbst ist NICHT defragmentiert. Grund : Es
werden keine Daten gelöscht. Selbst das Editieren ist bei den Großen
Datenbanken kaum ein Thema.
Sie werden einfach gefüllt, und schon sind die Daten da sauber drin.
Peter M. schrieb:> Nachts ist es kälter als draußen.
Erkläre mit bitte die Aussage. ???
Der Grund warum ich Access (*.mdb) in SQLite-Datenbanken umwandeln will
sind 2.
1. Ich bin es leid immer 2 Datenbank-Systeme zu benutzen beim
Programmieren.
2. Ich will nicht wie ja passiert an die 2 GB Grenze stoßen.
Ich habe mich nämlich vor den Umstieg auf SQLite schlau gemacht, ob das
LITE bedeutet das irgendwelche Einschränkungen bezüglich der Datenmenge
vorliegen.
Und damit das auch klar ist. Ich muss keine gigantischen Abfragen
machen.
In der Regel brauche ich nur Select * From DBB where xx = '11' and xy =
'22' order by zz . Auch als einzelfeldabfrage . sowie den Count Befehl.
Es geht bei meinen Datenbanken nur um das was man früher als
Karteikarten zum nachschauen benutzt hat. Also eine Teilmenge der Daten
bilden und die in einer Tabelle anzeigen lassen. Dann via Verstand den
richtigen Anklicken und dann VIA ID-Feld diesen Datensatz abfragen und
anzeigen lassen.
MEHR NICHT.
Und ich habe ca. 100 Datenbanken auf meinen Rechner. Da ich alle
Datensammlungen in DB stecke. Die kleinste hat übrigens z.Z. 58
Einträge und ist meine Einkaufslisten-Datenbank. Die kopiere ich einfach
auf mein Handy und das war's.
Was auch der Grund ist wieso ich SQLite nehme. Das Format selbst ist
Plattform übergreifend zu Android. Also Daten füttern am PC und dann die
DB einfach aufs Handy kopieren. Fertig. Dort habe ich dann eine (auch
selbst geschriebene) App die die Daten ausließt. Ich brauche zwar oft
auf den Handy nicht alle Daten, aber ich bin zu faul eine Hilfs-DB zu
programmieren. Und ich habe Platz genug auf mein Handy so das mich das
nicht juckt. Und sollte ich Änderungen gemacht haben, kopiere ich die DB
einfach zurück.
Außer der Einkaufs-Zettel-DB, sind die anderen DB's auf den Handy
übrigens für den Flohmarkt. Da sind meine gesammelten Comix drin (mit
Cover) soviel die Taschenbücher die sammele + DVD's die ich habe. Es
kotzt mich nämlich an wenn ich was doppelt kaufe. Als ich die Angelegt
habe, habe ich 37 Donald-Duck (Schmale Taschenbücher ca. 200 Seiten)
entdeckt die ich doppelt habe.
Anmerkung : Die erste Version dieser Comix-Datenbank habe ich für meinen
kleinste Laptop = ein Atari-Portfolio geschrieben. Da haben viele dumm
geguckt (machen sie noch immer) wenn ich das Teil raus geholt habe. Ist
halt cooler als dicke Listen zu wälzen und geht 100 x schneller. ;)
Hallo Pucki,
Schlaumaier schrieb:> eter M. schrieb:>> Nachts ist es kälter als draußen.>> Erkläre mit bitte die Aussage. ???
Meine Aussage ist genauso aussagekräftig wie Deine und soll Dich dezent
darauf hinweisen, den Sinngehalt Deiner Aussage zu überprüfen:
Peter M. schrieb:> Schlaumaier schrieb:>> Ich habe vor ein paar Tagen ein Prg. geschrieben was Access-Datenbanken>> in SQL umwandeln soll.>> Nachts ist es kälter als draußen.
Access ist ein Datenbankprodukt.
SQL ist eine Datenbankabfragesprache.
Bitte erkläre mir, wie man Datenbankprodukte in Datenbankabfragesprachen
wandelt!
Peter M. schrieb:> Access ist ein Datenbankprodukt.> SQL ist eine Datenbankabfragesprache.>> Bitte erkläre mir, wie man Datenbankprodukte in Datenbankabfragesprachen> wandelt!
Blödsinn.
SQL ist auch einen Datenbankformat genau wie Access. Die normale
Endung einer SQL-Datei ist *.db, bei Access *.mdb
Es gibt sogar innerhalb dieses SQL Formates kleinere Unterschiede. Aber
aus Kostengründen = kostenlos ist SQLite 3 (als Datenbank-Format) sehr
verbreitet. Welches ich benutzte und in das ich meine Access-Datenbanken
umwandele.
Das ich die Access-Datenbanken mit SQL -Befehlen abfrage ist mir auch
klar.
Diese Eigenschaft macht mir das Unwandeln sogar leichter, da ich nur ein
anderes Datenbank-Objekt deklarieren muss in meinen Prg.
Und diese Datenbanken haben die für mich wichtige Eigenschaft das sie
lt. Beschreibung relativ unendlich groß sein dürfen. Bei den
Access-Dateien die ich habe ist bei 2 GB Schluss. Und 2 GB sind echt
nicht wirklich ne Menge.
Und das ich gezwungen werde deshalb 2 Datenbank-Objekte im selben
Programm zu benutzen macht die Sache auch nicht besser, es nervt
nämlich.
Ich kann die erstellte *.DB Datei aber nehmen und auf z.b. Android
kopieren und dort STRESSFREI abfragen. Was ich ja bei den Einkaufzettel
und meiner Comix-DB mache.
Aber du kannst mir ja mal erzählen wieso ich mit einen SQL-Manager
Programm auf keine Access-Datenbanken zugreifen kann.
Kleiner Nachtrag für dich zum lesen.
Dann lernst du den Unterschied.
https://www.tenmedia.de/de/glossar/sql-datenbank
Zitat: Eine SQL Datenbank ist ein elektronisches Speicher- und
Verwaltungssystem, welches auf der Datenbankprogrammiersprache
Structured Query Language (SQL) basiert.
Es basiert auf der Sprache. Es geht aber nicht um die Abfrage sondern
die Struktur der Datensätze auf der Festplatte. !!!!
Zitat 2 :
In der Web- und Softwareentwicklung wird meist eine relationale
Datenbank benötigt, weshalb eine SQL Datenbank die am häufigsten
verwendete Datenbank ist.
Schlaumaier schrieb:> Peter M. schrieb:>> Access ist ein Datenbankprodukt.>> SQL ist eine Datenbankabfragesprache.>>>> Bitte erkläre mir, wie man Datenbankprodukte in Datenbankabfragesprachen>> wandelt!>> Blödsinn.>> SQL ist auch einen Datenbankformat genau wie Access. Die normale> Endung einer SQL-Datei ist *.db, bei Access *.mdb
Unfug. SQL ist die Abfrage- und Steuersprache und hat nicht das
Geringste damit zu tun, wie die eigentlichen Daten intern bzw. im
Filesystem strukturiert sind.
Diese Strukturen sind in keinster Weise standardisiert, denn sonst gäbe
es z.B. bei MySQL/MariaDB keine unterschiedlichen Storage-Engines, die
jeweils für unterschiedliche Ansprüche optimiert sind (Crash-Festigkeit,
RAM-optimiert, archivierend u.v.a).
Dass z.B. innerhalb des MS-Mikrokosmos evtl. auch andere Softwares als
Access etwas mit *.mdb-Files anfangen können, is eine Entscheidung von
MS, hat aber nichts mit dem Prinzip zu tun.
Bei einem DBMS überhaupt auf die Idee zu kommen, irgendwas mit einem
Zugriff auf die physikalischen Dateien anfangen zu wollen, ist
heutzutage nahezu absurd ...
Schlaumaier schrieb:> SQL ist auch einen Datenbankformat genau wie Access.
SQL ist die Sprache, nicht das System. Mit der Implementierung und dem
Format hat SQL absolut nichts zu tun.
Schlaumaier schrieb:> Zitat: Eine SQL Datenbank ist ein elektronisches Speicher- und> Verwaltungssystem, welches auf der Datenbankprogrammiersprache> Structured Query Language (SQL) basiert.
Auch andere drücken sich gelegentlich schlecht aus. Richtig wäre: "...
welches die Datenbankprogrammiersprache Structured Query Language (SQL)
unterstützt."
Mir egal.
Ich weiß was ich programmiere das reicht völlig.
Und ich mache es, weil mein Handy genauer gesagt mein
Android-Entwicklungssystem keine MDB-Datenbanken unterstützt sondern nur
SQl.
Schlaumaier schrieb:> Und ich mache es, weil mein Handy genauer gesagt mein> Android-Entwicklungssystem keine MDB-Datenbanken unterstützt sondern nur> SQl.
Du meinst das in Android obligatorische SQLite?
Justus schrieb:> Eine Datenbank bereinigen heißt NICHT, den fast immer vorhandenen> Menüpunkt "komprimieren" anzuwenden. Ich hatte zum Glück bisher immer> fähige DB-Admins. Eine Datenbank bereinigen heißt, eine NEUE leere> Festplatte zu nehmen, darauf eine neue (leere) Datenbank der alten> Strukturen anzulegen und dann die Daten von der alten in die neue Welt> umzuziehen. Auch bei der Vergrößerung der Datenbank geht man diesen Weg.> Alles andere ist Frickelei.>> Ich rede aber nur von wirklicher Großdatenverarbeitung. Beim üblichen> Hausgebrauch bringt das keine Geschwindigkeitsvorteile.
Ähm... das bedingt aber Stillstand. Die "Großdatenverarbeitung" die ich
kenne läuft 24/7.
Schlaumaier schrieb:> Aus diversen Gründen (inkl. Lizenz) benutze ich nur das.
Spricht auch nichts dagegen. Nur sollte man nicht aus dieser eher
schmalbandigen Erfahrung auf allgemeine Datenbanksysteme schliessen.
Lichtbogenofen schrieb:> Ähm... das bedingt aber Stillstand. Die "Großdatenverarbeitung" die ich> kenne läuft 24/7.
Yep. Ich hatte noch im HDD-Zeitalter mit einer DB zu tun, deren Inhalt
in einigen Tagen komplett veraltete, mitsamt deutlicher Fragmentierung
in ähnlichem Zeitrahmen. Es wäre eine seltsame Idee gewesen, das System
alle paar Tage für einige Zeit offline zu nehmen. ;-)
Hey Justus, Dankeschön für deinen Einblick in dein Fachwissen!
Wenn ich jetzt meine DB exportiere und auf ein sauberes Server System
aufspiele, sind die Löcher dann beseitigt? Oder wie muss ich vorgehen?
Ist es richtig dass wenn ich die Größe vom Datenfeld definiere keine
Löcher entstehen können auch wenn ich die Felder Überschreibe mit der
Voraussetzung dass die Feldgröße nicht größer oder kleiner wird?
Richard schrieb:> Ist es richtig dass wenn ich die Größe vom Datenfeld definiere keine> Löcher entstehen können auch wenn ich die Felder Überschreibe mit der> Voraussetzung dass die Feldgröße nicht größer oder kleiner wird?
Wenn du die Feldgröße Definierst, und das Feld mit ein größeren Wert
fütterst wird eine Fehlermeldung ausgelöst. Feste Feldgrößen halten die
Datenbank kleiner und den Zugriff schneller. Können aber bei falscher
Anwendung auch zu zu Großen Datenbanken (ich meine Speicherplatz)
führen.
Da Datenbanken meistens das Ergebnis eines Formular abspeichern, sollte
man eine Anpassung durchführen und das Problem ist gut eingegrenzt.
Wenn du die Feldgröße nachträglich änderst wäre es Sinnvoll mit ein
Copy-DB Befehl die Datenbank in einen neue Datenbank zu kopieren. Was
z.b. Access mit den Komprimieren Befehl RICHTIG macht. Eins der wenigen
Dinge. ;)
Peter M. schrieb:>> Nachts ist es kälter als draußen.Peter M. schrieb:> Access ist ein Datenbankprodukt.> SQL ist eine Datenbankabfragesprache.> Bitte erkläre mir, wie man Datenbankprodukte in Datenbankabfragesprachen> wandelt!
Frage mich immer, wodurch Leute getriggert werden, sinnloses Zeug zu
schreiben. Einsamkeit oder wa ??
Lichtbogenofen schrieb:> Justus schrieb:>> Eine Datenbank bereinigen heißt NICHT, den fast immer vorhandenen>> Menüpunkt "komprimieren" anzuwenden. Ich hatte zum Glück bisher immer>> fähige DB-Admins. Eine Datenbank bereinigen heißt, eine NEUE leere>> Festplatte zu nehmen, darauf eine neue (leere) Datenbank der alten>> Strukturen anzulegen und dann die Daten von der alten in die neue Welt>> umzuziehen. Auch bei der Vergrößerung der Datenbank geht man diesen Weg.>> Alles andere ist Frickelei.>>>> Ich rede aber nur von wirklicher Großdatenverarbeitung. Beim üblichen>> Hausgebrauch bringt das keine Geschwindigkeitsvorteile.> Ähm... das bedingt aber Stillstand. Die "Großdatenverarbeitung" die ich> kenne läuft 24/7.
Tja, das ist der Unterschied zwischen Theorie und Praxis. Keine
Verarbeitung läuft lückenlos 24/7. Selbst Spiegelsysteme brauchen ein
Wartungsfenster. SQL ist nicht gleich SQL. SQL-Server für Internetseiten
haben eine andere Geometrien wie SQL-Server für Banken. Nur bei
letzteren wird von "Großdatenverarbeitung" geredet, aber auch nur in
Etappen (z.B. Verdichtungsläufe). Bei SQL ergibt sich ein Fenster meist
nach Ende eines solchen Laufs. Ein Lauf ist definiert durch einen Job,
der eine Kette von Stored Procedures abarbeitet. Da solche Läufe so gut
wie immer nachts stattfinden, werden (MS) SQL-Server gerne tagsüber
migriert, vergrößert oder sonst wie gewartet. Dass während der
Migration/Datenübertragung keine Standardverarbeitung möglich ist,
sollte sich von selbst erklären, ist (bei SQL-Verarbeitungen) aber auch
nicht tragisch.
(prx) A. K. schrieb:> Justus schrieb:>> Selbst Spiegelsysteme brauchen ein Wartungsfenster.>> Wozu?
Weil sie wachsen, und irgendwann vergrößert werden müssen?
Bei gleichzeitigen Löschen von DS fragmentiert die DB mehr und mehr.
Schnelle CPUs / Datenträger sind nur ein Teil der Gegenargumente. Wenn
blockübergreifende Fragmente entstehen, leidet in Multiuser Systemen
mehr und mehr das Transaktionsmanagement, z.B. die Sperrung von
Datensätzen während einer Update-Aktion sperrt dann auch Datensätze, die
gar nicht betroffen sind, weil sie "zufällig" im selben Block liegen wie
der editierte Datensatz liegen (auf diese Weise kann im Worst Case sogar
über Access ein SQL-Server lahm gelegt werden).
Justus schrieb:> Weil sie wachsen, und irgendwann vergrößert werden müssen?
ALTER DATABASE DATAFILE
'/home/oracle/datenbanken/DB/TS_DATEN/daten_1.dbf' RESIZE 2000M;
50c schrieb:> ALTER DATABASE DATAFILE> '/home/oracle/datenbanken/DB/TS_DATEN/daten_1.dbf' RESIZE 2000M;
Die ALTER-Befehle gibts nicht nur bei Oracle, sondern überall. Ist ja
auch gut, und fast immer ausreichend. Beim ALTERn entstehen aber
Fragmente, so bei alten Leuten Falten :-) Und wer will das schon, wenn
Leistung und Performance das Ziel ist. Ich weiß, dass das den typischen
Programmierer nicht juckt. Jeder lebt in seiner eigenen Welt und glaubt,
eine andere gibt es nicht. Daher laufen so viele System ja auch total
unzuverlässig und lahmen wie eine fette Weihnachtsente.
Ein T. schrieb:> Deswegen kennen richtige (tm) Datenbanken so etwas wie VACUUM. Ich> glaube, bei MySQL und Abkömmlingen nennt sich das OPTIMIZE TABLE [1].
Ob vacuum optimize oder sonstwas, glaube mir, das sind nur Hilfskrücken.
Nur vollständig leere Speicherseiten können überhaupt gelöscht werden,
die wenigsten Seiten sind im Betrieb vollständig leer (praktisch gar
keine). Der Speicher wird auch nicht wirklich reorganisiert, sondern nur
die ungültig gewordenen Speicherbereiche als "frei" markiert. Diese
Markierungen werden in eine Free Space Map eingetragen; ein Katalog, in
dem die wiederverwendbaren Bereiche in den Speicherseiten aufgelistet
sind. Ein echtes Reorg im Betrieb ist ausgeschlossen. Garbage
Collection bei 64er Computern hatte das, es hat Stunden oder die ganze
Nacht gedauert. Selbst wenn man vacuum als soches interpretiert, würden
bestenfalls Lücken gefüllt. Das kommt dem Speicherplatz (vielleicht)
zugute, nicht aber der Performance. Weil die Nutzdaten immer noch
verstreut vorliegen. Die können gar nicht zusammengefügt werden, weil
andere (genutzte) Datensatz-Fragmente den Platz belegen. Die Jet Engine,
als "nicht-echte" Datenbank, macht beim Komprimieren das einzig
richtige: Sie legt eine neue Datenbank an und löscht die alte.
Ich glaube MySQL macht beim Optimize so ziemlich das Gleiche. Ich müsste
das direkt mal testen. Aber wenn du eine Tabelle mit sagen wir 200Mbyte
Größe hast und du führst darin ein DELETE WHERE 1 aus, ist die Tabelle
hinterher leer, aber dank 200Mbyte Überhang immer noch 200Mbyte groß.
Bei einem Optimize verschwindet dieser Überhang.
DELETE WHERE 1 öffnet intern eine Transaktion, ist also extrem langsam.
TRUNCATE TABLE arbeitet ohne Protokoll und dauert daher nur Sekunden,
egal wie groß die Tabele ist (war). Aufgeräumt wird aber bei beiden
nicht.
> DELETE WHERE 1 öffnet intern eine Transaktion,> ist also extrem langsam.
Um die Geschwindigkeit ging's gerade nicht, sondern um das Erstellen
eines möglichst großen Überhangs.
> TRUNCATE TABLE arbeitet ohne Protokoll und dauert daher> nur Sekunden, egal wie groß die Tabele ist (war). Aufgeräumt> wird aber bei beiden nicht.
Da hast Du leider das Manual nicht vollständig gelesen. Truncate
schmeißt die ganze Tabelle weg und erstellt die Struktur neu, besser
aufräumen geht nicht.
Ramona schrieb:> Ich hab nun eine Datenbank über Klimamessung mit MariaDB erstellt, mit> etwa 50 Millionen Zeilen und 10 Spalten (Eintragsnummer, Datum, Uhrzeit,> Temperatur Ort 1, Temperatur Ort 2 usw.).
So etwas haben wir auch im Einsatz unter mySQL auf einem schmalbrüstigen
System (2 Cores, 4 GB RAM, Linux). Das läuft auch mit mehreren Millionen
Datensätzen schnell.
(Und frag micht nicht, was man mit dem ganzen Datenberg eigentlich will
- ich weiß es schlicht und einfach nicht, aber hoffentlich die Kollegen,
für die das gesammelt wird.)
Allerdings haben wir die einzelnen Datensätze noch aufgeteilt, also in
Deinem Fall (ID, Datum, Zeit, Temp, Ort), um eine maximale Flexibilität
zu bekommen.
> Reorganisation
Bei so einer Meßdatenbank, wo keine Datensätze geändert oder gelöscht
werden, dürfte eine Reorganisation praktisch nicht erforderlich werden.
Ben B. schrieb:>> TRUNCATE TABLE arbeitet ohne Protokoll und dauert daher>> nur Sekunden, egal wie groß die Tabele ist (war). Aufgeräumt>> wird aber bei beiden nicht.> Da hast Du leider das Manual nicht vollständig gelesen. Truncate> schmeißt die ganze Tabelle weg und erstellt die Struktur neu, besser> aufräumen geht nicht.
Ausser natürlich, wenn die Tabelle im zentralen InnoDB Tablespace liegt,
statt separat.
Justus schrieb:> Ein T. schrieb:>> Deswegen kennen richtige (tm) Datenbanken so etwas wie VACUUM. Ich>> glaube, bei MySQL und Abkömmlingen nennt sich das OPTIMIZE TABLE [1].> Ob vacuum optimize oder sonstwas, glaube mir, das sind nur Hilfskrücken.> [...] Ein echtes Reorg im Betrieb ist ausgeschlossen.
Nein. VACUUM FULL schreibt die Tabellen neu.
Ben B. schrieb:>> TRUNCATE TABLE arbeitet ohne Protokoll und dauert daher>> nur Sekunden, egal wie groß die Tabele ist (war). Aufgeräumt>> wird aber bei beiden nicht.> Da hast Du leider das Manual nicht vollständig gelesen. Truncate> schmeißt die ganze Tabelle weg und erstellt die Struktur neu, besser> aufräumen geht nicht.
Nein, es wird nicht aufgeräumt. Die Geschwindigkeit steht im
Vordergrund, da verbietet sich jeglicher Overhead. TRUNCATE ist ein
Serverbefehl, der von Client-Engines nicht ausgeführt werden kann, PASS
THROUGH erforderlich. Und ja, die Tabelle wird neu erstellt. Habe auch
gar nix anderes behauptet. Das sind wieder typische Nur-Programmierer
Gedanken: Wenn die alte Tabelle weg ist, ist da viel Platz und die neue
Tabelle kann sauber erstellt werden. Leider ist das im realen Leben ein
Trugschluss. Wenn die alte Tabelle bis über die Ohren fragmentiert war,
wirddurch das Löschen eben kein zusammenhängender "neue Speicher" frei.
Das kann zwar sein (wenn der Server noch viel freien Paltz hat), muss
aber nicht. Im Worst Case (Speicher ist knapp) wird die neue Tabelle
wieder im selben fragmentierten Löcherwerk erstellt, nicht viel besser
als vorher. Die Datensätze mögen bündig aneinander liegen, insgesamt
(die Kette der DS) sind sie aber trotzdem fragmentiert und können sogar
quer über die Pages verteilt sein. Was soll der Server auch sonst
machen, wenn beispielsweise Speicherplatz knapp wird. Und nochmal ja, es
geht nicht um Geschwindigkeit. Wenn man im Zusammenhang mit Reorg ect.
aber das Löschen (im sinne von leer-machen) von Tabellen nennt, sollte
man auch die besten Befehle nennen. DELETE kann einer der langsamsten
Befehle der DB sein. Ja nachdem, wie sich der physikalische Verlauf der
Daten von jenen des PK unterscheidet - denn der PK gibt keinen
Rückschluss, wie die Daten auf dem Datenträger verteilt sind.
Bevor wir uns jetzt in Details verzetteln, will ich den Grund nennen,
warum ich das so ausführlich schrieb. Der Fragmentierungsgrad bei
EDV-Systemen ist das A & O i.p. Performance und Geschwindigkeit.
Fragmente bremsen alles aus. Tabellen fragmentieren. Das weiß der
geschulte Programmierer und löscht im Bedarfsfall lieber die Tabelle
samt Neuerstellung, wenn die meisten (oder alle) Datensätze gelöscht
werden sollen. Soweit ok. Aber die Datenbank fragmentiert sich auch. Und
dagegen ist kein wie auch immer geartetes Löschen von Tabellen gewapnet.
Als dritter im Bunde fragmentiert der Speicherplatz, den die DB
einnimmt, nämlich auf NT-Fileserver-Ebene. Das Ergebnis ist ein
pausenloses Hin- und Her-Rechnen der CPUs oder Tasks, bis die Daten
physikalisch addressiert werden können. Die CPU- und
Festplatten-Geschwindigkeit machts wieder wett, schon klar, warum soll
man sich dann noch darum kümmern, wie die Daten physikalisch angeordnet
sind. Ich mache das eben. Und zwar nicht nur aus Spaß, sondern weil ich
weiß, wie die Falle aussieht, wenn man erstmal drin ist. Fragmentierung
bedeutet eben nicht nur Reduzierung der Performance (das kann durch
schnelle Hardware leicht geheilt werden, wenn die DBen nicht zu groß
sind), Fragmentierung bedeutet auch, dass zusammengehörige Daten über
immer mehr Pages verteilt werden. Da manche DBen es so an sich haben,
beim Zugriff keine Datensätze zu sperren, sondern die zugehörigen Pages,
nehmen auch die unnötigen Locks mit steigender Fragmentierung zu. Das
sollte man wissen, wenn man in einer Multiuserumgebung arbeitet.
Justus schrieb:> nämlich auf NT-Fileserver-Ebene
Ah, da haben wir den Grund:
Schrottige Dateisysteme aus dem letzten Jahrtausend und
Kindergarten-Betriebssysteme.
Einer schrieb:> Schrottige Dateisysteme aus dem letzten Jahrtausend und> Kindergarten-Betriebssysteme.
Je weniger jemand von einer Technik versteht, desto eher ist er/sie
geneigt, sie für göttlich zu halten. Leider entspricht das nicht der
Realität. Immer komplexer, immer mehr Features und daher immer mehr
Fehlerquellen - die auch bedient werden. Um dem Menschen zu helfen, baut
der Mensch Werkzeuge, die später so ausgefeilt sind, dass Mensch sie
kaum mehr bedienen kann. Das gilt insb. in der EDV, und zwar in allen
Layern. Wer mit Sprüchen wie "Schrottige Dateisysteme" oder
"Kindergarten-Betriebssysteme" hausieren geht, hat nicht wirklich was
von EDV verstanden. Dieses Profilierungsgehabe ist es, das in den
Kindergarten gehört, und so wird es bei dir auch sein.
Selbstverständlich ist abzuwägen, auf welcher Daten- oder Serverbasis
ein System aufgesetzt wird. Daraus ein "So und nicht anders ist es" zu
machen, zeugt von wenig Efahrung auf dem Gebiet der EDV. Wenn die
Hardware nicht immer schneller werden würde, würden solche Entwickler
wie du, die sich nur auf "moderne Systeme" verbissen haben, ganz schnell
mit dem Kopf unter Wasser gehen. In einem gebe ich dir ja recht, das von
mir als Beispiel verwendete Microsoft Betriebssystem ist wirklich ein
Kindergarten-Betriebssystem. Das ändert aber nichts daran, dass solche
System den Markt geflutet haben. Ob NT (das war wirklich ein bisschgen
alt, um es als Beispiel zu nennen) oder Server 2022 - es kommt aus
derselben Kindergarten-Schmiede, nämlich M$. Und wenn man bei SQL
bleibt, hat M$ die SQL-Server. Davon ist ein Großteil wirklicher
Schrott. Das hat M$ irgendwann auch gemerkt und für 7er SQL-Server
Version externe Programmierer unter Vertrag genommen. In der 7er Version
ist dann auch ein Wunderwerk entstanden, das wirklich durchdacht war und
flott und fast fehlerfrei lief. Diese Technologie wurde von M$ in die
2000er Version übernommen, immer noch gut. Allerdings gingen da schon
wieder altbekannte Features verloren oder waren nicht mehr so performant
wie bei 7. Das typische M$-Syndrom also, alles "besser, einfach,
schneller" machen zu wollen, und letztendlich das Gegenteil von allem zu
erreichen. Ich kümmere mich auch nicht mehr darum, auf welchen Füßen ein
System steht. Das ist nicht mehr zeitgemäß und ändern kann man heute
sowieso kaum noch was. Man sollte aber wenigstens die Basics kennen und
warum etwas nicht richtig funktioniert oder langsamer als erwartet ist.
Und das habe ich geschrieben. Selbst wenn es für einige von euch Schnee
von gestern ist, so merkt man erst, dass es das nicht ist, wenn man
einmal selbst vor der Aufgabe steht, 50 Millionen Zeilen zu
aktualisieren (dieses Thema), und der Bildschirm friert stundenlang ein.
Wenn man dann nicht mehr hinkriegt, als Schrottige Dateisysteme aus dem
letzten Jahrtausend und Kindergarten-Betriebssysteme zu schimpfen, merkt
man im Geheimen selbst, dass man verloren hat.
Echt interessant, aber zum Optimieren von Maria DB (relationale DB) die
auf dem Kern / Engine InnoDB basiert, gibt es bereits einige
dokumentierte Optimierungsmöglichkeiten.
a) Vor allem im Basis Setup ist mal wichtig für die optimale Einstellung
der Konfiguration der MariaDB:
https://mariadb.com/kb/en/configuring-mariadb-for-optimal-performance/
Da gibt es viele Grundkonfigurationen, die zuerst nötig sind um die
MariaDB optimal zu betreiben.
b) Danach kann man sich an den Aufbau der DB (Datenstrukturen) machen
und UseCase - was ich will ich damit machen - ok - Temperaturmessungen -
da wie schon erwähnt wurde, wird öfters und viel an neuen Daten in die
DB geschrieben und aber weniger an alten Daten geändert, quasi ein
Datenspeicher von Messungen.
Da bietet sich ein performanter Index an auf die Felder die dann z.B. in
der GUI oder über die Software öfters abgefragt werden.
Man kann sich noch Gedanken machen um z.B. monats- oder wochenweise
Partitionierung (je nach Belieben).
c) Dann ev. sich um Housekeeping Gedanken machen:
will kann ich alte Daten und Logs aufräumen löschen? Kann ich sie in
alternative Tabellen z.B. als Backup ablegen? Damit man nicht immer
komplett alle Messdaten für alle Ewigkeiten in einer Tabelle hat - das
kann ebenso Suchanfragen sehr beschleunigen.
Danach Tabellenstatistiken immer wieder neu berechnen / aktuell halten -
z.B. in Oracle basieren sogenannte "Execution Pläne" immer auf jeweils
intern berechneten Statistiken die der jeweiligen Tabelle zugrunde
liegen.
Allein nach Befolgung dieser Tipps sollte die Performance der DB danach
massiv optimiert sein.
Grüsse,
DBA Murat K.
50c schrieb:> ALTER DATABASE DATAFILE> '/home/oracle/datenbanken/DB/TS_DATEN/daten_1.dbf' RESIZE 2000M;
Stimmt es dass man Oracle auch direkt auf Partitonen ohne FS betreiben
kann, eben wegen dem unnötigen Overhead, siehe oben Fragmentierung,...?
Wird das in der Praxis dann oft so genutzt oder doch eher mit FS?
Russenhocke schrieb:> Stimmt es dass man Oracle auch direkt auf Partitonen> ohne FS betreiben kann
Soweit mir bekannt ist, ist das die bevorzugte Methode.
