To "Velocity" είναι μία distributed in-memory application cache πλατφόρμα για την ανάπτυξη κατανεμημένων, διαθέσιμων, και υψηλής απόδοσης εφαρμογών. Με τη χρήση του "Velocity" οι εφαρμογές μπορούν να αποθηκεύσουν οποιοδήποτε serializable CLR αντικείμενο, χωρίς κάποια ανησυχία για το που θα αποθηκευτεί το αντικείμενο, καθώς τα δεδομένα αποθηκεύονται προσωρινά σε πολλούς υπολογιστές ταυτόχρονα. Το "Velocity" επιτρέπει αντίγραφα των δεδομένων να αποθηκεύονται σε όλους του υπολογιστές που συμμετέχουν στο cache cluster, προστατεύοντας το από δυσλειτουργίες. Μπορεί να διαμορφωθεί να τρέξει σαν ένα service που θα του γίνεται προσπέλαση από το δίκτυο, αλλά μπορεί να τρέχει ενσωματωμένο σε μία κατανεμημένη εφαρμογή. Το "Velocity" περιλαμβάνει ένα ASP.NET session provider object κάνοντας δυνατή την αποθήκευση των ASP.NET session objects μέσα στο κατανεμημένο cache, χωρίς να έχει να γράψει σε βάσεις δεδομένων, το οποίο αυξάνει την απόδοση και το scalability των ASP.NET εφαρμογών.

Διαβάστε περισσότερα: Microsoft Project Code Named “Velocity” CTP1

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Το παραπάνω λύνει μια σημαντική ανησυχία για availability που υφίσταται στα webfarms, σχετικά με τα Sessions. Ένας Session server είναι αρκετά γρήγορος μεν, αλλά αποτελεί single point of failure, ενώ ένας replicated SQL είναι πιο ασφαλής αλλά η ταχύτητα υπολείπεται του InProc ή του State server.


Βέβαια, πριν από μερικούς μήνες είχα μόλις ολοκληρώσει μια παρόμοια λύση για Session & Cache objects η οποία μάλλον θα πάει στο ντουλάπι με το πρώτο release του velocity...

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Μην βιάζεσαι! Το in-memory cache είναι πάντα περίεργη υπόθεση, επειδή κάθε εφραμογή έχει διαφορετικές απαιτήσεις στο συγχρονισμό των αλλαγών. Αν η εφαρμογή απαιτεί όλα τα μηχανήματα να έχουν την τελευταία έκδοση των cached δεδομένων περιορίζεται το scalability. Μία εφαρμογή η οποία αρκείται και σε "μπαγιάτικα" δεδομένα θα έχει και καλύτερο scalability και θα μπορεί να εκμεταλλευτεί την cache καλύτερα. Επιπλέον, ένα web site χρησιμοποιεί πολύ περισσότερα read-only δεδομένα από ένα Web Service/WCF component.

Η ιδέα του Velocity δεν είναι καινούρια. Ήδη από το COM+ (ουδεμία σχέση έχει με DCOM) υπήρχε η IMDB (In Memory Database) η οποία όμως αποσύρθηκε πολύ σύντομα γιατί δεν έλυνε το πρόβλημα του distribution. Με δεδομένο ότι όποιος χρησιμοποιούσε COM+ το έκανε για να μπορεί να βγάλει όσο το δυνατόν περισσότερα transactions, το IMDB δεν είχε επιτυχία. Μην βιάζεσαι να ξεφορτωθείς το δικό σου σύστημα γιατί μπορεί το Velocity να μην μπορεί να προσαρμοστεί στις δικές σου ανάγκες.

Κοιτάζωντας το concurrency model του Velocity πάντως, βλέπω ότι υποστηρίζει pessimistic locking (κλειδώνω τους πάντες μέχρι να κάνω update, χάλια scalability), optimistic (ελέγχω για αλλαγές μόνο στο update, αρκετά καλύτερο scalability), ίσως και καθόλου locking (το documentation της Put δεν ξεκαθαρίζει αν μπορεί να δουλέψει και χωρίς locking). H Put πάντως εκτελείται σύγχρονα, το οποίο σημαίνει ότι είτε η εφαρμογή σου θα πρέπει να περιμένει μέχρι να πάρει απάντηση από τους cache servers ότι έγινε η αποθήκευση, ή να γράψεις κώδικα για να την εκτελέσεις ασύγχρονα.
Τέλος, δεν βλέπω πουθενά στο API ή στο ... Reflector τη δυνατότητα να μπορεί ςνα δουλέψεις και με μπαγιάτικα δεδομένα. Αυτό σημαίνει ότι η ταχύτητα του δικτύου μπορεί να είναι θέμα σε περίεργες καταστάσεις, π.χ. σε ασύρματα δίκτυα ή WAN.

