Νίκο, αν προσέξεις μιλάμε για τα αρχεία μίας μόνο βάσης, όχι ολόκληρου του server. Επιπλέον, η διάσπαση των αρχείων της βάσης θα προκαλέσει καθυστέρηση, όχι επιτάχυνση. Με ένα RAID που υποστηρίζει striping όλοι οι σκληροί δουλεύουν ταυτόχρονα για να σερβίρουν τα αποτελέσματα. Αν βάλεις ένα βαρύ πίνακα σε ένα σκληρό θα αναγκάσεις όλα τα queries να περιμένουν τον ένα σκληρό. Αντί για parallel access προκαλείς serial access.
Σε πολύ βαριά συστήματα (με τα σημερινά δεδομένα, όχι του SQL Server 2000) αρχίζει να έχει νόημα να ξεχωρίσεις indexes από data, πάντα σε RAID με striping. Δεν μπορείς όμως να πεις εκ των προτέρων "ξεχωρίστε τα Indexes" γιατί κάθε συστοιχία έχει κόστος: χαμένο χώρο για το parity, και λιγότεροι παράλληλοι σκληροί ανά συστοιχία. Μην ξεχνάμε ότι indexes και data είναι διάσπαρτα και τη στιγμή που ένας σκληρός σερβίρει index μπορεί ένας άλλος να σερβίρει data. Είναι πολύ καλύτερο να έχω 10 σκληρούς να δουλεύουν παράλληλα παρά π.χ. 6 και 4 ή 5 και 5.
Τέλος, να πω ότι και εγώ είχα κάποτε αυτή την παρανόηση αλλά μερικές συζητήσεις με τον Lubor Kolar το ξεκαθάρισαν (είναι ο μπαμπάς του query optimizer, κάτι θα ξέρει). Ως developers έχουμε πάντα την τάση να κοιτάμε λύσεις που ελέγχουμε εμείς και έτσι μας ξεφεύγουν οι λύσεις που μπορεί να υπάρχουν έτοιμες σε hardware. Άσε που τα μηχανήματα μας δεν έχουν ποτέ RAID 5 κι έτσι δεν "βλέπουμε" την απλή λύση. Γι αυτό μπορεί κανείς να διαβάσει ένα Guideline που σου λέει κάνε RAID και αν χρειαστεί placement και να ακούσει μόνο "κάνε placement"
Κατάληξη: Η καλύτερη λύση εξαρτάται από τον όγκο και το workload (συχνότητα, concurrency, είδος queries). Η βασική συνταγή είναι τα δεδομένα των βάσεων (data + index) σε RAID με striping, όσο το δυνατόν μεγαλύτερο για να εκμεταλλευτείς την παράλληλη λειτουργία των σκληρών.
Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos