go backarticles

Articles of SQLschool.gr Team

Cosmos DB Design considerations

Antonios Chatzipavlis

Κάθε database system έχει τις ιδιαιτερότητες του και καλό είναι να γνωρίζουμε όσα περισσότερα για αυτές καθώς έτσι θα είμαστε σε θέση να σχεδιάζουμε καλύτερες λύσεις.

Έτσι και στην Cosmos DB υπάρχουν κάποιες που πρέπει να γνωρίζουμε για αυτό ας δούμε κάποιες που είναι κυρίαρχες.

Request Units

Η Cosmos DB έχει τα Request Units ανά δευτερόλεπτο (RU/s) τα οποία εφαρμόζονται σε επίπεδο collection και με τα οποία ορίζονται οι πόροι ( CPU, Memory, I/O of network activity) και με βάση αυτά γίνεται και η ωριαία χρέωση χρήσης.

Ένα RU σύμφωνα με την Microsoft είναι ισοδύναμο με το διάβασμα ενός document μεγέθους 1 ΚΒ με 10 properties.

Αν έχουμε εκτιμήσει χαμηλότερα από ότι χρειάζεται και έχουμε request που ξεπερνάνε την εκτίμηση τότε μπαίνουμε σε performance throttling που σημαίνει ότι ζητάτε από τα request να προσπαθήσουν αργότερα μέχρι να υπάρχουν οι πόροι που χρειάζονται για να εξυπηρετηθούν. Φυσικά αν ο αριθμός των requests είναι τόσο μεγάλος ή έχουμε μεγάλο αριθμό προσπαθειών τότε αυτά γίνονται abort.

Η σωστή εκτίμηση των RU/s όσο περισσότερο γίνει με ακρίβεια πέρα από το κόστος θα μας δώσει και το performance που επιθυμούμε, για αυτό το λόγο υπάρχει ο αντίστοιχος calculator.

Να επισημανθεί ότι μπορώ να αλλάζω κατά βούληση τα RU/s όποτε χρειάζεται να γίνεται πχ όταν κάνω import.

Είναι προφανές ότι στην επιλογή των RU/s θα πρέπει να λάβουμε υπόψη τα writes, complex queries, large documents όμως δεν είναι μόνο αυτά. Θα πρέπει να ληφθούν υπόψη:

  • το consistency level που θα επιλέξουμε καθώς το Strong και Bounded Staleness απαιτούν περισσότερα reads για να την επίτευξη του επιθυμητού consistency level
  • ο αριθμός των indexes που δημιουργούνται αυτόματα καθώς απαιτούν πολλά writes και μια πρακτική είναι να μειώνουμε τον αριθμό τους για το λόγο αυτό με βάση βέβαια και την απόδοση που θέλουμε.
  • το τρόπο με το οποίο γράφουμε stored procedures και triggers καθώς δεν θέλουμε μέσα σε αυτές να έχουμε αχρείαστα reads/writes.

Partitioning

Στην Cosmos DB έχουμε τρία container types (collections, tables, graphs) που είναι logical resources που αποτελούνται από ένα ή περισσότερα physical partitions.

Κάθε physical partition αποτελείται από ένα αριθμό από SSD storage που γίνεται local replicated για high availability και δεν υπάρχει περιορισμός στο μέγεθος και στην κλιμάκωση του και συνδυάζεται με CPU και memory resources αν έχουμε επιλέξει unlimited scaling. Φυσικά υπάρχει και το Fixed scaling model στο οποίο εξ αρχής έχω ορίσει το μέγεθος.

Δεν χρειάζεται να κάνουμε κάτι για αυτό καθώς γίνεται αυτόματα και με τον ίδιο τρόπο ανεξαρτήτως το τύπο του container σε συνάρτηση πάντα με τον αριθμό των RU/s που έχουμε επιλέξει.

Για να καταλάβουμε πως λειτουργεί η όλη διαδικασία ας υποθέσουμε ότι έχουμε ένα collection container που έχει documents και έχω αποφασίσει να έχω σαν partition key το userid. Αυτό σημαίνει ότι για κάθε userid έχω ένα logical partition το οποίο με βάση μια διαδικασία η οποία ονομάζεται consistent hashing σπάει σε ένα ή περισσότερα physical partitions.

Το πόσα physical partitions θα έχω είναι ο λόγος των επιλεγμένων RU/s διά το Maximum throughput per partition. Κάθε φορά που ένα partition φτάνει να γεμίσει τότε αυτόματα αυτό σπάει σε δύο νέα (50-50) κ.ο.κ

Partition Key

Στην Cosmos DB το partitioning είναι ο βασικός παράγοντας απόδοσης και κλιμάκωσης και ο μόνος τρόπος για επηρεάσουμε θετικά είναι η σοφή επιλογή του partition key.

Αρκετοί λένε και όχι άδικα ότι είναι «the top-most design decision in Cosmos DB».

