Datentransfer von mehreren Clients an einen Server über LAN

[Tempdir]

Hallo liebe Forengemeinde,

ich suche gerade nach Realisierungsmöglichkeiten für ein Server/Client Konzept.

Worum geht es?

Es gibt im Netzwerk (TCP/IP) mehrere Client-PCs auf denen jeweils eine Datenbank liegt, die permanent mit neuen Werten gefüllt wird. Im selben Netzwerk befindet sich ein Server-PC auf dem alle diese Datenbanken archiviert werden sollen.

Anforderungen:

Die Datenbank der Client-PCs kann von fast beliebigem Typ sein (IB, SQL, DBF...) und fasst maximal 100.000 Einträge die von einer Applikation auf dem Client geschrieben wird. Das System muss gegen Verbindungsabbrüche immun sein, und die Daten müssen nachträglich abgeholt werden können, wenn z.B. der Server-PC über Nacht ausgeschaltet wird.

Frage:

Was für Möglichkeiten der Realisierung gibt es mit Delphi oder Delphi im Zusammenspiel mit Webservern, Datenbankservern...?

Ich wäre euch für Tipps wirklich sehr dankbar!

Viele Grüße - Andreas

[Bernhard Geyer]

Müssen wirklich unterschiedliche DBMS unterstützt werden? Ich würde ein DBMS aussuchen und dann die Synchronisierung per Replikation laufen lassen.

[Tempdir]

Nein, das ganze soll nur für EINEN Datenbanktyp entwickelt werden. Jetzt hab ich noch die Wahl welche, daher hab ich das erwähnt :) Replikation bedeutet eine Datenbank auf eine andere abzubilden über Netzwerk?

Es muss nur sichergestellt werden, dass praktisch alle Datenbanken der Clients auf dem Server archiviert werden.

[mkinzler]

Zitat:

Replikation bedeutet eine Datenbank auf eine andere abzubilden über Netzwerk?

Allgemein der Abgleich verschiedenere Datenbanken ( Sychronisierung/Teilsynchronisierung, uni-/bidirektional, ...)

[Tempdir]

Danke für die Erklärung.

Gibt es da auch Optionen wie "Nur noch nicht archivierte Datensätze archivieren" ? In Hinsicht auf Verbindungsunterbrechungen.

[mkinzler]

Kommt auf die Replikationslösung an.

[Bernhard Geyer]

Zitat:

Zitat von Tempdir

Gibt es da auch Optionen wie "Nur noch nicht archivierte Datensätze archivieren" ? In Hinsicht auf Verbindungsunterbrechungen.

Sollte kein Problem sein da sowas i.d.R. in einem Transaktionskontext geschieht.

[Tempdir]

Kann ich sowas mit Delphi realisieren? Und wenn ja, gibt es dann eine Client- und eine Server-Applikation oder wie sieht der Aufbau aus?

[mkinzler]

Wäre möglich. Es gibt aber für verschiedene DBMs auch fertige Replikationslösungen

[Tempdir]

Eine fertige Lösung kommt leider nicht in Betracht da es etwas selbstgeschriebenes sein soll.

Bisher ist ein selbstgeschriebenes System im Einsatz welches mit den Delphi-Komponenten "TidTCPServer" und "TidTCPClient" arbeitet. Auf den Clients wird eine kleine *.EXE-Datei gestartet welche die IP des Servers kennt, und dieser findet diese dann automatisch und empfängt die neuen Daten.
Verwaltet werden die verschiedenen Verbindungen über Threads. Zur Sicherung der Übertragung der Daten wird jeder ausgelesene Datensatz in einen Frame verpackt.

So ist es bisher realisiert. Das System soll jetzt überarbeitet werden und daher meine Frage wie man sowas besser bzw. sogar einfacher realisieren könnte - z.B. auch via UDP ?

Danke für die ganzen Infos bisher !!!

[manfred_h]

Hallo Tempdir

schau Dir dochmal Copycat an. http://www.microtec.fr/copycat/

Zitat:

