MongoDB

Come muoversi tra database, collezioni e documenti di un server MongoDB.

Dove si trova: Workspace › Strumenti › Collezioni

L’esploratore mostra a sinistra le collezioni del database scelto e a destra i suoi documenti, come alberi richiudibili.

Un documento non è una riga: due documenti vicini possono non condividere alcun campo, ed è per questo che non si disegna una griglia di colonne. Accanto a ogni valore compare il suo tipo — ObjectId, decimal128, data, binario — che in un database senza schema è metà dell’informazione.

Per modificare, premi la matita: il documento si apre come JSON esteso e viene salvato per intero, identificato dal suo _id. Senza _id non si può modificare né eliminare, e lo si dice invece di offrire pulsanti che toccherebbero un altro documento. Le viste sono di sola lettura e sono contrassegnate; anche le collezioni limitate lo sono.

Il menu in alto cambia database, e Filtra restringe per nome l’elenco delle collezioni. I documenti arrivano a blocchi di 50: il piè di pagina conta quelli della collezione e quelli già caricati, e Carica altri, in fondo all’elenco, porta il blocco successivo. Nuovo documento apre lo stesso editor, vuoto; Formatta reindenta il testo e, se non si riesce a leggerlo, dice perché senza toccarlo.

Parole chiave: mongodb, collezioni, documenti, bson, json, esplorare

Filtri, proiezioni, ordinamento e pipeline di aggregazione.

Dove si trova: Workspace › Strumenti › Query

Lo strumento di query ha due modalità. «Cerca» applica un filtro, una proiezione e un ordine, tutti e tre scritti come documenti JSON. «Aggregazione» esegue una pipeline completa, cioè un elenco di fasi.

Il menu «Collezione» sceglie cosa interrogare, dal database scelto in «Collezioni», ed «Esegui» (⌘↩) invia la query. Il piè di pagina conta i documenti caricati e i millisecondi impiegati dal server. I campi accettano JSON esteso, quindi {"$date": …} e {"$oid": …} arrivano al server come data e come ObjectId, non come testo. Una pipeline che non è un elenco viene rilevata prima di inviare qualcosa; il resto di ciò che il server rifiuta torna con il suo messaggio.

I risultati arrivano a pagine: se ne chiedono altri con «Carica altri», e il cursore aperto sul server viene chiuso quando cambia la query — uno abbandonato resta vivo dieci minuti occupando memoria.

Qui i risultati non si modificano: un’aggregazione non ha un documento originale su cui riscrivere le modifiche, e con una proiezione i campi mancanti andrebbero persi al salvataggio. Per modificare c’è l’esploratore.

Gli operatori scritti nel filtro e nella pipeline hanno la scheda: lo spiega l'argomento Aiuto contestuale delle funzioni SQL.

Parole chiave: mongodb, query, find, aggregazione, pipeline, filtro

Vedere, creare ed eliminare indici, compresi unici, sparsi e con scadenza.

Dove si trova: Workspace › Strumenti › Indici

Scegli una collezione nel menu Collezione della barra; le viste non compaiono, perché una vista non ha indici propri. L’elenco mostra ogni indice per nome, con le chiavi sotto e le proprietà come etichette: unico, sparso o con scadenza (TTL). Un indice di testo mostra i campi che copre, ciascuno con «text». Aggiorna rilegge l’elenco dal server.

Nuovo indice apre un foglio con un Nome, le Chiavi scritte come documento (1 crescente, -1 decrescente, e valgono anche «text» o «2dsphere» per indici di testo e spaziali) e tre interruttori: unico, sparso e Scadenza (TTL). Con la scadenza, Secondi è quanto vive un documento dalla data del campo indicizzato. Crea lo invia al server; se il server lo rifiuta, per esempio perché un indice unico trova valori ripetuti, il suo messaggio compare nel foglio, che resta aperto.

L’indice _id non si può eliminare perché lo mantiene il server, quindi non viene offerto il pulsante. Qualsiasi altro si elimina con il suo cestino, dopo una conferma, e le query che lo usavano scorreranno l’intera collezione.

Parole chiave: mongodb, indici, unico, ttl, testo, 2dsphere

Ciò che sul lato relazionale sono il pannello, i processi e gli utenti.

Dove si trova: Workspace › Strumenti › Server

Riunisce tre cose che in MongoDB arrivano da tre comandi del server, una per sezione del controllo segmentato: Server (host, versione, tempo di attività, connessioni, memoria e operazioni cumulative), Operazioni (quello che il server sta facendo adesso) e Utenti (gli utenti con i loro ruoli). Nulla si aggiorna da solo: ogni sezione si legge quando la apri, e Aggiorna la rilegge.

