Forum: PC-Programmierung Einstieg in SQL


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ramona (Gast)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

Ramona schrieb:
> Kann man dies beschleunigen?

Ja. Aber SQL lernt man ebensowenig aus Forenfragen wie C Programmierung

von Ein Kommentar (Gast)


Lesenswert?

> 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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Ramona (Gast)


Lesenswert?

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.

von Sascha S. (dec)


Lesenswert?

SELECT * FROM Tabellenname WHERE (Spannung a > x) AND (Spannung a < y)

Grüße

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Äxl (Gast)


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> 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
von Pandur S. (jetztnicht)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

Ä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.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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 ...

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> 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.

von (prx) A. K. (prx)


Lesenswert?

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
von Gästin (Gast)


Lesenswert?

U. U. macht ja auch eine spezialisierte DB Sinn: 
https://de.wikipedia.org/wiki/Zeitreihendatenbank

von Ein Kommentar (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Einer (Gast)


Lesenswert?

Ä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.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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
von Rainer Z. (netzbeschmutzer)


Lesenswert?

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.
von Uwe (Gast)


Lesenswert?

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/

von Alonzo Mutex (Gast)


Lesenswert?

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.

von Nur_ein_Typ (Gast)


Lesenswert?

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.

von Nur_ein_Typ (Gast)


Lesenswert?

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"... ;-)

von Nur_ein_Typ (Gast)


Lesenswert?

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?!

von Ein Kommentar (Gast)


Lesenswert?

> 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...

von Markus L. (rollerblade)


Lesenswert?

Einer schrieb:
> D.h. PRIMARY KEY (Datum, Uhrzeit) setzen
Wozu? Es exitiert keine andere Tabelle, die ihn referenziert.

von Thomas W. (Gast)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

(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...

von Ein Kommentar (Gast)


Lesenswert?

> 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.

von Clemens S. (zoggl)


Lesenswert?

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

von seere (Gast)


Lesenswert?

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.

von seere (Gast)


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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.

von Johannes S. (Gast)


Lesenswert?

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.
von Einer (Gast)


Lesenswert?

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,- €.

von Rainer Z. (netzbeschmutzer)


Lesenswert?

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!

von Pandur S. (jetztnicht)


Lesenswert?

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 ?

von (prx) A. K. (prx)


Lesenswert?

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
von Ramona (Gast)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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
von Ein T. (ein_typ)


Lesenswert?

(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.

von Martin U. (Gast)


Lesenswert?

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?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Blödsinn. PHP hat mit der MySQL OderWasAuchImmerSQL Performance 
überhaupt nichts zu tun.

von Martin U. (Gast)


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Justus (Gast)


Lesenswert?

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.

von Justus (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Peter M. (r2d3)


Lesenswert?

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.

von Justus (Gast)


Lesenswert?

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.

von Justus (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Justus (Gast)


Lesenswert?

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.

von Justus (Gast)


Lesenswert?

(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

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Justus (Gast)


Lesenswert?

(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.

von Justus (Gast)


Lesenswert?

(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!

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Justus (Gast)


Lesenswert?

(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 :-)

von Schlaumaier (Gast)


Lesenswert?

(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. ;)

von Peter M. (r2d3)


Lesenswert?

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
von Schlaumaier (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Schlaumaier (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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?

von Schlaumaier (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Du meinst das in Android obligatorische SQLite?

Genau.

Aus diversen Gründen (inkl. Lizenz) benutze ich nur das.

von Lichtbogenofen (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Thomas S. (doschi_)


Lesenswert?

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

von Schlaumaier (Gast)


Lesenswert?

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.

von Richard (Gast)


Lesenswert?

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?

von Schlaumaier (Gast)


Lesenswert?

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. ;)

von Justus (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Justus schrieb:
> Selbst Spiegelsysteme brauchen ein Wartungsfenster.

Wozu?

von Justus (Gast)


Lesenswert?

(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).

von (prx) A. K. (prx)


Lesenswert?

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
von 50c (Gast)


Lesenswert?

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;

von Justus (Gast)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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

von Justus (Gast)


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Justus (Gast)


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> 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.

von svensson (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Ein T. (ein_typ)


Lesenswert?

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.

von Justus (Gast)


Lesenswert?

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.

von Justus (Gast)


Lesenswert?

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.

von Einer (Gast)


Lesenswert?

Justus schrieb:
> nämlich auf NT-Fileserver-Ebene

Ah, da haben wir den Grund:

Schrottige Dateisysteme aus dem letzten Jahrtausend und 
Kindergarten-Betriebssysteme.

von Justus (Gast)


Lesenswert?

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.

von Murat K. (Gast)


Lesenswert?

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.

von Russenhocke (Gast)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

Russenhocke schrieb:
> Stimmt es dass man Oracle auch direkt auf Partitonen
> ohne FS betreiben kann

Soweit mir bekannt ist, ist das die bevorzugte Methode.

Bitte 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
Noch kein Account? Hier anmelden.