Grundlegende Frage zu Replikation

[gschmid]

Hallo zusammen,

ich beschäftige mich zum ersten mal seit einigen Jahren wieder mit Notes und Domino, deshalb schon mal im voraus sorry, falls Euch die eine oder andere Frage in nächster Zeit etwas dämlich vorkommt... 

Wie auch immer, ich grübel gerade über das Thema Replikation. Mir ist klar, wie es funktioniert und warum es gemacht wird. Allerdings drängt sich mir der Eindruck auf, dass (zumindest mancherorts, wie z. B. bei meinem aktuellen Kunden) mehr als nötig repliziert wird.
Konkret: wenn ich eine Notes-Datenbank habe, die nur innerhalb einer Firma benutzt wird, Offline-Arbeiten also keine Rolle dabei spielt, wozu sollte ich diese DB dann auf die Clients replizieren, anstatt sie immer auf dem Server zu verwenden?

Wie sind denn da so die gängigen Praktiken, was sagen die erfahrenen Admins?
Ich wäre für ein wenig Erhellung sehr dankbar.

Gruß
Gunnar

[m3]

Lokal gehts schneller, das Arbeiten.
Und wenn der Server oder das Netzwerk mal abschmiert, merkt man es kaum.
Und man muss nicht so bald einen neuen Server kaufen, da die Last am Server gering bleibt.

[WernerMo]

Das ist mir nicht präzise genug:
Wann ist lokal schneller als Server? bei kleinen Datenbanken mit wenigen einfachen Ansichten?

Ich würde folgende für und wider nennen,

Für ZENTRALEN Server:

• Ansichten und Indexe werden schneller aufgebaut
• Resourcen schonender, da dieser Aufbau nur einmal pro Server nicht einmal pro User
• Weniger Wahrscheinlichkeit für Speicher und Replizierkonflikte
• Mehr Datensicherheit
• mehr Zugriffsschutz
• und und und...

Für dezentrale lokale Repliken:

• "Aussendienstmitarbeiter"

Von der Administration mal ganz zu schweigen.

[MartinG]

Bei uns wird keine Datenbank lokal repliziert, ausser der MA muss die DB zwingend offline verfügbar haben (sprich klassischer Aussendienstler)...

Mit lokalen Repliken schafft man sich IMHO nur unnötige Fehlerquellen...

[gschmid]

Danke für die Antworten, das bestätigt doch meine eigene Einschätzung.

Ich will die Diskussion damit aber nicht unbedingt beenden, weitere Aspekte sind sehr willkommen!

[m3]

Das ist mir nicht präzise genug:
Wann ist lokal schneller als Server? bei kleinen Datenbanken mit wenigen einfachen Ansichten?

Ich würde folgende für und wider nennen,

Für ZENTRALEN Server:

• Ansichten und Indexe werden schneller aufgebaut
• Resourcen schonender, da dieser Aufbau nur einmal pro Server nicht einmal pro User
• Weniger Wahrscheinlichkeit für Speicher und Replizierkonflikte
• Mehr Datensicherheit
• mehr Zugriffsschutz
• und und und...

Also wenn ein Server unter Last steht, sind die Views am Client schneller aufgebaut.
"Ressourcen schonender" ist mir aber relativ wurscht, wenn ich das aus der Serversicht betrachte. Ob sich nun ein oder 200 Clients den View neu aufbauen, ist mir als Server bei einer lokalen Replik relativ wurscht, das betrifft meine Ressourcen nicht.
Zig Clients, die auf mir als Server arbeiten erzeugen hingegen sehrwohl mehr Last, also wäre aus dieser Sichtweise die lokale Replik ressourcenschonender.

Kannst Du die Punkte "Zugriffsschutz", "Datensicherheit" sowie "und und und" genauer ausführen? Ich sehe hier keinen Vorteil bei einer reinen serverbasierten Lösung ohne lokaler Replik.

[Semeaphoros]

Werner und (weniger) MartinG: Eure Aussagen sind mir eindeutig zu religiös. Martin3 hat das im letzten Posting schon deutlich gemacht, dass man, wenn man so ins Einzelne gehen will, man schon sehr genau differenzieren muss. Beides hat Vor- und Nachteile. Wenn die Administration von lokalen Repliken eine Belastung wird, wie Werner erwähnt, dann stimmt was am Konzept nicht. Notes beherrscht diese Situation eigentlich sehr gut, hingegen gewisse Notes-Entwickler schlagen da manchmal quer, indem Funktionen so realisiert werden, dass sie nicht mehr dezentralisiert werden können. Das ist dann aber nicht wirklich ein Notes-Problem - eigentlich.