Αν δανειστούμε λίγη ορολογία από τις τηλεπικοινωνίες, φαίνεται ότι το Velocity είναι σχεδιασμένο για εφαρμογές HS (High Scalability) και VHS (Very High Scalabitliy, π.χ. τραπεζικές) όχι όμως και UHS (Ultra High Scalability, Amazon, eBay αλλά και κάποιες μικρότερες εφαρμογές distributed control).

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

I'm guilty, δεν το είδα καθόλου ακόμα, οπότε I'll take your word for it! Ούτως ή άλλως, είναι αρκετά νωρίς για να κάνω οποιαδήποτε αλλαγή για κάτι που δουλεύει αρκετά καλά, αλλά έχει ενδιαφέρον να βλέπεις λύσεις από την Microsoft οι οποίες ξεφεύγουν από τα "βασικά" και μέχρι πρότινος ήταν διαθέσιμες μόνο σε commercial επίπεδο (και σχετικά ακριβούτσικες για του λόγου το αληθές).

Μέχρι στιγμής πάντως, το μεγαλύτερο πρόβλημα που αντιμετώπισα με την δική μου υλοποίηση ήταν όταν χρειάζονταν να αλλάξω (και να ενημερώσω τις caches για αυτό) κάποιο πολύπλοκο object το οποίο είχε references σε άλλα objects που και αυτά έπρεπε να ενημερωθούν με διαφορετικές απαιτήσεις σε concurrency και... staleness των δεδομένων. Αν το Velocity μπορεί να προσφέρει ένα mixed μοντέλο των παραπάνω στην ίδια λύση (σε κάποια μελλοντική έκδοση ίσως; ) σίγουρα θα προσπαθήσω στο μέλλον να φτιάξω κάτι με αυτό.

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Εγώ πάντως θα έλεγα γενικά να μην βιαζόμαστε γιατί ακόμα ειναι μια απλή CTP1 και μέχρι την RTM μπορεί να αλλάξει και το σύμπαν.. Άλλωστε γι'αυτό βγαίνουν και οι CTP. Τρανό παράδειγμα CTP1 του Sync Framework και η CTP που βγήκε τώρα. Όπως επίσης και του SQL Server 2008.

---

Παναγιώτης Κεφαλίδης

"Για να επιτύχεις, θα πρέπει το πάθος σου για την επιτυχία να είναι μεγαλύτερο απο τον φόβο σου για την αποτυχία"

Οι απαντήσεις παρέχονται για συγκεκριμένες ερωτήσεις και χωρίς καμιά εγγύηση. Παρακαλώ διαβάστε τους όρους χρήσης.

Ρίχνοντας μια ματιά στο blog του Project Velocity, κάνω quote τα χαρακτηριστικά που πρέπει να έχουν οι εφαρμογές που έχουν σκοπό να χρησιμοποιήσουν το framework, και νομίζω ότι καλύπτει τα περισσότερα ερωτήματα και προβληματισμούς που έχουν διατυπωθεί:

• There is a considerable number of data requests that are mostly read (e.g. product catalogs)
• Large concurrent access to such data can be provided by replicating the catalog data on multiple cache nodes. Since updates are infrequent to such data, maintaining consistency (synchronously or asynchronously) is not very expensive
• Applications that can tolerate some staleness of data
• Such applications can provide better performance and scale by not requiring immediate updates ore refreshing of caches
• Applications that can work with highly partitioned data (e.g. session data, shopping cart)
• High scale and performance can be supported by partitioning and distributing data across multiple cache nodes, and thereby distributing data processing across the cache nodes
• Applications that can work well with eventual consistency
• Consider a flight inventory application, which must satisfy a large number of concurrent read/writes to the inventory of seats. To support large scale, the distributed cache may replicate the inventory value on multiple nodes; however, the inventory values on different nodes have to be made consistent in some fashion.  Requiring immediate (also known as strong) consistency will require updates to be synchronously propagated to all the copies. Such action would impact the overall performance and scale of the application. However, instead of immediately making the copies consistent, allowing them to eventually (in an asynchronous manner) become consistent will provide low latency, high performance access to inventory.

