Datenbankhandling über eine Cloud?

[sko1]

Hallo,

ich möchte Datenbanken über eine Cloud "verteilen" und synchronisieren.

Irgendwie fehlt mir jedoch die Vorstellung, was passiert wenn das Cloudsystem (ggf. langsamer Upload) dabei ist, die Datenbank von lokal zum Cloudspeicher zu kopieren und gleichzeitig während des Kopierens wieder Datensätze geändert werden?

Kann mir da jemand mit einem Denkansatz weiterhelfen?

Ciao
Stefan

[haentschman]

Moin...8-)

Was ist für dich eine Datenbank, welches DBMS?

[jobo]

Das klingt für mich etas schief.
Entweder,
Du hast eine DB in der Cloud, as a service, vielleich auch direkt, Du hast Images, die Du beliebig anwerfen und vermieten kannst oder ähnliches
oder
Du hast eine DB im Netz(Cloud), deren Daten Du mit diveresen Clients replizieren, synchronisieren willst.

Vielleicht kannst Du mal erläutern, was es genau sein soll.

[TigerLilly]

"Cloud" ist ein recht wolkiger Begriff. Es gibt dateibasierte Konzepte (Dropbox, GoogleDrive etc), da hast du deine Dateien lokal + ein eigener Dienst synchronisiert sie auf und von einem Server.
Oder du hast einen echten Server irgendwo im Netz (so wie Azure oder die Amazon Cloud), dort laufen Programme und Dienste.

"Datenbankhandling über eine Cloud" kann heißen, dass du deine Datenbank in die Dropbox legst. Dann wird die ganze Datei bzw Datenbank filebasiert synchronisiert. Wie du richtig sagst funktioniert das bei gleichzeitigen Zugriffen nicht, denn physisch gibt es die DB ja mehrfach.

Liegt die DB aber zB in Azure, dann gibt es sie nur 1x + der DB-Server kümmert sich um die Synchronisation der Zugriffe.

Google mal nach Replication und verteilten Transaktionen. :thumb:

[hoika]

Hallo,

Zitat:

Irgendwie fehlt mir jedoch die Vorstellung, was passiert wenn das Cloudsystem (ggf. langsamer Upload) dabei ist, die Datenbank von lokal zum Cloudspeicher zu kopieren und gleichzeitig während des Kopierens wieder Datensätze geändert werden

Das muss die Datenbank zusammen mit dem Cloudsystem handeln, z.B. über Datensatz-Sperren.
Das "Kopieren" ist ein ganz normales Datenbank-Update, so als wäre es lokal.

[skoschke]

Vielleicht etwas genauer:

Auf dem Handy gibt es eine SQLite-Datenbank, die in OwnCloud "gespiegelt" wird.
(es könnte aber auch OneDrive oder sonstwas sein, was der Anwender später benutzt).

Auf der anderen Seite gibt es eine Windows-Anwendung, welche diese Datenbank wiederum "gespiegelt" aus der Cloud erhält.

Wenn die Windows-Anwendung nun darin Datensätze ändert, geht das über die Cloud-Synchronisation dann auch wieder zurück zum Handy...

Das sollte unproblematisch laufen, nur was passiert wenn auf der Windows-Seite und gleichzeitig auf der Handyseite etwas an der DB geändert wird?

Ciao
Stefan

[TigerLilly]

Am Beispiel DropBox:
https://www.dropbox.com/de/help/sync...onflicted-copy

Das Problem ist, dass DropBox bzw alle dateibasierten Cloudlösungen die DB-Schreibzugriffe nicht als solche behandeln, sondern als reine Dateiänderungen.

Du verstehst diesen Unterschied?

Entweder bekommst du wie bei DropBox eine zweite "Kollisions"-Datei oder es gilt der "Zweite gewinnt".

[skoschke]

