Schnelle, verteilte Datenbank

  • Ich möchte mehrere Raspberrys (und vielleicht auch noch allgemein anderen Linux-Rechner) zu einem Verbund zusammenfügen. Und zwar ganz normal über das Netzwerk. Soweit so gut. Nun sollen auf jedem der Rechner bestimmte Hintergrundprogramme laufen, welche die angeschlossene Hardware ausliest, und zwar mit beliebiger Geschwindigkeit (ich denkle da so an eines bis zu 20 Werte pro Sekunde). Diese Werte sollen nun nicht irgendwie angezeigt werden, sondern in einer (verteilte) Datenbank weggesschieben werden. Hierzu sollte es eine linrary geben, welche ich zu meinen Ausleseprogrammen einfach hinzulinken kann und welche u.a. die Funktionen schreibe_wert und lese_wert bereitstellt.

    Verteilte Datenbank deshalb, weil das ganze auf allen Rechnern im Verbund genauso funktionieren soll, und ich möchte nicht bestimmen muessen, wo die werte tatsaechlich gespeichert werden. Überall sollen mit den gleichen Funktionen werte gelesen und geschrieben werden können. Natuerlich moechte ich auch mitbekommen, wenn ein anderer Rechner einen neuen Wert in die Datenbank geschrieben hat. Ich woll dann ggf. eine Routine triggern, die dann einen anderen Wert berechnet, und den wieder in die Datenbank schreibt. Und so weiter. ich hoffe, ich habe mich verstaendlich ausgedrückt. Wichtig ist:
    Auf jedem beliebigen rechner können sich Programme anmelden, dass die Aenderungen eines bestimmten wertes mitbekommen wollen (z.B. über eine callback-routine). Irgendow im Verbund könnte dann auch ein Programm laufen, was einige Werte in echtzeit grafisch anzeigt.

    Es sollte niemals ein in die Datenbank geschriebener Wert verlorengehen. Änderungen sollen mit kleinst möglicher Verzögerung an alle anderen programme (welche diese Werte benötigen) weiteregereicht werden.

    Die Datenbank muss einen guten Durchsatz haben,
    also alle Werte sollten mit bis zu 20 pro Sekunde zuverlaessig aufgenommen werden können und der ganze Mechanismus ikm Hintergrund (mitteilungen an andere Programme auf anderen rechnern) soll ganz transparent ablaufen. Kein rechner soll ausgezeichnet sein (also kein Server-Client modell).

    Welche Software (so es die gibt) würde man hierfür einsetzen?

  • 20 Datensätze/sec... soso...
    Mir ist zwar nicht klar, was das wird... aber sei es drum.

    Eine Möglichkeit wäre Datenbank(en) mit remote Sync. Können die üblichen Verdächtigen alle, also Oracle, MySql, PostgeSQL.
    Die gegenseitige Synchronisierung ist unterschiedlich kompliziert einzurichten, aber beherrschbar.
    Um wie viele einzelne Rechner soll es denn gehen? Weil: Der Netztrafik steigt mit etwa 2er Potenz der synchronisierten DBs... die Synchronisierung von mehr als 2 DBs miteinander ist schon etwas "Kunst".

    Einfacher Weg: Eine DB, jeder Dienst schreibt seine Daten direkt in eine DB, die auf einem der Rechner läuft (geht auch remote). Kannst du bei Bedarf per Python, HTMP, PHP oder weiss der geier mit irgendeiner Prog. Sprache machen...

  • Ja, das ist kompliziert, und mit einer einfachen Datenbank bin ich nicht zufrieden, denn das skaliert nicht. Ich möchte im Prinzip beliebig viele Rechner zum Verbund zusammenschalten können, ohne dass der Traffik quadratisch ansteigt. Hierzu benötigt man eine spezielle Software, die das relisiert. Eine verteilte Datenbank synchronisiert auch nicht immer den gesamten Inhalt an alle Teilnehmer, sondern nur den Teil, der auf dem jeweiligen Rechner auch benötigt wird. Ich frage nach einer vorhanden Software, weil ich sowas bisher nicht gefunden habe, und bevor ich das als Projekt selbt angehe, wollte ich schauen, ob es das schon gibt. Müsste eigentlich, denn es ist doch ein recht häufig anzutreffender Fall (viele Hardware, welche mit einigen verteilten Rechnern ausgelesen wird). Und von irgendwoher soll man das ganze steuern. Rechenintensive Berechnungen sollen auf andere Rechner ausgelagert werden können, damit nicht ein Rechner überlastet.

    Nur mal so ein Beispiel:

    Ein Raspberry Pi mit 20 Temperatursensoren. Die werden von einem Programm in einer Schleife alle 1 Sekunde ausgelesen. Die Werte werden dann mithilfe der Library in die Datenbank geschrieben, mit der Rate, wie sie anfallen (also 1 pro Sekunde).

    Ein anderer raspberry Pi, diesmal auf dem dachboden überwacht die Solaranlage, hat also einige Strom und Spannungswerte, vielleicht noch ne Temperatur,
    Die Stromwerte werden mit 3 Pro Sekunde ausgelesen, die Temperatur nur einmal pro Minute, was auch immer. Jeder wert wird dann mithilfe der Library in die Datenbank geschrieben.

    Dann noch ein Rechner, der die Türklingel bedient (Immer wenn die Klingel gedruckt wirtd, wird ein Zähler erhöht und in die Datenbank geschrieben).

    Ein anderer misst den Strom eines Motors und liefert 10 Werte pro Sekunde. --> in die Datenbank

    und so weiter.

    Nun gibt es einen etwas leistungsfaehigen Rechner, welche z.B. bei jeder aenderung des Stromwertes überprüft, ob was ungewöhnliches passiert ist, und wenn ja, wird ein parameter auf einen bestimmten Wert gesetzt, der wiederum in der Datenbank landet.

    Dann gibt es Prozesse (z.b. auf besagtem leistungsfähigen Rechner, oder aber auch auf einem beliebigen anderen), welche (einige) Parameter abboniert, und alle Aenderungen zeitnah mitgeteilt bekommt (ueber callback-routinen) die dann z.b. einen Alarm auslösen oder die Klingel läuten lassen etc.

    Ein weiteres Programm abboniert einige Parameter und zeigt sie auf einem GUI an, z.B. in einem simulierten Zeigerinstrument oder sonstwas. Da gibt es dann z.B. einen Button im Userinterface, immer wenn man den drückt, wird wiederum eine Variable in der Datenbank auf einen bestimmten Wert gesetzt. Das triggert dann wieder irgendwo eine Routine, die darauf reagiert. Ich denke, ihr bekommt eine Idee, was das soll.

    Was dazu nötig ist, ist eigetlich nur eine Library mit recht simpler API, was dass im Hintergrund dann synchronisiert, auf andere Rechner lauscht und ggf. callback-Routinen anstösst. Eigentlich ist es gar nicht so schwierig. Die Library muss z.B. nachfragen, wer einen bestimmten Datenbankparameter hat, wenn er angefordert wird, und dann den Wert holen und ann die Applikation weiterleiten. Oder der library auf einem anderen Rechner sagen, dass sie per Ethernet über alle Wertaenderungen einer Datenbankvariable informiert werden möchte, welche von besagtem Nachbarrechner gehostet wird.

    Das schwierigste ist herauszufinden, wer hostet welchen Parameter. Aber das kann ja über ein Protokoll abgefragt werden. Naja. Ich denke halt schon über die Relisierung nach, aber vielleicht gibt es das ja schon fertig. Wenn das ginge. liesse es sich für alle (grossen und kleinen) Raspberry Pi Projete verwenden, die mehr als einen Rechner im Verbund benötigen. Und mann kann zugreifen auf alle Variablen, als waere sie alle an einem Zentralrechner verfügbar (obwohl sie dann doch von einzelnen Mess-Rechnern zusammengetragen werden.).

  • Hast Du Dir mal MQTT angeschaut? Ist vielleicht ein etwas anderer Ansatz, aber das, was Dir vorschwebt, sollte sich darüber realisieren lassen. Ist für mich allerdings auch ziemlich neu, so ganz überblicke ich die Möglichkeiten noch nicht.

  • Also: (Performance MySQL auf RasPi)

    dermaster
    19. Februar 2016 um 21:17

    Im obigen Beispiel ist bei mir noch eine Apache-Webseite dazwischen, die für jeden Request eine einzelne Transaktion macht.

    Weiterhin Ich habe mal ca. 200.000 Datensätze (jeder Datensatz hatte Timestamp und 6 weitere Integer-Werte) per Python-Script remote von einem (leistungsfähigen) PC direkt in eine MySQL Datenbank auf einen RasPi B schreiben lassen...

    Der hat locker so um die 800 DS/sec geschafft, wenn man mehrerer DS zu einer Transaktion zusammen gefasst hat (bei mir waren es 1000DS/Transaktion).
    Entscheidend ist die Performance des "Plattenspeichers" - die SD Karte war letztlich der Anschlag... die RasPi-CPU hatte noch Reserven, die I/O-Load war aber sehr hoch... (Wait-Zyclen für Warten auf Medium).

    Insofern kann ich deine Bedenken mit der einen DB nicht schlüssig nachvollziehen... - nach dem, was du als Szenario beschrieben hast, macht das eine DB locker...
    Automatisch zusammengefügt:
    PS:
    Wichtig ist natürlich die sinnvolle Indexierung der Datentabelle(n) und die optimale Einstellung der der Datenbank-Parameter (Cache usw).
    Aber das wird dann relevant, wenn die ersten Engpässe kommen... setz doch mal ein Testscenario auf..!

  • MQTT kannte ich noch nicht. Danke. Von der Beschreibung her scheint es zumindest einige Anforderungen schonmal zu erfüllen . Publish/ subscribe waere eine Möglichkeit. Es muesste noch eine Art Broadcast mechanismus geben, wo jeder Rechner mitteilt, welche Parameter er anzubieten hat. Ich muss mich mal einlesen.
    Automatisch zusammengefügt:
    Zentris: Bist Du sicher, dass der Link korrekt ist? Ich komme auf eine Thema: Realisierungsschwierigkeit Rasbian.
    Ein Test lohnt immer. Mal sehen. Aber es hat, so wie ich das sehe eine Limitierung, wenn irgendwann die Datenbank zu gross wird, gehen alle beteiligten Rechner irgendwann in die Knie, und es nützt dann auch nichts, die Rechenpower durch mehr Rechner zu erweitern. Stimmts?

    Einmal editiert, zuletzt von wend (31. Oktober 2016 um 17:19)

  • Hallo,

    wend: deine Anforderungen sind IMHO so nicht umzusetzen - weil schlicht nicht alles auf einmal geht. Was ja auch das CAP-Theorem besagt.

    Was mir noch nicht klar ist: willst du _immer_ auf _allen_ Rechner möglichst alle Daten haben? Dann brauchst du eine echte Master-Master Replikation über alle Rechner. Nur braucht das natürlich entsprechend viel Netzwerkverkehr.

    Echte Master-Master Replikation ist z.B. CouchDB recht einfach möglich.

    Datenbanken, die Daten auf mehrere Knoten verteilen gibt's auch eine Reihe, z.B. Redis (was auch relativ klein und schnell ist), Cassandra (für dein Anliegen eher "too much") oder Postgre SQL mit der passenden Erweiterung. Nur hast du bei sharding über X Nodes immer noch das Risiko von Datenverlust (bzw. nicht Verfügbarkeit von Daten), wenn dummerweise genau die X Nodes ausfallen, die einen bestimmten Datensatz vorhalten.

    Ansonsten gilt bei Datenbankserver auch heute noch: viel hilft viel. IMHO macht es bei dir mehr Sinn, einen leistungsstärkeren, zentralen DB Server zu installieren. Und wenn dir wirklich jeder einzelne Wert hochgradig wichtig ist einen zweiten DB-Server im Hot Stand-By. Was für ein Heimprojekt aber eher... ungewöhnlich wäre.

    Gruß, noisefloor

  • Ich sehe hier auch das Problem der Datenkonsistenz, wenn Daten über mehrere "Datenbanken" ohne Redundanz verteilt werden. Da ginge vielleicht was mit publish/subscribe, z.B. immer mindestens 2 DB halten bestimmte Daten.

    Damit wäre das Speichern möglich, 2 DB horchen auf gesendete Daten und speichern.

    Aber wer stellt die Daten zur Verfügung? Welche DB? Beide können sich als Quelle anbieten, die Abfragelogik muss dann entweder selbst so was wie Load-Balancing machen, oder eine zentrale Stelle fingiert als "Relay", empfängt alle Abfragen und macht das Load Balancing.

    Knut

    Einmal editiert, zuletzt von KKoPi (31. Oktober 2016 um 19:14)


  • Zentris: Bist Du sicher, dass der Link korrekt ist? Ich komme auf eine Thema: Realisierungsschwierigkeit Rasbian.
    Ein Test lohnt immer. Mal sehen. Aber es hat, so wie ich das sehe eine Limitierung, wenn irgendwann die Datenbank zu gross wird, gehen alle beteiligten Rechner irgendwann in die Knie, und es nützt dann auch nichts, die Rechenpower durch mehr Rechner zu erweitern. Stimmts?

    Also der Link geht direkt auf meinen Beitrag, wo ich etwas zu den Durchsatzmessungen, die ich beobachten konnte, geschrieben habe...

    Datenbank zu groß?
    Ich weiss ja nicht, was du wegschreiben willst, ich habe derzeit eine Meßdaten-DB auf dem besagten Raspi B liegen mit ca. 900.000 Datensätzen, Struktur ist eher simpel (Struktur unter https://github.com/Zentris/erdfeu…e/ESPLogger.sql einsehbar).

    Da schreiben derzeit insgesamt 2 RasPi's und 3 ESP8266 Datenlogger ihre Daten rein, jeder ca. alle 30/60sec. echt keine Last...

    Die DB wird parallel dazu von verschiedenen Web-Servern für die graph. Bereitstellung der Daten mittels php/html abgefragt. Die Logger-Funktionalität ist gerade im entstehen... nur Peak-Last..

    Platzmäßig läuft das alles auf einer 16GB SD-Karte... die Indizes sind größer als der eigentliche Datenbestand...

    Alles in allem ist das eine "kleine" DB... wie noisefloor schon im übertragenen Sinne schrieb:
    Datenbanken sind resourcenhungrig, wenn sie schnell sein sollen/müssen. Ist einfach so.
    Wenn DBs auch noch ausfallsicher sein sollen/müssen, wird es nochmal "teuerer" - die Replikation ist ebenfalls rescourcenhungrig, vor allem, wenn es scnell sein muss.

    Aber das trifft doch bei dir gar nicht zu... was du da bisher an Daten einspeisen willst bzw. ausliefern willst... mal ehrlich, ist nichts, was einen RasPi 3 mit schneller SD-Karte aus dem Ruder werfen sollte...

    Wie schon geschrieben:
    Bau dir die DB auf, nimm dir einen PC mit ordentlich Leistung, dann schreib dir 2 Python-Scripte:
    Eins, was die DB in zufälligen Abständen (einstellbare Abstand und Durchsatz) die DB mit Datensätzen befeuert.
    Das andere liest Daten nach verschiedenen Filterkriterien ("select ... where ... order...").

    Diese Scripte startest du dann mehrfach (parallel) in mehreren Instanzen, so dass die Last auf die DB immer mehr ansteigt.
    Dann wirst du sehen, was passiert und wo die Grenzen sind... entweder ist das Netzwerkinterface dicht oder der Medienzugriff (Platte).

    "Nur Versuch mach kluch"... oder so :)

    das Zen

  • Die Anforderung, weniger als n^2 viele Netzwerkverbindungen zu haben, und gleichzeitig vollständige Ausfallsicherheit zu gewährleisten ist mathematisch im Widerspruch zueinander - denn dann gibt es immer eine Teilmenge S, durch deren Ausfall der Graph der Rechner in zwei Segmente zerteilt wird.

    Das ist natürlich dann ein Problem der Wahrscheinlichkeit, aber das ist das Thema insgesamt.

    Falls du so etwas selbst aufbauen willst, kann ggf nanomsg BUS dafür den Netzwerkteil übernehmen - http://250bpm.com/blog:17

    Damit hast du es relativ einfach, die Topologie zu bestimmen, und gleichzeitig die simple Semantik des Broadcasts zu haben.

  • PostgresXL vielleicht? Sie repliziert symmetrisch (also ist jeder Knoten sein eigener Master) und skaliert recht gut. Etwas unwohl wird mir aber bei der Verwendung von SD-Karten als Massenspeicher, besonders im Hinblick auf ihre Zuverlässigkeit bei zahlreichen Schreiboperationen. :/ Und für Postgres zu entwickeln ist schwieriger als für MySQL & Konsorten.


  • Etwas unwohl wird mir aber bei der Verwendung von SD-Karten als Massenspeicher, besonders im Hinblick auf ihre Zuverlässigkeit bei zahlreichen Schreiboperationen. :/

    Bin ich bei dir :lol: :thumbs1:
    Die SD-Karte (Samsung) in dem RP ist inzwischen >2Jahre drin und wird auch nicht angefasst (kein ständiges rein/raus usw).

    Dennoch wird die DB periodisch per mysqldump und rsync auf mein NAS gesichert (alle 24h):

    Das geht relativ schnell (ca. 20-30sec.) und ergibt ein gezipptes File von ca. 10MB.
    Per cronjob/rsync läuft das dann über die 100MBit-Nabelschnur innerhalb von Sekunden raus, die Systembelastung ist sehr übersichtlich...

    Grüße, das Zen

  • Ausfallsicherheit gehört nicht zu den Anforderungen. Wenn ein Rechner ausfällt sind die Daten, die er hostet halt nicht verfügbar. Geht ja auch nicht anders, denn er misst da die Werte von der Hardware, die dann ausgefallen ist.

    Das Beispiel oben sollte nur das Prinzip verdeutlichen. Ich will nun beliebig viele (!) Verbundrechner hinzufügen können, ohne dass es prinzipiell ein Überlastungsproblem wird. Mit jeden zusaetzlichen Rechner im Verbund kommt ja auch neue Rechenkapazität, so dass es eigentlich aufgehen müßte.

    Wenns das noch nicht gibt, lohnt es glaube ich, sowas zu programmieren. Denn wenn es das geben würde, würden doch viele Leute sowas einsetzen oder?
    Mit Datenbank meine ich auch nicht unbedingt einen Standard wie SQL oder so. Es darf (intern) alles verwendet werden. Die Nutzer sehen ja eh nur die API für die Programme.

  • Hallo,

    also es sind ja so ziemlich alle Möglichkeiten genannt worden, die es so gibt.

    > Ich will nun beliebig viele (!) Verbundrechner hinzufügen können, ohne dass es prinzipiell ein Überlastungsproblem wird.
    Natürlich wird es da. Irgendwann hast du so viel Kommunikation zwischen den Knoten, dass das Netzwerk ausgelastet ist. Ob du praktisch an den Punkt kommst ist ein anderes Thema.

    > Wenn wenn es das geben würde, würden doch viele Leute sowas einsetzen oder?
    Wenn viele Leute es brauchen würde, würde es sowas schon geben ;)

    > Es darf (intern) alles verwendet werden. Die Nutzer sehen ja eh nur die API für die Programme.
    Falscher Denkansatz. Wenn sollte sich schon vorher Gedanken machen, _welche_ Daten gespeichert werden und _wie_ du sie abfragen willst. Klar kannst du alles in jeder DB irgendwie speichern. Nur könnte dann die Abfrage sehr komplex und damit grundsätzlich zeit- und rechenintensiv werden.

    Hast du dich schon mal mit verschiedenen Datenbanken beschäftigt, um zu sehen, was es so gibt? Sonst liest dich doch mal ein bisschen durch die Doku von SQLite, PostgreSQL, MongoDB, CouchDB, Riak, Redis, InfluxDB und Cassandra. Sind alle relativ gängig und haben alle diverse Stärken (und Schwächen) für verschiedene Bereiche.

    Gruß, noisefloor

  • Geht nicht, gibts nicht!
    Unabhängig von der Realisierung spezifizier ich mal die Schnittstelle (Syntax ähnlich C):

    Angenommen, wir haben ein Programm, welches einen Sensor mit 20 Hz ausliest und die Werte in die Datenbank schreibt. Mehr macht es nicht. Programm würde auf Raspberry Pi Nummer 1 im Hintergrund laufen.


    Das waere dann alles, was man braucht, um einen Parameter auszulesen und wegzuschreiben. Man koennte mehrere Parameter auf einmal auslesen oder was auch immer, statt float auch int oder String.

    Die dazugelinkte Library kümmert sich um den Rest.

  • Schoen. Ich schreibe gelegentlich auch mal "solve_hard_problem()" - und dann ist die Welt wieder in Ordnung. Davon haben sich die NP-harten Probleme in der Informatik bisher aber nachdrücklich unbeeindruckt gezeigt.

    Im Ernst: es wurde schon erwähnt, und es schadet nicht, das wieder zu tun: CAP-Theorem. https://en.wikipedia.org/wiki/CAP_theorem

    Soviel zu deinem "geht nicht gibt's nicht". Tatsächlich stellt sich mir bei der ganzen Nummer hier die Frage, welches echte Problem du lösen willst. Ich nehme mal an, das ist einfach nur ein "wäre doch toll, wenn das so täte". Also - bastel schön. Wenn es aber um ein reales Problem geht, sollte man das mal besser beschreiben. Ein eventually consistent im grossen, und eine geclusterte, lokale Replikation unter Teilknoten würde im Zweifel schon alle "echten" Anforderungen lösen.

  • Nun wollen wir ein anderes Programm schreiben, was die Werte von dem Sensor bekommt, dann überprüft, ob diese eine Schwelle übersteigt, und wenn ja, ein Flag setzt.


    Automatisch zusammengefügt:
    Der Witz waere es jetzt, wenn sich das zweite Programm auch auf einem anderen Rechner befinden könnte, ohne dass man es ändern müsste. Die Berechnung könnte ja auch umfangreicher sein als nur auf eine Schwelle prüfen, und immerhin kommen die Änderungen des Wertes ja mit bis zu 20 Hz. Da flag ja ebenso wieder nur ein Parameter ist, kann dann wiederum auf einem dritten Rechner eine ähnliche Funktion laufen, die auf aenderungen des flags reagieer (nun mit viel weniger pro Sekunde) und das z.B. in einem Gui anzeigt oder sonstwas noch tut. Auf diese Weise werden alle Verbundrechner zum parallelrechnen genutzt. Wenn ein Rechner überlastet ist, überträgt man dann halt Teilaufgaben auf zusaetzliche neue Rechner, genauso wenn neue Sensoren hinzukommen, die dann ausgelesen werden muessen. Eine Überlastung kann man so immer abfangen und das ganze System skaliert beliebig. Also 1 Millionen Sensoren auf Hundertausend Raspberry-Pis mit viel Rechenlogig und Datenverarbeitung, verteilt, könnten bequem verarbeitet werden.
    Ich denke z.B. an die Automatisierung einer Fabrikhalle, einer Komplizierten Maschine (Kraftwerk oder so), oder ganz allgemein die Verbindung der Geräte im "internet of Things".
    Automatisch zusammengefügt:
    Ich hab nochmal zu MQTT gelesen. Im Prinzip geht es in die richtige Richtung, aber mir schwant, es ist zu langsam. Gibt es hierzu bei jemanden Erfahrungen?

    Einmal editiert, zuletzt von wend (1. November 2016 um 13:18)

  • Ideen zur Realisierung:
    1. es gibt eine library mit API, nennen wir sie backbonelib, welche zu allen Programmen hinzugelinkt werden muss. Diese stellt die basis-Funktionen, get/put-value, attach notifyer, etc zur Verfügung. Nutzen kann man sie dann in allen(!) Programmiersprachen über bindings.

    2. Im Hintergrund muss ein service auf allen Rechnern im Verbund laufen, nenne ich mal backbonekernel. Dieser lauscht auf Anfragen von anderen backbonekernels auf anderen Rechnern, und bedient diese. Ausserdem können sich beliebig viele lokale Programme über die backbonelib mit ihm lokal verbinden.

    Damit es schnell ist, waere für die Kommunikaltion backbonelib mit backbonekernel Shared-memory, pipes und Semaphores geeignet. Für die Komminikation von Rechner zu Rechner sockets. TCP/IP waere gut, damit es zuverlässig geht und man kein Fehlerprotokoll machen muss. Dafür ist der Durchsatz nicht konstant und das kann dazu führen, dass einige Kommunikation stockt oder hängt. Alternativ: UDP und ein eigenes kleines Protokoll schreiben, was sichergeht, dass Werteübertragungen, die zu alt sind, verworfen werden und ansonsten den Empfang quittieren. Das Scaliert auch besser, vielleicht mit multicast, wenn es viele Empfaenger für dieselben parameter gibt.

    Man kann mit einfachen Protokollen starten und es dann verbessern, solange das API zur backbonelib gleich bleibt. Der Durchsatz soll möglichst nur von der Netzwerkbandbreite limitiert werden (also 100MBit/s bei Raspis). Einfache Zahlenwerte brauchen nur ca 10 Bytes, vielleicht mit ein paar zusatzinformationen dann vielleicht ein UDP Paket mit 32 Bytes. Dann bekäme man theoretisch noch 300000 (Einzel-) Werte pro Sekunde übertragen. Oder 10000 Zahlen, die sich mit je 20 Hz ändern. An einen einzelnen Raspi könnten dann 10000 Sensoren angeschlossen werden, die alle mit 20 Hz ausgelesen werden, erst dann wäre ein theoretisches Limit erreicht. Da das am Anfang kaum vorkommen wird, kann man es auch so sehen: Man darf sich einen Faktor 100 an Ineffektivitäten bei der Protokollumsetzung erlauben. Und kann das ja mit der Zeit noch optimieren.
    Automatisch zusammengefügt:
    Damit die ganze Kommunikationsbandbreite nicht mit unnützen Synchronisierungen verschwendet wird, sorgt der backbonekernel dafür, dass nur Rarameter von einem Anderen rechner übertragen bzw. empfangen werden, wenn mindestens ein Prozess mit der backbonelib den Parameter auch benötigt. Also werden nicht permanent alle entfernetn Parameter subscribed. Wenn also keiner einen Bestimmten Parameter abfragt, werden die Werte auch nicht übertragen, und die werte bleiben dann nur lokal auf dem rechner, wo die Messung läuft. Da das ganze asynchron funktioniert, wird jeder Parameter mit seiner eigenenen, durch den Messprozess (sensor auslesen) eigenen rate verschickt. Oder sogar noch weniger, wenn z.B. zwei mal derselbe Wert gemessen wird, dann braucht ja auch kein Trigger geschickt werden und die angeschlossenen subscriber werden gar nicht belämmert, denn sie haben den aktuellen Wert ja noch. So ist gesorgt, dass niemals was unnötig übertragen wird und dennoch keine Wertänderung verlorengeht.

    Einmal editiert, zuletzt von wend (1. November 2016 um 13:41)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!