Gemeinsame Datenbank

[tömmel]

ähm... räusper mal abgesehen davon, dass es nicht die Rolle spielt wie weit weg so'n Rechner steht... aber die Lichtgeschwindigkeit für die Luftlinie anzusetzen - das hat schon was vom Milchmädchen.
Da sind Pakete unterwegs - da wird von Server zu Server gecheckt ob alles ankommt usw. da wird keineLichtgeschwindigkeit erreicht....

[Ralf Jansen]

Kann mir keiner sagen, dass man das merkt, wenn eine einzelne Abfrage 2-tausendstel länger braucht.

Dein Blick ist ein wenig auch einen bestimmten Anwendungstyp eingegrenzt. Natürlich gibt es auch Anwendungen wo jede Millisekunde zählt insbesondere wenn nicht direkt User beteiligt sind. Blödes Beispiel die in New York ansässigen Hedgefonds haben sich kürzlich gerade für einen dreistelligen Millionenbetrag ein eigenes Überseekabel nach London geleistet. Mit lächerlicher Bandbreite aber höhere Signalausbreitungsgeschwindigkeit als Standard Glasfaser. Und nun haben die anstatt 60ms einen Ping von 55ms. In deren Geschäftsfeld ist jede Millisekunden Milliarden wert. Ist in anderen Bereichen sicher nicht so krass aber auch wichtig.

[hwoess]

Wenn ich mal grob 300.000 Km/Sekunde bei der Lichtgeschwindigkeit annehme, dann braucht das Licht ca. 2-tausendstel Sekunden für diese 600 Km. Kann mir keiner sagen, dass man das merkt, wenn eine einzelne Abfrage 2-tausendstel länger braucht. Und wenn ich 100 Abfragen hintereinander brauche, um einen Bildschirm aufzubauen, dann würde das, wäre nur die Distanz der maßgebliche Faktor, gerade mal 2-zehntelsekunden länger dauern als in der Zentrale. Ärgert sich ein Anwender über sowas? Nein, würde ich mal behaupten.
Wenn ich aber in der Firma ein Gigabit-Netz habe (also 1000 MBit) und im Gegensatz dazu dann alle Aussenstellen zusammen gemeinsam über einen 1 MBit-Flaschanhals müssen, braucht man sich nicht zu wundern, dass Applikationen draußen plötzlich einknicken, sobald es zu einer Datenabfrage kommt. Passiert besonders gerne bei "select * from tabelle" - also ohne Feldangaben und where-Klausel.
Meistens erfolgt der Test des Programmierers mit 3 Datensätzen in der Testdatenbank, der Kunde hat aber dann 30.000 Datensätze drinnen und alle wundern sich, warum das Ganze auf einmal unbrauchbar wird :-)

bye,
Helmut

[Bernhard Geyer]

Das liegt normalerweise nicht daran, dass die Standorte zuweit auseinander sind, sondern an zwei zusammenfallenden Problempunkten:
a) der Serverstandort hat eine zu langsame (meistens asynchrone) Internetanbindung, ich sehe da bei meinen kleineren Kunden zB. beim Server manchmal nur 0,7 MBit Upstream, gerade der wird aber gebraucht, wenn externe Standorte zugreifen. Und diesen Upstream müssen sich alle teilen, die gleichzeitig zugreifen, mit jedem weiteren Standort wird es also immer schlimmer!
b) die Applikation wurde so programmiert, dass immer viel mehr Daten vom Server geholt werden als man eigentlich braucht.

Ist hier nicht der Fall gewesen. Hier waren/sind es einfach das viele Einzelabfragen die nötig sind um alle nötigen Informationen für das Arbeiten zu bekommen.
Und jede Abfrag ist nun mal mit maximal Lichtgeschwindigkeit (im Idealfall) unterwegs. Nun kann man sich ausrechnen um wie viel solche Abfragen langsamer werden wenn Anwendung und DB z. B. 600 km auseinander liegen.
Sicherlich kann man versuchen diese Einzelabfragen über eine Monster-Abfrage zusammenzufassen. Ist aber nicht unerheblicher Aufwand und wenn man 99% Kunden hat welche diese Problem nicht haben wird man wohl sich eher an den SW-Teilen optimierungen vornehmen die 99% der Kunden was bringt :-)

[hwoess]

Wenn die Standorte zu weite auseinander sind kannst du dir damit aber sehr leicht ein Performancegrab ins Haus holen

