Re: Filesysteme / Datenbank

In <C1256664.00323709.00(at)notes.labcontrol.com>, Marc_van_Woerkom(at)notes.labcontrol.com wrote:
>
>
>
>
>
> Marc van Woerkom
> 18.08.98 11.35

Und wieder ein Notes-client. Will ja nicht meckern, aber eine
Software, die eine halbe Bildschirmseit bis zum Beginn des Textes
verbraet und das nicht nur aus Versehen, sondern weil sie's fuer gut
haelt, bestimmte Headerinformationen hervorzuheben, finde ich nervig.

Anyway...
 
> Ich habe es derzeit mit einer Anwendung zu tun, in der viele (ca. 10.000
> bis 1.000.000) kleine Dateien unterschiedlcher Groesse (ca. 1 kb bis
> 10 kb) verwaltet werden muessen.
> Weiter muss man diese Dateien moeglicht schnell sequentiell einlesen
> koennen (Reihenfolge egal, es muessen aber *alle* gelesen werden).

Ich sehe drei Ansaetze:

1) Wie haeufig kommen neue Files dazu? Wenn sich an der Datenbasis nur
sehr selten was aendert und das Performancekritische nur das einlesen
ist, koenntest Du doch mit einem regulaeren UFS mit option noatime
auskommen. Vorausgesetzt, Du hast ein schnelles OS.

2) Wenn sich auch haeufig was aendert, dann brauchst Du ein eigenes
Filesystem, ggf. auch lokal nur innerhalb der Applikation
implementiert.

Wenn Du ein normales Filesystem benutzt, hast Du zuviel Overhead mit
synchronen Metadata oder Du bist zu unsicher dran mit asynchronen
Metadaten. Mit einem eigenen Filesystem hast Du unter Kontrolle, was
wann gesynct wird.

Die Implementation eines solchen Filesystem duerfte auch in diesem
Fall nicht so schwer werden, wenn meine Vermutung richtig ist, dass
Files nur hinzukommen und geloescht werden, die Files aber nie Ihre
Groesse aendern bzw. sowieso niemals geaendert werdem. Letzteres ist,
was "echte" Filesystem so kompliziert macht.

Dieses Filesystem kannst Du dann auf einem regulaeren File in einem
UFS-Filesystem aufsetzen, dann hast Du immer noch den Vorteil, das
Ding als ganzes bequem wachsen, schrinken und sichern zu koennen und
Du hast den normalen Buffer-Cache mit readahead des Betriebssystems
zur Verfuegung.

3) Mir scheint das Kernproblem zu sein, dass die Applikation, die eure
Abfragen macht, etwas zu straightforward implementiert ist und bei
jeder Abfrage erwartet, alle Files neu einzulesen.

Oder anders gesagt: bei jeder Abfrage so viele Files neu einzulesen
muss normalerweise verhindert werden, indem man die Applikation so
implementiert, dass sie nach dem reboot der Maschine einmal alles
einliesst und im VM hat und das Filesystem nur fuer Aenderungen
anfasst (die von diesem Programm oder einem externen gemacht werden
koennen).

Da Ihr dies nicht tut, deutet es darauf hin, das Ihr Wert darauf legt,
euer Abfrageprogramm neu starten zu koennen, z.B. weil sich oefter mal
was am Binary aendert oder andere Gruende habt, wieso nicht ein
permanent laufender Prozess die ganze Sache implementieren kann.

Dieses neu gestartete Programm fragt ein anderes Programm, ihm doch
bitte die Daten zu geben. Dieses andere Programm ist zumindest so
schlau, die Daten zu cachen, egal ob es nun ein Filesystem (also der
Betriebsystemkern) oder ein SQL-Server ist, wobei der SQL sicherlich
cleverer cachet, aber mehr CPU-Overhead hat.

Der Knackpunkt an eurer Situation offenbart sich meiner Meinung nach
daran, dass das, was Ihr von diesen Fileserver verlangt, ganz platt
ist, *alle* File rueberzujagen.

Der Ansatzpunkt fuer eine Verbesserung ist hier, dass der Fileserver
nicht nur einfach file als "black-box" durchreicht, sondern einen Teil
der Funktionalitaet des Abfrageprograms uebernimmt. So dass der
Fileserver eben nicht mehr alle Files zum Abfrageprogramm rueberjagt,
sondern schon eine Optimierung vornehmen kann, z.B. ungewuenschte
Files ausfiltern oder nur relevante Teile von Files sendern.

Der Trick ist nun, im Abfrageprogramm Funktionalitaet zu
identifizieren, die Ihr in das permanent laufende Programm verlagern
koennt, ohne dass eure Flexibilitaet beim Anpassen des restlichen
Abfrageprogramms eingeschraenkt wird.

Wenn ich mich nicht sehr irre, dann scheitert das derzeit bei euch
daran, dass der SQL-Server nicht in der lage ist, *irgendwelche*
Operationen auf den kleinen FIles effizient durchzufuehren (z.B. Text
in diesen Files bearbeiten oder Bilder auswerten).

