¿Qué hardware hace un buen servidor MongoDB? ¿Dónde conseguirlo?

Supongamos que está en dell.com en este momento y está comprando un servidor para ejecutar su base de datos MongoDB para su pequeña startup. Tendrá que manejar literalmente decenas de miles de escrituras y lecturas por minuto (pero objetos pequeños). ¿Irías por 2 procesadores? ¿Invertir más en RAM?

Escuché (corríjame si me equivoco) MongoDB maneja lo más que puede en la RAM y luego descarga todo al disco, en ese caso debería invertir en una CPU con un gran caché L2, probablemente> 40 GB de RAM y una unidad de estado sólido ... ¿verdad?

¿Estaría mejor con un servidor de gama alta (~ $ 11,309, 2 procesadores caros, 96 GB de RAM) o 2x (~ $ 6,419, 2 procesadores caros, 12 GB de RAM)?

¿Está bien Dell o tiene mejores sugerencias? (Estoy fuera de los Estados Unidos, en Portugal)

Inicialmente, querrás reforzar la RAM. La RAM que necesitará dependerá de la cantidad de datos que esté almacenando, la cantidad de colecciones, los índices de esas colecciones, los patrones de acceso a datos, etc. Muchos factores.

Lo más importante es tener suficiente RAM para mantener sus índices en RAM. De lo contrario, su rendimiento se verá afectado drásticamente, ya que su (s) servidor (es) buscarán constantemente mientras Mongo mueve los archivos asignados de memoria dentro y fuera de la RAM. A pesar de todo esto, no hemos visto afectada la velocidad de escritura, pero todo lo demás sí. El procesamiento elimina las colas, el vaciado, los volcados, etc., todos reciben un golpe dramático una vez que sus índices ya no caben en la RAM.

Entonces no hay una respuesta corta real. Básicamente, sea inteligente sobre sus índices. Solo usa lo que necesitas. Mantenga las colecciones pequeñas si puede (es decir, divídalas en múltiples donde pueda). También es interesante examinar las colecciones con tapa.

Es muy importante utilizar una máquina de 64 bits, no 32 bits. http://blog.mongodb.org/post/137788967/32-bit-limitations

Con MongoDB lo que quieres es RAM. Y luego un poco más de RAM. Comprar RAM no puede hacer daño.

Si está en la etapa de compra de hardware de producción, entonces la aplicación que está ejecutando ya debe estar escrita, ¿verdad? Ejecute la aplicación en el hardware que tenga y tome métricas. Cambie gradualmente algunos componentes y tome más métricas. Cuando haya terminado, sabrá qué puntos de enfoque son más importantes para su aplicación y escenario.

Primero, compre tanta RAM como pueda. El segundo factor limitante es la velocidad del disco. RAID ayuda. SSD ayuda. Más fragmentos ayudan. Mida el rendimiento en comparación con la eficiencia del disco y los tiempos de respuesta requeridos, luego decida qué hacer dentro del presupuesto que tiene.

Me pregunto si una solución en clúster de Linux sería una alternativa mejor y más barata.

MongoDB le permite distribuir datos a través de muchos servidores. Eso será imposible con un servidor que toque la bocina.

Pensé que MongoDB era uno de los siguientes pasos dados después de descubrir que implementar una base de datos relacional en un servidor de bocina no escalaba lo suficientemente bien.

Decenas de miles escriben por minuto no es nada. Puede obtener 50,000 o más escrituras por segundo en hardware decente. Las especificaciones de hardware realmente dependen de lo que intente hacer. En general, la RAM suficiente para grandes bases de datos y un sistema IO rápido son importantes además de una CPU decente ...

Es importante establecer una línea de base sólida antes de diseñar su hardware. En general, espere que las personas con experiencia en mongoDB hagan este tipo de preguntas antes de que alguien pueda siquiera considerar responder a su pregunta.

Estadísticas de aplicación actuales (si las hay)

• ¿Total de registros hasta la fecha?
• ¿Estimación de almacenamiento inicial?
• % De crecimiento esperado / mes?
• Tamaño promedio del documento?

Carga de trabajo de ingestión de datos

• Nuevas inserciones / día, pico y promedio por segundo?
• Actualizaciones / día, pico y promedio por segundo?
• Lecturas / día, pico y promedio / segundo?
• Número promedio de documentos devueltos por consulta: 70
• Elimina / día, pico y promedio / segundo: ninguno
• ¿Habrá cargas masivas / actualizaciones masivas? Si es así, ¿qué tan grande y con qué frecuencia?
• ¿Cuántos tipos diferentes de documentos habrá?
• Cuantos de cada uno?
• ¿Cómo espera que se vean sus documentos (documento de muestra)?

Patrones de consulta y expectativas de rendimiento

• Leer respuesta SLA?
• Escribir respuesta SLA?
• ¿Las lecturas están basadas en rangos o son aleatorias?

Patrones de acceso anticipados

• ¿Número de índices secundarios requeridos?
• Número de atributos?
• Ordenar condiciones?
• ¿Soltero o compuesto?