CopyCat is a multi-database replication component suite for Borland Delphi / C++Builder

* Full two-way replication.
* As a Delphi / C++Builder component set, CopyCat allows you to embed and customize replication logic in your own applications.
* Heterogenous replication between Interbase, Firebird, and Microsoft SQL Server.
* Transport layer abstraction allowing to replicate over any supported remoting framework, such as XML-RPC, RTC, RemObjects, KbmMW, etc. This enables both better security and compression.
* Using CopyCat, you can either setup automatic replication of all or part of your database (using triggers), or you can manually synchronize specific records as needed.
* No server-side is needed: thus CopyCat can be used on any MS Windows client, regardless of the OS of the remote server.
* Advanced primary key synchronization techniques, using either a generator, a stored procedure, or a custom SQL expression. This feature is currently available only for Interbase/Firebird
* Advanced conflict management techniques, allowing you to completely avoid the risk of crushing any data in any event changes were made to the same record in both databases.
* Complex replication situations can be resolved using advanced techniques such as stored procedure replication
* Support for limiting the replication of certain tables using a customized WHERE clause.
* Designed for and tested with Interbase 6.0 - 7.5, Firebird 1.x - 2.0 and MS SQL Server 2005.
* Supports C++Builder 5 - 6 and Delphi 5 - 2006.
* Support for many different data-connectivity components: FIBPlus, IBX, IBObjects, UIB, and ADO.

Shalom
Manfred

[Bernhard Geyer]

Zitat:

Zitat von Tempdir

Eine fertige Lösung kommt leider nicht in Betracht da es etwas selbstgeschriebenes sein soll.

Wieso? mit fertig ist gemeint das sowas die DBMS schon von haus mitbringen. Also keine 3th-Party-Lösung installiert werden muss.

[mjustin]

Zitat:

Zitat von Tempdir

Bisher ist ein selbstgeschriebenes System im Einsatz welches mit den Delphi-Komponenten "TidTCPServer" und "TidTCPClient" arbeitet. Auf den Clients wird eine kleine *.EXE-Datei gestartet welche die IP des Servers kennt, und dieser findet diese dann automatisch und empfängt die neuen Daten.
Verwaltet werden die verschiedenen Verbindungen über Threads. Zur Sicherung der Übertragung der Daten wird jeder ausgelesene Datensatz in einen Frame verpackt.

So ist es bisher realisiert. Das System soll jetzt überarbeitet werden und daher meine Frage wie man sowas besser bzw. sogar einfacher realisieren könnte

Eine sehr zuverlässige, ausfallsichere und lastverteilte Lösung kann man zum Beispiel mit einem Message Broker realisieren. Clients können auf diesen zugreifen auch wenn das Zielsystem, das die Daten weiterverarbeiten soll, nicht läuft. Der Message Broker puffert die Daten, bei Bedarf auch auf die Festplatte so dass er selber auch ausfallen darf, ohne dass Daten verloren gehen.

Die Empfänger-Anwendung kann dann vom Messagebroker die Daten abholen und weiter verarbeiten. Zur Lastverteilung können auch mehrere Empfänger Anwendungen parallel laufen. Der Broker wird die Daten dann gleichmäßig auf die Empfänger verteilen.

Kostenlose Open Source Implementierungen wie z.B. Apache ActiveMQ sind bereits sehr leistungsfähig, es existieren Clients für viele verschiedene Programmiersprachen, daher sind sie auch sehr gut für die Verbindung bestehender Systeme geeignet.

[mkinzler]

ActiveQ Schnittstelle für Delphi
http://activemq.apache.org/delphi-and-freepascal.html

[Tempdir]

Danke für die vielen Tipps!

@Manfred: Die komponente sieht gut aus, allerdings fehlt der Support für D2009 und es sieht so aus als sei das ganze etwas eingeschlafen (letzter Release Ende 2007). Da das ganze aber für ein kleines Projekt in einer Firma sein soll, ist diese somit eher unbrauchbar (Support).

@Bernhard: Wie sieht sowas genau aus? Eine Software die der Datenbank beiliegt bzw. heruntergeladen werden kann?