Das liegt normalerweise nicht daran, dass die Standorte zuweit auseinander sind, sondern an zwei zusammenfallenden Problempunkten:
a) der Serverstandort hat eine zu langsame (meistens asynchrone) Internetanbindung, ich sehe da bei meinen kleineren Kunden zB. beim Server manchmal nur 0,7 MBit Upstream, gerade der wird aber gebraucht, wenn externe Standorte zugreifen. Und diesen Upstream müssen sich alle teilen, die gleichzeitig zugreifen, mit jedem weiteren Standort wird es also immer schlimmer!
b) die Applikation wurde so programmiert, dass immer viel mehr Daten vom Server geholt werden als man eigentlich braucht.

Wenn also die Internetleitung die vom Server weg die Daten an die Aussenstellen liefert, zu schwach dimensioniert ist und außerdem die Anwendung zu viele Daten holt, dann kann das mit dem Performancegrab natürlich schnell passieren. Da ist es aber dann egal, ob der Abstand zwischen den Standorten 50 Km oder 5000 Km ist.

Der Vorteil bei einer verteilten Datenbank mit Replikation ist natürlich die Unabhängigkeit von einem Zentralserver, aber dafür muss man sich um die Datenabgleiche kümmern, die auch nicht gerade trivial sind.
Und man hat auch meistens keinen aktuellen Stand der Gesamtdaten. Wenn man damit leben kann ist's okay, wenn nicht, dann geht das mit Replikation sowieso nicht.
Ich sehe das also Konzeptfrage, beide Lösungen haben ihre Vor- und Nachteile.

bye,
Helmut

[tömmel]

Naja - kommt meiner Meinung nach auch immer auf den konkreten Anwendungsfall und die Problemstruktur an. Das muss man aber bei der Enticklung einer Lösung berücksichtigen. Auch Replikation muss keine Lösung sein. Genau genommen kann man soeine Frage garnicht beantworten wenn man die Aufgabenstellung und Gegebenheiten nicht kennt.

Ich weiss ich krieg da wieder haue - aber das ist so eine Frage, die ich mir stelle, bevor ich eine Anwendung entwickle

[Bernhard Geyer]

Wenn man mit einem "richtigen" SQL-Server (SQL Express und aufwärts) arbeitet, kann man, sofern man eine öffentliche IP für den Router mit dem Netz, in dem der SQL Server steht, hat, diesen so konfigurieren, dass man auch von aussen mittels dieser IP-Adresse (und ev. Portnummer) sogar ohne VPN auf den SQL-Server zugreifen kann (natürlich verschlüsselte Verbindung, schon beim Login). Habe das bei vielen meiner Kunden erfolgreich im Einsatz.

Wenn die Standorte zu weite auseinander sind kannst du dir damit aber sehr leicht ein Performancegrab ins Haus holen. Hatten schon den Fall das eine IT unbedarft den DB-Server im Süddeutschen Raum betreiben wollte und die zugreifende Anwendung in Norddeutschland. Hatten sich dann gewundert das viele Anwendungen erheblich langsamer waren.

[tömmel]

ähmm...
Also das "Management Studio" ist das Verwaltungstool - ich gehe mal frech davon aus, dass er die express edition mit "Management Studio" heruntergeladen und installiert hat...

Allerdings kann ich nicht soweit hellsehen, ob er eine Replikation braucht - wenn die VPN stabil und schnell genug ist, sehe ich das Problem nicht - sind die Rechner doch 'normal' im Netwerk erreichbar.

vielleicht sehe ich aber auch nur das Problem nicht...

[hwoess]

Das Management Studio ist ein Werkzeug für die Verwaltung des SQL-Servers und keine Datenbank.
Wenn man mit einem "richtigen" SQL-Server (SQL Express und aufwärts) arbeitet, kann man, sofern man eine öffentliche IP für den Router mit dem Netz, in dem der SQL Server steht, hat, diesen so konfigurieren, dass man auch von aussen mittels dieser IP-Adresse (und ev. Portnummer) sogar ohne VPN auf den SQL-Server zugreifen kann (natürlich verschlüsselte Verbindung, schon beim Login). Habe das bei vielen meiner Kunden erfolgreich im Einsatz.

bye,
Helmut

[Bernhard Geyer]

Stichwort wäre hier Replikation.
Du hast in den Filialen die kleinen Serverversion welche sich per Replikation mit der Zentrale abgleichen.
Nötig ist in der Zentrale eine größerer Version und auch die Anwendungen müssen Replikationsfähig sein.