Αν έχουμε κάνει λάθος επιλογή ο μόνος τρόπος για να το διορθώσουμε είναι να ξαναδημιουργηθεί ο container. Βέβαια πρέπει να επισημάνω ότι το σύνηθες είναι να μην μπορούμε να καλύψουμε όλες τις περιπτώσεις με το επιλεγμένο partition key για αυτό και επιλέγουμε αυτό που καλύπτει τις περισσότερες περιπτώσεις.

Το partition key μπορεί να είναι κάποιο από τα document properties αν είμαστε σίγουροι ότι σε όλα τα documents αυτό θα υπάρχει ή κάποιο generic που θα φτιάχνουμε για να καλύψουμε την ανάγκη αυτή.

Εδώ θα πρέπει να λάβουμε υπόψη ότι μπορεί να μην έχω περιορισμό στο μέγεθος των physical partitions αλλά έχω περιορισμό στο μέγεθος του κάθε logical partition και αυτός είναι τα 10GB.

Ακόμα θα πρέπει να υπολογίσουμε τα transactions στην επιλογή του partition key καθώς η Cosmos DB υποστηρίζει ACID transactions αλλά μόνο στα όρια ενός single partition.

Φυσικά ακόμα μια παράμετρος είναι το querying καθώς δεν θέλουμε να δημιουργούμε hot sports στο partitioning (odd distribution vs even distribution).

Η Microsoft προτείνει ότι το partition key πρέπει να πολλές διακριτές τιμές (100-1000 το ελάχιστο).

Επίσης έχει διαπιστωθεί ότι collections που είναι κάτω από 1GB η επιλογή partition key μπορεί να γίνει «αυθαίρετα», αν και θα συνιστούσα να μην γίνει.

When to denormalize data

Σε προηγούμενο άρθρο μου ανέφερα ότι στην Cosmo DB τα δεδομένα είναι κυρίως denormalized, όμως πάντα υπάρχει το σαιξπηρικό ερώτημα που πρέπει να απαντηθεί.

Επιλέγουμε να κάνουμε denormalization όταν:

  • έχουμε λογικές οντότητες που περιέχονται σε άλλες πχ μαθήματα / μαθητής.
  • οι λογικές οντότητες έχουν 1:Μ σχέσεις πχ τηλέφωνα / πρόσωπο
  • τα denormalized records αλλάζουν σπάνια πχ μαθήματα
  • ο αριθμός των denormalized records είσαι συγκεκριμένος και μικρός.

Αντίθετα επιλέγουμε το normalization όταν:

  • Οι λογικές οντότητες αλλάζουν συχνά πχ αλλαγές τιμών στα προϊόντα.
  • Όταν οι λογικές οντότητες έχουν N:M σχέσεις.
  • Όταν δεν υπάρχει συγκεκριμένος αριθμός από records πχ σχόλια σε κοινωνικά δίκτυα.

Επίσης πρέπει να επισημανθεί ότι στην Cosmos DB όταν κάνω update ένα συγκεκριμένο σημείο ενός document θα πρέπει να κάνω update όλο το document καθώς δεν υποστηρίζει partial update και αυτό σαν διαδικασία είναι ακριβή σε πόρους ιδιαίτερα όταν έχω να κάνω συχνά αυτή.


//antonch


Antonios Chatzipavlis

Antonios Chatzipavlis

Antonios is a Data Solutions Consultant and Trainer. He has been working in IT since 1988. In his career, he has worked as senior developer, IT Manager, Solutions Architect and IT Consultant. Since 1995 he has been devoted on new technologies and software development tools, mainly by Microsoft, either by training company staff and colleagues or assisting them in design, development and implementation as a consultant or chief developer. He has focused in Databases and Data Science since 1995. He specialized in Microsoft SQL Server since version 6.0 in areas like SQL Server Internals, Database Design and Development, Business Intelligence and in 2010 he has started working with Azure Data Platform, NoSQL databases, Big Data Technologies and Machine Learning. He is an active member of many IT communities in Greece, answering colleagues' questions and writing articles in his web site. He is the owner of SQLschool.gr which is a community portal with a lot of information about Microsoft SQL Server. He has been a Microsoft Certified Trainer (MCT) since 2000. Microsoft honored him as MVP on Data Platform due to his activities in SQL Server since 2010. He holds a large number of Microsoft Certifications and Microsoft SQL Server Certifications since version 6.5.


Leave your comment

COMMENT

FULL NAME

EMAIL ADDRESS

We use Gravatar

WEB SITE



captcha


 

Newsletter

If you want to receive updates from us subscribe below with your email.
Follow us in
PASS chapter logo

The Official PASS Local Group for Greece

About us Contact us Terms of Use Privacy Sing in Register
sql school greece logo
© 2010-2020 All rights reserved

This site uses cookies for operational and analytics purposes only. By continuing to browse this site, you agree to their use.