Quale hardware rende un buon server MongoDB? Dove trovarlo


13

Supponi di essere su dell.com in questo momento e stai acquistando un server per eseguire il database MongoDB per il tuo piccolo avvio. Dovrai gestire letteralmente decine di migliaia di scritture e letture al minuto (ma piccoli oggetti). Andresti per 2 processori? Investi di più sulla RAM?

Ho sentito (correggimi se sbaglio) MongoDB gestisce il più possibile sulla RAM e quindi scarica tutto sul disco, in tal caso dovrei investire su una CPU con una grande cache L2, probabilmente> 40 GB di RAM e un disco a stato solido .. giusto?

Sarei meglio con un server di fascia alta (~ $ 11,309, 2 costosi processori, 96 GB di RAM) o 2x (~ $ 6,419, 2 costosi processori, 12 GB di RAM)?

Dell è ok o hai suggerimenti migliori? (Sono fuori dagli Stati Uniti, in Portogallo)


3
perché acquisti hardware invece di utilizzare EC2 per la tua startup? Almeno inizialmente fino a quando non saprai quali saranno le tue esigenze.

D'accordo con Tom. Perché non prendere alcune istanze sul cloud?

1
@mixdev, ti sbagli: "Linux, NUMA e MongoDB tendono a non funzionare bene insieme." fonte: mongodb.org/display/DOCS/NUMA
Shadok

Risposte:


19

Inizialmente, ti consigliamo di rinforzare la RAM. La RAM di cui hai bisogno dipende dalla quantità di dati che stai memorizzando, dal numero di raccolte, dagli indici su tali raccolte, dai modelli di accesso ai dati, ecc. Molti fattori.

La cosa più importante è avere abbastanza RAM per mantenere gli indici nella RAM. In caso contrario, le prestazioni ne risentiranno notevolmente poiché i server eseguiranno la pagina costantemente mentre Mongo sposta i file mappati in memoria dentro e fuori dalla RAM. Nonostante tutto ciò, non abbiamo visto la velocità di scrittura influenzata, ma tutto il resto lo è. L'elaborazione cancella la coda, svuotamento, dump, ecc. Tutti subiscono un duro colpo quando gli indici non si adattano più alla RAM.

Quindi non c'è una vera risposta breve. Fondamentalmente, sii intelligente sui tuoi indici. Usa solo ciò di cui hai bisogno. Mantieni piccole raccolte se puoi (es. Dividi in più dove puoi.) Anche le raccolte con cappuccio sono interessanti da esaminare.


1
Nella nostra esperienza, quando Mongo ha esaurito la RAM per le query, non solo la query passa ai documenti (esegui per sempre, 5 minuti, 15 minuti, ora ...), ma gli inserti iniziano a fallire.
Jonesome ripristina Monica il


6

Con MongoDB quello che vuoi è la RAM. E poi ancora un po 'di RAM. L'acquisto di RAM non può far male.


3

Se sei nella fase di acquisto dell'hardware di produzione, l'applicazione che stai eseguendo deve già essere scritta, giusto? Quindi esegui l'app sull'hardware che hai e prendi le metriche. Modificare gradualmente alcuni componenti e acquisire più metriche. Al termine, saprai quali punti di messa a fuoco sono più importanti per l'applicazione e lo scenario.


3

Primo: acquista quanta più RAM possibile. Il secondo fattore limitante è la velocità del disco. RAID aiuta. SSD aiuta. Altri frammenti aiutano. Misura la velocità effettiva confrontandola con l'efficienza del disco e i tempi di risposta richiesti, quindi decidi cosa fare nel budget che hai.


1

Mi chiederei se una soluzione cluster Linux sarebbe un'alternativa migliore, più economica.

MongoDB ti consente di distribuire dati su molti server. Ciò sarà impossibile con un server di clacson.

Pensavo che MongoDB fosse uno dei passi successivi dopo aver scoperto che la distribuzione di un database relazionale su un server di clacson non era sufficientemente scalabile.


1

Decine di migliaia scrivono al minuto non è niente. Puoi ottenere 50.000 o più scritture al secondo su hardware decente. Le specifiche hardware dipendono davvero da cosa stai cercando di fare. In generale, abbastanza RAM per database di grandi dimensioni e sistemi IO veloci sono importanti accanto a una CPU decente ...


0

È importante stabilire una solida base prima di progettare l'hardware. In genere, si aspettano che questo tipo di domande vengano poste dalle persone esperte di mongoDB prima che chiunque possa prendere in considerazione la possibilità di rispondere alla tua domanda.

Statistiche attuali dell'applicazione (se presenti)

  • Record totali fino ad oggi?
  • Avvio del preventivo di archiviazione?
  • Crescita% prevista al mese?
  • Dimensione media del documento?

Carico di lavoro per ingestione di dati

  • Nuovi inserimenti / giorno, picco e media al secondo?
  • Aggiornamenti / giorno, picco e media al secondo?
  • Letture / giorno, picco e media / secondo?
  • Numero medio di documenti restituiti per query: 70
  • Elimina / giorno, picco e media / secondo: nessuno
  • Ci saranno carichi di massa / aggiornamenti di massa? In tal caso, quanto è grande e quanto spesso?
  • Quanti tipi diversi di documenti ci saranno?
  • Quanti di ciascuno?
  • Come ti aspetti dai tuoi documenti (esempio di documento)?

Modelli di query e aspettative sulle prestazioni

  • Leggi lo SLA di risposta?
  • Scrivi risposta SLA?
  • Le letture sono basate su intervallo o casuali?

Schemi di accesso previsti

  • Numero di indici secondari richiesti?
  • Numero di attributi?
  • Ordina condizioni?
  • Singolo o composto?
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.