Ist diese Idee eines verteilten Datenbankservers mit zentralem Speicher realisierbar?

Ich verwende SQLite oft zum Erstellen einfacher Programme in Unternehmen. Die Datenbank wird auf einem Dateiserver abgelegt. Dies funktioniert einwandfrei, solange nicht mehr als 50 Benutzer gleichzeitig an der Datenbank arbeiten (je nachdem, ob sie gelesen oder geschrieben wird). Sobald es mehr als dies gibt, werden sie eine Verlangsamung bemerken, wenn viel gleichzeitig auf dem Server geschrieben wird, da viel Zeit für Sperren aufgewendet wird, und es gibt nichts Schöneres als einen Cache, da es keinen Datenbankserver gibt.

Der Vorteil, keinen Datenbankserver zu benötigen, besteht darin, dass die Zeit zum Einrichten eines Unternehmens-Wikis oder ähnlichem von mehreren Monaten auf nur wenige Tage reduziert werden kann. Es dauert oft mehrere Monate, da einige IT-Abteilungen den Server bestellen müssen und er den Unternehmensrichtlinien und Sicherheitsregeln entsprechen muss. Er muss auf der ausgelagerten Server-Hosting-Einrichtung platziert werden, die es vermasselt und an der falschen Stelle platziert usw. usw.

Daher habe ich mir überlegt, einen verteilten Datenbankserver zu erstellen. Der Prozess wäre wie folgt: Ein Benutzer auf einem Firmencomputer bearbeitet etwas auf einer Wiki-Seite (die diese Datenbank als Backend verwendet). Dazu liest er eine Datei auf der lokalen Festplatte, in der die IP-Adresse des letzten Desktop-Computers angegeben ist ein Datenbankserver sein. Anschließend versucht er, diesen Computer direkt über TCP / IP zu kontaktieren. Wenn es nicht antwortet, liest er eine Datei auf dem Dateiserver, in der die IP-Adresse des letzten Desktop-Computers angegeben ist, der ein Datenbankserver ist. Wenn dieser Server auch nicht antwortet, wird sein eigener Desktop-Computer zum Datenbankserver und registriert seine IP-Adresse in derselben Datei. Die SQL-Update-Anweisung kann dann ausgeführt werden, und andere Desktop-Computer können eine direkte Verbindung zu ihm herstellen.

Der Punkt bei dieser Architektur ist, dass je höher die Last, desto besser die Funktion ist, da jeder Desktop-Computer immer die IP-Adresse des Datenbankservers kennt. Mit diesem Setup glaube ich auch, dass eine Datenbank, die auf einem Dateiserver abgelegt ist, Hunderte von Desktop-Computern anstelle der aktuellen 50 oder so bedienen kann. Ich glaube auch nicht, dass die Belastung des einzelnen Desktop-Computers, der zum Datenbankserver geworden ist, jemals spürbar sein wird, da auf diesem Desktop keine Festplattenvorgänge ausgeführt werden, sondern nur auf dem Dateiserver.

Ist diese Idee machbar? Existiert es schon? Welche Art von Datenbank könnte eine solche Architektur unterstützen?

Bearbeiten: Ich sollte darauf hinweisen, dass diese Idee nicht hübsch, stabil, Best Practice oder etwas ist, auf das ich wirklich stolz sein würde. Der Grund, warum ich immer noch an der Machbarkeit interessiert bin, ist, dass einige meiner Kunden Banken sind und die Bürokratie, die mit dem Zugriff auf eine Datenbank verbunden ist, enorm ist. Oft muss der Projektsponsor für solche Projekte aufgrund seiner extremen Sicherheitsbedenken hinsichtlich des Zugriffs auf Server über dem Niveau des Vizepräsidenten liegen. Das bedeutet natürlich, dass es viel Arbeit gibt, ein Wiki einzurichten. Wenn sich das Wiki später als erfolgreich erweist, sollte es natürlich auf einen geeigneten Datenbankserver migriert werden.

