FabioBuono ha scritto:
Inoltre tu hai citato booking dicendo che non userebbe mai un NoSql, ma se avessi letto il link dei clienti mongodb che postai avresti letto nomi come Expedia, Facebook, il sito del guardian, ebay, è mille altri...
E anche booking.com lo usa https://www.slideshare.net/mobile/isotopp/data-diversity-at-bookingcom
E cito testualmente "used for search much faster then mysql"
Concludo dicendo che i database Sql ci saranno sempre ma saranno e sono già tanto tanto affiancati al NoSql perché sono più veloci e comodi.
1) Nosql non è più veloce, è più lento in tutto, tranne 1 caso
2) non sono più comodi, sono più scomodi in tutto, tranne 1 caso
3) manca la gestione delle transazioni, in nosql, e pertanto nessun sito "serio", cioè deve devi essere sicuro che la transazione sia completata oppure no, può usarlo.
niente homebanking, niente booking di biglietti aerei o quello che vuoi.
niente amazon
insomma niente che non possa tollerare errori.
se mandi un messaggio facebook e questo non arriva al destinatario, è un problema, ma anche no (nel senso che non "muore nessuno").
se in booking.com quando ti appare un link esso riporta 10 risultati, invece poniamo degli 11 effettivi, non succede nulla, pazienza.
se prenoti un biglietto aereo, il sistema di dice che è OK, e lo paghi, e ti prende i soldi dalla carta di credito, ma in realtà la prenotazione non c'è, è un problema ben diverso.
Suggerisco quindi di impratichirsi con nosql, e SQL "canonico", per comprendere di cosa si tratta, piuttosto che leggere "tizio lo usa, quindi è fico", per poi scoprire che tizio lo usa per le ricerche nelle email (applicazione per inciso per cui si utilizza lucene e sphinx) o per rendere più veloce l'autocomposizione nelle ricerche proposte.
La slide dice "mysql fa molto, ma non fa tutto".
E' verissimo.
Si potrebbe aggiungere "nosql fa pochissimo, ma lo fa bene"