OK, danke, jetzt habe ich es verstanden, bringt mich aber nicht so richtig weiter :-(

Mir fällt kein Weg ein, das ohne diese Dateikonflikte zu lösen, oder hat jemand eine Idee dazu?

Ciao
Stefan

[hoika]

Hallo,

Zitat:

nur was passiert wenn auf der Windows-Seite und gleichzeitig auf der Handyseite etwas an der DB geändert wird?

der letzte gewinnt.
Das musst Du dann selber programmieren (z.B. ein DB-Log mitführen und auswerten).

Dafür ist OwnCloud nicht gedacht.

[TigerLilly]

@hoika: Das ist kein guter Tipp, weil du eine DATEI(!)Kollision mit konkurrierenden Schreibzugriffen auf eine DB vermischt.

@skoschke: Sei kreativ! 8-)
- Sorg dafür, dass nur einer in die DB schreiben kann.
- Nimm einen SQL-Server und mach alle(!) Schreibzugriffe Konkurrent + vergiss die DropBox.
- Bestimme einen Client als Master, der darf in die DB schreiben. Diese DB wird via DropBox synchronisert. Alle(!) anderen Clients erzeugen nur Änderungsprotokolle, die via DropBox zum Master gesynct werden, der sie dann in die DB überträgt. Aber Achtung: Das ist nicht trivial.

[Rollo62]

Da ist eine grundsätzliche Frage die mir bei Cloud (egal Google, AWS, Azure) unklar bleibt.
Vielleicht passt das ja hier auch ganz gut hin.

1. Ich habe z.B. eine Tabelle (oder was auch immer) in der Cloud.
2. Dazu gehört ja i.d.R. eine App
3. Für die App bekomme ich immer einen ApiKey
4. Die Nutzer könnten als weitere Tabelle angelegt werden.
5. Ich kann in meiner App mehrere Nutzer auf die gleiche Tabelle zugreifen lassen,
   und die App hat über den EINEN ApiKey den Zugriff auf die Tabelle.
6. Für die User habe ich aber i.d.R. KEINEN separaten UserKey, oder etwa doch ?

Was ich meine ist:
Bedeutet das nicht:
Das meine App die EIN User regulär nutzt von diesem gehackt werden kann ?

So das dieser User mit dem ApiKey (über den er ja regulär Zugriff hat),
dann einfach die ganze Tabelle ausliest (Vollzugriff), und nicht nur einen für ihn bestimmten Teil ?

Ok, man könnte sich da sicher die ein oder andere Sicherheitsmethode drumrum bauen,
aber in der Standardtabelle/anwendung, z.B. per SQL, sehe ich keine Beschränkung durch spezielle UserToken o.ä.

Ich bin bis jetzt eher theoretisch damit unterwegs gewesen, und habe nur ein paar kleinere Versuche gemacht.
Aber für ein MultiUser-Management müsste man dann extra zahlen, dan ist man auch womöglich in verschiedenen Tabellen unterwegs, und relativ schnell auf horrende Summen.

Wie würde denn in der Cloud eine sicher MultiUser-App aussehen, in der alle User voll gegeneinander gekapselt sind ?

Sehe ich das richtig, oder bin ich da vielleicht auf der falschen Fährte ?

Rollo

[TigerLilly]

Naja, ich finde, das passt nicht ganz daher, aber sei´s drum:

Das was du beschreibst ist die "Mandantenfähigkeit". In einer Datenbank liegen viele Daten, aber immer nur Teile davon sind einem User/einer App/einem Mandaten zuzuordnen bzw dürfen von ihm verarbeitet werden.

Ob die DB in der Cloud liegt oder nicht, ist da egal. Deine App muss dafür sorgen, dass deine User nur die Daten sehen, die sie sehen dürfen.

Der API-Key erlaubt den Zugriff auf das (nona) API bzw den entsprechenden Dienst (muss ja kein API sein). Im Fall von Azure hast du zB einen Datenbankserver + kein API.

[Rollo62]

Vielleihct ist "mandantenfähig" zu viel des Guten.

Was ich meine ist, du hast ein App,

1. wo sich sagen wir mal 1000-10000 einzelne Nutzer registrieren.
2. jeder User kann sich selbst registrieren und bekommt ein Unique-UserToken.
3. Jetzt möchte jeder vielleicht seinen kleinen Bereich nutzen,
   sei es seine Settings speichern, seine Messdaten speichern, nichts Besonderes halt.

Mit dem AccessToken hätte doch ein User die Möglichkeit des Vollzugriffs, wenn er etwas hacken könnte ?

Wenn ich dafür schon die "mandantenfähige" Cloud brauche bin ich schnell im 3-4 stelligen Bereich pro Monat, und deshalb halte ich noch ziemlichen Abstand zur Cloud.
Und der User müsste aufwändig an der Cloud registriert werden.
Das mit der "günstigen" Cloud ist IMHO nämlich eine Mogelpackung :stupid:

Es müsste aber doch eine "kleine" Lösung geben für solche Anwendungen,
und ich denke das ist es was der TE genauso sucht wie ich.
(also deshalb hoffe ich der TE mir diese kleine Zwischenfrage erlaubt :oops:)

