Che cosa è meglio per la scalabilità per questo specifico set di dati, MongoDB o MySQL?

Sulla base dei dati che hai fornito, direi che questo potrebbe essere fatto per funzionare in entrambi i modi.

Tuttavia, dal momento che hai iniziato con MongoDB, evidenzierò quanto segue:

Prima di tutto, penso che stai iniziando dalla premessa sbagliata: stai cercando di ridurre le letture al database. Ma MongoDB è progettato per un accesso rapido a grandi quantità di dati, ecco perché e quando lo si utilizzerà.

Se stavi parlando di cercare di ridurre 40 letture a 5 letture sarebbe una cosa sola. Ma da quello che posso dire che stai tagliando 2 letture a 1 lettura. Se il tuo MongoDB non può gestire 2 letture per richiesta utente, stai facendo qualcosa di sbagliato. Controlla i tuoi indici.

E se effettivamente ricevi troppo traffico, puoi sempre aggiungere un altro server al set di repliche o dividere le raccolte.

Quindi, vorrei semplicemente archiviare gli amministratori in una raccolta e le forme in un'altra. La duplicazione dei dati non è mai buona e, data la natura non transazionale di MongoDB, è possibile eseguirli senza corrispondere in alcuni casi.

Per poter efficacemente incrociare il riferimento a entrambe queste raccolte, puoi configurare lo schema in questo modo:

Amministratori

{
   "_id" : 12345
   "name" : "Joe"
   "formIds" : [
      1234,
      5678
      9123
   ]
}

Forme

{
   "_id" : 1234,
   "field1" : "bla",
   "field2" : "bla"
   "adminId" : 12345
}

In questo modo puoi creare indici e cercare l'amministratore di formId e il modulo di adminId . Puoi anche utilizzare solo uno dei metodi di riferimento incrociato, a seconda di quale sia più adatto ai tuoi schemi di accesso.

Nota: ora siamo finiti fondamentalmente con uno schema di database relazionale, appena eseguito in MongoDB. E quindi non farà una grande differenza.

Quindi, dove MongoDB sarebbe utile è, se si dispone di moduli, che hanno campi variabili o cambiano nel tempo o moduli che hanno dati annidati, tutti richiedono uno schema complesso su MySQL.

Non possiamo rispondere a questo. Dipende non solo dal tuo schema o dalla sua mancanza. Dipende anche da come colpisci il servizio (nel codice), da come i tuoi utenti colpiscono l'applicazione, da quale tipo di cache sei preparato per l'implementazione, ecc.

Utilizza il meccanismo di archiviazione più adatto a come pensi e codice. Mantenere le interazioni con quel servizio di archiviazione come isolate e astratte come è ragionevole che tu faccia. E se le prestazioni diventano un problema, noleggia un DBA e / o il servizio completamente astratto in modo da confrontare le opzioni con un carico di lavoro rappresentativo.