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?
Ramona schrieb: > Kann man dies beschleunigen? Ja. Aber SQL lernt man ebensowenig aus Forenfragen wie C Programmierung
> 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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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,
:
Bearbeitet durch User
Ä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.
:
Bearbeitet durch User
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/
:
Bearbeitet durch User
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.
Beitrag #6954693 wurde vom Autor gelöscht.
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...
Einer schrieb: > D.h. PRIMARY KEY (Datum, Uhrzeit) setzen Wozu? Es exitiert keine andere Tabelle, die ihn referenziert.
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ß.
:
Bearbeitet durch User
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.
Beitrag #6955198 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
(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?
Blödsinn. PHP hat mit der MySQL OderWasAuchImmerSQL Performance überhaupt nichts zu tun.
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 | ALTER TABLE adresse ADD INDEX ixd1 (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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
(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.
:
Bearbeitet durch User
(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!
:
Bearbeitet durch User
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 ...
:
Bearbeitet durch User
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."
:
Bearbeitet durch User
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?
(prx) A. K. schrieb: > Du meinst das in Android obligatorische SQLite? Genau. Aus diversen Gründen (inkl. Lizenz) benutze ich nur das.
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. ;-)
:
Bearbeitet durch User
zum Thema "Access (.mdb) --> SQLite": da gibt es (mindestens) eine fertige Lösung: https://github.com/arturasn/mdb2sqlite Hier in "fertig": https://github.com/arturasn/mdb2sqlite/blob/master/bin/mdb2sqlite.exe
Thomas S. schrieb: > Hier in "fertig": > https://github.com/arturasn/mdb2sqlite/blob/master/bin/mdb2sqlite.exe Werde ich mal testen. Danke für die Info. Wir reden immerhin über ca. 40 z.T. Mini-Datenbanken (= kleiner 3000 Einträge + im Schnitt 2-3 Tabellen) die ich umwandeln bzw. Konvertieren muss.
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? OK. Ich dachte du meinst regelmässige Wartungsfenster, jede Woche oder so.
:
Bearbeitet durch User
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.
Justus schrieb: > Bei gleichzeitigen Löschen von DS fragmentiert die DB mehr und mehr. Deswegen kennen richtige (tm) Datenbanken so etwas wie VACUUM. Ich glaube, bei MySQL und Abkömmlingen nennt sich das OPTIMIZE TABLE [1]. [1] https://dev.mysql.com/doc/refman/5.7/en/optimize-table.html
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.