Zentral = Ressourcenschonend kann ich auch nicht unterschreiben. Die normalen Clients heutzutage sind eh nicht ausgelastet. Warum nicht deren Ressourcen mitverwenden?

Und dann. Werner, wenn Du schon proklamierst "Das ist mir nicht präzise genug", halte ich das a) für einen etwas unhöflichen Umgangston und b) sollte man sich dann schon selber daran halten.

[MartinG]

Hallo Jens,

so ganz kann ich Dein Posting nicht nachvollziehen. Was für einen Vorteil soll denn eine lokale Replik haben, wenn ich eine DB nicht ausser Haus nehmen will z.B. für Aussendienstler? Performanceprobleme des Dominoservers/Netzwerk sollten IMHO nicht durch lokale Repliken gelöst werden...

Gruss
Martin

[WernerMo]

Oh das tut mir leid, mit meiner Einleitung wollte ich nicht unhöflich sein, sonder nur einleiten, dass ich das gerne genauer beleuchten würde.
Eine Diskussion lebt aus meiner Sicht, davon, dass man das FÜR und WIDER beleuchtet.

Also nichts für ungut, ich wollte nicht unhöflich sein, sorry.

[Semeaphoros]

Ok, Werner, dann waren wir beide vielleicht ein wenig zu heftig oder hitzig oder was immer. Diskussion soll leben, das sehe ich auch so.

MartinG: Im Prinzip bin ich mit Dir einverstanden, ich würde das auch so als Leitlinie nehmen, es dann aber sicher nicht religiös ausleben, sondern im Einzelfall genauer hinsehen.

Typischer Fall, wo ich das mal hatte. Callcenter-Anwendung. Die Damen am Telefon waren auf superschnelles Funtkionieren der Applikation angewiesen und mussten natürlich auch bei einem eventuellen Netzwerk oder Serverausfall weiterarbeiten können.

[Driri]

Ich sehe das ähnlich wie Werner und MartinG. Lokale Repliken machen IMO nur Sinn, wenn ich auch Mobil auf die Daten zugreifen muß. Einen Serverausfall sollte man anders absichern, als über lokale Repliken.

Man kann sich auch wunderbare Eigentore schießen, wenn die Mitarbeiter dann evtl. nicht regelmäßig replizieren. Wir hatten hier schon den Fall, daß ein MA mit lokalen Repliken einer Anwendung über einen Zeitraum von mehreren Monaten nicht repliziert hat.
Nach der nächsten Replikation hatten wir plötzlich auf der Serverdatenbank wieder Dokumente, die schon vor Monaten gelöscht worden sind.
Das lag an dem Replizierparameter "Dokumente entfernen, die seit X Tagen nicht mehr geändert wurden."

[diali]

Die Replizierung kann am Client auch auf periodisch im Hintergrund gestellt werden.

Ich sehe es wie Jens (Semeaphoros) es gibt Anwendungen, bei denen es durchaus Sinn macht, mit der lokalen Replik zu arbeiten.

[WernerMo]

Hallo,

so gefällt mir das sehr gut, nun haben wir doch schon viele Argumente, wann was von Vorteil ist.
Nun wäre eine Forumsfunktion praktisch, die es ermöglicht, ein "wiki"-dokument zu eröffnen, in das jeder von uns Teilnehmer seine Punkte für (Zentral)Server und (Dezentral)Clientreplik reinschreiben kann.

[Driri]

Die Replizierung kann am Client auch auf periodisch im Hintergrund gestellt werden.

Ist klar, aber das ist auch keine Sicherheit. Der Anwender kann sich das genausogut wieder deaktivieren oder im Replikator die Datenbank deaktivieren.

[Marinero Atlántico]

Es ist ein Unterschied, ob jemand mit sehr guten Notes Kenntnissen mit lokalen Repliken arbeitet oder ein Anwender. Ich bezweifele, dass der Speicher und Replizierkonflikte im Ernstfall wirklich mitbekommt.

Notes beherrscht diese Situation eigentlich sehr gut,

Naja. Ich würde sagen: Recht gut.
Speicher und Replizierkonflikte als *das* Mittel gegen Dateninkonsistenzen in Folge von konkurrierenden Zugriff auf geteilte Ressourcen kann auch als ein bischen grobgranular angesehen werden. In RDBMS geht das mit optimistic und pessimistic locking für ähnliche Situationen ein bischen weiter um nicht zu sagen einiges weiter.

