Diskussion:Amazon Dynamo

das amazonlogo ist nicht zu sehen, es wird nur der schriftzug 200px angezeigt. (nicht signierter Beitrag von 194.76.29.2 (Diskussion) 09:10, 18. Aug. 2010 (CEST))

Durchsicht 2009/08

Nicht mein Gebiet, wie Du weist, kann der Sache aber ganz gut folgen, insofern hast Du etwas für meine Weiterbildung getan. Danke dafür. Ich habe mich "zum Dank" in Deinem Artikel ausgetobt. Es ist halt einfacher, etwas direkt zu ändern als es lange zu erklären. Mach ruhig rückgängig, was Dir nicht passt. Folgende Funkte habe ich noch gesammelt:

• Begriff "verteiltes Storagesystem". Für mich missverständlich, ich assoziiere das eher mit Hauptspeicher, was ja absolut nicht gemeint ist. Ist es ein Verteiltes Dateisystem oder ein en:File Hosting Service (überhaupt sollte für letzteren Artikel wohl noch eine deutsche Variante angelegt werden, in welcher Beziehung steht das zu Sharehoster?)
• "routes flapping" kann man einfach nicht gescheit übersetzten
• Konsistente Hash-Funktion=en:Consistent Hashing. Dennoch hier im Artikel in diesem Detail erklären?
• Consistent Hasing: Warum virtuelle Knoten bei der Heterogenität hilfreich sind, wird nicht klar: Vermutung: Man kann wenig nachgefragte Bereiche auf einem physischen Rechner vereinen und spart Hardware. Wenn das stimmt, sollte es erläutert werden.
• Warum ist 3, 1, 3 eine Art Lesepuffer? Wo ist da der Puffer?
• Warum ist im Beispiel "Sloppy Quorum und Hinted Handoff" Knoten D der Stellvertreter von A (und nicht B)? Im Beispiel von "Vector Clocks" sieht es so aus, als seien B und C die Stellvertreter von A.
• "Anti-Entropie durch Merkle Trees". Den dargestellten Abgleichmechanismus beim Neustart verstehe ich, allerdings nicht das Beispiel. In dem darsgestellten beispiel müsste A als Koordinator ja allein durch die Version Clocks von B und C erkennen, dass seine Datei alt ist. Zudem: Diese Abhandlung beim Neustart hilft ja nur, falls der Rechner ausfällt, nicht aber, wenn das Netzwerk ausfällt, oder?
• Gossip-basiertes Protokoll: Etwas überraschend finde ich hier, dass erklärt wird, dass man das Hinzufügen eines Knotens über Kommandozeile bewerkstelligt. Das finde ich nicht sonderlich wichtig. Was ich mich frage, ist wie dann die Schlüsselbereiche zwischen den Knoten neu aufgeteilt werden, hierzu müssen ja Dateien verschoben werden, oder? Auch muss ein ausscheidender Rechner ja beispielsweise sein ganzes Zeug abgeben.

Hoffe, das hilft was. Viele Grüße--Cactus26 17:11, 5. Aug. 2009 (CEST)

Danke schonmal für Deine Arbeit! Ich werde vorraussichtlich Ende nächster Woche mal genauer danach schauen können - bis Mittwoch bin ich noch im Prüfungsstress. Danke nochmal und viele Grüße--Flash1984 21:17, 8. Aug. 2009 (CEST)

So, jetzt endlich meine Antwort:

1. Also es ist ein verteiltes Dateisystem, werde das auch gleich entsprechend ändern. File Hosting und Sharehoster geht aber wohl in die selbe Richtung: Daten für das Web anbieten. S3 wäre dafür ein Beispiel. Dynamo wird nur intern genutzt. (Allerdings liegt S3 natürlich intern auch wieder ein Dateisystem zu Grunde...)
2. stimmt ;-)
3. das ist das selbe wie konsistentes Hashing - nur speziell angewendet. Und ich bin mir nicht sicher, ob es in allen Teilen so identisch ist. Darum habe ich es nochmal beschrieben.
4. Heterogenität: Es ist hilfreich, weil alle Knoten per se erstmal gleichgroß sind. Durch die Verteilung über Hashs ergibt sich bei genügend vielen Dateien halt eine Art Gleichverteilung. Wenn man jetzt (übertrieben) einen Rechner mit 10GB Festplatte und einen mit einer 1TB-Platte hat, dann ist das sicherlich ineffizient, weil insgesamt nicht mehr als 10GB pro Knoten gespeichert werden könnten. Legt man hingegen mehrere virtuelle Knoten auf einen physikalischen Knoten, entfällt das Problem der ineffizienten Ausnutzung.
5. Puffer: Puffer ist wohl der falsche Ausdruck...per se ist ja ein Lesepuffer einfach ein Speicher, der die Reads schneller machen soll. Naja, und ein 3,1,3-System wäre halt zumindest für Reads optimiert. Was wäre denn dann ein besserer Begriff?
6. Stellvertreter: Nicht ganz. B und C speichern Replika der Daten von A. Ist aber A vorhanden, ist A der Koordinator. Fällt jetzt A weg, so braucht man auch einen neuen dritten Knoten, damit man N = 3 weiterhin erfüllt. Da der ursprüngliche Koordinator weggefallen ist, ist es zufallsabhängig, wer jeweils der neue Koordinator ist (hängt davon ab, wer dann den ursprünglichen Request bekommt).
7. Stimmt, man könnte es auch durch die Vector Clocks erkennen. Allerdings kann A ja auch nur Bruchteile von Millisekunden weggewesen sein und es kam in der Zwischenzeit gar kein Write. Der Entropiebaum sorgt einfach dafür, dass nicht alle Dateien verglichen werden müssen. Logisch? ;-)

Den zweiten Teil verstehe ich allerdings nicht...meinst Du, dass die Netzwerkverbindung zwischen allen Knoten zusammenbricht, oder? Oder meinst Du, weil dann kein Restart durchgeführt wird? Falls ja: Die Hashs werden auch kontinuierlich über die Gossipmessages ausgetauscht (ist ja nur ein kleiner Wert).

1. Das mit dem Kommandozeile steht nur drin, um deutlich zu machen, dass es explizit durchgeführt werden muss. Gibt auch eine Variante per Browser, wenn ich mich recht an das Paper erinnere. Die Daten werden auch neu aufgeteilt. Falls ein Knoten abgemeldet wird, gibt er nicht seine Daten ab, sondern die werden dann von den anderen Replika im Hintergrund kopiert. Für die Neuaufteilung gibt es allerdings verschiedene Mechanismen - die stehen im verlinkten Paper ziemlich am Ende (3 Stück).

Danke nochmal fürs Durchschauen und viele Grüße--Flash1984 19:43, 14. Aug. 2009 (CEST)

Schön, dass Du mit meinem Feedback was anfangen kannst. Folgendes habe ich noch:

• Consistent Hashing, Heterogeniät: Habe es nochmal etwas umformuliert, das ausführliche Beispiel brauch es mMn nicht.
• Lesepuffer. Das passt so.
• Stellvertreter: Dann verstehe ich nicht, warum im Vector-Clocks Beispiel B für den ausfallenden A als Koordinator einspringt. Das müsste dann D machen.
• Zu 7: Ich meinte, dass ein Rechner zwar nicht ausfällt, aber nicht mehr erreichbar ist (und das möglicherweise selbst nicht bemerkt). Das würde durch den kontinuierlichen Austausch erkannt (wie Du in Deiner Antwort schreibst), solltest Du vielleicht auch in den Text nehmen.
• Gossip-basiertes Protokoll bei Hinzufügen/Wegfall eines Knotens: Ich fände hier viel interessanter, was mit Daten passiert, als wie kommuniziert wird, dass sich die Struktur geändert hat. Die Beispieltabelle, wer wann und wie vom neuen Knoten erfährt, finde ich eigentlich nicht nötig.

--Cactus26 10:01, 16. Aug. 2009 (CEST)