@mjustin Danke, ich werde mich darüber informieren.



Was haltet ihr von folgender Idee:

Auf jedem PC-Client läuft z.B. ein Firebird SQL-Server.
Jetzt schreib ich in Delphi ein Programm mit den IB-Datenbankkomponenten, welches sich automatisch mit dem jeweiligen Client verbindet, und die neu hinzugekommenen Daten abholt. Dass sie neu sind erkennt das Programm daran, indem die Datensätze die noch nicht abgeholt wurden ein Feld enthalten das z.B. den Wert FALSE (= noch nicht abgeholt) hat.
Somit könnte ich über eine SQL-Query einen Eintrag auslesen, und dann den Wert TRUE (=abgeholt) in das Feld schreiben.

Die IPs der Clients werden in einer Liste angegeben, welche das Programm zyklisch abarbeitet.

Bitte um eure Kommentare - vielen vielen Dank!

[mkinzler]

Dann wäre doch der andere Weg sinnvoller: Der Client verbindet sich mit einem zentralen FireBird Server und gleicht lokalen Bestand ab.

[Tempdir]

Aber dann hätte ich wiederum das "Problem", dass sich mehrere Clients gleichzeitig verbinden und gleichzeitig Daten senden (ok ist eigentlich auch Sinn und Zweck eines DB-Servers - aber ich weiß nicht ob und was da schief gehen könnte).
Und ich wüsste nicht ob die Daten in der Firebird-DB gespeichert wurden? Höchstens ich mach eine erneute Anfrage, ob die Daten drin sind.
Ich sollte noch erwähnen, dass auf der Client-Seite die CPU-Last möglichst gering sein sollte. Serverseitig ist es egal.

[mkinzler]

Zitat:

Und ich wüsste nicht ob die Daten in der Firebird-DB gespeichert wurden? Höchstens ich mach eine erneute Anfrage, ob die Daten drin sind.

Ich glaube nicht, das irgendwer ein DBMS einsetzen würde, wenn der Client keine Rückmeldung vom Server bekommen würde

Zitat:

Ich sollte noch erwähnen, dass auf der Client-Seite die CPU-Last möglichst gering sein sollte. Serverseitig ist es egal.

Abfragen kann man ja auf den Server verlagern (z.B. in SPs). Zudem würde die Replikation, ja bei Wiederanmelden der Clients an den Server erfolgen.

[Tempdir]

Guten Morgen,

also wenn ich die Methode mit dem zentralen Server machen würde, so hätte ich den Vorteil dass ich auf der Client-Seite nur eine Exe starten müsste (welche die DB des Clients ausliest und versendet). Und auf der Empfangsseite (Server) müsste ich einen SQL-Server installieren der die Daten "einsammelt".
Bei dieser Variante könnte man auf dem Server die SQL-Datenbank nicht einfach "anschauen" mit z.B. Notepad. Bei der anderen Variante, wo auf jedem Client ein SQL-Server ist, könnte ich auf der Serverseite die Daten z.B. in ein DataBase File oder CSV speichern.

Spricht viel gegen meine erste Variante von Seite 1 ?

[mquadrat]

Wie schaut die Verbindung zwischen Clients und Server aus? LAN?

Wir haben eine ähnliche Problemstellung so gelöst:
- Die Tabellen, die übertragen werden sollen haben einen Trigger der bei Inserts, Updates und Deletes anspringt
- Dieser Trigger schreibt einen Datensatz in eine Replikationstabelle mit Operation, Tabelle, Primärschlüssel
- Auf dem Server läuft ein Programm, dass zyklisch bei allen Clients diese Informationen ausliest und entsprechende Selects durchführt
- Die Datensätze werden in einer Zwischendatenbank gepuffert, falls der Zielserver nicht erreichbar ist
- Ist er erreichbar wird die gleiche Operation auf der Zieldatenbank ausgeführt.

Das Zwischenpuffern in der DB ist u.U. nötig da wir sämtliche Datenbanken vollständig untereinander synchronisieren. Fertige Lösung haben wir damals ein oder zwei ausprobiert, aber da hat es uns ein bisschen an Flexibilität gefehlt.

Vorteil der Lösung: An den Clients muss (bis auf die Trigger) überhaupt nichts geändert werden.

[Tempdir]

Zitat:

Wie schaut die Verbindung zwischen Clients und Server aus? LAN?

Ja! Über Netzwerk.

Wenn ich deine Realisierung richtig verstehe, dann entspricht das in etwa meiner Idee auf Seite 1 des Threads.

Darf ich fragen wieviele Clients ihr habt, und wie oft von denen Daten abgeholt werden (z.B. in der Minute, oder Sekunde...).

Und vielleicht noch was für Delphi-Komponenten bzw. Datenbanksystem zum Einsatz kam.

[mquadrat]

Jep, nur das wir keine Flags in den Datensätzen nehmen. Die sind nämlich nach einem delete auf den Datensatz weg ;)

Derzeit hängen vier Standorte dran. Angebunden über Internet via VPN. Die Daten werden alle 3 Minuten abgeholt. Die Datenmenge variiert. Bei den kleineren Standorten ca. 50 Datensätze pro Zyklus bei den großen bis ca. 150. Angeschlossen werden noch drei bis vier weitere Standorte auch im Ausland. Als Zugriffskomponenten verwenden wir derzeit IBX. Die Datenbanken sind ein Gemisch aus 1.5er und 2.1er Firebirds. Da die VPNs (gerade ins Ausland) gerne mal zusammenbrechen wird jede Änderung in eine eigene Transaktion gepackt.

Und da sind wir auch schon beim Problem ;) Geschwindigkeit. Firebird (besonders die 1.5er) sind über Internet verdammt langsam. Aber sonst funktioniert's eigentlich :D

[Tempdir]

Das hört sich alles gut an!

Bei mir ist Geschwindigkeit ein wichtiges Kriterium. Die Clients sind aber alle in einem LAN, jedoch sollte der Server schon mehrere Datensätze pro Sekunde einlesen können.

Ich hab mir das so gedacht, dass wenn es z.B. 5 Clients gibt, der Server immer zyklisch alle 5 clients durchgeht und von jedem dabei z.B. einen Datensatz abholt. Ich muss mal testen wie schnell sich die IP bei den IB-Komopnenten wechseln lässt und wie lange ein Transfer von einem Datensatz dauert.

Die Client-DB soll ca. 100.000 Einträge haben. Ich frage mich wie da die Zugriffszeiten sind? Mit MySQL dauerte ein einfacher SELECT ein "Wimpernzucken", allerdings hab ich mit Firebird in der Hinsicht NULL Erfahrungen.

[mquadrat]

In nem LAN dauert das mit FB auch nicht länger. Selbst via VPN nach China gehen gehen mehrere Queries pro Sekunde ohne Probleme. Aber statt 100 halt nur 5 oder so ;)

Warum immer nur einen Datensatz? Dann biste ja mehr am Verbindung auf- und abbauen als am Daten übertragen. Aufbauen alles holen was da ist und weiter zum nächsten.

Client-DB Größe ist relativ egal. Wir dürften inzwischen irgendwo bei 2 Millionen Datensätzen je Standort liegen.

[Tempdir]

Ja eigentlich würde es mehr Sinn machen gleich 5 oder mehr zu holen, es ging nur darum, dass alle Clients mal bedient werden und deren "maximal 100.000 Einträge-DB" nicht überläuft (also der Puffer).

Ich versuche mich gerade über die IB-Komponente mit einem Firebird-Server auf einem anderen Rechner zu verbinden, aber irgendwie klappt das nicht. Auf meinen lokalen FB-Server kann ich problemlos zugreifen. Immer diese Probleme :)

[mquadrat]

Wieviele Datensätze kommen denn pro Sekunde / Minute / Stunde in den Client-DBs dazu bzw. werden geändert?

Zum Problem: Port in der Firewall freigegeben?

