Wer nutzt denn alles DataSnap?

[DSCHUCH]

ich vermute mal ihr nutzt data abstract. das ist eine art middle tier bzw mapping für db-zugriff, korrekt? eigene funktionen damit abzubilden scheint mir zumindest im video nicht vorzukommen. auch benötigt man ja häufig unabhängig der datenbank funktionen welche zB einfach nur rechnen und ein ergebnis zurückgeben.

eine weitere anforderung ist ja zB caching. der application server soll daten zwischencachen damit die datenbank nicht ständig durch abfragen belastet wird, welche immer das gleiche ergbnis an die clients liefert (statusinformation). wenn es änderungen an daten gibt, meldet der db-server dies dem app-server, dieser fragt die daten neu ab und meldet den clients, dass diese ihre neuen informationen jetzt beziehen können.

[stahli]

@ himitsu:
Nur der Vollständigkeit die heutige eMail...

@ DSCHUCH:
So hatte ich das auch interpretiert und wenig verstanden (insb. für welche Anwendungsfälle so etwas geeignet ist)
Erst dachte ich, es wäre ein Ersatz/Nachfolger von ECO aber das ist es wohl doch nicht.

[himitsu]

@stahli: Jupp, hab ich gesehn.
Ich glaub der beobachtet mich ... Zum Mittag hab ich seinen Namen erwähnt und kurz darauf kommt eine Mail.
Ansonsten, nutze ich auch schon einige seiner Veröffentlichungen, zu diesem Thema.
Och, als Erstes wird dann erstmal Mister Eissing genervt, wenn wir ihn bald sehn

[add]
soviele persönliche Information für eine kleine PDF?
http://forms.embarcadero.com/forms/A...SnapWhitepaper

[Phoenix]

Zitat von DSCHUCH:

ich vermute mal ihr nutzt data abstract. das ist eine art middle tier bzw mapping für db-zugriff, korrekt? eigene funktionen damit abzubilden scheint mir zumindest im video nicht vorzukommen. auch benötigt man ja häufig unabhängig der datenbank funktionen welche zB einfach nur rechnen und ein ergebnis zurückgeben.

Das Mapping ist nur ein kleiner Aufgabenteil von DataAbstract. Der Schwerpunkt liegt selbstverständlich auf der Implementierung eigener Business-Logik in einer skalierbaren Schicht. Du kannst eigene Funktionen sowohl im Code als auch mittels Scripting implementieren. Wahlweise eins von beidem oder auch in Kombination. Je nach belieben. Scripting hat hierbei den Vorteil, dass die Scripte auch zur Verifizierung noch an den Client übertragen werden können und dort eine Vor-prüfung durchführen können um unnötiges Übertragen von Daten zu verhindern.

Zitat von DSCHUCH:

eine weitere anforderung ist ja zB caching. der application server soll daten zwischencachen damit die datenbank nicht ständig durch abfragen belastet wird, welche immer das gleiche ergbnis an die clients liefert (statusinformation). wenn es änderungen an daten gibt, meldet der db-server dies dem app-server, dieser fragt die daten neu ab und meldet den clients, dass diese ihre neuen informationen jetzt beziehen können.

Nicht wirklich. Cacheing macht in N-Tier-Umgebungen nahezu überhaupt keinen Sinn. Das Problem ist durch die Skalierbarkeit gegeben. Was für einen Sinn macht es, wenn der Application Server auf Maschine 1 Daten cached, die auf Maschinen 2, 3 und 4 gerade (ggf. gegensätzlich) verändert wurden? Um die Caches immer über alle Maschinen aktuell zu halten würde man so viel Synchronisierungs-Overhead erzeugen, das es keinen Sinn mehr machen würde das überhaupt in eine Separate Logik-Schicht auszulagern. Die Datenbank cached schon genug, daher besteht keine Notwendigkeit eine weitere Cache-Schicht einzuziehen. Um Datenbanken über die Verwendung größerer Cluster hinaus zu skalieren muss man anfangen, Daten zu partitionieren. Auch hier macht Cacheing gar keinen Sinn.

