Γεια σας, κάτοικοι του Khabrovsk. Τα μαθήματα στην πρώτη ομάδα του μαθήματος ξεκινούν σήμερα . Από αυτή την άποψη, θα θέλαμε να σας πούμε πώς πραγματοποιήθηκε το ανοιχτό διαδικτυακό σεμινάριο σε αυτό το μάθημα.
В μιλήσαμε για τις προκλήσεις που αντιμετωπίζουν οι βάσεις δεδομένων SQL στην εποχή των cloud και του Kubernetes. Ταυτόχρονα, εξετάσαμε πώς οι βάσεις δεδομένων SQL προσαρμόζονται και μεταλλάσσονται υπό την επίδραση αυτών των προκλήσεων.
Το διαδικτυακό σεμινάριο πραγματοποιήθηκε , Google Cloud Practice Delivery Manager στην EPAM Systems.
Όταν τα δέντρα ήταν μικρά...
Αρχικά, ας θυμηθούμε πώς ξεκίνησε η επιλογή του DBMS στα τέλη του περασμένου αιώνα. Ωστόσο, αυτό δεν θα είναι δύσκολο, γιατί η επιλογή ενός DBMS εκείνες τις μέρες ξεκίνησε και τελείωσε μαντείο.
Στα τέλη της δεκαετίας του '90 και στις αρχές της δεκαετίας του 2, ουσιαστικά δεν υπήρχε επιλογή όσον αφορά τις βιομηχανικές κλιμακούμενες βάσεις δεδομένων. Ναι, υπήρχαν IBM DBXNUMX, Sybase και κάποιες άλλες βάσεις δεδομένων που ήρθαν και έφυγαν, αλλά γενικά δεν ήταν τόσο αισθητές στο φόντο της Oracle. Αντίστοιχα, οι δεξιότητες των μηχανικών εκείνης της εποχής ήταν κατά κάποιο τρόπο συνδεδεμένες με τη μοναδική επιλογή που υπήρχε.
Το Oracle DBA έπρεπε να είναι σε θέση:
- εγκαταστήστε τον Oracle Server από το κιτ διανομής.
- ρυθμίστε τις παραμέτρους του διακομιστή Oracle:
- init.ora;
- ακροατής.ora;
- δημιουργία:
- επιτραπέζιοι χώροι?
- σχέδιο;
- χρήστες·
— δημιουργία αντιγράφων ασφαλείας και επαναφορά·
— διεξαγωγή παρακολούθησης·
— αντιμετώπιση μη βέλτιστων αιτημάτων.
Ταυτόχρονα, δεν υπήρχε ειδική απαίτηση από την Oracle DBA:
- να είναι σε θέση να επιλέξει το βέλτιστο DBMS ή άλλη τεχνολογία για την αποθήκευση και την επεξεργασία δεδομένων.
- παρέχουν υψηλή διαθεσιμότητα και οριζόντια επεκτασιμότητα (αυτό δεν ήταν πάντα ένα ζήτημα DBA)·
- καλή γνώση του αντικειμένου, της υποδομής, της αρχιτεκτονικής εφαρμογών, του λειτουργικού συστήματος.
- φόρτωση και εκφόρτωση δεδομένων, μετεγκατάσταση δεδομένων μεταξύ διαφορετικών DBMS.
Γενικά, αν μιλάμε για την επιλογή εκείνων των ημερών, μοιάζει με την επιλογή σε ένα σοβιετικό κατάστημα στα τέλη της δεκαετίας του '80:
Ο χρόνος μας
Από τότε, φυσικά, τα δέντρα μεγάλωσαν, ο κόσμος άλλαξε και έγινε κάπως έτσι:
Η αγορά DBMS έχει επίσης αλλάξει, όπως φαίνεται ξεκάθαρα από την τελευταία αναφορά της Gartner:
Και εδώ πρέπει να σημειωθεί ότι τα σύννεφα, των οποίων η δημοτικότητα αυξάνεται, έχουν καταλάβει τη θέση τους. Αν διαβάσουμε την ίδια έκθεση Gartner, θα δούμε τα ακόλουθα συμπεράσματα:
- Πολλοί πελάτες βρίσκονται στο δρόμο για τη μεταφορά εφαρμογών στο cloud.
- Οι νέες τεχνολογίες εμφανίζονται αρχικά στο cloud και δεν είναι γεγονός ότι θα περάσουν ποτέ σε υποδομές non-cloud.
- Το μοντέλο τιμολόγησης pay-as-you-go έχει γίνει συνηθισμένο. Ο καθένας θέλει να πληρώσει μόνο για ό,τι χρησιμοποιεί, και αυτό δεν είναι καν τάση, αλλά απλώς μια δήλωση γεγονότων.
Τώρα τι?
Σήμερα είμαστε όλοι στο σύννεφο. Και τα ερωτήματα που προκύπτουν για εμάς είναι ζητήματα επιλογής. Και είναι τεράστιο, ακόμα κι αν μιλάμε μόνο για την επιλογή τεχνολογιών DBMS σε μορφή On-premises. Έχουμε επίσης διαχειριζόμενες υπηρεσίες και SaaS. Έτσι, η επιλογή γίνεται πιο δύσκολη κάθε χρόνο.
Μαζί με ερωτήσεις επιλογής, υπάρχουν επίσης περιοριστικούς παράγοντες:
- τιμή. Πολλές τεχνολογίες εξακολουθούν να κοστίζουν χρήματα.
- δεξιότητες. Αν μιλάμε για ελεύθερο λογισμικό, τότε τίθεται το ζήτημα των δεξιοτήτων, καθώς το ελεύθερο λογισμικό απαιτεί επαρκή ικανότητα από τους ανθρώπους που το αναπτύσσουν και το χειρίζονται.
- λειτουργικός. Δεν έχουν όλες οι υπηρεσίες που είναι διαθέσιμες στο cloud και κατασκευασμένες, ας πούμε, ακόμη και στο ίδιο Postgres, τις ίδιες δυνατότητες με τις On-premises Postgres. Αυτός είναι ένας ουσιαστικός παράγοντας που πρέπει να γίνει γνωστός και κατανοητός. Επιπλέον, αυτός ο παράγοντας γίνεται πιο σημαντικός από τη γνώση κάποιων κρυφών δυνατοτήτων ενός μεμονωμένου DBMS.
Τι αναμένεται από το DA/DE τώρα:
- καλή κατανόηση της θεματικής περιοχής και της αρχιτεκτονικής εφαρμογών.
- τη δυνατότητα σωστής επιλογής της κατάλληλης τεχνολογίας DBMS, λαμβάνοντας υπόψη την υπό εξέταση εργασία.
- τη δυνατότητα επιλογής της βέλτιστης μεθόδου για την εφαρμογή της επιλεγμένης τεχνολογίας στο πλαίσιο των υφιστάμενων περιορισμών·
- ικανότητα μεταφοράς και μετεγκατάστασης δεδομένων·
- ικανότητα εφαρμογής και λειτουργίας επιλεγμένων λύσεων.
Παρακάτω παράδειγμα με βάση το GCP δείχνει πώς λειτουργεί η επιλογή μιας ή άλλης τεχνολογίας για εργασία με δεδομένα ανάλογα με τη δομή της:
Λάβετε υπόψη ότι η PostgreSQL δεν περιλαμβάνεται στο σχήμα και αυτό συμβαίνει επειδή είναι κρυμμένο κάτω από την ορολογία Cloud SQL. Και όταν φτάσουμε στο Cloud SQL, πρέπει να κάνουμε ξανά μια επιλογή:
Θα πρέπει να σημειωθεί ότι αυτή η επιλογή δεν είναι πάντα σαφής, επομένως οι προγραμματιστές εφαρμογών συχνά καθοδηγούνται από τη διαίσθηση.
Итого:
- Όσο προχωράτε, τόσο πιο πιεστικό γίνεται το ζήτημα της επιλογής. Και ακόμα κι αν κοιτάξετε μόνο το GCP, τις διαχειριζόμενες υπηρεσίες και το SaaS, τότε κάποια αναφορά του RDBMS εμφανίζεται μόνο στο 4ο βήμα (και εκεί βρίσκεται το Spanner κοντά). Επιπλέον, η επιλογή του PostgreSQL εμφανίζεται στο 5ο βήμα και δίπλα του υπάρχουν επίσης MySQL και SQL Server, δηλαδή υπάρχουν πολλά από όλα, αλλά πρέπει να διαλέξετε.
- Δεν πρέπει να ξεχνάμε τους περιορισμούς στο πλαίσιο των πειρασμών. Βασικά όλοι θέλουν ένα κλειδί, αλλά είναι ακριβό. Ως αποτέλεσμα, ένα τυπικό αίτημα μοιάζει κάπως έτσι: "Παρακαλώ κάντε μας ένα κλειδί, αλλά για την τιμή του Cloud SQL, είστε επαγγελματίες!"
Αλλά τι να κάνουμε;
Χωρίς να ισχυριζόμαστε ότι είμαστε η απόλυτη αλήθεια, ας πούμε τα εξής:
Πρέπει να αλλάξουμε την προσέγγισή μας στη μάθηση:
- Δεν έχει νόημα να διδάσκουμε τον τρόπο που διδάσκονταν τα DBA πριν.
- Η γνώση ενός προϊόντος δεν είναι πλέον αρκετή.
- αλλά το να γνωρίζεις δεκάδες στο επίπεδο του ενός είναι αδύνατο.
Πρέπει να γνωρίζετε όχι μόνο και όχι πόσο είναι το προϊόν, αλλά:
- περίπτωση χρήσης της εφαρμογής του·
- διαφορετικές μεθόδους ανάπτυξης·
- πλεονεκτήματα και μειονεκτήματα κάθε μεθόδου·
- παρόμοια και εναλλακτικά προϊόντα για να κάνετε μια ενημερωμένη και βέλτιστη επιλογή και όχι πάντα υπέρ ενός οικείου προϊόντος.
Πρέπει επίσης να είστε σε θέση να μεταφέρετε δεδομένα και να κατανοήσετε τις βασικές αρχές της ενοποίησης με το ETL.
πραγματική υπόθεση
Στο πρόσφατο παρελθόν, ήταν απαραίτητο να δημιουργηθεί ένα backend για μια εφαρμογή για κινητά. Όταν ξεκίνησαν οι εργασίες σε αυτό, το backend είχε ήδη αναπτυχθεί και ήταν έτοιμο για εφαρμογή, και η ομάδα ανάπτυξης πέρασε περίπου δύο χρόνια σε αυτό το έργο. Ορίστηκαν οι ακόλουθες εργασίες:
- Δημιουργία CI/CD.
- αναθεώρηση της αρχιτεκτονικής?
- τα θέσει όλα σε λειτουργία.
Η ίδια η εφαρμογή ήταν microservices και ο κώδικας Python/Django αναπτύχθηκε από την αρχή και απευθείας στο GCP. Όσον αφορά το κοινό-στόχο, υποτέθηκε ότι θα υπήρχαν δύο περιοχές - ΗΠΑ και ΕΕ, και η κίνηση κατανεμήθηκε μέσω του εξισορροπητή παγκόσμιου φορτίου. Όλοι οι φόρτοι εργασίας και ο υπολογισμός του φόρτου εργασίας εκτελούνταν στο Google Kubernetes Engine.
Όσον αφορά τα δεδομένα, υπήρχαν 3 δομές:
- Cloud Storage;
- Αποθήκη δεδομένων;
- Cloud SQL (PostgreSQL).
Θα μπορούσε κανείς να αναρωτηθεί γιατί επιλέχθηκε το Cloud SQL; Για να πούμε την αλήθεια, μια τέτοια ερώτηση έχει προκαλέσει κάποιο είδος αμήχανης παύσης τα τελευταία χρόνια - υπάρχει η αίσθηση ότι οι άνθρωποι έχουν γίνει ντροπαλοί για τις σχεσιακές βάσεις δεδομένων, αλλά παρόλα αυτά συνεχίζουν να τις χρησιμοποιούν ενεργά ;-).
Όσον αφορά την περίπτωσή μας, το Cloud SQL επιλέχθηκε για τους εξής λόγους:
- Όπως αναφέρθηκε, η εφαρμογή αναπτύχθηκε χρησιμοποιώντας το Django και διαθέτει ένα μοντέλο για την αντιστοίχιση μόνιμα δεδομένων από μια βάση δεδομένων SQL σε αντικείμενα Python (Django ORM).
- Το ίδιο το πλαίσιο υποστήριζε μια αρκετά πεπερασμένη λίστα DBMS:
- PostgreSQL;
- MariaDB;
- MySQL;
- Μαντείο;
- SQLite.
Συνεπώς, η PostgreSQL επιλέχθηκε από αυτήν τη λίστα μάλλον διαισθητικά (καλά, δεν είναι η Oracle να επιλέξει, πραγματικά).
Τι έλειπε:
- η εφαρμογή αναπτύχθηκε μόνο σε 2 περιοχές και μια 3η εμφανίστηκε στα σχέδια (Ασία).
- Η βάση δεδομένων βρισκόταν στην περιοχή της Βόρειας Αμερικής (Αϊόβα).
- από την πλευρά του πελάτη υπήρχαν ανησυχίες για πιθανή καθυστερήσεις πρόσβασης από την Ευρώπη και την Ασία και διακοπές σε υπηρεσία σε περίπτωση διακοπής λειτουργίας του DBMS.
Παρά το γεγονός ότι το ίδιο το Django μπορεί να συνεργαστεί με πολλές βάσεις δεδομένων παράλληλα και να τις χωρίσει σε ανάγνωση και γραφή, δεν υπήρχε τόσο πολλή γραφή στην εφαρμογή (πάνω από το 90% διαβάζει). Και γενικά, και γενικά, αν ήταν δυνατόν να γίνει ανάγνωση-αντίγραφο της κύριας βάσης στην Ευρώπη και την Ασία, αυτή θα ήταν μια συμβιβαστική λύση. Λοιπόν, τι είναι τόσο περίπλοκο σε αυτό;
Η δυσκολία ήταν ότι ο πελάτης δεν ήθελε να εγκαταλείψει τη χρήση διαχειριζόμενων υπηρεσιών και Cloud SQL. Και οι δυνατότητες του Cloud SQL είναι προς το παρόν περιορισμένες. Το Cloud SQL υποστηρίζει High Availability (HA) και Read Replica (RR), αλλά το ίδιο RR υποστηρίζεται μόνο σε μία περιοχή. Έχοντας δημιουργήσει μια βάση δεδομένων στην περιοχή της Αμερικής, δεν μπορείτε να δημιουργήσετε αντίγραφο ανάγνωσης στην ευρωπαϊκή περιοχή χρησιμοποιώντας το Cloud SQL, αν και η ίδια η Postgres δεν σας εμποδίζει να το κάνετε αυτό. Η αλληλογραφία με τους υπαλλήλους της Google δεν οδήγησε πουθενά και τελείωσε με υποσχέσεις του τύπου «ξέρουμε το πρόβλημα και εργαζόμαστε πάνω σε αυτό, κάποια μέρα το ζήτημα θα επιλυθεί».
Αν απαριθμήσουμε τις δυνατότητες του Cloud SQL εν συντομία, θα μοιάζει κάπως έτσι:
1. Υψηλή διαθεσιμότητα (HA):
- εντός μιας περιοχής·
- Μέσω αναπαραγωγής δίσκου.
- Οι μηχανές PostgreSQL δεν χρησιμοποιούνται.
- δυνατός αυτόματος και χειροκίνητος έλεγχος - failover/failback.
- Κατά την εναλλαγή, το DBMS δεν είναι διαθέσιμο για αρκετά λεπτά.
2. Διαβάστε το αντίγραφο (RR):
- εντός μιας περιοχής·
- ζεστή αναμονή?
- Αντιγραφή ροής PostgreSQL.
Επιπλέον, όπως συνηθίζεται, όταν επιλέγετε μια τεχνολογία βρίσκεστε πάντα αντιμέτωποι με κάποια περιορισμοί:
- ο πελάτης δεν ήθελε να δημιουργήσει οντότητες και να χρησιμοποιήσει το IaaS, παρά μόνο μέσω ΓΚΕ.
- ο πελάτης δεν θα ήθελε να αναπτύξει αυτοεξυπηρέτηση PostgreSQL/MySQL.
- Λοιπόν, γενικά, το Google Spanner θα ήταν αρκετά κατάλληλο αν δεν ήταν για την τιμή του, ωστόσο, το Django ORM δεν μπορεί να λειτουργήσει μαζί του, αλλά είναι καλό.
Λαμβάνοντας υπόψη την κατάσταση, ο πελάτης έλαβε μια επόμενη ερώτηση: "Μπορείτε να κάνετε κάτι παρόμοιο ώστε να είναι σαν το Google Spanner, αλλά και να λειτουργεί με το Django ORM;"
Επιλογή λύσης Νο. 0
Το πρώτο πράγμα που μου ήρθε στο μυαλό:
- παραμονή στο CloudSQL.
- Δεν θα υπάρχει ενσωματωμένη αναπαραγωγή μεταξύ περιοχών σε οποιαδήποτε μορφή.
- προσπαθήστε να επισυνάψετε ένα αντίγραφο σε ένα υπάρχον Cloud SQL από την PostgreSQL.
- εκκινήστε μια παρουσία PostgreSQL κάπου και με κάποιο τρόπο, αλλά τουλάχιστον μην αγγίζετε το master.
Δυστυχώς, αποδείχθηκε ότι αυτό δεν μπορεί να γίνει, επειδή δεν υπάρχει πρόσβαση στον κεντρικό υπολογιστή (είναι σε διαφορετικό έργο συνολικά) - pg_hba και ούτω καθεξής, και επίσης δεν υπάρχει πρόσβαση στον υπερχρήστη.
Επιλογή λύσης Νο. 1
Μετά από περαιτέρω προβληματισμό και λαμβάνοντας υπόψη τις προηγούμενες συνθήκες, η σειρά της σκέψης άλλαξε κάπως:
- Εξακολουθούμε να προσπαθούμε να παραμείνουμε εντός του CloudSQL, αλλά μεταβαίνουμε στη MySQL, επειδή το Cloud SQL by MySQL έχει ένα εξωτερικό κύριο, το οποίο:
— είναι ένας διακομιστής μεσολάβησης για εξωτερική MySQL.
- μοιάζει με μια παρουσία MySQL.
- εφευρέθηκε για τη μεταφορά δεδομένων από άλλα σύννεφα ή On-premises.
Δεδομένου ότι η ρύθμιση της αναπαραγωγής της MySQL δεν απαιτεί πρόσβαση στον κεντρικό υπολογιστή, καταρχήν όλα λειτουργούσαν, αλλά ήταν πολύ ασταθής και άβολος. Και όταν προχωρήσαμε παραπέρα, έγινε εντελώς τρομακτικό, γιατί αναπτύξαμε ολόκληρη τη δομή με terraform, και ξαφνικά αποδείχθηκε ότι ο εξωτερικός κύριος δεν υποστηρίχθηκε από terraform. Ναι, η Google έχει ένα CLI, αλλά για κάποιο λόγο όλα λειτουργούσαν εδώ κάθε τόσο - μερικές φορές δημιουργείται, μερικές φορές δεν δημιουργείται. Ίσως επειδή το CLI εφευρέθηκε για εξωτερική μετεγκατάσταση δεδομένων και όχι για αντίγραφα.
Στην πραγματικότητα, σε αυτό το σημείο έγινε σαφές ότι το Cloud SQL δεν είναι καθόλου κατάλληλο. Όπως λένε, κάναμε ό,τι μπορούσαμε.
Επιλογή λύσης Νο. 2
Δεδομένου ότι δεν ήταν δυνατό να παραμείνουμε εντός του πλαισίου Cloud SQL, προσπαθήσαμε να διαμορφώσουμε απαιτήσεις για μια συμβιβαστική λύση. Οι απαιτήσεις αποδείχτηκαν οι εξής:
- εργασία στο Kubernetes, μέγιστη χρήση των πόρων και των δυνατοτήτων του Kubernetes (DCS, ...) και του GCP (LB, ...).
- έλλειψη έρματος από ένα σωρό περιττά πράγματα στο σύννεφο όπως HA proxy.
- τη δυνατότητα εκτέλεσης PostgreSQL ή MySQL στην κύρια περιοχή HA. σε άλλες περιοχές - HA από το RR της κύριας περιοχής συν το αντίγραφό του (για αξιοπιστία).
- multi master (δεν ήθελα να επικοινωνήσω μαζί του, αλλά δεν ήταν πολύ σημαντικό)
.
Ως αποτέλεσμα αυτών των αιτημάτων, ο σελκατάλληλες επιλογές DBMS και δέσμευσης:
- MySQL Galera;
- CockroachDB;
- Εργαλεία PostgreSQL
:
- pgpool-II;
— Πατρώνη.
MySQL Galera
Η τεχνολογία MySQL Galera αναπτύχθηκε από την Codership και είναι ένα πρόσθετο για το InnoDB. Ιδιαιτερότητες:
- multi master?
- Σύγχρονη αντιγραφή?
- ανάγνωση από οποιονδήποτε κόμβο?
- εγγραφή σε οποιονδήποτε κόμβο.
- ενσωματωμένος μηχανισμός HA.
- Υπάρχει ένα διάγραμμα Helm από το Bitnami.
Κατσαρίδα DB
Σύμφωνα με την περιγραφή, το πράγμα είναι απολύτως βόμβα και είναι ένα έργο ανοιχτού κώδικα γραμμένο στο Go. Ο κύριος συμμετέχων είναι η Cockroach Labs (που ιδρύθηκε από άτομα της Google). Αυτό το σχεσιακό DBMS σχεδιάστηκε αρχικά για διανομή (με οριζόντια κλιμάκωση εκτός του κουτιού) και ανεκτικό σε σφάλματα. Οι συντάκτες του από την εταιρεία περιέγραψαν τον στόχο του «συνδυασμού του πλούτου της λειτουργικότητας SQL με την οριζόντια προσβασιμότητα που είναι γνωστή στις λύσεις NoSQL».
Ένα ωραίο μπόνους είναι η υποστήριξη για το πρωτόκολλο σύνδεσης μετά την έξοδο.
pgpool
Αυτό είναι ένα πρόσθετο στην PostgreSQL, στην πραγματικότητα, μια νέα οντότητα που αναλαμβάνει όλες τις συνδέσεις και τις επεξεργάζεται. Διαθέτει τον δικό του εξισορροπητή φορτίου και αναλυτή, με άδεια χρήσης βάσει της άδειας BSD. Παρέχει άφθονες ευκαιρίες, αλλά φαίνεται κάπως τρομακτικό, επειδή η παρουσία μιας νέας οντότητας θα μπορούσε να γίνει η πηγή κάποιων επιπλέον περιπετειών.
Πατρώνη
Αυτό είναι το τελευταίο πράγμα στο οποίο έπεσαν τα μάτια μου και, όπως αποδείχτηκε, όχι μάταια. Το Patroni είναι ένα βοηθητικό πρόγραμμα ανοιχτού κώδικα, το οποίο είναι ουσιαστικά ένας δαίμονας Python που σας επιτρέπει να διατηρείτε αυτόματα συμπλέγματα PostgreSQL με διάφορους τύπους αναπαραγωγής και αυτόματη εναλλαγή ρόλων. Το πράγμα αποδείχθηκε πολύ ενδιαφέρον, αφού ενσωματώνεται καλά με το cuber και δεν εισάγει νέες οντότητες.
Τι διάλεξες τελικά;
Η επιλογή δεν ήταν εύκολη:
- Κατσαρίδα DB - φωτιά, αλλά σκοτεινό.
- MySQL Galera - επίσης δεν είναι κακό, χρησιμοποιείται σε πολλά μέρη, αλλά MySQL.
- pgpool — πολλές περιττές οντότητες, άρα ενσωμάτωση με το cloud και τα K8.
- Πατρώνη - εξαιρετική ενσωμάτωση με K8, χωρίς περιττές οντότητες, ενσωματώνεται καλά με το GCP LB.
Έτσι, η επιλογή έπεσε στον Πατρώνη.
Ευρήματα
Ήρθε η ώρα να συνοψίσουμε εν συντομία. Ναι, ο κόσμος της υποδομής πληροφορικής έχει αλλάξει σημαντικά και αυτή είναι μόνο η αρχή. Και αν πριν τα σύννεφα ήταν απλώς ένας άλλος τύπος υποδομής, τώρα όλα είναι διαφορετικά. Επιπλέον, καινοτομίες στα σύννεφα εμφανίζονται συνεχώς, θα εμφανίζονται και, ίσως, θα εμφανίζονται μόνο στα σύννεφα και μόνο τότε, με τις προσπάθειες των startups, θα μεταφερθούν στο On-premises.
Όσο για την SQL, η SQL θα είναι ζωντανή. Αυτό σημαίνει ότι πρέπει να γνωρίζετε τα PostgreSQL και MySQL και να μπορείτε να εργαστείτε μαζί τους, αλλά ακόμα πιο σημαντικό είναι να μπορείτε να τα χρησιμοποιείτε σωστά.
Πηγή: www.habr.com