Edit2: Der Grund für diese Idee besteht darin, das Risiko von Writer Starvation bei Verwendung von SQLite zu verringern, wenn die Datenbank auf dem Dateiserver abgelegt wird. Dieses Problem wird in Abschnitt 5.1 beschrieben hier . Die Verwendung eines Desktop-Computers für einen Cache mit den am häufigsten aufgerufenen Informationen (z. B. Wiki-Seiten) würde bedeuten, dass die Arbeitslast auf dem Dateiserver drastisch reduziert würde. Dies sollte wiederum die Benutzererfahrung verbessern. Glaubst du wirklich, dass ich mit dieser Idee noch weit weg bin?

Sie könnten tatsächlich eine gute verteilte Datenbankumgebung erstellen, wenn Sie Ihre Lese- und Schreibvorgänge in verschiedenen Datenbanken partitionieren (oder darauf abzielen). Wir machen solche Arbeit und der Trick ist sehr einfach. Sie haben die Master-Datenbank auf einem Dateiserver und zielen auf alle Schreibvorgänge ab. Sie haben eine lokale Kopie der Datenbank auf dem Computer jedes Benutzers und richten die Lesevorgänge darauf aus. Sie benötigen jetzt auch einen Synchronisationsmechanismus zwischen der Master-Datenbank und den lokalen Datenbanken. Dies kann auf verschiedene Arten erfolgen. Eine Möglichkeit besteht darin, eine "Delta" -Tabelle in der Master-Datenbank zu haben. Diese Delta-Tabelle enthält die Transaktionen, die in der Master-Datenbank angewendet wurden. Immer wenn die Anwendung des Benutzers eine Lese- oder Schreiboperation ausführt, wird das Delta auf dem Master zuerst lokal überprüft und aktualisiert. Es müssen nur die noch nicht angewendeten Transaktionen im Delta angewendet werden (die anhand des Zeitstempels überprüft werden können). Sie könnten sogar einen Hintergrundprozess haben, der dies kontinuierlich durchführt. Dieses Delta kann ein tägliches Delta (oder ein wöchentliches Delta) sein, wenn es gespült wird. Wenn sich ein Benutzer etwa eine Woche lang nicht angemeldet hat, kopieren Sie einfach die gesamte Datenbank auf den Computer des Benutzers. Der Vorteil einer lokalen Kopie besteht darin, dass Benutzer Inhalte abfragen können, auch wenn sie offline sind, und - ob Sie es glauben oder nicht - dies ist ziemlich schnell, selbst wenn Sie Online-Aktualisierungen durchführen.

Ist diese Idee machbar?

Nein.

Existiert es schon?

Nicht, dass ich davon Wüste.

Welche Art von Datenbank könnte eine solche Architektur unterstützen?

Siehe oben.

Ehrlich gesagt ist dies auf vielen Ebenen eine wirklich schlechte Idee. Es gibt einen Grund, warum Unternehmen wichtige Daten im Rechenzentrum aufbewahren. Sie möchten nicht, dass Geschäftsanwendungen von der Anzahl der betriebsbereiten Desktop-Computer abhängig sind. Ein weiteres Problem wären Firewalls - in allen außer kleinen Umgebungen gibt es keine Garantie dafür, dass Desktop X mit Desktop Y kommunizieren kann, und viel Glück, dass sich die Firewall an Ihrem Netzwerkteam vorbei ändert.

Gibt es einen Grund, warum Ihr Unternehmen keinen zentralen, gut gewarteten Datenbankserver hat, den diese App verwenden kann? Es gibt keinen Grund, warum ein Unternehmens-Wiki einen eigenen Datenbankserver benötigen sollte.

Diese Frage bezieht sich nicht auf die Systemadministration, aber als ich sie las, gingen so viele Warnalarme aus, dass ich sie nur beantworten muss.