In Operazioni, ogni riga dice il tipo di operazione, il suo namespace, da quanti secondi è in corso e la connessione da cui arriva. Includi inattive aggiunge le connessioni aperte che non fanno nulla e i thread del server a riposo. Ferma l’operazione chiede al server di terminarne una, e si offre solo per le operazioni che arrivano da un client: i thread del server stesso, come Checkpointer, non hanno il pulsante, perché non li fermerebbe.

Utenti elenca tutti gli utenti del server, di tutti i database, come utente@database: un utente vive in un database. Un ruolo di un altro database porta la sua @. I ruoli personalizzati appartengono a un database preciso, quindi si elencano quelli del database scelto nelle altre schede, e il titolo della sezione lo nomina.

Parole chiave: mongodb, server, operazioni, utenti, ruoli, currentop

Il profiler di MongoDB: a che livello sta ogni database e cosa ha registrato.

Dove si trova: Workspace › Strumenti › Profiler

Il profiler ha tre livelli: spento, solo le operazioni che superano la soglia, e tutte. La soglia è in millisecondi —non in secondi, come quella di MySQL— e il campionamento, fra 0 e 1, dice quale quota delle lente viene registrata: sotto 1 il server scarta operazioni lente di proposito.

Il livello appartiene a ogni database, non al server. Per questo la barra porta il suo selettore di database e tutto ciò che si legge e si scrive si riferisce a quello scelto. E vive in memoria: riavviando il server torna a quanto dice la sua configurazione di avvio.

Ciò che viene registrato va in «system.profile», una collezione limitata di 1 MB per database: è una finestra sulle ultime operazioni, non uno storico, e i suoi documenti non hanno «_id», quindi si leggono e non si modificano. Svuotarla elimina la collezione, e per farlo bisogna spegnere un momento il profiler: Calíope lo spegne, la elimina e ripristina il livello che c’era.

Sotto, l’elenco mostra ciò che contiene «system.profile», dal più recente al più vecchio: ora, operazione, spazio dei nomi, millisecondi e, quando il server li registra, il piano, i documenti e le chiavi esaminati, i documenti restituiti e il client. Si leggono solo le ultime 200, e il piè di pagina lo dice. Un doppio clic o Invio sul Mac, o un tocco sull’iPad, apre il documento registrato per intero; da lì, e dal menu della riga, «Copiare il JSON» lo copia e «Copiare e aprire Query» copia solo il suo comando e apre Query. «Aggiorna da solo (10 s)» rilegge tutto ogni dieci secondi, «Letto» dice quando l’ha fatto l’ultima volta, e «Aggiorna» ricarica anche l’elenco dei database.

«Livello», «Soglia» e «Campionamento» non cambiano nulla prima di «Applica», e dopo Calíope rilegge il profiler: il server risponde con i valori di prima, non con quelli nuovi.

Non c’è una vista «per istruzione» come nel registro delle query lente relazionale: MongoDB non pubblica un riassunto aggregato per forma di operazione, e calcolarlo nel client su una finestra di 1 MB affermerebbe più di quanto il dato regga.

Su Atlas condiviso e dietro «mongos» i livelli 1 e 2 non si possono impostare: lì il server accetta solo lo 0.

Parole chiave: mongodb, profiler, lente, slowms, system.profile, campionamento

La via d’uscita per ciò che l’interfaccia non copre.

Dove si trova: Workspace › Strumenti › Comandi

In MongoDB un comando è un documento, e questo strumento lo invia così com’è e mostra la risposta completa.

Copre ciò che nessuna interfaccia fa: convalidare una collezione, chiedere statistiche, spiegare una query o qualsiasi comando amministrativo. Si scrive il documento nell’editor e si preme Esegui (⌘↩). Il menu Esempi porta i più frequenti già pronti; quelli che agiscono su una collezione portano «COLLEZIONE» al posto del suo nome.

Il menu all’inizio della barra sceglie su quale database inviarlo, perché alcuni comandi vengono accettati solo su «admin»: getCmdLineOpts, per esempio, che mostra le opzioni con cui è stato avviato il server.

La risposta arriva come un albero, e la freccia accanto a un sottodocumento o a un array lo apre. Se il testo non è JSON valido, Calíope dice dove prima di inviare qualsiasi cosa; se il server rifiuta il comando, l’avviso riporta il suo codice e il suo nome. Una scrittura può anche essere accettata a metà: un insert che un validatore rifiuta risponde comunque ok: 1, e il documento rifiutato arriva dentro writeErrors, con la regola violata.

Parole chiave: mongodb, comandi, runcommand, validate, explain, statistiche