hingegen gewisse Notes-Entwickler schlagen da manchmal quer, indem Funktionen so realisiert werden, dass sie nicht mehr dezentralisiert werden können. Das ist dann aber nicht wirklich ein Notes-Problem - eigentlich.

Dann zähle ich mich zu diesen "gewissen Entwicklern". Verteilte Datenverarbeitung ist komplex und es ist auch mit Notes komplex. Man beachtet da schnell bestimmte Dinge eben nicht. Ich sitze in einer Organisation, wo an ca. 300 z.T. noch autark administrierte Organisationen Gestaltungen repliziert, per script-Automatisierung Konfig-Dokumente erstellt/upgedated/gelöscht etc. werden, die von den 500 Organisationen editierbar sind und und und. Besagte Organisationen haben z.T. langsame Leitungen. Die Admins in den Organisationen haben ein unterschiedliches Level an Erfahrung und Kenntnissen.

Natürlich ist verteilte IT überall komplex und ich fange innerlich an zu schreien, wenn ich ein lächelndes Gesicht sehe, dass von völlig transparenter Verteilung redet. Gibts in J2EE auch nicht. Der berühmte Cameron Purdy, der mit an einem verteilten Cache arbeitet, sagt auch, dass die meisten Leute, die von Verteilung reden, davon eigentlich nicht die richtige Vorstellung haben und ich traue diesem Mann. Oder z.B. wird in dem Buch Java Transaction Processing verteilte Transaktionen gegen mehrere Datenquellen sehr gut beschrieben. IBM arbeitete seit den 60ern an so einem Zeugs und es ist einfach grundsätzlich komplex und ich möchte nicht wissen, wie viel % der J2EE Entwickler im Grunde genommen keine Vorstellungen der Fundamentals von verteilten Transaktionen haben, und das ist vielleicht das Herzstück von J2EE.

ABER ERZÄHLT MIR NICHT IRGENDEINE UMGEBUNG HÄTTE DAS "GELÖST" UND ES WÄRE EINFACH UND ICH ZU BLÖD.

[koehlerbv]

Aus meiner Sicht geht der Tenor schon in die Richtung: Lokale Repliken, wo erforderlich, ansonsten nicht. Man sollte das aber nicht auf "lokale" Repliken (he, Replik ist Replik) beschränken, sondern das gilt ebenso für Repliken, die auf unterschiedlichen Domino-Servern liegen.

Und die ganze Sache läuft aus meiner Sicht auf zwei Dinge hinaus:
- Notes / Domino bietet state-of-the-art-Möglichkeiten der Replikation.
- Diese muss man zu nutzen wissen oder genauso auch wissen, wann man die Finger davon lässt (zum Beispiel schlicht lokale Repliken verbietet). Die Möglichkeiten der Replikation bieten enorme Vorteile, aber eben nur, wenn diese Replikation auch im Sinne der Applikationsarchitektur sichergestellt ist.

Meine Erfahrung (neben oben genannten): Mit der Kenntnis der Möglichkeiten und der damit entstehenden Problem kann man durchaus auch Leistungen anbieten, die (insofern es die Architektur der Applikation irgendwie hergibt) die Gefahren minimiert. Will heissen:
- Verhinderung der Dokument-Manipulation bei nicht vorgeschriebener Vorgehensweise hinsichtlich Replikationsintervallen
- Zwangsweise Replikation (basierend auf den o.g. Forderungen)
- Verhinderung auseinanderlaufender Prozesse (Beispiel: Änderung von Doc X in DB Y triggert eMail. eMail (mit DocLink) wird sofort übertragen (auf anderen Server !), die dazugehörige Replikation des Dokuments steht aber noch aus.

Meine Meinung: Alles eine Frage der Architektur von Notes / Domino an sich und wie die Architektur der eigenen Applikationen diese reflektiert. Vor allem: Wie und mit welchem Aufwand man sich dieser stellt. "Keine 'lokalen' Repliken !" kann sicherlich nicht immer die richtige Antwort sein.
Die richtige (der jeweiligen Situation entsprechende) Antwort wird aber sicher aufzeigen, wer dier Problematik beherrscht - oder eben nicht.

Bernhard

[Semeaphoros]

Bernhard, das ist eine sehr gute ausführliche Ausarbeitung von dem, was oben in Einzelteilen durchgekommen ist. Und genau das ist die Ausführliche Version von (sinngemäss) "es kommt darauf an". Vielen Dank für diese klare Ausarbeitung.