Όταν είσαι διψασμένος το μόνο που θέλεις είναι να πιεις ένα ποτήρι νερό για να σβήσεις την δίψα σου. Την στιγμή αυτή δεν κοιτάς αν το συγκεκριμένο ποτήρι με νερό είναι παγωμένο ή δροσερό. Θέλεις να το πιεις γιατί αλλιώς σβήνεις.

Έτσι όταν έχεις εκατομμύρια εγγραφές που θέλεις να τις διαβάσεις για να εξάγεις κάποιο αποτέλεσμα θέλεις κάτι που να σου δίνει την δυνατότητα να το κάνεις γρήγορα. Αυτό είναι ο εφιάλτης κάθε DBA /DB DEV.

Καημός όλων μας είναι να επεξεργαζόμαστε μεγάλο όγκο πληροφορίας σε μηδενικό χρόνο, σωστά;

Αν λοιπόν είστε οπαδός αυτής της φιλοσοφίας τότε καλώς ήρθατε στους columnstore indexes που υπάρχουν στον SQL Server 2012.

Δεν θα σας περιγράψω εδώ το τι είναι ούτε πως θα τους φτιάξετε. Δεν υπάρχει λόγος να κάνω κάτι τέτοιο.

Περιγράφονται αναλυτικότητα στα BOL αλλά υπάρχει και ένα wiki που έχει γραφτεί από τον καθ’ ύλη αρμόδιο για αυτούς, μιας και είναι μέσα από την ομάδα που τους δημιούργησε και που στο τελευταίο MVP Summit είχα την ευκαιρία να έχω μια αρκετά ενδιαφέρουσα συζήτηση μαζί του, και δεν είναι άλλος από τον Eric Hanson.

Ο Eric έχει γράψει το SQL Server Columnstore Index FAQ στο οποίο εξηγεί με άρτιο τρόπο αυτούς. Μπορώ εύκολα να το χαρακτηρίσω σαν A-Z reference για τους columnstore indexes. Έτσι δεν βλέπω το νόημα να κάνω το παπαγαλάκι διαβάστε το wiki και είστε έτοιμοι!.

Επίσης ο Eric έχει γράψει και το SQL Server Columnstore Performance Tuning με πολλά DOs and DON’Ts.

Στην συζήτηση που είχα μαζί του με ρώτησε για την άποψη μου στους columnstore index. Η απάντηση μου ήταν ακριβώς η φράση με την οποία ξεκίνησα το post αυτό.

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

Ενώ είναι ξεκάθαρο στο πότε έχει νόημα να χρησιμοποιηθούν οι συγκεκριμένοι indexes εντούτοις υπάρχουν αρκετοί που γκρινιάζουν για τ α limitations που υπάρχουν σε αυτούς με βασικό ότι είναι read only πλέον ο πίνακας.

Πραγματικά δεν με ενδιαφέρει καθόλου αυτό την στιγμή μάλιστα που μου έχουν δώσει ένα workaround για το πώς να το λύσω το θέμα αυτό. Εξάλλου μιλάμε για το DW που έχω. Είναι ξεκάθαρο για μένα τουλάχιστον ότι αυτοί οι indexes δημιουργήθηκαν για αυτό το είδος database και τους λατρεύω.

Λατρεύω την αρχιτεκτονική τους.

Λατρεύω το γεγονός ότι είναι compressed by default.

Λατρεύω τον τρόπο με τον όποιο γίνεται το retrieve των δεδομένων (batch mode processing).

Μα πάνω από όλα Λατρεύω το γεγονός ότι μπορώ να διαβάσω εκατομμύρια γραμμές με καλύτερο performance το οποίο ανέρχεται σε βελτίωση της τάξεως του 40%, 50% ή και σε κάποιες περιπτώσεις περισσότερο.

Αυτή την στιγμή δεν με απασχολούν τα limitations έχω το ποτήρι με το νερό που χρειάζομαι για να μην σβήσω.

Να μην σβήσω μέσα στον τεράστιο όγκο δεδομένων που έχω. Αν δεν έχεις τέτοιο όγκο απλά δεν σου χρειάζονται φίλε μου αυτοί οι indexes.

Κάθε προϊόν έρχεται με ένα πλήθος αριθμό από χαρακτηριστικά, δεν σημαίνει ότι όλα τα θέλουμε και θα τα χρησιμοποιήσουμε. Για αυτό και στο πόλεμο έχουμε διαφορετικά όπλα, άλλο για τον ανταρτοπόλεμο, άλλο για τον υποβρύχιο, άλλο για το χιόνι κ.ο.κ. Όπως δεν θα πας να σκοτώσεις ελέφαντα με σφεντόνα ή μυρμήγκι με μπαζούκας έτσι και εδώ όταν έχεις την ανάγκη, όπως περιγράφει ο Eric, να τους χρησιμοποιήσεις τους χρησιμοποιείς.

Ο SQL Server είναι πλέον ένα πολυεργαλείο, ένας ελβετικός σουγιάς. Έχει το κατάλληλο εργαλείο για την κατάλληλη εργασία.

Δεν θα πας να φας φασολάδα με το πιρούνι επειδή απλά μπορείς θα βγάλεις το κουτάλι. Εξάλλου αν χρησιμοποιήσεις το πιρούνι θα χάσεις το ζουμάκι της φασολάδας και αυτό δεν λέει.

Από την άλλη πρέπει να λάβουμε σοβαρά υπόψη ότι είναι η πρώτη εμφάνιση του συγκεκριμένου feature. Είναι λογικό να υπάρχουν κάποιοι περιορισμοί και δεν νομίζω ότι θα μείνει έτσι. Πιστεύω ότι θα εξελιχθεί.

Μένω σε αυτό που μου προσφέρει αυτή την στιγμή και είναι και αυτό που ζητάω αυτή την στιγμή.

Διψάω κύριοι συνάδελφοι Διψάω και δεν με νοιάζει αν είναι κρύο το νερό…

/* antonch */