4. SQLite plattgemacht ;-)

SQLite plattgemacht ;-)

  • Z

    Aggregierungen (z.B. count, sum) über alles in einer Tabelle sind eigentlich Beispiele, wo ein Index nichts bringt.

    Edit: Was mich noch interessieren würde: Wie groß ist das SQLLite-File?

    0

  • Also count(*) sollte eine Datenbank "so" können.

    Und bei sum() kann ein Index schon was bringen, nämlich wenn die Tabelle relativ breit ist und der Index relativ schmal, aber ausreicht um die Abfrage durchzuführen (=alle nötigen Spalten enthält).

    Wobei ich nicht weiss ob SQLite nen Index so verwenden kann (SQL Server kann es).

    0
  • ?

    sqlite ist einfach nicht webscale

    0
  • S

    Zebald schrieb:

    Wie groß ist das SQLLite-File?

    3,81 GB (4.101.040.128 Bytes) lt. "Eigenschaften" (Größe Auf Datenträger 3,81 GB (4.101.042.176 Bytes)). Der Windows-Explorer zeigt 4.004.922 KB.

    Also in dieser Gegend ...

    0
  • S

    brogram schrieb:

    sqlite ist einfach nicht webscale

    Was meinst Du damit ?

    0
  • V

    das sqLITE nicht fürs web gemacht ist, sondern für andere dinge

    0
  • S

    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 😉

    0

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

    0
  • S

    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 Wichtigeres

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

    0

  • Und Indexe etc. passt alles?

    0
  • S

    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.

    0
  • ?

    MongoDB

    0
  • S

    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 😉

    0
  • G

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

    0
  • S

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

    0
  • G

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

    0
  • S

    Klar. Wir sind aber eine kleine Firma mit 7 Leuten, das ist zu teuer 😉

    0

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

    0
  • M

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

    0
  • S

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

    0
Anmelden zum Antworten