Προσωπική άποψη είναι ότι προσπαθούν να φτιάξουν ένα framework που λείπει πραγματικά από τα developing tools της Microsoft. Τέτοια frameworks χρειάζονται σε κατανεμημένα συστήματα που υπάρχουν στις αγορές των cluster και near real time συστημάτων...

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Διαβάζοντας ακόμα περισσότερο ανακάλυψα ότι το Velocity είναι ένα clone του memcached. Το memchaced είναι ένα από τα μυστικά επιτυχίας που είναι πίσω από τα Slashdot, Facebook, Digg, Flickr και Wikipedia.

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Χμμμ, φαίνεται ότι στόχος του Velocity είναι και τα UHS! Είχα ρίξει μια βιαστική ματιά στο documentation και τον κώδικα (μέσω reflector) και από εκεί δεν φαινόταν αν το Velocity μπορεί να κάνει τα updates ασύγχρονα και αν μπορεί να ρυθμιστεί αυτό.

Εντωμεταξύ, ο Scott Hanselman έχει ένα podcast σχετικά με το Velocity το οποίο περιλαμβάνει και links σε υλοποιήσεις και ASP.NET providers για το memcached, αλλά και ένα link σε μία πολύ καλή ανάλυση του Velocity από τον Dare Obasanjo. Μεταξύ άλλων, αναφέρει ότι το Velociy υποστηρίζει και χρήση χωρίς ελέγχους concurrency για πολύ μεγάλο scalability.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Παναγιώτης Καναβός:

Χμμμ, φαίνεται ότι στόχος του Velocity είναι και τα UHS! Είχα ρίξει μια βιαστική ματιά στο documentation και τον κώδικα (μέσω reflector) και από εκεί δεν φαινόταν αν το Velocity μπορεί να κάνει τα updates ασύγχρονα και αν μπορεί να ρυθμιστεί αυτό.

Εντωμεταξύ, ο Scott Hanselman έχει ένα podcast σχετικά με το Velocity το οποίο περιλαμβάνει και links σε υλοποιήσεις και ASP.NET providers για το memcached, αλλά και ένα link σε μία πολύ καλή ανάλυση του Velocity από τον Dare Obasanjo. Μεταξύ άλλων, αναφέρει ότι το Velociy υποστηρίζει και χρήση χωρίς ελέγχους concurrency για πολύ μεγάλο scalability.

Γενικά το "velocity" που έχεις για το "Velocity", δεν σου επιτρέπει να διαβάζεις πράγματα αν δεν ανοίξουνε μπροστά σου - πχ τη προηγούμενη δημοσίευση με τι δική σου που έχει ακριβώς τους ίδιους συνδέσμους....

 

George J.

---

George J. Capnias: Χειροπρακτικός Υπολογιστών, Ύψιστος Γκουράρχης της Κουμπουτερολογίας w: capnias.org, t: @gcapnias, l: gr.linkedin.com/in/gcapnias

Εγώ όμως πρόσεξα άλλα σημεία!

Μόλις άκουσα και το podcast του Hanselman, και μπορώ να πω ότι το Velocity μπορεί σίγουρα να καλύψει τόσο τα UHS  όσο και μικρότερα συστήματα. Το Velocity είναι εξαιρετικά ενδιαφέρον γιατί μπορεί να χρησιμοποιηθεί σε πολλά διαφορετικά συστήματα, και όχι απαραίτητα σε συστήματα με δεκάδες web servers. Μία περίπτωση που σκέφτομαι είναι για το caching metadata μεταξύ πολλών application servers, π.χ. για την αποθήκευση των περιγραφών domain models, business processes και workflows.
Το ωραίο είναι ότι η ποιότητα του CTP είναι αρκετά καλή ώστε να μπορεί κανείς να το χρησιμοποιήσει άμεσα. Αν είχα τώρα ένα έργο το οποίο απαιτούσε καλό caching, θα το προτιμούσα σε σχέση με μία home-grown λύση η οποία αναγκαστικά θα έπρεπε να γίνει σε περιορισμένο χρόνο.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos