Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20352

MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti)

Show all headers | View raw

Il Sat, 13 Feb 2016 12:30:13 -0800, fmassei ha scritto:

>> Il trucco sta nel settare il sync in modo che salvi almeno in un nodo
>> del cluster (anche se hai un nodo solo).

> Ah, qui mi posso solo fidare (e conoscendoti, naturalmente, mi fido :)
> ). L'ultima volta che l'ho usato era nel periodo in cui erano appena
> tornati di moda i NoSQL, saranno stati cinque/sei anni fa se non mi
> sbaglio, e ricordo che c'erano casi in cui nemmeno si poteva avere la
> certezza che una scrittura venisse eseguita. 

È vero. MongoDB 1.x aveva il sync di default a false, quindi scrivevi, la 
insert tornava dopo 1 microsecondo, e i dati prima o poi venivano scritti, 
se ti andava bene. :D

Dalla 2.x il sync è di default a true, e dalla 2.6 è impostato a 1 (cioè: 
assicurati che il dato sia scritto su almeno un nodo del cluster).
Che, per chi usa Mongo su un solo server, è esattamente come un SQL.

>> Non ha assenza di consistenza. Mancano solo per transazioni e
>> l'integrità referenziale,
> 
> Beh, senza quelle come fai a garantire la consistenza? :)

Forse intendiamo due cose diverse. :)

La consistenza dei dati, per come la intendo io, è: quando la insert o la 
update torna, sono sicuro che il dato è nel DB.

Per come clusterizza MongoDB, puoi avere 3 nodi in un cluster.
Quando scrivi su nodo1 con sync a 1, Il nodo 1 è consistente con sè 
stesso, cioè il dato che hai appena scritto lo conosce, e una read 
succesiva lo trova.
Se leggi da nodo2 o nodo3, potrebbe non esserci, perché viene sincronizzata 
5 secondi dopo (o più, se ci sono tanti dati in coda), ma prima o poi ci 
arriva.
Se vuoi che funzioni come un SQL, metti la sync a 3, e la insert non torna 
niente finchè il cluster non è sincronizzato.
Naturalmente le prestazioni in scrittura diventano pari a quelle di un SQL 
con 2 slave.
 
> ma un DB deve essere sempre consistente mentre corre, indipendentemente
> da cosa ci si sta facendo sopra e come. Anche sugli SQL, per esempio,
> non ho mai usato ISAM (o MyISAM/Aria per MySQL che sia - su quello vado
> quasi sempre di InnoDB).

Qui forse intendi integrità referenziale: se aggiorni dati connessi su due 
tabelle, il riferimento è sempre valido in moto atomico.

Beh, in MongoDB non hai FK, quindi non ha nemmeno senso parlare di 
integrità referenziale. :D

Quello che hai, però, è garanzia di operazioni atomiche su un documento. 
Avendo i documenti struttura libera, nella maggior parte dei casi (come in 
quello dei prodotti configurabili che facevo), è lo stesso, anche perché 
hai upsert che modifica al volo i documenti mentre fa la ricerca.

> Oltretutto, senza triggers e stored procedures, la gestione quotidiana
> dei dati è una pila di scripts, di solito senza un filo logico, in
> svariati linguaggi o scritta on-the-fly sul client :)

Operazioni di questo tipo normalmente le fai con sweep di upsert: Fai un 
primo giro di upsert settando un flag su tutti i documenti che vuoi 
processare, e poi te li passi eventualmente uno per uno.

Volendo farti male puoi anche passare un javascript a una map() (senza 
reduce) e processare i documenti server-side. :)
 
> D'accordissimo, infatti per grandi(ssime) quantità di dati sceglierei
> anche io un NoSQL.
> Probabilmente prima mi chiederei se è vero che servono, tutti questi
> dati, perché già per la maggior parte delle applicazioni attuali sono
> molto scettico sulla necessità di memorizzare miliardi d'informazioni
> "inutili".

Come dicevo, dipende dai problemi che hai da risolvere.

Ma, per esempio, un catalogo prodotti IMHO sta perfettamente in Mongo, 
visto che puoi indicizzare anche documenti embedded. Non ti serve nemmeno 
la "tabella categorie", volendo, o n tabelle incrociate per i tag, le 
varianti e, in alcuni casi, anche per i prezzi customizzati.

Idem per un blog, o un CMS.
 
> Io userei MongoDB per cose tipo collezione di dati statistici, secondo
> me per quello calza a pennello.

Io invece li metterei in Hadoop, avendo l'hardware disponibile, che 
gestisce meglio la parte "faccio l'analisi mentre sto ancora ricevendo 
migliaia di scritture al secondo". Anche se dovrei tapparmi il naso per 
Java. :)

Altrimenti sì, MongoDB è abbastanza buono, anche se è un po' più "manuale" 
da gestire in questo scenario.

Bye.

Back to it.comp.www.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-10 14:48 +0100
  Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-10 06:00 -0800
    Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-10 21:01 +0100
      Re: [OT] MySQL e tabella prodotti Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-10 20:21 +0000
        Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-10 12:42 -0800
          Re: [OT] MySQL e tabella prodotti Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-11 08:23 +0000
            Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-11 13:52 +0100
              Re: [OT] MySQL e tabella prodotti "ciccio" <21669invalid@mynewsgate.net> - 2016-02-11 13:58 +0000
                Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-12 13:57 +0100
                Re: [OT] MySQL e tabella prodotti "ciccio" <21669invalid@mynewsgate.net> - 2016-02-12 19:03 +0000
              Re: [OT] MySQL e tabella prodotti Warp10 <warp10@libero.it> - 2016-02-11 15:10 +0100
                Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-12 14:02 +0100
            Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-12 06:53 -0800
              Re: [OT] MySQL e tabella prodotti Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-13 18:09 +0000
                Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-13 12:30 -0800
                MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti) Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-13 21:03 +0000
                Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti) fmassei@gmail.com - 2016-02-13 14:01 -0800
                Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti) Alessandro Pellizzari <shuriken@amiran.it> - 2016-02-16 08:25 +0000
                Re: MongoBD, NoSQL, SQL, ecc. (Era Re: [OT] MySQL e tabella prodotti) fmassei@gmail.com - 2016-02-21 21:27 -0800
        Re: [OT] MySQL e tabella prodotti GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2016-02-12 14:07 +0100
      Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-10 12:38 -0800
        Re: [OT] MySQL e tabella prodotti leo <leofante_XNOSPAMX_@gawab.com> - 2016-02-11 11:45 +0100
          Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-12 06:59 -0800
            Re: [OT] MySQL e tabella prodotti leo <leofante_XNOSPAMX_@gawab.com> - 2016-02-15 10:40 +0100
              Re: [OT] MySQL e tabella prodotti fmassei@gmail.com - 2016-02-15 11:26 -0800
                Re: [OT] MySQL e tabella prodotti bramante <bramante@yopmail.com> - 2016-02-16 01:58 +0100

csiph-web