SQL, τι θα μπορούσε να είναι πιο απλό; Ο καθένας μας μπορεί να γράψει ένα απλό αίτημα - πληκτρολογούμε επιλέξτε, απαριθμήστε τις απαιτούμενες στήλες και στη συνέχεια από, όνομα πίνακα, ορισμένες προϋποθέσεις σε όπου και αυτό είναι όλο - χρήσιμα δεδομένα βρίσκονται στην τσέπη μας και (σχεδόν) ανεξάρτητα από το ποιο DBMS βρίσκεται κάτω από την κουκούλα εκείνη τη στιγμή (ή ίσως ). Ως αποτέλεσμα, η εργασία με σχεδόν οποιαδήποτε πηγή δεδομένων (σχεσιακή και όχι τόσο) μπορεί να εξεταστεί από την άποψη του συνηθισμένου κώδικα (με ό,τι συνεπάγεται - έλεγχος έκδοσης, έλεγχος κώδικα, στατική ανάλυση, αυτόματες δοκιμές και αυτό είναι όλο). Και αυτό δεν ισχύει μόνο για τα ίδια τα δεδομένα, τα σχήματα και τις μετεγκαταστάσεις, αλλά γενικά για ολόκληρη τη διάρκεια ζωής του χώρου αποθήκευσης. Σε αυτό το άρθρο θα μιλήσουμε για καθημερινές εργασίες και προβλήματα εργασίας με διάφορες βάσεις δεδομένων κάτω από το φακό της «βάσης δεδομένων ως κώδικας».
Και ας ξεκινήσουμε αμέσως από . Οι πρώτες μάχες τύπου "SQL vs ORM" παρατηρήθηκαν ξανά .
Αντικειμενική-σχεσιακή χαρτογράφηση
Οι υποστηρικτές του ORM παραδοσιακά εκτιμούν την ταχύτητα και την ευκολία ανάπτυξης, την ανεξαρτησία από το DBMS και τον καθαρό κώδικα. Για πολλούς από εμάς, ο κώδικας για την εργασία με τη βάση δεδομένων (και συχνά την ίδια τη βάση δεδομένων)
συνήθως μοιάζει κάπως έτσι...
@Entity
@Table(name = "stock", catalog = "maindb", uniqueConstraints = {
@UniqueConstraint(columnNames = "STOCK_NAME"),
@UniqueConstraint(columnNames = "STOCK_CODE") })
public class Stock implements java.io.Serializable {
@Id
@GeneratedValue(strategy = IDENTITY)
@Column(name = "STOCK_ID", unique = true, nullable = false)
public Integer getStockId() {
return this.stockId;
}
...Το μοντέλο είναι κρεμασμένο με έξυπνους σχολιασμούς και κάπου στα παρασκήνια ένα γενναίο ORM δημιουργεί και εκτελεί τόνους κάποιου κώδικα SQL. Παρεμπιπτόντως, οι προγραμματιστές προσπαθούν ό,τι μπορούν για να απομονωθούν από τη βάση δεδομένων τους με χιλιόμετρα αφαιρέσεων, κάτι που δείχνει κάποια .
Στην άλλη πλευρά των οδοφραγμάτων, οι οπαδοί της καθαρής «χειροποίητης» SQL σημειώνουν την ικανότητα να συμπιέζουν όλο το χυμό από το DBMS τους χωρίς πρόσθετα στρώματα και αφαιρέσεις. Ως αποτέλεσμα, εμφανίζονται έργα «data-centric» όπου εμπλέκονται στη βάση δεδομένων ειδικά εκπαιδευμένοι άνθρωποι (είναι επίσης «βασικοί», είναι επίσης «βασικοί», είναι επίσης «basdeners» κ.λπ.) και οι προγραμματιστές αρκεί να «τραβήξουμε» τις έτοιμες προβολές και αποθηκευμένες διαδικασίες, χωρίς να μπούμε σε λεπτομέρειες.
Τι θα γινόταν αν είχαμε τα καλύτερα και των δύο κόσμων; Πώς γίνεται αυτό σε ένα υπέροχο εργαλείο με όνομα που επιβεβαιώνει τη ζωή . Θα δώσω μερικές γραμμές από τη γενική ιδέα στην ελεύθερη μετάφρασή μου και μπορείτε να την εξοικειωθείτε με περισσότερες λεπτομέρειες .
Η Clojure είναι μια δροσερή γλώσσα για τη δημιουργία DSL, αλλά η ίδια η SQL είναι μια ωραία DSL και δεν χρειαζόμαστε άλλη. Οι εκφράσεις S είναι υπέροχες, αλλά δεν προσθέτουν τίποτα νέο εδώ. Ως αποτέλεσμα, παίρνουμε αγκύλες για χάρη των αγκύλων. Δεν συμφωνω? Στη συνέχεια, περιμένετε τη στιγμή που η αφαίρεση πάνω από τη βάση δεδομένων αρχίσει να διαρρέει και αρχίσετε να παλεύετε με τη συνάρτηση (raw-sql)
Αρα τι πρέπει να κάνω? Ας αφήσουμε την SQL ως κανονική SQL - ένα αρχείο ανά αίτημα:
-- name: users-by-country
select *
from users
where country_code = :country_code... και, στη συνέχεια, διαβάστε αυτό το αρχείο, μετατρέποντάς το σε μια κανονική συνάρτηση Clojure:
(defqueries "some/where/users_by_country.sql"
{:connection db-spec})
;;; A function with the name `users-by-country` has been created.
;;; Let's use it:
(users-by-country {:country_code "GB"})
;=> ({:name "Kris" :country_code "GB" ...} ...)Με την τήρηση της αρχής "SQL από μόνη της, Clojure από μόνη της", λαμβάνετε:
- Χωρίς συντακτικές εκπλήξεις. Η βάση δεδομένων σας (όπως και κάθε άλλη) δεν είναι 100% συμβατή με το πρότυπο SQL - αλλά αυτό δεν έχει σημασία για την Yesql. Δεν θα χάσετε ποτέ χρόνο αναζητώντας συναρτήσεις με σύνταξη ισοδύναμης SQL. Δεν θα χρειαστεί ποτέ να επιστρέψετε σε μια λειτουργία (raw-sql "some('funky'::SYNTAX)")).
- Καλύτερη υποστήριξη συντάκτη. Ο επεξεργαστής σας έχει ήδη εξαιρετική υποστήριξη SQL. Αποθηκεύοντας την SQL ως SQL μπορείτε απλά να τη χρησιμοποιήσετε.
- Συμβατότητα ομάδας. Τα DBA σας μπορούν να διαβάζουν και να γράφουν την SQL που χρησιμοποιείτε στο έργο Clojure.
- Ευκολότερος συντονισμός απόδοσης. Χρειάζεστε να δημιουργήσετε ένα σχέδιο για ένα προβληματικό ερώτημα; Αυτό δεν είναι πρόβλημα όταν το ερώτημά σας είναι κανονικό SQL.
- Επαναχρησιμοποίηση ερωτημάτων. Σύρετε και αποθέστε αυτά τα ίδια αρχεία SQL σε άλλα έργα επειδή είναι απλά παλιά SQL - απλώς μοιραστείτε το.
Κατά τη γνώμη μου, η ιδέα είναι πολύ δροσερή και ταυτόχρονα πολύ απλή, χάρη στην οποία το έργο έχει κερδίσει πολλούς σε μια ποικιλία γλωσσών. Και στη συνέχεια θα προσπαθήσουμε να εφαρμόσουμε μια παρόμοια φιλοσοφία διαχωρισμού του κώδικα SQL από οτιδήποτε άλλο πολύ πέρα από το ORM.
Διευθυντές IDE & DB
Ας ξεκινήσουμε με μια απλή καθημερινή εργασία. Συχνά πρέπει να αναζητήσουμε ορισμένα αντικείμενα στη βάση δεδομένων, για παράδειγμα, να βρούμε έναν πίνακα στο σχήμα και να μελετήσουμε τη δομή του (ποιες στήλες, κλειδιά, ευρετήρια, περιορισμοί κ.λπ. χρησιμοποιούνται). Και από οποιοδήποτε γραφικό IDE ή έναν μικρό διαχειριστή DB, πρώτα απ 'όλα, περιμένουμε ακριβώς αυτές τις ικανότητες. Για να είναι γρήγορο και να μην χρειάζεται να περιμένετε μισή ώρα μέχρι να σχεδιαστεί ένα παράθυρο με τις απαραίτητες πληροφορίες (ειδικά με αργή σύνδεση σε απομακρυσμένη βάση δεδομένων), και ταυτόχρονα οι πληροφορίες που λαμβάνετε να είναι φρέσκες και σχετικές, και όχι αποθηκευμένα σκουπίδια. Επιπλέον, όσο πιο σύνθετη και μεγαλύτερη είναι η βάση δεδομένων και όσο μεγαλύτερος είναι ο αριθμός τους, τόσο πιο δύσκολο είναι να γίνει αυτό.
Συνήθως όμως πετάω το ποντίκι και γράφω απλώς κώδικα. Ας υποθέσουμε ότι πρέπει να μάθετε ποιοι πίνακες (και με ποιες ιδιότητες) περιέχονται στο σχήμα "HR". Στα περισσότερα DBMS, το επιθυμητό αποτέλεσμα μπορεί να επιτευχθεί με αυτό το απλό ερώτημα από το information_schema:
select table_name
, ...
from information_schema.tables
where schema = 'HR'Από βάση δεδομένων σε βάση δεδομένων, τα περιεχόμενα τέτοιων πινάκων αναφοράς ποικίλλουν ανάλογα με τις δυνατότητες κάθε DBMS. Και, για παράδειγμα, για τη MySQL, από το ίδιο βιβλίο αναφοράς μπορείτε να λάβετε παραμέτρους πίνακα ειδικών για αυτό το DBMS:
select table_name
, storage_engine -- Используемый "движок" ("MyISAM", "InnoDB" etc)
, row_format -- Формат строки ("Fixed", "Dynamic" etc)
, ...
from information_schema.tables
where schema = 'HR'Η Oracle δεν γνωρίζει το information_schema, αλλά γνωρίζει , και δεν προκύπτουν μεγάλα προβλήματα:
select table_name
, pct_free -- Минимум свободного места в блоке данных (%)
, pct_used -- Минимум используемого места в блоке данных (%)
, last_analyzed -- Дата последнего сбора статистики
, ...
from all_tables
where owner = 'HR'Το ClickHouse δεν αποτελεί εξαίρεση:
select name
, engine -- Используемый "движок" ("MergeTree", "Dictionary" etc)
, ...
from system.tables
where database = 'HR'Κάτι παρόμοιο μπορεί να γίνει στην Κασσάνδρα (η οποία έχει οικογένειες στηλών αντί για πίνακες και κενά κλειδιά αντί για σχήματα):
select columnfamily_name
, compaction_strategy_class -- Стратегия сборки мусора
, gc_grace_seconds -- Время жизни мусора
, ...
from system.schema_columnfamilies
where keyspace_name = 'HR'Για τις περισσότερες άλλες βάσεις δεδομένων, μπορείτε επίσης να βρείτε παρόμοια ερωτήματα (ακόμη και η Mongo έχει , το οποίο περιέχει πληροφορίες για όλες τις συλλογές του συστήματος).
Φυσικά, με αυτόν τον τρόπο μπορείτε να λάβετε πληροφορίες όχι μόνο για πίνακες, αλλά για οποιοδήποτε αντικείμενο γενικότερα. Κατά καιρούς, ευγενικοί άνθρωποι μοιράζονται τέτοιο κώδικα για διαφορετικές βάσεις δεδομένων, όπως, για παράδειγμα, στη σειρά άρθρων habra «Λειτουργίες τεκμηρίωσης βάσεων δεδομένων PostgreSQL» (, , ). Φυσικά, το να κρατάω όλο αυτό το πλήθος ερωτημάτων στο μυαλό μου και να τις πληκτρολογώ συνεχώς, είναι πολύ ευχάριστο, έτσι στον αγαπημένο μου IDE/editor έχω ένα προπαρασκευασμένο σύνολο αποσπασμάτων για συχνά χρησιμοποιούμενα ερωτήματα και το μόνο που μένει είναι να πληκτρολογήσω το ονόματα αντικειμένων στο πρότυπο.
Ως αποτέλεσμα, αυτή η μέθοδος πλοήγησης και αναζήτησης αντικειμένων είναι πολύ πιο ευέλικτη, εξοικονομεί πολύ χρόνο και σας επιτρέπει να λαμβάνετε ακριβώς τις πληροφορίες με τη μορφή που είναι τώρα απαραίτητες (όπως, για παράδειγμα, περιγράφεται στην ανάρτηση ).
Λειτουργίες με αντικείμενα
Αφού βρούμε και μελετήσουμε τα απαραίτητα αντικείμενα, ήρθε η ώρα να κάνουμε κάτι χρήσιμο με αυτά. Φυσικά, επίσης χωρίς να αφαιρέσετε τα δάχτυλά σας από το πληκτρολόγιο.
Δεν είναι μυστικό ότι η απλή διαγραφή ενός πίνακα θα φαίνεται ίδια σε όλες σχεδόν τις βάσεις δεδομένων:
drop table hr.personsΑλλά με τη δημιουργία του πίνακα γίνεται πιο ενδιαφέρον. Σχεδόν κάθε DBMS (συμπεριλαμβανομένων πολλών NoSQL) μπορεί να "δημιουργήσει πίνακα" με τη μία ή την άλλη μορφή και το κύριο μέρος του θα διαφέρει ακόμη και ελαφρώς (όνομα, λίστα στηλών, τύποι δεδομένων), αλλά άλλες λεπτομέρειες μπορεί να διαφέρουν δραματικά και εξαρτώνται από εσωτερική συσκευή και δυνατότητες ενός συγκεκριμένου ΣΔΒΔ. Το αγαπημένο μου παράδειγμα είναι ότι στην τεκμηρίωση της Oracle υπάρχουν μόνο "γυμνά" BNF για τη σύνταξη "δημιουργία πίνακα" . Άλλα DBMS έχουν πιο μέτριες δυνατότητες, αλλά καθένα από αυτά έχει επίσης πολλά ενδιαφέροντα και μοναδικά χαρακτηριστικά για τη δημιουργία πινάκων (, , , ). Είναι απίθανο οποιοσδήποτε γραφικός «μάγος» από άλλο IDE (ειδικά καθολικό) να μπορεί να καλύψει πλήρως όλες αυτές τις ικανότητες, και ακόμα κι αν μπορεί, δεν θα είναι θέαμα για τους αδύναμους. Ταυτόχρονα μια ορθή και έγκαιρη γραπτή δήλωση δημιουργία πίνακα θα σας επιτρέψει να τα χρησιμοποιήσετε εύκολα όλα, να κάνετε την αποθήκευση και την πρόσβαση στα δεδομένα σας αξιόπιστα, βέλτιστα και όσο το δυνατόν πιο άνετα.
Επίσης, πολλά DBMS έχουν τους δικούς τους συγκεκριμένους τύπους αντικειμένων που δεν είναι διαθέσιμα σε άλλα DBMS. Επιπλέον, μπορούμε να εκτελέσουμε λειτουργίες όχι μόνο σε αντικείμενα βάσης δεδομένων, αλλά και στο ίδιο το DBMS, για παράδειγμα, να «σκοτώσει» μια διαδικασία, να ελευθερώσει κάποια περιοχή μνήμης, να ενεργοποιήσει την ανίχνευση, να μεταβεί σε λειτουργία «μόνο για ανάγνωση» και πολλά άλλα.
Τώρα ας ζωγραφίσουμε λίγο
Μία από τις πιο συνηθισμένες εργασίες είναι να δημιουργήσετε ένα διάγραμμα με αντικείμενα βάσης δεδομένων και να δείτε τα αντικείμενα και τις συνδέσεις μεταξύ τους σε μια όμορφη εικόνα. Σχεδόν κάθε γραφικό IDE, ξεχωριστά βοηθητικά προγράμματα "γραμμής εντολών", εξειδικευμένα εργαλεία γραφικών και μοντελιστές μπορούν να το κάνουν αυτό. Θα σχεδιάσουν κάτι για εσάς "όσο καλύτερα μπορούν" και μπορείτε να επηρεάσετε λίγο αυτήν τη διαδικασία μόνο με τη βοήθεια μερικών παραμέτρων στο αρχείο διαμόρφωσης ή πλαισίων ελέγχου στη διεπαφή.
Αλλά αυτό το πρόβλημα μπορεί να λυθεί πολύ πιο απλά, πιο ευέλικτα και κομψά, και φυσικά με τη βοήθεια κώδικα. Για τη δημιουργία διαγραμμάτων οποιασδήποτε πολυπλοκότητας, έχουμε αρκετές εξειδικευμένες γλώσσες σήμανσης (DOT, GraphML κ.λπ.) και για αυτές μια ολόκληρη διασπορά εφαρμογών (GraphViz, PlantUML, Mermaid) που μπορούν να διαβάσουν τέτοιες οδηγίες και να τις απεικονίσουν σε διάφορες μορφές . Λοιπόν, ξέρουμε ήδη πώς να λαμβάνουμε πληροφορίες για αντικείμενα και συνδέσεις μεταξύ τους.
Ακολουθεί ένα μικρό παράδειγμα για το πώς θα μπορούσε να μοιάζει, χρησιμοποιώντας το PlantUML και (στα αριστερά είναι ένα ερώτημα SQL που θα δημιουργήσει την απαιτούμενη εντολή για το PlantUML και στα δεξιά είναι το αποτέλεσμα):
select '@startuml'||chr(10)||'hide methods'||chr(10)||'hide stereotypes' union all
select distinct ccu.table_name || ' --|> ' ||
tc.table_name as val
from table_constraints as tc
join key_column_usage as kcu
on tc.constraint_name = kcu.constraint_name
join constraint_column_usage as ccu
on ccu.constraint_name = tc.constraint_name
where tc.constraint_type = 'FOREIGN KEY'
and tc.table_name ~ '.*' union all
select '@enduml'Και αν προσπαθήσετε λίγο, τότε με βάση μπορείτε να πάρετε κάτι πολύ παρόμοιο με ένα πραγματικό διάγραμμα ER:
Το ερώτημα SQL είναι λίγο πιο περίπλοκο
-- Шапка
select '@startuml
!define Table(name,desc) class name as "desc" << (T,#FFAAAA) >>
!define primary_key(x) <b>x</b>
!define unique(x) <color:green>x</color>
!define not_null(x) <u>x</u>
hide methods
hide stereotypes'
union all
-- Таблицы
select format('Table(%s, "%s n information about %s") {'||chr(10), table_name, table_name, table_name) ||
(select string_agg(column_name || ' ' || upper(udt_name), chr(10))
from information_schema.columns
where table_schema = 'public'
and table_name = t.table_name) || chr(10) || '}'
from information_schema.tables t
where table_schema = 'public'
union all
-- Связи между таблицами
select distinct ccu.table_name || ' "1" --> "0..N" ' || tc.table_name || format(' : "A %s may haven many %s"', ccu.table_name, tc.table_name)
from information_schema.table_constraints as tc
join information_schema.key_column_usage as kcu on tc.constraint_name = kcu.constraint_name
join information_schema.constraint_column_usage as ccu on ccu.constraint_name = tc.constraint_name
where tc.constraint_type = 'FOREIGN KEY'
and ccu.constraint_schema = 'public'
and tc.table_name ~ '.*'
union all
-- Подвал
select '@enduml'
Αν κοιτάξετε προσεκτικά, κάτω από την κουκούλα πολλά εργαλεία οπτικοποίησης χρησιμοποιούν επίσης παρόμοια ερωτήματα. Είναι αλήθεια ότι αυτά τα αιτήματα είναι συνήθως βαθιά , για να μην αναφέρουμε καμία τροποποίηση τους.
Μετρήσεις και παρακολούθηση
Ας προχωρήσουμε σε ένα παραδοσιακά πολύπλοκο θέμα - την παρακολούθηση της απόδοσης της βάσης δεδομένων. Θυμάμαι μια μικρή αληθινή ιστορία που μου είπε «ένας από τους φίλους μου». Σε ένα άλλο έργο ζούσε ένα συγκεκριμένο ισχυρό DBA και λίγοι από τους προγραμματιστές τον γνώριζαν προσωπικά ή τον είχαν δει ποτέ προσωπικά (παρά το γεγονός ότι, σύμφωνα με φήμες, δούλευε κάπου στο διπλανό κτίριο) . Την ώρα "Χ", όταν το σύστημα παραγωγής ενός μεγάλου λιανοπωλητή άρχισε να "αισθάνεται άσχημα" για άλλη μια φορά, έστειλε σιωπηλά στιγμιότυπα οθόνης από γραφήματα από το Oracle Enterprise Manager, στα οποία τόνισε προσεκτικά κρίσιμα μέρη με έναν κόκκινο δείκτη για "κατανοητότητα" ( αυτό, για να το θέσω ήπια, δεν βοήθησε πολύ). Και με βάση αυτή τη «φωτογραφία» έπρεπε να αντιμετωπίσω. Ταυτόχρονα, κανείς δεν είχε πρόσβαση στον πολύτιμο (με τις δύο έννοιες της λέξης) Enterprise Manager, γιατί το σύστημα είναι πολύπλοκο και ακριβό, ξαφνικά «οι προγραμματιστές σκοντάφτουν σε κάτι και σπάνε τα πάντα». Ως εκ τούτου, οι προγραμματιστές «εμπειρικά» βρήκαν τη θέση και την αιτία των φρένων και κυκλοφόρησαν ένα έμπλαστρο. Αν η απειλητική επιστολή από το DBA δεν ερχόταν ξανά στο εγγύς μέλλον, τότε όλοι θα έπαιρναν μια ανάσα και θα επέστρεφαν στα τρέχοντα καθήκοντά τους (μέχρι τη νέα Επιστολή).
Αλλά η διαδικασία παρακολούθησης μπορεί να φαίνεται πιο διασκεδαστική και φιλική, και το πιο σημαντικό, προσβάσιμη και διαφανής για όλους. Τουλάχιστον το βασικό του κομμάτι, ως προσθήκη στα κύρια συστήματα παρακολούθησης (που είναι σίγουρα χρήσιμα και σε πολλές περιπτώσεις αναντικατάστατα). Οποιοδήποτε ΣΔΒΔ είναι δωρεάν και εντελώς δωρεάν για την κοινή χρήση πληροφοριών σχετικά με την τρέχουσα κατάσταση και την απόδοσή του. Στο ίδιο «αιματοβαμμένο» Oracle DB, σχεδόν οποιαδήποτε πληροφορία σχετικά με την απόδοση μπορεί να ληφθεί από προβολές συστήματος, που κυμαίνονται από διεργασίες και περιόδους λειτουργίας έως την κατάσταση της προσωρινής μνήμης προσωρινής αποθήκευσης (για παράδειγμα, , ενότητα "Παρακολούθηση"). Το Postgresql έχει επίσης μια ολόκληρη δέσμη προβολών συστήματος για , ιδίως εκείνα που είναι απαραίτητα στην καθημερινή ζωή οποιουδήποτε DBA, όπως π.χ , , . Η MySQL έχει ακόμη και ένα ξεχωριστό σχήμα για αυτό. . A In Mongo ενσωματωμένο συγκεντρώνει δεδομένα απόδοσης σε μια συλλογή συστήματος .
Έτσι, οπλισμένοι με κάποιο είδος συλλέκτη μετρήσεων (Telegraf, Metricbeat, Collectd) που μπορεί να εκτελέσει προσαρμοσμένα ερωτήματα sql, μια αποθήκευση αυτών των μετρήσεων (InfluxDB, Elasticsearch, Timescaledb) και έναν οπτικοποιητή (Grafana, Kibana), μπορείτε να αποκτήσετε μια αρκετά εύκολη και ένα ευέλικτο σύστημα παρακολούθησης που θα είναι στενά ενσωματωμένο με άλλες μετρήσεις σε όλο το σύστημα (που λαμβάνονται, για παράδειγμα, από τον διακομιστή εφαρμογών, από το λειτουργικό σύστημα κ.λπ.). Όπως, για παράδειγμα, αυτό γίνεται στο pgwatch2, το οποίο χρησιμοποιεί τον συνδυασμό InfluxDB + Grafana και ένα σύνολο ερωτημάτων σε προβολές συστήματος, στις οποίες μπορείτε επίσης να έχετε πρόσβαση .
Σε συνολικά
Και αυτή είναι μόνο μια κατά προσέγγιση λίστα με το τι μπορεί να γίνει με τη βάση δεδομένων μας χρησιμοποιώντας κανονικό κώδικα SQL. Είμαι σίγουρος ότι μπορείτε να βρείτε πολλές ακόμη χρήσεις, γράψτε στα σχόλια. Και θα μιλήσουμε για το πώς (και το πιο σημαντικό γιατί) να αυτοματοποιήσετε όλα αυτά και να τα συμπεριλάβετε στο CI/CD σας την επόμενη φορά.
Πηγή: www.habr.com