Καλησπέρα,
στην περίπτωση του eventual consistency, αν ένα query request φτάσει σε κόμβο ο οποίος δεν είναι μεν υπεύθυνος για αυτό το key βάσει του hash, αλλά θα έπρεπε να το έχει βάσει του replication (δηλαδή θα έπρεπε να έχει το κλειδί ως replica) τότε: Αν για κάποιο λόγο *δεν* έχει το κλειδί στο storage του, αλλά με βάση το replication factor ο επόμενος του θα έπρεπε και αυτός να το έχει, τότε προωθεί το query request στον επόμενο (για να δει μήπως το έχει εκείνος)?, ή απαντάει στον κόμβο που έγινε το original query με "Not Found" (επειδή θα έπρεπε ο ίδιος να το έχει ως replica αλλά δεν το έχει)?
Ευχαριστώ εκ των προτέρων, Ηλίας Μπίμπας
Το προωθεί στον επόμενο μέχρι (στη χειρότερη) να φτάσει στον primary replica.
K.
Στις Δευ, 22 Φεβ 2021 στις 12:14 μ.μ., ο/η Ilias Bimpas < bibas.ilias@gmail.com> έγραψε:
Καλησπέρα,
στην περίπτωση του eventual consistency, αν ένα query request φτάσει σε κόμβο ο οποίος δεν είναι μεν υπεύθυνος για αυτό το key βάσει του hash, αλλά θα έπρεπε να το έχει βάσει του replication (δηλαδή θα έπρεπε να έχει το κλειδί ως replica) τότε: Αν για κάποιο λόγο *δεν* έχει το κλειδί στο storage του, αλλά με βάση το replication factor ο επόμενος του θα έπρεπε και αυτός να το έχει, τότε προωθεί το query request στον επόμενο (για να δει μήπως το έχει εκείνος)?, ή απαντάει στον κόμβο που έγινε το original query με "Not Found" (επειδή θα έπρεπε ο ίδιος να το έχει ως replica αλλά δεν το έχει)?
Ευχαριστώ εκ των προτέρων, Ηλίας Μπίμπας _______________________________________________ Distrib mailing list Distrib@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/distrib
Καλησπέρα σας,
Στην περίπτωση του linearizability ισχύει το ίδιο; Δηλαδή αν βρισκόμαστε σε κάποιον ενδιάμεσο RM και το δεδομένο δεν υπάρχει, τότε προωθούμε στον επόμενο μέχρι (στη χειρότερη) να φτάσει στον replica manager? Ρωτάω επειδή και σε αυτή την περίπτωση δε μπορούμε να γνωρίζουμε ποιος είναι secondary RM και πού λήγει η αλυσίδα στην ειδική περίπτωση που δεν υπάρχει δεδομένο για το κλειδί.
Στις Δευ, 22 Φεβ 2021 στις 10:37 μ.μ., ο/η Katerina Doka < katerina.doka@gmail.com> έγραψε:
Το προωθεί στον επόμενο μέχρι (στη χειρότερη) να φτάσει στον primary replica.
K.
Στις Δευ, 22 Φεβ 2021 στις 12:14 μ.μ., ο/η Ilias Bimpas < bibas.ilias@gmail.com> έγραψε:
Καλησπέρα,
στην περίπτωση του eventual consistency, αν ένα query request φτάσει σε κόμβο ο οποίος δεν είναι μεν υπεύθυνος για αυτό το key βάσει του hash, αλλά θα έπρεπε να το έχει βάσει του replication (δηλαδή θα έπρεπε να έχει το κλειδί ως replica) τότε: Αν για κάποιο λόγο *δεν* έχει το κλειδί στο storage του, αλλά με βάση το replication factor ο επόμενος του θα έπρεπε και αυτός να το έχει, τότε προωθεί το query request στον επόμενο (για να δει μήπως το έχει εκείνος)?, ή απαντάει στον κόμβο που έγινε το original query με "Not Found" (επειδή θα έπρεπε ο ίδιος να το έχει ως replica αλλά δεν το έχει)?
Ευχαριστώ εκ των προτέρων, Ηλίας Μπίμπας _______________________________________________ Distrib mailing list Distrib@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/distrib
-- Katerina Doka, PhD Senior Researcher, Computing Systems Laboratory National Technical University of Athens phone: +30 2107721175 Web: http://www.cslab.ntua.gr/~doka _______________________________________________ Distrib mailing list Distrib@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/distrib
Ναι, αν δεν υπάρχει το κλειδί μπορείς να το καταλάβεις μόνο αν φτάσεις στον primary και δεν το έχει.
Στις Δευ, 1 Μαρ 2021 στις 12:15 π.μ., ο/η Jason Milionis < jasonmili.ece@gmail.com> έγραψε:
Καλησπέρα σας,
Στην περίπτωση του linearizability ισχύει το ίδιο; Δηλαδή αν βρισκόμαστε σε κάποιον ενδιάμεσο RM και το δεδομένο δεν υπάρχει, τότε προωθούμε στον επόμενο μέχρι (στη χειρότερη) να φτάσει στον replica manager? Ρωτάω επειδή και σε αυτή την περίπτωση δε μπορούμε να γνωρίζουμε ποιος είναι secondary RM και πού λήγει η αλυσίδα στην ειδική περίπτωση που δεν υπάρχει δεδομένο για το κλειδί.
Στις Δευ, 22 Φεβ 2021 στις 10:37 μ.μ., ο/η Katerina Doka < katerina.doka@gmail.com> έγραψε:
Το προωθεί στον επόμενο μέχρι (στη χειρότερη) να φτάσει στον primary replica.
K.
Στις Δευ, 22 Φεβ 2021 στις 12:14 μ.μ., ο/η Ilias Bimpas < bibas.ilias@gmail.com> έγραψε:
Καλησπέρα,
στην περίπτωση του eventual consistency, αν ένα query request φτάσει σε κόμβο ο οποίος δεν είναι μεν υπεύθυνος για αυτό το key βάσει του hash, αλλά θα έπρεπε να το έχει βάσει του replication (δηλαδή θα έπρεπε να έχει το κλειδί ως replica) τότε: Αν για κάποιο λόγο *δεν* έχει το κλειδί στο storage του, αλλά με βάση το replication factor ο επόμενος του θα έπρεπε και αυτός να το έχει, τότε προωθεί το query request στον επόμενο (για να δει μήπως το έχει εκείνος)?, ή απαντάει στον κόμβο που έγινε το original query με "Not Found" (επειδή θα έπρεπε ο ίδιος να το έχει ως replica αλλά δεν το έχει)?
Ευχαριστώ εκ των προτέρων, Ηλίας Μπίμπας _______________________________________________ Distrib mailing list Distrib@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/distrib
-- Katerina Doka, PhD Senior Researcher, Computing Systems Laboratory National Technical University of Athens phone: +30 2107721175 Web: http://www.cslab.ntua.gr/~doka _______________________________________________ Distrib mailing list Distrib@lists.cslab.ece.ntua.gr http://lists.cslab.ece.ntua.gr/mailman/listinfo/distrib
distrib@lists.cslab.ece.ntua.gr
-
Ilias Bimpas -
Jason Milionis -
Katerina Doka -
Katerina Doka