MongoTorino - 1st Ottobre 2011 - appunti sparsi

Appunti sparsi della giornata

Politecnico di Torino 1 ottobre 2011 aula 10d.

----------------------------
@FlaPer87

- memory mapped files : alloca memoria (usare free)
- lock gloabal : molti possono leggere ma uno solo lo può scrivere.
- scritture asincrone in coda di scrittura.
- usare il lock per collection (prossima release).
- indici: non possono essere cambiati solo b-tree, possono essere interpretate in modo diverso (es index di geoloc). MongoDB elabora solo un indice per volta.
- cpu: la scrittura usa un core solo, in lettura usa più core, Spidermonkey in javascript è single core mono thred.
- map reduce non disponibile fino alla v8, locks in lettura,locks sulla map, lock sulla reduce, lock sulla write, (lock di scrittura su tutta l'istanza del db).
Usare mapreduce non su strutture principali.
- Scripting usa Spidermonkey, v8 multithreading.
- java jpa si può implementare uno scripting in jvm.
- mongodb mapreduce single core causato dalla limitante dell'engine javascript.
- mongodb è un document store, molto vicino a json e python utile e vicino al linguaggio di programmazione.
- mongoodb spedisce molte info in parallelo, no join e le transaction.
- sharding: molto complesso sulla concororrenza e consistenza del dato.

che db usare:
- che tipo di gestione del dato devo fare?
- che tipo di interazione del dato?
- che modelli devo disegnare? ( oppure ristrutturare i modelli)
- adattare i modelli al db che si usa.
- se estraggo un doc e mi serve sempre un doc correlato uso un embedding altrimenti una reference.
- In memoria (cache) rimane il documento e non la query (uso degli indici sul b-tree), cache a lista.
- sharding degli indici (vedi Kristina della 10gen), esiste un master punti a mongoS che conosce dove viene posizionati gli indici, quindi gli indici sono distribuiti.
- limiti del doc in collection di 16 MB.
- Foursquare tutti i check-in sono in mongodb.

update degli appunti direttamente da @FlaPer nei commenti.


-----------------------------------------------

Diego Guenzi - CSP (centro ricerca)

Web scalabile con Nginx e MongoDB
- test su Nginx - php - mongodb
- scalabilità verticale (comprare hardware della macchina più costi) /orizzontale (più server meno costi)
- rdmbs poca scalabilità orizzontale.
- nosql molta scalabilità orizzontale.
- teorema CAP (Partition Tolerance,Availability,Consistency).
- teorema CAP - C.A. per rdbms
- teorema CAP - P.A. per nosql
- teorema CAP - C.P. per nosql
- bisogna decidere da che tipologia di prestazioni si vogliono avere.
- rdbma modello ACID
- dbms modello BASE (dato non consistente in maniera completa)
- Replica distibuisco su più nodi le stesse info nel caso di network partitionig il db replica i dati e aggiorna successivamente (eventuali conflitti).
- sharding: le info sono distribuite su più server.
- si può mischiare sharding e replica per ottenere buone performance.
- test specifici con ycsb di yahoo.
- mongos per sharding, l'ottimale è sharding+repliche (le repliche devono essere dispari).
- client nginx.
- oracle Exadata (si può clonare con mongo).
- nosql senza standard.
- server web scalabili: tornado,lighttpd, cherokee (sfida delle 10000 connessioni).
- nginx - veloce e low balancing compreso.
- nginx - php - mongodb - aggiungo una macchina clono il tutto ed ogni macchina ha tutto.
- altra soluzione nginx davanti, cluster di nginx e php con solo il driver e una macchina per lo storage.
- altra nginx sul load balancer, macchine con php e macchine sotto con storage.

------------------------------------------------
ore 14:00 - Brendan McAdams 10gen, inc.

mongodb and the jvm
- java driver 2.6.5
- vari esempi di codice basilari...
- scala...
- object -> document
- ODMS in java Morphia (JPA inspired,Annotation driven) e Spring-DataDocument (data-system,Spring paradigms,mutiple datastorage)
- Hadoop + Mongo
- no-web app : logging (graylog2,flume sink)
- WTF:
- le dimensioni collection sono disegnate oer la Replica.
- i documenti sono mantenuti in ordine di inserimento
- cursore di tipo Tailable. (molto efficiente per le query senza indici)
- Messaggistica veloce sul broadcast.

-----------------------------------------------
ore 14:30 - Realtime Analytics using mongodb, phyton source forge.

- couchdb no performance
- new platfom with mongodb
- zarkov (async tpc server,inc validate).
- Bson - ZeroMQ - journal - write log - commit greenlet - Mongo Cronjob.
- mongorestore is fast, but locks a lot.
- indexing is nice, but slows use _id when you can.
- use databases to partition really big data, not collections.

------------------------------------------------
15:14 - new fetured v 2.0 Brendan McAdams 10gen

- journaling compressed
- command compact (old repair)
- old repair (double space on database on disk)
- command compat (defrag individual collections,more fash and light)
- replica sets (priorirties (node with highest prioirty become primary), reconf,tags,majority write concerns)
- indici pù leggeri
- stack defaul 1mb
- geospatial indexing

------------------------------------------------
15:40 - GridFS - Mitch Pirtle

- i metadata sono separati e possono comodamente stare in un array di metadata
- add attribute to store file
- Replica set - ridondare
- master-slave - performance
- sharding - scalare
- i file vengono splittati a blocchi


----

Questi sono solo appunti, che dovrò approfondire, presi durante l'ottima giornata.