Einige fragen zu DAOS und komprimierung

[Ebil]

Hallo erstmal

Ich überlege die einführung von DAOS zu meinem Abschlussprojekt als Fachinformatiker / Systemintegration zu machen.
Zusätzlich wollte ich die LZ1 Kompression und Design / Document Kompression gleich miteinführen (ist hier alles nicht aktiv).

Ein paar fragen plagen mich , auf die ich auch mithilfe von google keine antwort fand, ein wenig hilfe wäre nett.

- Gibt es irgendwelche performance tests über: DAOS , LZ1 (im vergleich zu Huffman) und Document  / Design Kompression?
- Was genau fallen so für schwierigkeiten bei DAOS an, über einen längeren Zeitraum gesehen? Ich les immer nur das es ein mega feature ist, aber nicht wo die nachteile liegen, also wo liegt der Administrationsaufwand?
- Wie verhält es sich mit der dekompression der daten von LZ1 / Document und Design kompression? Geschieht dies auf dem client? Auf dem Server? Wie ist es wenn ein Server wo die Kompressionen aktiv sind daten an eine Replik ohne kompression schickt? Wird es von dem Server dekomprimiert von dem es geschickt wird, oder muss der empfangende es dekomprimieren?

Testweise habe ich DAOS und LZ1 mal auf einem unserer kleineren Server aktiviert, bis jetzt kamen noch keine Tickets mit problemen rein und so sieht auch alles recht gut aus.

Hoffe jemand kann mir ein wenig helfen, vllt auch mit TechNotes von IBM direkt (man kann ja auch mal falsch suchen ^^).

LG Ebil

[eknori]

Also eines vorweg: DAOS ist  mega feature; aber das wusstest du ja schon.

Probleme wirklich apokalyptischen Ausmaßes habe ich bei meinen DAOS Projekten noch keine gesehen.

Früher war ich auch der Meinung, daß man peinlich genau darauf auchten sollte, daß wirklich ALLE Files mit einem einheitlichen Komprimierungsalgorithus versehen sein sollten, um nicht doch doppelte NLO files zu erhalten. heute halte ich den administrativen Aufwand für zu gross, als daß man um der Einsparung won ein paar hundert MB wegen einen solchen Aufwand betreiben sollte.

Kleines Beispiel: Setzt man iNotes ( Webmail ), dann werden die über das Web hochgeladenen Attachments überhaupt nicht komprimiert. Ein über den Client hochgeladenes, bitidentisches Attachment wird mit der gewählten Methode komprimiert. Resultat: 2 NLO files, weil die Attachments nach dem Hochladen in die Datenbank aufgrund unterschiedlicher Komprimierung nicht bitidentisch sind.

Man kann jetzt bei IBM einen PMR aufmachen und um Behebung des Problems bitten; die 20 Jahre habe ich aber nicht mehr ...

Alternativ kann man Programmdockumete erstellen, die eine Re-Komprimierung über den Datenbankbestand automatisiert durchführt. Das macht was her für die Serverdokumentation; die Duplikate reduzieren sich ( dummerweise kommen aber immer auch neue Duplikate hinzu ) Ist also ein kreislauf. Die Methode mag das gewissen beruhigen; man hat was unternommen; das eigentliche Problem löst es nicht.

Aus meiner Sicht kann man auf solchen sinnlosen Aktionismus gerne verzichten.

Zum Thema performance kann ich nbur sagen, daß das Compact/ Fixup einer kleinen Datenbank immer schneller ist, als die Aktion auf einer mit Attachments gefüllten Datenbank auszuführen. Irgendwo gab es auch ein WhitePaper der IBM zu dem Thema. Muss ich sehen, ob ich das finde.

DAOS ist ein Serverfeature; also müssen die daten bei der replikation auf den Client von diesem wieder dekomprimiert werden; heißt, das Attachment muss aus den DAOS Store gelesen werden und an das Dokument angehöängt werden.

DAOS kann auch daten mit Servern austauschen, die nicht DAOS enbled sind. Dafür gibt es mitlerweile ganz gute Algorithmen. Auch die replizierung von DAOS zu DAOS ist optimiert worden. Es werden nur die Daten ( Attachments ) übertragen, die nicht schon am Zielserver vorhanden sind.

Das kann man sicherlich noch lange drüber reden. Mache ich auch ab und an auf Konferenzen ...

Nehme an, hier werden gleich noch ein paar mehr Kommentare auftauchen .

[Ebil]

Danke für deine ausführliche Antwort.

Ja DAOS sieht wirklich gut aus, deswegen konnte ich die Kollegen auch überzeugen das ich es auf einem unserer kleineren Live server testen darf 

iNotes nutzen wir nicht, von daher ist das vernachlässigbar.

Was mich wundert ist, das wir auf unseren Servern teilweise unkomprimierte, teilweise Huffman und teilweise LZ1 dateien haben. Da versuch ich in 2 Wochen mich auch mal dran zu machen (erstmal Urlaub  ).

Von welcher Serverversion reden wir hier wenn du sagst das DAOS sogar bei der Replizierung darauf achtet das nicht Dateien übertragen werden die schon bei dem anderen Server vorhanden sind (find ich wahnsinn, wir nutzen 8.5.2 auf den meisten Servern)

Mir ging es eher um die Performance bei User zugriffen was die Kompression angeht.
Ein Beispiel, unsere größten Datenbanken sind 30GB Groß, eine mit 700000 die anderen mit 350000 Dokumenten (meist haben die User nur lokale Repliken). Nicht das die Kompression da das öffnen unnötig verlängert (solange es nicht zu viel ist, ist es ja ok).

Wie sieht es mit der Document und Design Kompression aus? Wird das auch auf dem Client dekomprimiert?

LG Ebil

[stoeps]

Hi,

meiner Meinung nach kannst du die CPU Zeit für die Dekompression vernachlässigen, da die geringere Größe bei der Übertragung das wettmacht. Es werden ja nur einzelne Anhänge dekomprimiert und nicht alle.

Die Designer Hilfe der Version 7 behauptet folgendes:
Because LZ1 compression can be performed quickly and efficiently, it is favored over the Huffman method.

Der "Flaschenhals" bzw. der begrenzende Faktor bei der Performance von Domino ist meist der Zugriff auf die Festplatte, bzw. allgemein I/O. Von daher bringt eine Verringerung des I/O (DAOS, Kompression) einen deutlichen Performance Schub.
Bitte v.a. bei der Aktivierung von Transaction Logging auf einen eigenen I/O Kanal achten, um I/O nicht zu verschlechtern.