nicht angemeldet
Mysql-Blob vs. Filesystem bei Datensynchronisation
Mahlzeit,
folgendes Szenario:
4 Server an verschiedenen Orten, verbunden über Internet
Datenzugriffe/-änderungen erfolgen auf alle 4 Server.
Jetzt sollen die Daten (Datenbank, Bilder, Dokumente usw.) möglichst konsistent sein. Eine Verzögerung von 5-10 Minuten ist dabei kein Problem.
Macht es in dem Fall mehr Sinn, Binärdaten als Blob zu speichern, um bei der Replikation die Daten gleich mit zu synchronisieren oder ist es sinnvoller, per rsync über ssh die Dateien extra zu synchronisieren?
Es ist nicht möglich, dass zwei Personen gleichzeitig das gleiche Dokument bearbeiten. Damit muss dieser Aspekt nicht berücksichtigt werden.
Mir geht es in erster Linie um Geschwindigkeit und einfach Handhabung.
Gibt es evtl. noch weitere Möglichkeiten für mein Vorhaben? Eine externe Cloud oder sonstige externe Anbieter fallen aus.
Gibt es noch Aspekte, die ich evtl. nicht berücksichtigt habe?
-
Tach!
Macht es in dem Fall mehr Sinn, Binärdaten als Blob zu speichern, um bei der Replikation die Daten gleich mit zu synchronisieren oder ist es sinnvoller, per rsync über ssh die Dateien extra zu synchronisieren?
Definiere Replikation! Ist es der in MySQL eingebaute Replication-Mechanismus, der bei jeder Datenänderung am Master sofort die Slaves zu aktualisieren versucht, oder ist es ein eigenständiger Algorithmus, der zeitgesteuert aufgerufen wird?
Es ist nicht möglich, dass zwei Personen gleichzeitig das gleiche Dokument bearbeiten. Damit muss dieser Aspekt nicht berücksichtigt werden.
Nun ja, aber wenn grad jemand ein Dokument bearbeiten will, dessen Binärdaten noch nicht von einem separat laufenden rsync an den von ihm genutzten Server verteilt worden sind, dann ist das sicher nicht sehr schön.
Mir geht es in erster Linie um Geschwindigkeit und einfach Handhabung.
Der Flaschenhals ist das Netzwerk. Ob du die Daten nun auf die eine Weise oder die andere überträgst, spielt keine Rolle - wenn nicht einer von beiden durch Komprimierung einen Vorteil rausholt. rsync kann das, ob es die MySQL-Replication macht, weiß ich nicht. Kommt sicher auch darauf an, ob die Verbindung über einen komprimierenden Tunnel läuft oder nicht.
Einfache Handhabung ist, keinen zweiten Mechanismus warten zu müssen. Allerdings können Geschwindigkeitsaspekte auch zuungunsten einer einfachen Handhabung den Zuschlag bekommen.
dedlfix.
-
Definiere Replikation! Ist es der in MySQL eingebaute Replication-Mechanismus, der bei jeder Datenänderung am Master sofort die Slaves zu aktualisieren versucht, oder ist es ein eigenständiger Algorithmus, der zeitgesteuert aufgerufen wird?
Es wird entweder eine Master-Master-Replikation oder Master-Slave direkt in Mysql.
Nun ja, aber wenn grad jemand ein Dokument bearbeiten will, dessen Binärdaten noch nicht von einem separat laufenden rsync an den von ihm genutzten Server verteilt worden sind, dann ist das sicher nicht sehr schön.
Wie gesagt, das kann aktuell nicht passieren. Dazu mach ich mir Gedanken, wenn das vorkommen kann ;)
Der Flaschenhals ist das Netzwerk. Ob du die Daten nun auf die eine Weise oder die andere überträgst, spielt keine Rolle - wenn nicht einer von beiden durch Komprimierung einen Vorteil rausholt. rsync kann das, ob es die MySQL-Replication macht, weiß ich nicht. Kommt sicher auch darauf an, ob die Verbindung über einen komprimierenden Tunnel läuft oder nicht.
Ich hab auch nichts gefunden, dass Mysql komprimieren könnte.
Einfache Handhabung ist, keinen zweiten Mechanismus warten zu müssen. Allerdings können Geschwindigkeitsaspekte auch zuungunsten einer einfachen Handhabung den Zuschlag bekommen.
Da es hier ja keine komplizierte Sache ist, rsync entsprechend aufzusetzen, würde ich hier eher auf Geschwindigkeit setzen. Muss aber erst noch sehen, obs keine unvorhergesehenen Probleme geben kann.
-
-
Moin!
4 Server an verschiedenen Orten, verbunden über Internet
Datenzugriffe/-änderungen erfolgen auf alle 4 Server.Jetzt sollen die Daten (Datenbank, Bilder, Dokumente usw.) möglichst konsistent sein. Eine Verzögerung von 5-10 Minuten ist dabei kein Problem.
CouchDB kann Multi-Master-Replikation sehr gut und einfach. Insbesondere auch bei unzuverlässigen Verbindungen ist die Wiederaufnahme kein Thema, oder alternativ das Anstoßen der Replikation on-demand.
Nur kannst du dann natürlich deine MySQL-DB wegwerfen.
Das kannst du vermutlich aber auch dann, wenn dein Replikationskanal mal abstirbt. Ich erinnere mich, dass MySQL-Replikation nicht ganz so pflegeleicht ist.
Macht es in dem Fall mehr Sinn, Binärdaten als Blob zu speichern, um bei der Replikation die Daten gleich mit zu synchronisieren oder ist es sinnvoller, per rsync über ssh die Dateien extra zu synchronisieren?
Definiere "sinnvoll". Auf welcher Skala wird das bewertet? Geschwindigkeit? Konsistenz? Zuverlässigkeit?
Es ist nicht möglich, dass zwei Personen gleichzeitig das gleiche Dokument bearbeiten. Damit muss dieser Aspekt nicht berücksichtigt werden.
Doch, das ist es grundsätzlich erstmal. Wer verhindert das? Und wie?
Mir geht es in erster Linie um Geschwindigkeit und einfach Handhabung.
Einfache Handhabung: Nimm nur EINS, nicht zwei verschiedene Kanäle. Wenn der eine kaputt ist, merkt man das und repariert ihn.
Geschwindigkeit: Musst du ausmessen. MySQL-Replikation verschickt alle an den Master gesendeten SQL-Kommandos auch an alle Slaves, damit sie dort erneut ausgeführt werden. Das sollte zwar auf Binärebene geschehen, aber Updates schreiben immer alle aktualisierten Daten des Querys nochmal neu auf das Ziel, egal ob die dort schon mal vorlagen.
Gibt es evtl. noch weitere Möglichkeiten für mein Vorhaben? Eine externe Cloud oder sonstige externe Anbieter fallen aus.
CouchDB. ;)
Gibt es noch Aspekte, die ich evtl. nicht berücksichtigt habe?
Du hast behauptet, man könne nicht parallel am gleichen Dokument arbeiten. Das bezweifle ich. Entweder hast du recht große Latenzen, um eine angeforderte Sperrung eines Dokuments erstmal von allen Mastern rückbestätigt zu bekommen, oder das System ist nicht zuverlässig dagegen gesichert.
- Sven Rautenberg
-
CouchDB kann Multi-Master-Replikation sehr gut und einfach. Insbesondere auch bei unzuverlässigen Verbindungen ist die Wiederaufnahme kein Thema, oder alternativ das Anstoßen der Replikation on-demand.
Schau ich mir direkt mal an. Da das System so ausgelegt ist, dass zum Implementieren einer neuen DB-Software nur eine Klasse ausgetauscht werden muss, würde sich der Aufwand in Grenzen halten.
Nur kannst du dann natürlich deine MySQL-DB wegwerfen.
Damit kann ich leben. Entscheidend ist, dass die Wartung dauerhaft möglichst einfach ist.
Das kannst du vermutlich aber auch dann, wenn dein Replikationskanal mal abstirbt. Ich erinnere mich, dass MySQL-Replikation nicht ganz so pflegeleicht ist.
Ich kenn das nur vom Lesen, noch nie ne Replikation im Einsatz gehabt.
Definiere "sinnvoll". Auf welcher Skala wird das bewertet? Geschwindigkeit? Konsistenz? Zuverlässigkeit?
1. Zuverlässigkeit
2. Konsistenz
3. GeschwindigkeitSo ist die Gewichtung. Wenn das Grundsystem erstmal steht, kümmere ich mich darum, dass die Bearbeitung von einem Dokument durch mehrere Personen abgefangen wird. Da das in absehbarer Zeit, wie erwähnt, absolut unmöglich ist, eilt das aber nicht.
Doch, das ist es grundsätzlich erstmal. Wer verhindert das? Und wie?
Nein, ist es nicht. Aktuell kann ein Dokument nur beim Hochladen bearbeitet werden. Liegt es erstmal auf dem Server kann es nur gelesen werden. Bearbeiten vorhandener Dokumente ist nur auf einem einzigen Server möglich und da kann nur ich allein dran.
Mir geht es in erster Linie um Geschwindigkeit und einfach Handhabung.
Einfache Handhabung: Nimm nur EINS, nicht zwei verschiedene Kanäle. Wenn der eine kaputt ist, merkt man das und repariert ihn.
Geschwindigkeit: Musst du ausmessen. MySQL-Replikation verschickt alle an den Master gesendeten SQL-Kommandos auch an alle Slaves, damit sie dort erneut ausgeführt werden. Das sollte zwar auf Binärebene geschehen, aber Updates schreiben immer alle aktualisierten Daten des Querys nochmal neu auf das Ziel, egal ob die dort schon mal vorlagen.
Ok, das lass ich mir nochmal durch den Kopf gehen.
Gibt es evtl. noch weitere Möglichkeiten für mein Vorhaben? Eine externe Cloud oder sonstige externe Anbieter fallen aus.
CouchDB. ;)
Wie geschrieben, schau ich mir an, hört sich gut an.
Du hast behauptet, man könne nicht parallel am gleichen Dokument arbeiten. Das bezweifle ich. Entweder hast du recht große Latenzen, um eine angeforderte Sperrung eines Dokuments erstmal von allen Mastern rückbestätigt zu bekommen, oder das System ist nicht zuverlässig dagegen gesichert.
Absolut zuverlässig, wie geschrieben, kann ein Dokument nach dem Hochladen nicht mehr geändert werden. einen besseren Schutz vor paralleler Bearbeitung dürfte es kaum geben ;)
-
Tach!
CouchDB [...]
Schau ich mir direkt mal an. Da das System so ausgelegt ist, dass zum Implementieren einer neuen DB-Software nur eine Klasse ausgetauscht werden muss, würde sich der Aufwand in Grenzen halten.Ich stell mir das nicht ganz einfach vor, weil RDBMS und die dokumentenbasierenden Systeme schon von der Philosophie her unterschiedlich arbeiten. Wenn deine Anwendung datensatzorientiert ist, dann wirst du aus einer dokumentenbasierenden Ablage nicht das Optimum rausholen. (Stell ich mir zumindest vor. Erfahrungen damit hab ich keine.)
Das kannst du vermutlich aber auch dann, wenn dein Replikationskanal mal abstirbt. Ich erinnere mich, dass MySQL-Replikation nicht ganz so pflegeleicht ist.
Ich kenn das nur vom Lesen, noch nie ne Replikation im Einsatz gehabt.Es ist recht einfach aufzusetzen. Auch wenn das Handbuch dazu eine ziemliche Menge schreibt, halten sich die eigentlichen Handlungen in Grenzen. Zu einem ernsthaften Betrieb gedieh das Projekt aber nicht, so dass mir die praktische Erfahrung fehlt. Aber eigentlich merkt sich der Slave, wie weit er gekommen ist und setzt nach einem Abbruch an genau der Stelle fort, das inzwischen am Master weiter gefüllte Log abzuarbeiten.
MySQL-Replikation verschickt alle an den Master gesendeten SQL-Kommandos auch an alle Slaves, damit sie dort erneut ausgeführt werden. Das sollte zwar auf Binärebene geschehen, aber Updates schreiben immer alle aktualisierten Daten des Querys nochmal neu auf das Ziel, egal ob die dort schon mal vorlagen.
Was ist das spezielle am Binären, wenn trotzdem Statements ausgeführt werden müssen? Im Log-File stehen die Statements jedenfalls nicht vorkompiliert oder so drin. Das für die Replikation verwendete Log heißt zwar Binary-Log, aber es werden trotzdem auf den Slaves die kompletten Statements abgearbeitet. Auch Stored Procedures werden komplett durchlaufen und nicht nur deren Änderungen am Datenbestand synchronisiert. - Ich blättere grad durch das Replication-Kapitel und stelle fest, dass es sowohl statement-based als auch row-based Replication gibt. In meiner Erinnerung befand sich jedoch nur ersteres.
dedlfix.
-
Ich stell mir das nicht ganz einfach vor, weil RDBMS und die dokumentenbasierenden Systeme schon von der Philosophie her unterschiedlich arbeiten. Wenn deine Anwendung datensatzorientiert ist, dann wirst du aus einer dokumentenbasierenden Ablage nicht das Optimum rausholen. (Stell ich mir zumindest vor. Erfahrungen damit hab ich keine.)
Auf die Mysql-Datenbank kann das System eh nicht verzichten, wäre zuviel Aufwand, CouchDB kommt dann eh nur für diesen einen Einsatzzweck dazu.
Aber von der Philosophie ist es wirklich kein Problem, da meine Klasse Anfragen nach dem Schema "Schreibe Daten X in die Tabelle Y nach dem Schem Z", die Queries werden dann in der Klasse zusammengebaut.
Da ich nur recht einfache Datenbankabfragen hab, ist das kein Problem, kompliziert wirds erst, wenn ein Query direkt abgesetzt werden muss, weils die Klasse sonst nicht umsetzen kann. Dann müsste ich auswerten, welche Datenbank ich anspreche.
Das kommt aber nur in einer meiner Erweiterungen vor und würde somit den Aufwand in Grenzen halten ;)Konzeptmässig plane ich aktuell so: Alles, was Dokumentenbasiert ist und auf mehreren Servern verfügbar sein muss, wird auf CouchDB aufgebaut, der rest, wie lokale Sessions, Userdaten (verschiedene User in verschiedenen Netzwerken für verschiedene Server mit verschiedenen Rechten) usw. bleibt Mysql.
Auf jeden Fall Danke an dich und auch an Sven, hat mir sehr geholfen der Thread. Und ne Gelegenheit, etwas neues zu lernen, hab ich nie ausgelassen :D
-
-
-
CouchDB. ;)
Hab jetzt mal erste Gehversuche unternommen, gefällt mir bisher gut :)
Was fein ist, es gibt keine starre Tabellenstruktur sondern jedes Dokument kann praktisch beliebige Felder enthalten die sich von Dokument zu Dokument unterscheiden.Was jetzt noch fehlt, ist ne API für PHP, die aktiv entwickelt wird, damit ich kein eigenes Süppchen kochen muss. Die Hauptanwendung läuft mit PHP.
Aktuell bin ich bei PHP on Couch hängengeblieben, hab mir aber PHPillow angesehen und ein paar andere. Aber meist halt mehrere Jahre Stillstand (meist von 2010).
Mal sehen, was sich da von ergibt. Auf jeden Fall ist die Art der Datenbank ne echt feine Sache :)
-