• Consistent Hashing: Gibt es irgendwelche Unternamensräume zu dem Artikel, wo man das dann evlt. hinverschieben könnte?
• Stellvertreter: Nunja, es könnte genauso wahrscheinlich B, C oder D sein. Mit dem Beispiel wollte ich durchaus auch zeigen, dass ein Version Branching nicht so sehr wahrscheinlich ist ;-). Anfragen von außen gehen entweder über einen Load Balancer, der die Anfrage an irgendeinen Knoten routet, der wiederum den Koordinator anspricht. Ist der nicht verfügbar, geht es an irgendeinen der anderen. Falls nicht Load Balancer, dann kennt der anfragende Client die Fragmentierung und fragt direkt einen der drei Knoten (oder falls A nicht da ist auch D). Welcher das dann ist, liegt in der Implementierung des Clients. Für Reads darf ja sowieso jeder Knoten Koordinator sein (selbst ein Knoten X!), nur bei Writes ist das entscheident, um die Vector Clocks klein zu halten (Ausnahme: Strategie last-write-wins. Dabei darf auch jeder Knoten koordinieren).
• 7: Trage ich noch nach :-)
• Gossip: Mmmh, ich finde eigentlich das andere wichtiger...aber werde das andere auch noch mitreinnehmen :-)

Danke und viele Grüße--Flash1984 11:27, 16. Aug. 2009 (CEST)

Zu 7, Beispiel zu virtuellen Knoten, Unterseiten. Im Prinzip ginge das, z.B.: Amazon Dynamo/Beispiele von Kontenkonfigurationen. Wäre in diesem Fall etwas ungewöhnlich.--Cactus26 07:30, 17. Aug. 2009 (CEST)

Ich denke, dann würde ich es drinlassen und auch keine Unterseiten nutzen..oder findest Du es ganz schrecklich? Meiner Ansicht nach ist es dem Verständnis schon dienlich - sonst hättest Du ja auch nicht nachgefragt. Grüße--Flash1984 20:09, 17. Aug. 2009 (CEST)

Nein, schrecklich ist es nicht. Es stört halt ein wenig die Ausgewogenheit des Artikels und ist von der Formatierung her recht ungewöhnlich. So wie der Text jetzt ist, würde ich es wohl auch ohne das Beispiel verstehen.--Cactus26 07:21, 18. Aug. 2009 (CEST)

Na gut, dann doch ohne - ich hab es mal in meinem Namensraum aufgehoben, falls doch jemand Bedarf äußert...Danke und Grüße--Flash1984 11:12, 18. Aug. 2009 (CEST)

Verteiltes Dateisystem???

Hi, ich weiss nicht ob ich das richtig verstehe, aber handelt es sich nicht eher um eine verteilte Datenbank (Stichwort !NoSQL) als ein verteiltes Dateisystem? (nicht signierter Beitrag von 62.156.183.195 (Diskussion) 08:21, 8. Nov. 2010 (CET))

Nur bedingt. Datenbanken sind üblicherweise keine key-value-Stores sonder strukturierter. Ein FS ist hierarchisch - das lässt sich relativ leicht auf key-value abbilden. Grüße --Flash1984 12:55, 8. Nov. 2010 (CET)

