[Allegro] war: import.exe und sehr große dateien (2GB-grenze) -> nachbeobachtungen -> kein qrix-problem, es ist nur MULTIX

[Thomas Berger]

Hallo Herr Lehmann,

> 2b. die konsequenz dessen, was da unten geschildert wird
> zitat: 
>> Fazit: Versucht man fuer *32bit-Plattformen* die 2GB-Grenze zu umschiffen,
>> muss man recht viel im Code aendern, staerker die unterschiedlichen Welten
> , ist: mit echten 64bit-tools zu arbeiten, wenn man gewisse grenzen 
> überschreitet oder schreiten muss. 
> ein qrix.exe, welches nach unten kompatibel bleiben will, so umzubauen, daß es beiden welten 
> (=lesbar/erzeugbarkeit von größer als 2GB-dateien), geht nicht. 
> ein qrix.exe, welches nur in der 64bit-welt lebt, sei einfach zu bauen.
> das hiesse, ein gespann index/qrix.exe für 64bit muß her. habe ich das 
> richtig verstanden? allegro ist auf dem weg ins 64bit-wunderland! ;-)

Meine Aeusserungen waren eher abstrakt gemeint bzw. auch
vor dem Hintergrund des Problems bei Import.exe

Etwas konkreter ist es so: Es ist zwar bereits einmal eine Umstellung
erfolgt, naemlich von 16bit auf 32bit, diese aber nicht unbedingt
aktuell mit srch32.exe etc., sondern vor allem bei der Entwicklung
der Klassenbibliothek ab 1997(?), und damit war auch der Umstieg
von C auf C++ als Programmierplattform verbunden. Es ist extrem
unwahrscheinlich, dass die derzeitigen C- und C++-Programme sich
durch einfaches Umlegen eines Schalters sauber fuer 64bit-Plattformen
compilieren lassen. Es ist aber durchaus /moeglich/, dass eine
Umstellung auf 64bit dennoch einfacher sein wird als die Umarbeitung in
Richtung 32bit plus Support fuer grosse Dateien. Oder dass eine
Umstellung auf 64bit-Faehigkeit den Code insgesamt so saeubert, dass
die Erweiterung unter 32bit deutlich einfacher wird. Und letztlich
ist durch 32bit erweitert die irgendwann faellige Umstellung auf
64bit ja nicht unbedingt abgewendet...

Geht es um konkrete Datenbanken, ist nicht nur die Kompatibilitaet
bzw. Umschaltbarkeit der Sourcen oder der Binaries Thema, sondern
auch die der realen Datenbanken (.CLD-Dateien und Indices):
- Indexdateien > 2GB sind definitiv das Aus fuer PRESTO etc.,
  aber "DOS ist tot" wurde etwa 1995 bereits angekuendigt, ist
  unter Windows 7 x86_64 oder Server 2008 R2 Tatsache geworden,
  da braucht nun allegro m.E. nicht mehr viel Ruecksicht zu
  nehmen.

- Wenn aber keine 16bit-Programme mehr auf den Index etc. zugreifen,
  dann kann man auch daran denken, an den internen Strukturen diverse
  Optimierungen (v.a. Alignierungen) vorzunehmen, von denen die Performance
  von 32- und 64bit-Programmen deutlich profitieren duerfte: Also z.B.
  "vorne" in der .TBL-Datei noch zwei oder 6 Leerbytes spendieren, damit
  dann alle Adressen der Satznummern auf durch 4 oder sogar 8 teilbaren
  Dateioffsets wohnen. Desgleichen fuer die Daten in den .cLD-Dateien,
  ungefaehr entsprechend einem Faktor 4 oder 8 fuer die 1999 fuer
  "spaete" v16's erfolgten "Aufbohrung".

- Das bedeutet aber, dass man eine "alte" Datenbank erst reorganisieren
  muss, bevor man mit "neuen" Programmen damit arbeiten kann (und
  umgekehrt, also zurueck von neu zu alt, geht es evtl. gar nicht).
  Anderswo ist das normal (inkompatible Aenderungen sind "major releases"
  vorbehalten und umgekehrt ist eigentlich bei jedem "major release"
  mit Umsetzungen oder Rekonfiguration zu rechnen), allegro jedoch
  tickt normalerweise anders...

- Solange es noch 32bit-Plattformen gibt, sollte man natuerlich darauf
  achten, dass Datenbanken zu einer Version binaerkompatibel sind,
  egal ob sie mit 32- oder 64-bit-Modulen erzeugt wurden.

- Die .STL-Datei hat - beim Wert i0=72 aus cat.api - ein 2GB-Problem,
  das bei knapp 30 Millionen Datensaetzen zuschlagen wird. Konzeptionell
  muss sie aber ohnehin irgendwann einmal hinterfragt werden, in
  Web-Kontexten ist sie fuer die Anzeige normalerweise schon laengst
  irrelevant, und ihre Nuetzlichkeit beim Sortieren ist traditionell
  leider recht unterentwickelt.

- Derzeit, mit Aufbohrung, ist das Verhaeltnis ansonsten recht ausgewogen:
  Der maximale Aufbohrfaktor ist 124, damit kann man 255 .cLD-Dateien
  beschicken, die jeweils etwa 1,85GB gross sind, insgesamt also
  eine Datenbankgroesse von ca. 470GB, die - bei "kleinen" Datensatz
  laengen von weniger als 119 Bytes, dem theoretischen Maximum von
  4,29 Milliarden adressierbaren Datensaetzen recht nahe kommt.
  Demgegenueber steht, dass man mit der Multix-Methode maximal 36
  je 2 GB grosse Einzelindex-Dateien fahren kann (72GB Index fuer 470GB
  Datenbank ist wenig, das wuerde ich bereits fur eine 47GB grosse
  Datenbank erwarten), und auch jedes logische Register fuer sich nur
  <2GB Umfang haben darf: Indexiert man fuer ein Uebernahmeregister
  Koerperschaftsansetzungen und -verweise in voller Laenge (bei maximaler
  Indexbreite von 250 Zeichen), dann bekommt man u.U. schon bei 8 bis 10
  Millionen /Eintragungen/ Probleme, also einer deutlich geringeren Zahl
  von Datensaetzen.

  Ich denke, insgesamt effizientere Indexierung (und nicht nur Dateien
  >2GB) wird irgendwann auch Thema fuer allegro werden und fuer den
  dann zu erwartenden Kompatiblitaetsbruch kann man auch Optimierungen
  in der allgemeinen Datenhaltung in Bezug auf hoeherbittige Plattformen,
  evtl. sogar interne Speicherung in Unicode etc. vorsehen.

viele Gruesse
Thomas Berger