Über DropBox, OwnCloud, etc. habe ich natürlich entsprechend auch nachgedacht,
ich bin aber im Moment eher bei einer kleinen PHP-Lösung mit REST-Service stehengeblieben.

Rollo

[mjustin]

Zitat:

Zitat von Rollo62 (Beitrag 1417685)

Wie würde denn in der Cloud eine sicher MultiUser-App aussehen, in der alle User voll gegeneinander gekapselt sind ?

Bei Firebase über Berechtigungen. Man kann Resourcen (Daten) Berechtigungen geben, damit sind diese dann

* öffentlich, ohne Anmeldung, zugänglich
* öffentlich, aber nur nach Anmeldung zugänglich
* nur dem Besitzer zugänglich
* nur einer Benutzergruppe zugänglich

Code:

service firebase.storage {
  match /b/{bucket}/o {
    match /images {
      // Anyone can view any image (no auth, publicly readable)
      match /{allImages=**} {
        allow read;
      }

      // Only authenticated users can write to "public" images
      match /public/{imageId} {
        allow write: if request.auth != null;
      }

      // Only an individual user can write to "their" images
      match /{userId}/{imageId} {
        allow write: if request.auth.uid == userId;
      }

      // Allow a "group" of users to read/write to shared images
      // An owner metadata property on the object contains the groupId for reads
      // A custom token has been minted with a groupId property for writes
      match /{groupId}/{imageId} {
        allow read: if resource.metadata.owner == request.auth.token.groupId;
        allow write: if request.auth.token.groupId == groupId;
      }
    }
  }
}

https://firebase.google.com/docs/sto.../user-security

Den API Key benötigt man nur, damit sich die App bei der Verbindunng zu Firebase legitimieren kann.

[Rollo62]

Hallo Michael,

Richtig, Firebase hatte ich in der Liste vergessen.
Könnte eine einfache Möglichkeit sein, ich tendiere sowieso eher zu Firebase statt anderen Clouds für mobile Anwendungen, weil da Alles drin ist was man braucht.

Etwas schwammig bleiben immer die Kosten, die muss man sich z.B. bei AWS von zig Stellen zusammensuchen und grob schätzen, und erlebt hinterher böse Überraschungen.
Z.B. hatte ich mal eine "tote" EC2 Instanz die nach 1 Jahr Test angefangen hat ca. 18 EUR pro Monat abzubuchen, ohne das darauf irgendwas gelaufen ist.
Zum Glück hatte ich nicht noch 50 andere Services getestet.
Wie ist das für eine simple Anwendung bei Firebase, kannst du das kostenmäßig empfehlen ?
Google ist ja mit den Free Tiers recht moderat.

Wichtig wäre ja das ein Nutzer sich selbst einen privaten Bereich auf dem Service anlegen kann (nach Addresscheck),
ist das damit auch möglich, ohne das ein Admin das extra freigeben muss ?

Bei AWS gibt es ja auch etwas wie IAM Manager oder so ähnlich, für die Nutzerverwaltung.
Das ist aber ein relativ komplexes Thema, und braucht glaube ich immer EC2 Instanzen, auf die ich gerne verzichten würde.

Ach ja, bei AWS gibt es AWS Lightsail relativ neu, das habe ich mir aber noch nicht tiefer angesehen.

Rollo

[Morphie]

Zitat:

Zitat von Rollo62 (Beitrag 1417694)

Mit dem AccessToken hätte doch ein User die Möglichkeit des Vollzugriffs, wenn er etwas hacken könnte ?
...
Es müsste aber doch eine "kleine" Lösung geben für solche Anwendungen,
und ich denke das ist es was der TE genauso sucht wie ich.
(also deshalb hoffe ich der TE mir diese kleine Zwischenfrage erlaubt :oops:)

Ich habe deine Bedenken noch nicht so ganz verstanden.
Normalerweise läuft es doch so, dass man irgendeine REST-API (oder ähnliches) in der Cloud hostet, an die man sich dann technisch per Access-Token anmeldet. (OAuth2)
Zu keiner Zeit hat ein Nutzer von außerhalb direkten Zugriff auf die Datenbank. Jede Anfrage muss also durch die API gestellt werden, die natürlich nur die Daten bereitstellt, die für den angemeldeten Benutzer (über den Access-Token) ersichtlich sein sollen.

[Rollo62]

