SQLite plattgemacht ;-)
-
vario-500 schrieb:
das sqLITE nicht fürs web gemacht ist, sondern für andere dinge
Es funktioniert aber wirklich gut. Nur ab ca 5 Mio Records wird es etwas
langsam (muß ich noch mal genauer testen). SQLite habe ich im Live-Betrieb
laufen. Die Kunden sind zufrieden.Problematisch sind halt größere Datenmengen >100 GB / Jahr.
Der Kunde wo ich da probiert habe, wird pro Jahr >200 Mio Records haben.
Es war halt mal ein Versuch. Im Moment habe ich da eine selbsgebaute DB
laufen.Ich habe das mit Kollegen besprochen - alle meinten dafür braucht's einen
Oracle-Cluster
-
Scheppertreiber schrieb:
vario-500 schrieb:
das sqLITE nicht fürs web gemacht ist, sondern für andere dinge
Es funktioniert aber wirklich gut. Nur ab ca 5 Mio Records wird es etwas
langsam (muß ich noch mal genauer testen).Könnte das vielleicht genau die Grenze sein wo der File-Cache nimmer ausreicht um die relevanten Teile der DB vorrätig zu halten?
Problematisch sind halt größere Datenmengen >100 GB / Jahr.
Problematisch sind Abfragen die zu viele IOs brauchen um ausgeführt zu werden, ganz egal wie man zu diesen IOs kommt.
Und genau da schraubt man dann auch: entweder man kauft sich mehr IOs/Sekunde, oder man guckt dass man weniger IOs/Sekunde braucht.
Dafür braucht es dann oft ne schlauere Datenbank als SQLite, oder man muss es zu Fuss programmieren.Aber zurück zum Thema SQLite: welche Einstellungen verwendest du?
-
Aber zurück zum Thema SQLite: welche Einstellungen verwendest du?
Ich habe es ma bei den Standardeinstellungen belassen.
Die Applikation archiviert und stellt die Zettel über das Web zur Verfügung.
Mit dem üblichen Rattenschwanz an Zugriffsrechten die man kaum noch über DBs
abbilden kann, vielen kundenspezifischen Gimmicks und Zertifikaten.Verarbeitet werden Streamdaten (Text, XML *bäh*) und PDF/TIFF. Zur Ausgabe werden
die PDF entweder ausgeliefert oder on-the-fly erzeugt. Die Dokumente kann
der Kunde auch auf eine CD/DVD mit Abfrageprogramm bekommen (uA der Grund
für SQLite - ich kann es für alles nehmen).Bei einem großen Kunden sind das knapp 500 GB pro Jahr.
Bei kleineren Kunden hat sich SQLite prima bewährt. Flexibel (halt SQL) und
einfach anwendbar, es sind dadurch noch einige WorkFlow-Anwendungen dazu
gekommen.Vorteile SQLite:
* keine Installation oder Pflege notwendig
* alle Platformen
* die beiden Admins die sich um die Systeme kümmern haben Zeit für WichtigeresProblematisch ist, ich muß irgendwo eine Grenze ziehen die sich durch eine
erträgliche Performance SQLite ergibt. Da versuche ich mich heranzutasten.Mit SQLite3.exe kann ich mein 3-Mio-Records-Monster abfragen, es dauert aber ...
Die Sache mit dem Cache müsste man mal genauer beobachten. Ich habe ja immer
noch im Hinterkopf, alles auf Linux umzuheben (in C ja machbar) und mich um
Caching nicht gekümmert. Im Moment laufen die Server und XP prof.Compiler: Watcom C, nix PHP oder so.
-
Und Indexe etc. passt alles?
-
hustbaer schrieb:
Und Indexe etc. passt alles?
Weitestgehend
Wie es so schön heißt: Immer Platz für Optimierungen ...
Im Moment lese ich mal in mein System 40 GB Daten ein und vergleiche das mal.
-
MongoDB
-
Soderle, schlaffe 36 GB Daten sind importiert (in meine Eigenkonstruktion).
Es paßt nicht alles auf meinen Server, also nur 1 Monat. Die Suchzeiten sind
dramatisch kleiner (ich habe ja auch alles rausgeworfen was nicht unbdedingt
notwendig ist).Quelle: XML-Daten mit assoziierten PDF, insgesamt 9.615.069 Datensätze /
PDF. Ist 2 Tage gelaufen. Suchzeiten incl. Ausgabe als HTML/CSV, Excel in
1 sec bei 100 Treffern. Wäre nicht die Zeit um das über den Webserver zu
jagen wäre ich noch mehr zufrieden
-
Hallo, mal dumm gefragt, wäre es aber bei der Menge an Daten nicht eventuell eine Überlegung wert auf andere DB's zurück zu greifen z. B. PostgreSQL, MySQL, etc...?
-
guenni81 schrieb:
Hallo, mal dumm gefragt, wäre es aber bei der Menge an Daten nicht eventuell eine Überlegung wert auf andere DB's zurück zu greifen z. B. PostgreSQL, MySQL, etc...?
Mir wurde berichtet, ein Oracle-Cluster hätte da auch dran zu kauen ...
-
Scheppertreiber schrieb:
Mir wurde berichtet, ein Oracle-Cluster hätte da auch dran zu kauen ...
Ich behaupte mal das kommt wohl auch auf die größe des Clusters an.
-
Klar. Wir sind aber eine kleine Firma mit 7 Leuten, das ist zu teuer
-
Ich würde sagen das kommt auch noch auf einen Haufen anderer Faktoren an.
Der Schluss "XXX GB Daten/Jahr => brauchst du Oracle Cluster" ist vollkommener Quatsch.
Je nachdem wie die Abfragen aussehen die man auf diese Daten macht kann das ein einzelner MS SQL/Oracle Server oder auch eine "kleine" Datenbank-Engine ala SQLite locker packen.
Bzw. auch einen dicken Cluster überfordern - nur durch den Cluster werden die Disks ja z.B. nicht schneller. (Und mehr bzw. schnellere Disks kann man auch schön an einen einzelnen Server anbinden. Bis zu dem Punkt wo es auf Grund von anderen Engstellen nimmer schneller wird - aber bis der erreicht ist hat man einiges an Geld verbraten.)
-
hustbaer schrieb:
Ich würde sagen das kommt auch noch auf einen Haufen anderer Faktoren an.
Der Schluss "XXX GB Daten/Jahr => brauchst du Oracle Cluster" ist vollkommener Quatsch.
Je nachdem wie die Abfragen aussehen die man auf diese Daten macht kann das ein einzelner MS SQL/Oracle Server oder auch eine "kleine" Datenbank-Engine ala SQLite locker packen.
Bzw. auch einen dicken Cluster überfordern - nur durch den Cluster werden die Disks ja z.B. nicht schneller. (Und mehr bzw. schnellere Disks kann man auch schön an einen einzelnen Server anbinden. Bis zu dem Punkt wo es auf Grund von anderen Engstellen nimmer schneller wird - aber bis der erreicht ist hat man einiges an Geld verbraten.)Da bin ich komplett deiner Meinung, habe aktuell auch mit einen Kunden zu tun, bei den laufen ca. 100 GB an Daten im Jahr auf und dort läuft ein MS SQL Server. Dort habe ich auch schon einiges an Optimierung rein gesetzt und das meiste ging bis jetzt in dem die Konstrukte umgestrikt wurden um die Daten passend zu selektieren oder eben die Indexe zu treffen :-).
-
Der Schluss "XXX GB Daten/Jahr => brauchst du Oracle Cluster" ist vollkommener Quatsch.
Klar. Es ging mir um die Anzahl Records, die Datenmenge selbst ist unkritisch
(es sind Druckdaten in XML zusammen mit einem PDF das im Idealfall das gleiche
anzeigt). Aus den einzelnen Positionen des Lieferscheins wird die fragliche
Datenbank aufgebaut. Der Kunde kann die Daten dann übers Web abfragen (klar,
Flaschenhals Web).Die einzelnen Suchbegriffe haben immer konstante Längen in Byte. eigentlich
müßte da ein DBMS wie zB Btrieve oder DBASE erheblich schneller wie eins mit
flexiblen Satzlängen sein. dBASE ist tot und Btrieve heute zu teuer (die
spinnen mit ihren Preisen).Ich habe für den Import und die Bereitstellung ein Zeitfenster von ca 2h.
Dann noch heftige Probleme, große Einzeldateien täglich zu sichern ...Die Daten selbst (PDF, XML) lege ich in Tagescontainern ab, die relevanten
Suchbegriffe in einer Datenbank (also keine Blobs die mir alles noch mehr
aufblähen würden). Dazu die Tabellen mit den Suchbegriffen, jeweils mit einem
Pointer auf die Tagescontainer. Sortiert sind diese Tabellen nach dem
jeweiligen Schbegriff, mit ein paar vergleichen habe ich den ersten Treffer
(reine Lehre wäre natürlich ein Binärbaum, dauert aber zu lange, den zu
erstellen. Ausßerdem sind es max 20 Vergleiche bis ich den ersten am
Wickel habe. So steckt der "binary tree" in der Suche).Das System ist seit mehreren Jahren im produktiven Einsatz - es gibt aber
immer Luft nach oben und SQLite ist eine geile Sache !Auf M$ will ich mich nicht festlegen.
Grüße Joe (Sch..erkältung. Gerade mal den Dreck rausgeduscht und einen
Kaffee reingedröhnt, dazu 'ne Selbstgedrehte. Mopped steht vor der Tür,
vielleicht mal bald Brötchen holehn ).PS: Warum in C ?
Ei warum denn nicht. Die Junks aus dem XHTML-Forum haben beim Treffen auch mal
gesehen, daß CGI-Sachen auch mal richtig schnell laufen können ...
-
Scheppertreiber schrieb:
Der Schluss "XXX GB Daten/Jahr => brauchst du Oracle Cluster" ist vollkommener Quatsch.
Klar. Es ging mir um die Anzahl Records, die Datenmenge selbst ist unkritisch
(es sind Druckdaten in XML zusammen mit einem PDF das im Idealfall das gleiche
anzeigt). Aus den einzelnen Positionen des Lieferscheins wird die fragliche
Datenbank aufgebaut. Der Kunde kann die Daten dann übers Web abfragen (klar,
Flaschenhals Web).Ja, egal, auch die Anzahl der Records alleine ist nicht ausschlaggebend.
Wenn ich 100 Mio. Records in einer Tabelle habe, und über nen Index 100 davon raushole, dann geht das relativ fix. Mit jedem System, sei's nun MSSQL, Oracle oder SQLite.
Wenn der Herr Datenbank aus 100 Mio. Datensätzen dann 100.000 lesen muss, dann wird die Sache schon interessanter. Wenn es bei sowas nicht möglich ist die Daten physikalisch so abzulegen, dass er für die 100.000 Records nur z.B. 1000 Pages braucht, dann wird man LANGE warten - auch wieder egal mit welchem System.
Der grösste Unterschied zwischen SQLite und anderen Datenbanken ist da wohl, dass andere Datenbanken einem mehr Möglichkeiten geben die Daten physikalisch passend anzuordnen. (Stichwort Clustered Index)Die einzelnen Suchbegriffe haben immer konstante Längen in Byte. eigentlich
müßte da ein DBMS wie zB Btrieve oder DBASE erheblich schneller wie eins mit
flexiblen Satzlängen sein. dBASE ist tot und Btrieve heute zu teuer (die
spinnen mit ihren Preisen).Ich wüsste keinen Vorteil den DBMS' mit fixen Zeilengrössen hier haben sollten.
Die Daten selbst (PDF, XML) lege ich in Tagescontainern ab, die relevanten
Suchbegriffe in einer Datenbank (also keine Blobs die mir alles noch mehr
aufblähen würden). Dazu die Tabellen mit den Suchbegriffen, jeweils mit einem
Pointer auf die Tagescontainer. Sortiert sind diese Tabellen nach dem
jeweiligen Schbegriff, mit ein paar vergleichen habe ich den ersten Treffer
(reine Lehre wäre natürlich ein Binärbaum, dauert aber zu lange, den zu
erstellen. Ausßerdem sind es max 20 Vergleiche bis ich den ersten am
Wickel habe. So steckt der "binary tree" in der Suche).Macht ne Datenbank nicht wesentlich anders, nur dass hier B-Bäume zum Einsatz kommen - die den Vorteil haben dass man sie billiger updaten kann als sortierte Listen. Und gegenüber binären Bäumen den Vorteil haben dass sie "Disk-IO-freundlich" aufgebaut sind.
Wenn du die Tables als Clustered Index auf den Suchbegriff anlegst, dann wirst du sogar deutlich unter 20 IOs/Lookup kommen - ich würde eher mit <= 2 (physikalischen) IOs/Lookup rechnen.
Und selbst wenn es nur ein normaler Index ist, wird es sich im Bereich <=5 IOs/Lookup abspielen.----
Scheppertreiber schrieb:
Ich habe für den Import und die Bereitstellung ein Zeitfenster von ca 2h.
Dann noch heftige Probleme, große Einzeldateien täglich zu sichern ...Hast du...
..."PRAGMA journal_mode = OFF" und "PRAGMA synchronous = OFF" zum Aufbauen der Datenbank gesetzt (wenn während dem Aufbauen was passiert muss man halt von vorne anfangen - d.h. da kann man auf ACID gut verzichten)?
...die Daten alle ohne Indexe importiert und die Indexe erst danach aufgebaut?
...die Cache-Grösse mit PRAGMA cache_size hochgedreht?
-
Hast du...
Jepp.
Macht ne Datenbank nicht wesentlich anders, nur dass hier B-Bäume zum Einsatz kommen - die den Vorteil haben dass man sie billiger updaten kann als sortierte Listen. Und gegenüber binären Bäumen den Vorteil haben dass sie "Disk-IO-freundlich" aufgebaut sind.
Vorteil einer festen Satzlänge ist, ich kann die schneller lesen. Eine mit
variablen Satzlängen ist da aufwendiger (Länge Record => Record lesen => alle
Felder mit den Längen isolieren).Bei festen Satzlängen mache ich mir ein darauf passendes struct und lese den
Kram mit einem read() hinein - fertig.Der sonst (bei einer mit flexibler Satzlänge) notwendige physical index
ergibt sich einfach aus recno und sizeof( Struktur), muß also beim Einlesen
auch nicht gepflegt werden.Die Sache mit einem binary tree habe ich mir auch überlegt, Problem ist
nur: solange der nicht ausbalanciert ist bringt der wenig. Und das kann
dauern.Bei größeren Indextabellen (in der Gegend mehrerer GB) kann ich das nicht
mehr in einem Zug in den Speicher laden. Dann gehe ich mit meinem Suchbegriff
in die Mitte, ist er größer oder kleiner ? Dann in dieser Richtung weiter.
Auch recht flott. Sobald ich den ersten habe ist es nur noch satzweises
Weiterlesen - easy.SQLite ist ein EWS-System, meins speziell für diese Anwendung und da (und
auch nur da) natürlich wesentlich schneller ...Bei dem Dings was ich gerade baue komme ich auf max ~1 MB an Daten. Die
lese ich mit einem Zug in den Speicher und filtere dann im Speicher.
Halbwegs narrensicher (es kommen noch callbacks wegen Zugriffsrechten
dazu) und recht flott.Flaschenhals ist die Ausgabe über den Webserver bzw das http. Da muß ich
dann leider Kompromisse im HTML-Code machen um die klein zu halten.
JSON muß ich mir da noch mal ansehen. Wenn nur der IE6 nicht wäre
-
Sag ja zu NO-SQL
-
PRIEST schrieb:
Sag ja zu NO-SQL
SQL ist nicht das Maß der Dinge, klar ...
Halt universell anwendbar, ideal für BWLer
-
Scheppertreiber schrieb:
Macht ne Datenbank nicht wesentlich anders, nur dass hier B-Bäume zum Einsatz kommen - die den Vorteil haben dass man sie billiger updaten kann als sortierte Listen. Und gegenüber binären Bäumen den Vorteil haben dass sie "Disk-IO-freundlich" aufgebaut sind.
Vorteil einer festen Satzlänge ist, ich kann die schneller lesen. Eine mit
variablen Satzlängen ist da aufwendiger (Länge Record => Record lesen => alle
Felder mit den Längen isolieren).Bei festen Satzlängen mache ich mir ein darauf passendes struct und lese den
Kram mit einem read() hinein - fertig.Der Overhead die Zeilen zu "parsen" geht normalerweise komplett in den IO-Kosten unter. Daher ... kein Vorteil bei DBs die nicht komplett ins RAM passen.
Der sonst (bei einer mit flexibler Satzlänge) notwendige physical index
ergibt sich einfach aus recno und sizeof( Struktur), muß also beim Einlesen
auch nicht gepflegt werden.Das bringt dir nur was, wenn du die Record-Number bereits kennst.
Wenn du Zeilen anhand des Inhalts suchst, bringt es dir dagegen nix. Weil du sowohl mit fixer Datensatz-Länge als auch mit variabler Länge einen Index brauchst. Ob dort dann die Record-Number oder die Page-Number drinnen steht, ist ziemlich egal.Die Sache mit einem binary tree habe ich mir auch überlegt, Problem ist
nur: solange der nicht ausbalanciert ist bringt der wenig. Und das kann
dauern.Bei größeren Indextabellen (in der Gegend mehrerer GB) kann ich das nicht
mehr in einem Zug in den Speicher laden. Dann gehe ich mit meinem Suchbegriff
in die Mitte, ist er größer oder kleiner ? Dann in dieser Richtung weiter.
Auch recht flott. Sobald ich den ersten habe ist es nur noch satzweises
Weiterlesen - easy.Wenn du immer grosse Teile des Tables "am Stück" lesen musst, dann wird das Vorteile haben.
Wenn man immer nur einen oder ein paar Records braucht, und dann wieder wo anders hin springen muss, ist ein B-Baum (B-Tree != Binary Tree!) besser (schneller), weil man beim Lookup weniger IOs braucht als mit ner sortierten Liste.SQLite ist ein EWS-System, meins speziell für diese Anwendung und da (und auch nur da) natürlich wesentlich schneller ...
Bei dem Dings was ich gerade baue komme ich auf max ~1 MB an Daten. Die
lese ich mit einem Zug in den Speicher und filtere dann im Speicher.
Halbwegs narrensicher (es kommen noch callbacks wegen Zugriffsrechten
dazu) und recht flott.Ja, wenn du die Daten am Stück lesen kannst, dann bringt das natürlich enorme Vorteile. Eine "normale" Datenbank wird nie grosse Teile am Stück lesen können, sondern maximal eine Page. D.h. mit einer massgeschneiderten Lösung wirst du da immer schneller sein.
@PRIEST
Ich weiss nicht was eine "NO-SQL" Datenbank in diesem Fall für Vorteile haben sollte.
-
Das bringt dir nur was, wenn du die Record-Number bereits kennst.
Wenn du Zeilen anhand des Inhalts suchst, bringt es dir dagegen nix. Weil du sowohl mit fixer Datensatz-Länge als auch mit variabler Länge einen Index brauchst. Ob dort dann die Record-Number oder die Page-Number drinnen steht, ist ziemlich egal.Nein. Ein "echtes" DBMS lädt eine Seite, sucht darin den Record und muß
dann die einzelnen Felder suche und die Werte irgendwie laden (egal wie
es den Record findet). Das dauert naturgemäß länger wie ein einzelnes
lseek() mit nachfolgendem read() in eine Struktur wo die Felder ja bereits
"fest" enthalten sind.In dieser struktur ist auch der Zeiger auf den Container mit dem PDF.
Der Vorgang anhand einer Satznummer ist bei der Tabelle trivial, das DBMS
muß sich durch den physical Index durchhangeln und die Recordnummer dort
erstmal finden. Klar dauert das ...Die Suche nach dem Inhalt eines Feldes ist bei der Tabelle recht einfach.
Die Tabelle sei nach A sortiert. Verfahren: Gehe in die Mitte (recmax /2)
und vergleiche. Kleiner ? Ja -> in die Mitte der oberen Hälfte, nein->
nach vorne. etcpp. Mit memcmp() direkt das Feld gegen den Suchbegriff testen
ist trivial und schnell.Die Suche im Index eines DBMS funktioniert im Prinzip genauso, nur müssen
komplette Pages geladen und deren Inhalt auseinandergebastelt werden. Die
Laufzeit und den tree zu erstellen mal außen vor gelassen.Der Laufzeitunterschied ist heftig, schätze mal Faktor 100 bis 1000 (hab's
noch nicht genau gemessen).