Dann ist die Loesung klar: Ich braucht einen Server, der permanent
laeuft und alle Files halten kann und der so implementiert ist, dass
er bisher bei euch im Abfrageprogramm implementierte Funktionalitaet
effizient durchfuehren kann. Zu deutsch: Er muss C-Code sehr effizient
ueber alles Files hecheln koennen.

Es ist nicht unmoeglich, dass das mit einem SQL-Server geht, wenn man
C-Code einbinden kann. Ich glaube aber, dass trotzdem ein gewaltiger
Ovberhead da ist. Eure Datenmenge duerfte sich am oberen Rand der
VM-Addressierbarkeit eures Betriebsystems befinden oder sogar
darueber. Dann muss gewaltig hin- und hergeschaufelt werden. Wenn der
VM-Space reichen wuerde, wuerde nur normales paging stattfinden, was
in modernen Unixen zmundesit ohne groesse Kopiererei im RAM abgehen
sollte. Ein Mechanismus, Datenmengen > VM-Space zu verwalten, geht
sicherlich auch noch enorm auf die Speicherbandbreite. Hm na gut, ich
komm in's spekulieren.

Wenn Ihr nicht den SQL-Server benutzen wollt, aber auf der anderen
Seite nicht die Programmierkapazitaeten habt, sowas komplett selbst zu
entwickeln, dann kaeme als Kompromiss in Frage, eine
persistence-Library zu nehmen. Etwa eine der objectorientierten
Datenbanken fuer C++, die nicht beabsichtigen, eine Abfragesprache zu
implementieren, sondern die einer anderen "normalen"
Programmiersprache wie C++ persistence zu geben. Aber Vorsicht, diese
Datenbanken sind zwar sicherlich schnell in dem Sinne, dass man leicht
mit C++-Code in den "Records" rumwuehlen kann, aber es stellt sich die
Frage, ob die Datenzugriffsmechanismen insgesamt so getunt sind wie
bei einem der grossen SQL-Server. Das kann nach hinten losgehen.

> Derzeit setzt diese Anwendung auf einer relationalen Datenbank (Sybase)
> auf und bereitet Probleme, da sie auf der verfuegbaren Hardware schlicht
> zu langsam ist.

Wie gross sind eure Daten insgesamt jetzt und in absehbarer Zeit und
ist das ggf. Hardware, die mehr als 2 GB VM addressieren kann?
 
> Gut, die Datenbank ist multi-user faehig und verfuegt ueber Mechanismen,
> die gegen Datenverluste schuetzen - sie wird aber im wesentlichen nur als
> indizierte Datenbank genutzt, die relationalen Eigenschaften werden IMHO
> nicht genutzt. Eine Blackbox, die sich schwer optimieren laesst.
>
> Daher meine naive Frage - wieso nicht ein Unix Filesystem einsetzen?
> Dazu wuerden mich Eure Kommentare sehr interessieren.
>
> - Hat jemand von Euch vielleicht Erfahrungen mit sehr vielen Dateien
> unter ufs gemacht?

Wie gesagt, das ist meiner Meinung nach nur dann schnell, wenn sich
an der Datenbasis selten was aendert.

> - Wo bekomme ich Informationen zum Aufbau und Tuning?
>
> - Gibt es alternative Filesysteme oder einfachere flotte Datenbanken,
> die Ihr empfehlen koenntet?

Also zu Filesystem faellt mir ein, dass man bei vielen kommerziellen
Unix-Systemen den metadatenoverhead druecken kann, wenn man
batteriegepuffertes RAM fuer den buffer cache einsetzt. Ich bin da mit
Produkten nicht ganz auf dem laufenden, aber schon zu SunOS-4- Zeiten
konnte man mit diesen NFS-Server-Beschelunigern auch fuer lokale
Zugriffe genau das machen.

Bei Datenbank faellt mir Empress ein. Die haben drei C-Apis, die auf
verschiedenen Abstraktionsebenen aufsetzen. Die untereste Ebene stellt
gar keine Abfragesprache mehr bereit, sondern praktisch nur noch eine
C-Library zum direkten Zugriff auf eine Ansammlung von records, die
aber im Gegensatz zu Files in einem Filesystem anpassbaren
Lookup-Mechanismen unterliegen.

> - Wie sind eigentlich die grossen Suchmaschinen im WWW realisiert,
> bauen die alle auf relationalen Datenbanken wie Sybase, Oracle
> oder DB/2 auf?

Bei Dejanews ist soweit ich weiss (offizielle Informationen sind
leider spaerlich) ein Linux-Kernel im Einsatz, in den genau solche
Suchfunktionen unterstuetzenden Teile in den Kernel hinein verlagert
worden sind, um z.B. den ganzen Cache context-sensitiv zu machen und
nochmal Systemcall-Overhead gegenueber einem Userlevel-Abfrageserver
zu sparen. Zumindest zum halten der Artikel selbst, ueber die Art der
Verwaltung der Schluesselwoerter ist mir nichts bekannt.

Martin

-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer
  cracauer(at)wavehh.hanse.de (batched, preferred for large mails)
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536
  Paper: (private) Waldstrasse 200, 22846 Norderstedt, Germany