Was ich meine ist:

Wenn eine App und deren Cloud die Nutzerverwaltung selber macht,
dann gibt es EINEN AppToken, mit dem ich theoretisch auf alle Bereiche zugreifen kann.

Wenn die App also Nutzer anlegen, löschen, etc. kann, dann könnte sie auch auf ALLE Nutzerdatentabellen zugreifen.

Der Zugriff müsste in der Cloud verhindert werden, durch eine Art "UserToken" oder "Mandanten-Steuerung", wie auch immer.
So das ein angemeldeter User nur auf SEINE eigenen Daten zugriff hat.

Die App könnte z.B. sowas einbauen, aber ein Hacker könnte immer an den lokal gespeicherten AppToken kommen und sich generellen Zugriff verschaffen.
Es muss eine Art UserToken geben, den nur die Cloud verwaltet, und die Tabellen und Daten gegeneinander abschottet.


Rollo

[Morphie]

Im Grunde ist es dasselbe Problem wie bei Anmelde-Cookies auf einer Website.
Daher ist sicherzustellen dass die Tokens nicht extern ausgelesen werden können (Dafür gibt es in der Regel spezielle Mechanismen auf den Devices).
Außerdem benötigt man ein sicheres Übertragungsmedium. (HTTPS)

[Rollo62]

Ja, der Web-Server kümmert sich darum.

Aber die einfachen Cloud-Tabellen eben nicht automatisch.
So sehe ich das zumindest.
Entweder muss man das mit anderen Anmelde-Diensten verknüpfen, oder in der Cloud Mehrnutzer-Handling beantragen/zukaufen, etc.

Dehalb bin ich ja bei einem einfachen PHP Rest Service, der kann die Authentifizierung wieder selber übernehmen.

Es sei denn es gäbe einen Trick das auch bei AWS, Azure, etc. mit einfachen Mitteln hinzubekommen.
Der Tipp mit Firebase geht ja in die Richtung, muss ich checken.

[mjustin]

Zitat:

Zitat von Rollo62 (Beitrag 1417715)

Dehalb bin ich ja bei einem einfachen PHP Rest Service, der kann die Authentifizierung wieder selber übernehmen.

Selbst verwalten bringt natürlich wieder den Aufwand der Benutzer- und Passwortverwaltung mit sich. Wenn es um eine App geht, sind Facebook oder Google Konten eine beliebte Methode, ohne weitere Passworteingabe authentifizieren zu können. Damit braucht man auf dem Server keine Benutzer/Passwortzuordnung mehr. Sobald ein Benutzer z.B. ein Google Konto auf dem Smartphone nutzt, kann Google ein kontobezogenes Zugriffstoken erzeugen - dieses kann die App an den Server senden, der Server (z.B. ein Webservice) kann dieses Token bei Google gegenchecken lassen. Falls Google das Token als gültig bestätigt, kann der Server dem Client vertrauen. "Wer" der Client ist, kann der Server aus der Google-Antwort auslesen (z.B. die registrierte E-Mailadresse des Kontos).

p.s. mit der Google App Engine hatte ich vor einigen Jahren eine cloudbasierte Datenbank für Delphi madExcept Bugreports im Betatest[1][2], diese unterstützte bereits OpenID Identitätsprovider und trennte die Benutzerdaten je registriertem Benutzerkonto (aus Zeitmangel habe ich die Entwicklung dann eingestellt).

[1] https://www.delphipraxis.net/159516-...tegration.html
[2] https://mikejustin.wordpress.com/201...-in-the-cloud/

[Rollo62]

Hallo Michael,

ja dankesehr für die Info.
In Richtung BugTracker hatte ich auch schon überlegt, und ein Mantis-System hat z.B. einen SOAP-Zugang.
Ist aber nicht zum Speichern gedacht.

Zitat:

Google ein kontobezogenes Zugriffstoken erzeugen - dieses kann die App an den Server senden, der Server (z.B. ein Webservice) kann dieses Token bei Google gegenchecken lassen.

Das ist die Variante mit dem Mehraufwand, mit separaten z.B. PHP-Server, richtig ?
Oder meinst du das soetwas in den Clouds schon in Simpel existiert ?

Gibt es da von dir irgend etwas Fertiges in diese Richtung, um das einfach einzubinden ?
Das wäre ja interessant.

Mit Facebook-ID hatte ich auch schon geliebäugelt als Authentifizierung,
geht angeblich ohne weitere Services und Kosten.

Rollo