[MEissing]

Zitat von Phoenix:

Nicht wirklich. Cacheing macht in N-Tier-Umgebungen nahezu überhaupt keinen Sinn. Das Problem ist durch die Skalierbarkeit gegeben. Was für einen Sinn macht es, wenn der Application Server auf Maschine 1 Daten cached, die auf Maschinen 2, 3 und 4 gerade (ggf. gegensätzlich) verändert wurden? Um die Caches immer über alle Maschinen aktuell zu halten würde man so viel Synchronisierungs-Overhead erzeugen, das es keinen Sinn mehr machen würde das überhaupt in eine Separate Logik-Schicht auszulagern. Die Datenbank cached schon genug, daher besteht keine Notwendigkeit eine weitere Cache-Schicht einzuziehen. Um Datenbanken über die Verwendung größerer Cluster hinaus zu skalieren muss man anfangen, Daten zu partitionieren. Auch hier macht Cacheing gar keinen Sinn.

Diese Aussage ist in ihrer Pauschalität nicht richtig. Letztendlich geht es in jeder (Multi-Tier-) Anwendung um die Kosten für die Verarbeitung und Beschaffung der Daten. Nebenläufigkeiten () wie die Wahl zwischen Skalierbarkeit und Verfügbarkeit lasse ich hier erstmal weg:
Ein Cache kann durchaus Sinn ergeben, auch über verschiedene Instanzen eines Anwendungsservers hinweg. Sind die Kosten für bestimmte Datenbankabfragen besonders hoch, so implementiert man seit Jahren in den verschiedensten Anwendungen eine Caching-Protokoll, was diese Instanzen aktualisiert. Das ist nichts Neues.

Nimmt man dann doch noch die Verfügbarkeit des Gesamtsystems mit in die Waagschale, so ist es unerlässlich sich über ein zentrales Session-Management Gedanken zu machen. Spätestens da muss man sich über Caches und deren Synchronisation Gedanken machen.

Eine skalierbare Infrastruktur zu bauen ist nicht weiter kompliziert. Eine verfügbare Infrastruktur dagegen schon.

[Phoenix]

Rreden wir hier z.B. von Euren Foren? *scnr*

[himitsu]

Eigentlich wollten wir im ersten Schritt unser Dateimanagement auf Basis vom Datasnap auslagern, aber so wie es aussieht, ist das ja arschlangsam.
selbst wenn Server/Client auf dem selben Rechner direkt nebeneinander laufen, dann bekomm ich, via TCP/IP auf localhost, effektiv grade mal nur 1 MB/s raus.

Übers Netztwerk konnte ich jetzt leider noch nicht direkt testen, aber dort erwarte ich dann noch weniger.

[Daniel]

Welche Geschwindigkeiten bekommst Du denn in Eurem System, wenn Du die Dateien direkt via TCP/IP (z.B. mittels INDY) überträgst?
Sprich: Über welche Verzögerung durch DataSnap reden wir?

[himitsu]

TIdTCPServer/Client
5.000.000 Byte in 47 Milisekunden


DataSnap
2.251.872 Byte, nach Umwandlung in Base64 vielleicht 3 MB in 2,5 bis 3 Sekunden (knapp 150-200 ms sind dabei mein eigener Code)

[Phoenix]

Zitat von himitsu:

Eigentlich wollten wir im ersten Schritt unser Dateimanagement auf Basis vom Datasnap auslagern, aber so wie es aussieht, ist das ja arschlangsam.
selbst wenn Server/Client auf dem selben Rechner direkt nebeneinander laufen, dann bekomm ich, via TCP/IP auf localhost, effektiv grade mal nur 1 MB/s raus

Sowas ähnliches wurde auf Basis von RO/SDK schonmal umgesetzt: Case Study, Shell+ and Documents. Da gibts auch Beispiel-Sourcen dazu. Und von der Performance her ist das alles andere als langsam