(My)SQL Limitations (off-topic)

[Pantelis Koukousoulas]

2011/6/21 Apostolos Bessas <mpessas at gmail.com>:
> 2011/6/21 Giorgos Logiotatidis <seadog at sealabs.net>:
>> Ήδη ετοιμάζω ένα sql schema για να μπορέσω να κάνω
>> μερικά συγκριτικά με τον πραγματικό φόρτο που θέλω
>> να βάλω

FWIW, για το είδος της εφαρμογής που θέλεις αντί για MySQL θα δοκίμαζα
MariaDB (το "100% compatible" fork της MySQL) γιατί έχει ένα ωραίο patch
από google μεριά, ώστε όταν έχεις master-slave replication, να μην
οριστικοποιεί (commit) ένα update αν τα καινούργια δεδομένα δεν έχουν
περάσει και σε τουλάχιστον έναν slave.

Είναι δηλαδή κάτι ανάμεσα στο να έχουν αντίγραφο όλοι οι slaves και
το να έχει τα δεδομένα μόνο ο master.

Καθώς η google έχει χρησιμοποιήσει MySQL για τα adwords, φαντάζομαι
ότι δεν υπάρχει κάποιο "inherent" scalability πρόβλημα και στη MySQL.

Τώρα από εκεί και πέρα, το ποια ακριβώς λύση σε βολεύει καλύτερα
είναι θέμα των χαρακτηριστικών της εφαρμογής (επιθυμητό transaction
rate, read vs write ποσοστά, SLA ή όχι ως προς το χρόνο απόκρισης,
θέματα  διαχείρισης, θέματα μεγέθους του κώδικα και αποσφαλμάτωσης,
πόσο εύκολο και γρήγορο είναι το να προσθέσεις ένα νέο χαρακτηριστικό
κλπ κλπ).

Προσωπικά θα κοίταγα σοβαρά την πιθανότητα να υλοποιήσω μια τέτοια
εφαρμογή, (dropbox alternative) τουλάχιστον εν μέρει πάνω στο google
appengine.

Λόγοι:
    * Storage replicated across datacenters και κάποιος άλλος έχει την
      ευθύνη της διαχείρισης.

    * Αν η εφαρμογή έχει αρκετή επιτυχία ώστε να στηρίξει ένα startup, το να
      τρέχεις ήδη πάνω στην υποδομή της google αυξάνει τις πιθανότητες να
      θέλει να αγοράσει στο μέλλον η Google αυτό το startup.

Το μειονέκτημα είναι ότι αν πας σε τέτοια λύση τότε ξεχνάς κάθε δυνατότητα
για JOINs και πολύπλοκο schema και θα πρέπει να δομήσεις την εφαρμογή
σου έτσι ώστε να μπορεί να δουλέψει με το "πρωτόγονο" μοντέλο πρόσβασης
που σου προσφέρει η Gql (κάτι που δεν είναι απίστευτα δύσκολο αλλά θέλει
μια κάποια σκέψη).

Just Food For Thought,
Παντελής