Ich muss Ihnen wirklich sagen, dass Ihr gesamtes Konzept so weit vom Ziel entfernt ist, dass Sie niemanden finden, der es tut. Für den Anfang ist SQLite für solche Jobs ungeeignet und die Tatsache, dass Sie damit einige Erfolge erzielt haben, ist eher dem Glück als irgendetwas anderem zu verdanken.

Ihr Plan enthält so viele Lücken, dass ich wirklich nicht weiß, wo ich anfangen soll, aber ich werde Ihnen sagen, dass es sich um ein übermäßig komplexes System handelt, das sich als unglaublich unzuverlässig und leistungsschwach erweisen wird.

Dein Kommentar

Die Zeit, um so etwas wie ein Firmen-Wiki oder ähnliches einzurichten, kann von mehreren Monaten auf nur Tage reduziert werden

Erzählt mir viel. Das Einrichten eines Wikis dauert normalerweise nur wenige Minuten, und jedes anständige Wikisystem verfügt über Hilfsmittel, um den Import von Daten aus anderen Systemen zu beschleunigen.

Ich schlage vor, Sie geben Ihre aktuellen Designideen auf und schauen sich an, wie solche Dinge von anderen gemacht werden. Wenn Sie eines der gängigen Wiki-Systeme (ich bevorzuge MediaWiki) mit einem regulären Datenbanksystem verwenden (MySQL ist sehr beliebt), sparen Sie nicht nur viel Zeit, sondern erhalten auch ein System, das sowohl benutzerfreundlicher als auch benutzerfreundlicher ist robuster und viel billiger zu implementieren.

Kurz gesagt, hören Sie auf, das Rad neu zu erfinden, da Ihr aktuelles Design eher wie ein Quadrat mit einem Loch in der Mitte aussehen wird.

Wie bereits erwähnt, liegt diese Frage außerhalb des Bereichs der Systemadministration. Verteilte Datenbanken und verteilte Datenspeicher werden jedoch an einigen sehr erkennbaren Stellen verwendet. Während sich die Stärken von SQLite im Allgemeinen nicht für diesen Typ eignen, wenn es sich um eine Anwendung handelt, ist dies nicht ungewöhnlich. Schauen Sie sich zum Beispiel das Fossil- Projekt an. Obwohl dies ein verteiltes Versionsverwaltungssystem ist, das auf SQLite basiert, bietet es auch ein verteiltes Wiki und eine Blogging-Anwendung und könnte tatsächlich den Trick für Sie tun. Während Sie wahrscheinlich über SQLite hinausschauen sollten, bedeutet dies nicht, dass Sie Open Source aufgeben müssen. Erwägen Sie, Ihr Projekt in Apache CouchDB zu implementieren oder ein Hadoop-basierter Datenspeicher Ein noch neuerer Ansatz besteht darin, Anwendungen in einer verteilten virtuellen Umgebung mit Benutzerbereich wie Inferno zu erstellen.

Ihre Beschreibung ähnelt stark der Verwendung von POS-Systemen (Point of Sale). Beim Start wird ein Master-Terminal deklariert, das die Datenbankverarbeitung ausführt. Eine Kopie der Datenbank wird zur Sicherung zwischen dem Master und allen Slave-Terminals synchronisiert.

Wenn der Master ausfallen sollte, wird auf allen anderen Terminals die Meldung "Mach mich zum neuen Master?" Angezeigt. Sie drücken Ja und alles geht weiter. Dies konnte fortgesetzt werden, bis ein Terminal stand.

Es funktioniert und ist eine Art idiotensicherer Beweis, aber eine beschädigte Datenbank am Ende des Tages ist üblich. Glücklicherweise speichern die Terminals nur die Verkäufe an diesen Tagen, sodass Ihre täglichen Gesamtbeträge möglicherweise etwas abweichen, da einige Bestellungen nicht richtig gespeichert wurden. Dies wird dem System vorgezogen, das einige Stunden lang ausfällt und Verkäufe verliert.