Amazon Dynamo bzw. Amazon DynamoDB ist eine NoSQL-Datenbank und kein verteiltes Dateisystem. Neue NoSQL Datenbanken sind natürlich auch unter anderem key-value-Stores, siehe [[1]] und auch http://aws.amazon.com/de/dynamodb/, sowie (Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability.) http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/Introduction.html. Bitte korrigiert das! Weitere Quellen:
http://nosql-database.org/
http://en.wikipedia.org/wiki/Dynamo_%28storage_system%29
Es ist auch keine IaaS sondern fällt mehr unter SaaS.
Grüße:Jehasius (19:46, 27. Sep. 2012 (CEST), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Sorry, dass das SaaS sein soll ist völliger Blödsinn - viel mehr IaaS als DynamoDB wird es nicht. Und ob man es nun verteilte Datenbank oder verteiltes Filesystem nennt, ist letztlich eine Definitionsfrage. Ich nutze in meiner Diss lieber den Begriff "Distributed Storage System" - das ist maximal generisch und umfasst alles. Leider gibt es da im Deutschen keine wirkliche Entsprechung, die tatsächlich genutzt wird. Gruß--Flash1984 (Diskussion) 11:13, 28. Sep. 2012 (CEST)

Fakt ist, das DynamoDB erst seit Januar 2012 als AWS in einer Beta-Version angeboten wird. Zum Zeitpunkt der Beitragserstellung war diese NoSQL-Datenbank (darum DB und nicht FS) somit nie ein (XYZ)aaS gewesen, das war also totaler Quatsch. Die Datenbanktechnik wurde nur intern von Amazon genutzt und war nicht direkt als Service für Anwender verfügbar. Seit Januar 2012 wird Amazon DynamoDB als vollständig verwalteter (was eine Argumentation für IaaS relativiert) NoSQL-Datenbank-Service angeboten. Eine Eingruppierung ist nicht immer so offensichtlich, da sich die Eigenschaften der AWS überlappen und die Übergänge von I-P-SaaS so wolkig sind wie ihr Ursprung, auch das ist Definitionssache und so gesehen ist SaaS generisch genug um alles abzudecken ;-). Vielleicht sollte man die NoSQL-Datenbank einfach als Bestandteil vom AWS kennzeichnen.
Vorlieben beim Verfassen der eigenen Dissertation sollte man hier hier außer Acht lassen. Generell sollte man sich an die Definitionen vom Anbieter, also Amazon halten und da wir ganz klar angegeben was es wirklich ist: ein vollständig verwalteter NoSQL-Datenbank-Service, das ist ein Fakt. Ich hoffe ich konnte zur Verbesserung diese Artikels ein wenig beitragen.
Viele Grüße --Jehasius (Diskussion) 12:10, 29. Sep. 2012 (CEST)

Ich stimme dir zu, dass es wirklich nur begrenzt sinnvoll ist, Dynamo als aaS zu bezeichnen (wobei man es als Private Cloud-Service innerhalb von Amazon sehen könnte...). Ich muss dir aber kategorisch widersprechen, was die Einordnung als SaaS betrifft: Die Einordnung mag oft schwammig sein, aber DynamoDB ist zu 100% eindeutig IaaS. Dabei würde ich mich auch gerade nicht auf Definitionen des Anbieters verlassen, sondern mich an etablierten Definitionen (z.B. NIST) orientieren. Und laut denen gehört ein Storageservice eindeutig in den Bereich IaaS. SaaS richtet sich an den Endnutzer (das wäre dann Dropbox bspw.). Es ging mir auch nicht darum, meine "Vorlieben beim Verfassen der eigenen Dissertation" durchzudrücken (steht ja auch so nicht im Artikel), sondern deutlich zu machen, dass Dynamo definitiv ein verteiltes Storagesystem ist (Oberkategorie von verteiltem Filesystem und verteilter Datenbank). Über die Unterkategorie kann man streiten, wobei für mich ein verteilter Hashtable keine Datenbank ist (und im Gegensatz zu DynamoDB ist Dynamo eben nur ein key-value-Store).--Flash1984 (Diskussion) 14:15, 2. Okt. 2012 (CEST)

Bezüglich der Definitionen gehört die "storage infrastructur" und somit auch Amazon Dynamo und auch DynamoDB natürlich zu IaaS, da gehe ich mit dir konform, das war von mir zu hoch gegriffen. Über die Kategorisierung kann man sich wirklich streiten, gerade wenn man auch bedenkt das Key-Value Datenbanken und relationale Datenbanksystem schon in der Vergangenheit parallel entwickelt wurden. Bereits 1979 wurde die erste Key-Value Datenbank von Ken Thompsen entwickelt http://de.wikipedia.org/wiki/DBM_%28Datenbank%298. Nur verteilter Hashtable, damit wird man dem Dynamo System nicht gerecht.
-- Jehasius (Diskussion) 18:08, 3. Okt. 2012 (CEST)

VIelleicht sollte man es dann einfach wirklich "verteiltes Speichersystem" nennen?--Flash1984 (Diskussion) 11:50, 9. Okt. 2012 (CEST)

Anti-Entropie

In dem Abschnitt "Anti-Entropie durch Merkle-Trees" wird nicht erklärt, was Anti-Entropie ist, wie man dies erreichen kann und wozu es dient. Dies ist für ein Fachwort, zu dem sonst nicht viel zu finden ist, in einer Überschrift eher unglücklich. (nicht signierter Beitrag von CorneliusSchmale (Diskussion | Beiträge) 23:00, 23. Nov. 2011 (CET))