[Tempdir]

Also die Clients fügen im Maximalfall einen Datensatz / Sekunde in ihrer Tabelle hinzu (diese ist wie gesagt auf 100.000 Einträge beschränkt, wird danach von neuem überschrieben).

PERFEKT ! Danke, es lag wirklich an der Firewall :wink: Und die Daten von C:\TestDB.fdb weden auch angezeigt. Wie es scheint dauert der Verbindungsaufbau aber 1-2 Sekunden. Dann macht es wohl Sinn mehr als nur einen Datensatz zu übertragen. Hoffentlich sind die SQL-Queries nicht so langsam :(

[mquadrat]

Na dann haste ja einen Puffer von ~24 Stunden. Das sollte kein Problem sein.

1-2 Sekunden? Nur für die Verbindnung? Da muss noch was faul sein. Wenn ich einfach nur die Verbindung aufbau, passiert das im LAN mehr oder weniger sofort.

[Tempdir]

Ok, woher die Verzögerung kommt kann ich NOCH nicht sagen.

Was mir noch sehr schwer fällt ist das Erstellen von Firebird DBs :( Bei MySQL gibt es ja den phpMyAdmin mit dem alles supereinfach geht.
Bei Firebird hab ich es zwar geschafft eine Tabelle zu erstellen (über das Pendant zu phpMyAdmin <-> WebAdmin) aber das mit dem Primary-Key blick ich einfach nicht :( . Zwar kann ich ein Feld als "Primary_Key" definieren, aber anscheinend benötigt man noch so etwas wie einen "Generator" usw. für die AutoIncrement Funktion?

Kurz gesagt: Ich möchte ein Feld Namens "ID" das als Primary Key (Integer) definiert ist.

Hab auch mal dieses "SQL Maestro" getestet, aber dort verstehe ich die Optionen für den Primary Key nicht.

Kann mir da jemand einen Tipp geben?

[mquadrat]

Als Admintool empfiehlt sich z.B. IBExpert.

AutoIncrement Felder gibt es in Firebird nicht. Statt dessen gibt es sogenannte Generatoren. Das ist im Grunde ein Interger, das auf Anforderung hochgezählt wird.

Sieht dann in etwa so aus:

SQL-Code:

insert into Testtabelle (PK_Feld, Feld1, Feld2) values (GEN_ID(Generatorname, 1), 'Wert', 'Wert)

Den Generator kann man anlegen über

SQL-Code:

create generator Generatorname

EDIT:
Man kann mittels eines Triggers das AutoIncrement auch simulieren.

Weitere Infos zu den Unterschieden Migration MySQL nach Firebird

[mkinzler]

Es wäre beim Inline-Aufruf der Genaratorfunktion sinnvoll sich den vergebenen Wert zurückliefern zu lassen:

SQL-Code:

insert into Testtabelle (PK_Feld, Feld1, Feld2) values (GEN_ID(Generatorname, 1), 'Wert', 'Wert) returning PK_Feld;

[mquadrat]

Und wieder was gelernt. Der Vorteil von Generatoren liegt für mich vor allem darin, dass ich mir schon die ID eines Datensatzes holen kann, bevor er überhaupt gespeichert ist. Daher hab ich den PK beim insert schon. Aber gut zu wissen, was man theoretisch machen könnte ;)

[Tempdir]

Danke für die ganzen, sehr brauchbaren Tipps von euch!

Leider hakt es etwas: Ich mache gerade alles über die iSQL-Konsole von Firebird:

Ein Create klappt super:

Delphi-Quellcode:

SQL>CREATE DATABASE 'C:\test.fdb' page_size 8192↵
CON>user 'SYSDBA' password 'masterkey';↵

Doch dann versuche ich z.B. ein:

Delphi-Quellcode:

SQL>SELECT * FROM test;↵

und bekomme ein SQL-Error -204. Ich hab mich mit einem

Delphi-Quellcode:

CONNECT C:\test.fdb user SYSDBA password masterkey;↵

auch nochmals mit der DB verbunden, aber weder ein INSERT noch ein SELECT klappen.

[mquadrat]

Du hast doch nur ne Datenbank erstellt und noch keine Tabelle?! Oder hast du das create table Statement einfach nur nicht in den Beitrag geschrieben?

[Tempdir]

:oops: SORRY richtig !

Jetzt klappt alles einwandfrei :) Was ich nur etwas doof finde ist, dass man bei jedem INSERT den "Generator" mitgeben muss:

Delphi-Quellcode:

INSERT INTO test (field1, field2) VALUES (gen_id(gen_test_id, 1), 'testme');

Delphi-Quellcode:

Also ein reines INSERT INTO test (field2) VALUES ('hallo');

geht leider nicht.

[Tempdir]

Also ich hab noch Probleme bei der Dauer des Verbindungsaufbaus:

Hab mir ein kleines Programm geschrieben, dass sich abwechselnd entweder mit dem Localhost-SQL-Server oder einem im Netzwerk vorhandenen SQL-Server verbindet.
Meine komponente ist die IBDatabase und so sieht die Schleife aus:

Delphi-Quellcode:

  for i:= 0 to 5 do begin
    IBDatabase1.Connected := FALSE;
    IBDatabase1.DatabaseName := '192.168.173.46:C:/TEST.FDB';
    IBDatabase1.Connected := TRUE;

    IBDatabase1.Connected := FALSE;
    IBDatabase1.DatabaseName := '127.0.0.1:C:/TEST.FDB';
    IBDatabase1.Connected := TRUE;

  end;

Zum localhost connected er sehr schnell, aber zumn Netzwerk-PC dauerts 1-2 Sekunden. Ping zu dem Netzwerkrechner ist <1ms.

[mquadrat]

Zum Insert: Schau dir mal den Link an, den ich gepostet hat. Mittels eines Triggers kann man auch deine Wunschsyntax verwenden.

Benutzt du lokal und auf dem Server die gleiche Firebird-Version?

[Tempdir]

Danke @ Insert.

Sind 100% gleich die Firebird-Versionen.

Was mir aufgefallen ist: Bei oben genannter Schleife geht die CPU-Last des Netzwerk-Clients auf ca. 70%-80% hoch. Es ist zwar nur ein 300MHz Celeron, aber trotzdem etwas heftig wie ich finde - also für einen einfachen Connect. Das ist ein ziemlich großes Problem da es womöglich ein KO-Kriterium für mein Vorhaben darstellt :(

*edit* ich hab den Classic-Server installiert

[mquadrat]

Was das Verbinden angeht isses egal ob Classic oder Superserver.

1-2 Sekunden sind zwar ungewöhnlich lang, aber solange die Queries schnell durchlaufen, dürfte das doch eigentlich kein KO Kriterium sein. Du kannst die Verbindung ja halten und nur neu aufbauen, falls sie abbricht.

Wieviele Clients hängen denn da dran, wenn das so ein Problem ist? Wenn du auf nem 300Mhz System testest wo wird das denn eingesetzt? Industrie-PC in der Fertigung?

[Tempdir]

Richtig! Es ist ein Industrie-PC der gleichzeitig eine Maschine steuert. Ich rechne mal so mit ca. 10 Clients. Wieviele es genau werden kann ich nicht exakt sagen.

Meine Lösung wär ja gewesen mit einer IB-Komponente abwechselnd zu den Clients zu connecten und dann je Client ein paar Datensätze abholen.
Ich könnte auch zu allen Clients gleichzeitig connecten und die Daten dann von jedem ständig abholen. Aber dann bräuchte ich mehrere IB-Komponenten und z.B. Threads. Oder gibt es da klügere Lösungen?

Wie gesagt, bisher läuft das ganze über TCP/IP mit TidTCPServer/-Client Komponenten und Threads. Wir haben auch darüber nachgedacht das ganze über UDP usw. zu machen, allerdings denke ich wäre es mit SQL am einfachsten zu realisieren - wenn es da nicht was gibt was ich nicht beachtet habe.