2012-02-19 16 views
8

Actualmente manejo mi sitio web en un único servidor con MongoDB. En mi servidor tengo dos componentes (1) un rastreador que se ejecuta cada hora y agrega datos a mi instancia de MongoDB (2) un sitio web que lee desde el índice del rastreador y también escribe en un DB de personalización del usuario. Me estoy mudando a Amazon EC2 para escalar automáticamente, de modo que el servidor web pueda escalar automáticamente, así puedo aumentar la cantidad de servidores a medida que aumenta el tráfico web. No necesito escalado automático para mi rastreador. Esto plantea un desafío para la forma en que uso MongoDB. Me pregunto lo que mi mejor opción es optimizar elEscalando MongoDB en EC2 o debería simplemente cambiar a DynamoDB?

  • cambios mínimos en mi código (el código está en Perl)
  • Posibilidad de añadir a la perfección/eliminar servidores web sin tener que preocuparse por la pérdida de datos en el PP
  • bajo costo

a corto plazo, la base de datos sin duda será capaz de encajar en la memoria a través de todos machies ya que será menos de 2 GB. El DB de personalización del usuario no se puede reconstruir, por lo que es más importante tenerlo, mientras que el índice se puede reconstruir fácilmente. El índice de rastreo MongoDB actual tiene aproximadamente 100k entradas que están codificadas en ~ 15 columnas diferentes. Esto está diseñado para la velocidad, ya que estoy trabajando en un sitio de citas en línea (que se puede buscar de muchas maneras).

puedo pensar en una pocas opciones

  1. Uso de SimpleDB para el almacén de personalización de usuario, y MongoDB para el índice. Haga que el índice se replique en todas las máquinas, sin embargo, no sé demasiado sobre la replicación de MongoDB.
  2. Mover todo para SimpleDB
  3. Mover todo para DynamoDB

No sé demasiado acerca de SimpleDB y/o DynamoDB. Basado en artículos, parece que DynamoDB sería una elección natural, pero no estoy seguro si contará con un buen soporte de Perl, si puedo tener todas las columnas, índices, etc. ¿Alguien tiene experiencia o tiene algún consejo?

Respuesta

3

Puede alojar Mongo en un único servidor en EC2 al que se conectan cada una de las casillas de la comunidad web. A continuación, puede girar fácilmente otra instancia web que use el mismo cuadro de DB.

Actualmente tenemos tres servidores Mongo cuando ejecutamos un conjunto de réplicas y cuando llegamos al punto en el que tenemos que escalar horizontalmente con Mongo, crearemos nuevas instancias y fragmentaremos las colecciones más grandes.

+0

Gracias Joe! Esto es muy perspicaz Entonces, para aclarar, ¿sus datos de Mongo se distribuyen en 3 máquinas o se replican en 3 máquinas? Esta es una muy buena idea para separar la escala de mis servidores web con mi escala de Mongo. ¿Hay algún tiempo de inactividad cuando escala sus servidores mongo? ¿Tiene alguna sugerencia/enlace sobre las buenas formas de escalar Mongo cuando necesita más capacidad? – ZenoriInc

+0

Utilizamos 3 máquinas separadas con un conjunto de réplicas, una maestra, dos réplicas. Esto es principalmente para el fail-over automático, por lo que si nuestro maestro muere, una de las réplicas se promociona para ser el maestro. La información en cada réplica de datos es la misma. – Joe

+0

Cuando se trata de escalar los datos, puede usar lo que se conoce como fragmentación. Aquí es donde distribuyes los datos de una o más colecciones en varias instancias de Mongo. Esto le permite escalar horizontalmente. Sus datos están distribuidos en varias máquinas físicas, y un proxy le dice a Mongo a dónde ir basándose en una clave de fragmento. Configuramos la infraestructura para que esto funcione, pero actualmente no tenemos datos suficientes para justificar el uso, una vez que lo hacemos, solo iniciaremos esas instancias. – Joe

3

Actualmente manejo mi sitio web en un único servidor con MongoDB.

En primer lugar, esta es una gran bandera roja. Cuando se ejecuta en producción, siempre se recomienda ejecutar un conjunto de réplicas con al menos tres nodos completos.

La replicación proporciona redundancia automática y conmutación por error.

Posibilidad de añadir a la perfección/eliminar servidores web sin tener que preocuparse por la pérdida de datos en la base de datos

MongoDB soporta un concepto llamado sharding. Sharding proporciona una forma de escalar horizontalmente partionando datos automáticamente. La partición se realiza a través de shard key.

Si va a utilizar la fusión, lea con atención el enlace muy y reconozca las limitaciones. Para la fragmentación de MongoDB, debe seleccionar la clave correcta que permitirá que las consultas se distribuyan uniformemente entre los fragmentos.

El índice de rastreo de MongoDB actual tiene aproximadamente 100k entradas que están codificadas en ~ 15 columnas diferentes.

Esto va a ser un problema con la fragmentación. Sharding solo puede escalar consultas que usan la clave de fragmento. Una consulta en la clave del fragmento se puede enrutar directamente a una sola máquina. Una consulta en un índice secundario va a todas las máquinas.

Tiene 15 índices diferentes, por lo que básicamente todas estas consultas irán a todos los fragmentos. Eso no va a "escalar automáticamente" muy bien.

1

Tenga en cuenta que, por el momento, EC2 no tiene instancias pequeñas de 64 bits, lo que hace que la replicación sea potencialmente costosa. Debido a que la memoria MongoDB asigna archivos, no se recomienda un sistema operativo de 32 bits.

+1

La semana pasada, Amazon finalmente anunció 64 bits para todos los tamaños de instancia y un nuevo tamaño mediano – Bryce

1

He tenido muy malas experiencias con SimpleDB y creo que es fundamentalmente defectuoso, así que lo evitaría.

Tres es un buen libro blanco sobre cómo configurar MongoDB en Amazon EC2: http://d36cz9buwru1tt.cloudfront.net/AWS_NoSQL_MongoDB.pdf

sospecho que la creación de MongoDB en EC2 es la solución más rápida en comparación con la reescritura-para/migración a DynamoDB.

¡La mejor de las suertes!

Cuestiones relacionadas