Bei einem großen Netzwerk- / Stromausfall ist die Bereinigung am Ende des Tages das, was im Laufe der Zeit vorgesehen ist, da die Verkäufe der aktuellen Tage auf mehrere verschiedene Terminals verteilt werden können und Sie alles klären müssen. Ich bin froh, dass ich diese Arbeit nicht mehr mache.

Halten Sie sich an einen großen Datenbankserver mit guten Backups.

Aus Ihrer Frage geht nicht ganz hervor, wo sich die Daten letztendlich befinden. Lebt es auf dem zentralen Dateiserver? Wenn Sie das Datenbankmodul auf einer Vielzahl von Desktops verschieben, während Sie den zentralen Dateiserver als Plattenspeicher verwenden, erhalten Sie wahrscheinlich nicht viel Leistung. Wenn überhaupt, wird die Entfernung der Festplatte vom Motor wahrscheinlich dazu führen, dass sie, wenn überhaupt, schlechter läuft.

Wenn die Daten nicht zentralisiert sind, ist die Datenkonsistenz ein Problem, wenn Sie mehrere Desktops haben, die alle unterschiedliche Datenbits enthalten.

Ähnliche Probleme bestehen bei der Datenbankkonfiguration und -sicherheit, von denen keines trivial ist. Und schließlich hat das Ausführen eines Datenbankservers auf einem Desktop-Computer, auf dem mehr als 100 aktive Remotebenutzer arbeiten, spürbare Auswirkungen auf die Leistung dieses Desktops.

Haben Sie http://litereplica.io/ gesehen ? Sie haben einen sqlite3-Treiber für nodejs und er scheint ziemlich gut aufgebaut zu sein.

Ich habe kürzlich die Entwicklung einer verteilten Datenbankschicht für ein SOA / ESB / RESTful-Middleware-Framework abgeschlossen, das ohne die Abhängigkeit der Datenbankinfrastruktur proprietär sein musste und in c # mit einem Wrapper für SQLite erstellt wurde.

Meine Datenbankschicht arbeitet als Cluster von Knoten, die aus Zeugenknoten (Master und Failover), Datenschreib- / Festschreibungsknoten (wieder Master und Failover) und Replikationsknoten bestehen, in denen im Wesentlichen replizierte Daten gespeichert sind.

Bei Schreibvorgängen generiert der ausgewählte Schreibknoten eindeutige IDs und Fremdschlüssel, die den Speicherort erfolgreicher Datenschreibvorgänge auf Knoten indizieren. Dadurch wird sichergestellt, dass replizierte Daten dieselben IDs und Fremdschlüssel beibehalten. Es gibt Thread- / Parallelprozesse, die die Replikation aufrechterhalten. Fremdschlüssel werden nicht strikt durchgesetzt, funktionieren aber.

Ich habe auch einen Client-Wrapper für diese Datenschicht geschrieben, der ein Failover der Client-Verbindungszeichenfolge zwischen Zeugen ermöglicht.

Bisher scheinen Tests und Benchmarking das Konzept zu beweisen. Ich habe mit verschiedenen Datengrößen getestet und es scheint gut zu funktionieren. Da meine Datenbankschicht als Restful Middleware konzipiert ist, ist ihre Geschwindigkeit offensichtlich weniger wichtig als die Hochverfügbarkeit. Darüber hinaus sind die Anforderungen an die Struktur Ihrer Daten der Hauptfaktor dafür, ob dieser Ansatz funktioniert oder nicht.

Meine nächste Überarbeitung wird sein, um zu sehen, ob ich das Abrufen großer Datasets auf replizierte Knoten verteilen kann, wenn das Dataset an das Client-Framework gestreamt wird, eine Art Datenraster mit JSON-Idee.