Henryk Plötz: Was bedeutet "Skalierbarkeit" genau?

Beitrag lesen

Moin,

Ich kann mir darunter einfach nichts vorstellen, auch nicht was es technisch für einen Sinn macht diese vorerst künstlich zu beschränken.
Für Software verstehe ich das noch weniger, was soll da "Skalierbar" sein?

Das hat nichts mit künstlich beschränken zu tun, sondern eher mit prinzipiellen Schranken.

Beispiel: Das Filesharing-Netz Gnutella. Suchanfragen und Antworten werden zwischen Servents direkt ausgetauscht. Um zu Verhindern, dass Anfragen ewig rumkurven, kriegen alle Pakete eine Time-to-Live, also eine maximale Anzahl von Zwischenstationen die sie passieren können, bevor sie gelöscht werden. Daraus ergibt sich, dass ein Servent eine bestimmte maximale Anzahl an anderen Servents sehen kann. (Bin mir nicht sicher, aber das müsste in der Gegend von (Durschnittliche Anzahl der direkten Verbindungen zu anderen Servents) hoch TTL liegen.)
Um diesen Sichtbereich zu erweitern, müsste man jetzt die TTL hochdrehen, bekommt dann aber Probleme, weil a) die Antwort-Zeit steigt und b) der durschnittliche Netzwerkverkehr der nur mit diesen Metadaten verschwendet wird (also noch nicht zum Dateienübertragen benutzt werden kann) ebenfalls stark steigt. Oder man könnte die Anzahl der Verbindungen zu anderen Servents erhöhen, bekommt dann aber Probleme, weil der Netzwerkverkehr für Metadaten dadurch auch steigt.
Man sieht: Gnutella skaliert schlecht auf viele Teilnehmer mit langsamen Leitungen.

Das Gegenbeispiel wäre Fast-Track: Es gibt eine Anzahl an SuperNodes die aufgrund ihrer überdurchschnittlich schnellen Internetanbindung und verfügbaren Rechenkapazität ausgewählt werden und die sind untereinander alle verbunden. Dann gibt es noch Nodes, die jeweils eine Verbindung zu einer oder mehreren SuperNodes aufrechterhalten. Die Supernodes wissen, welche Dateien die mit ihnen verbundenen Nodes bereitstellen und bearbeiten alle Suchanfragen unter sich. Da sie so dicke Leitungen haben, ist es kein Problem, dass dort viele Metadaten umherflitzen. Die Internetanbindungen jeder einzelnen Node wird nur mit von dieser Node direkt gestellen Suchanfragen und den Antworten darauf zusätzlich zum Dateiaustausch belastet. Sollten mehr Nodes in das Netzwerk kommen, werden halt mehr SuperNodes bestimmt.
Man sieht: Fast-Track skaliert wesentlich besser auf viele Teilnehmer mit langsamen Leitungen. Es müssen nur ein gewisser Prozentsatz der Teilnehmer auch besonders dicke Leitungen haben (und das ist eigentlich immer der Fall).

Ähnliche Probleme erwarten dich _immer_ wenn du irgendetwas verteilt erledigen musst. Es gibt einen bestimmten Aufwand den jedes Teilsystem relativ unabhängig von den anderen erledigen kann (die reinen Berechnungen zum Beispiel) und es gibt einen Aufwand für die Kommunikation und Koordination der Teilsysteme, der dich der Erfüllung deiner Aufgabe nicht direkt näher bringt. Leider steigt letzterer Aufwand bei eigentlich allen Problemklassen deutlich schneller als linear, die insgesamt zur Verfügung stehende Kapazität steigt aber nur linear. Es gibt also immer einen Punkt, an dem das, was du durch Hinzufügen neuer Komponenten an Kapazität gewinnst, weniger ist, als das, was du durch dieses Hinzufügen an Kapazität verlierst. (Natürlich fügst du niemals Komponenten bis zu dieser Grenze hinzu. Wenn durch eine Vervierfachung der Kosten, die Kapazität nichtmal mehr verdoppelt wird, überlegt man sich schon, ob das noch Sinn macht.)

Was den nachträglichen Ausbau angeht, so skaliert ein System offensichtlich umso besser, je weiter der oben erwähnte böse Punkt vom aktuellen Ausbau entfernt ist.
Allgemein skaliert das System besser, wenn der Kommunikationsoverhead klein ist, die Kosten also nahezu linear mit der Kapazität steigen.

--
Henryk Plötz
Grüße aus Berlin

* Help Microsoft combat software piracy: Give Linux to a friend today! *