Soy nuevo en NoSQL mundo y el pensamiento de la sustitución de mi MS Sql Server base de datos de MongoDB. Mi solicitud (escrito en .Net C#) interactúa con las Cámaras IP y los registros de datos de metadatos para cada imagen procedente de la Cámara, en la Base de datos MS SQL. En promedio, estoy insertando sobre 86400 registros por día para cada cámara y en el actual esquema de base de datos que he creado una tabla separada para separar las imágenes de la Cámara, por ejemplo, Camera_1_Images, Camera_2_Images … Camera_N_Images. Única de registro de imagen consiste en la simple información de metadatos. como AutoId, Ruta de archivo, campos creationdate. Para añadir más detalles a este, mi aplicación se inicia proceso independiente (.exe) para cada cámara y cada proceso de inserciones de 1 registro por segundo en relación de la tabla en la base de datos.

Necesito sugerencias de los (MongoDB) expertos en las siguientes inquietudes:

  1. para saber si MongoDB es bueno para la celebración de tales datos, que a la larga va a ser consultados en contra de los rangos de tiempo (por ejemplo, recuperar todas las imágenes de una cámara en particular entre una hora especificada)? Cualquier sugerencia sobre el Documento Basado en el diseño del esquema para mi caso?

  2. Lo que deben ser las especificaciones de servidor (CPU, RAM, Disco)? alguna sugerencia?

  3. Debería considerar la posibilidad de Fragmentación/Replicación para este escenario (teniendo en cuenta el rendimiento en la escritura para sincronizar los conjuntos de réplicas)?

  4. Hay beneficios del uso de múltiples bases de datos en la misma máquina, por lo que una base de datos contendrá imágenes del día corriente para todas las cámaras, y el segundo va a ser utilizado para archivar día anterior las imágenes? Estoy pensando en esto con respecto a la división de lee y escribe en bases de datos separadas. Debido a que todas las solicitudes de lectura pueden ser servidas por segundo de la base de datos y se escribe en primera. Beneficiará o no? Si sí, entonces cualquier idea para asegurarse de que ambas bases de datos se sincronizan siempre.

Otras sugerencias son bienvenidos, por favor.

InformationsquelleAutor theGeekster | 2012-11-02

3 Comentarios

  1. 29

    Yo soy una de arranque en las bases de datos NoSQL. Así que estoy respondiendo esto a expensas de posibles abajo votos, pero será una gran experiencia de aprendizaje para mí.

    Antes de intentar mi mejor esfuerzo para responder sus preguntas debo decir que si MS
    SQL Server está funcionando bien para usted, entonces quédate con él. Usted no tiene
    menciona cualquier razón válida desea utilizar MongoDB, excepto el hecho de
    que has aprendido acerca de él, como un documento orientado a la db. Por otra parte veo
    que tiene casi el mismo conjunto de meta-datos que se capturan para
    cada cámara, es decir, su esquema es dinámico.

    • para saber si MongoDB es bueno para la celebración de tales datos, que a la larga va a ser consultados en contra de los rangos de tiempo (por ejemplo, recuperar todas las imágenes de una cámara en particular entre una hora especificada)? Cualquier sugerencia sobre el Documento Basado en el diseño del esquema para mi caso?

    MongoDB ser un documento orientado a la db, es bueno consultar dentro de un agregado (se llame documento). Puesto que ya se van a almacenar de cada cámara los datos en su propia mesa, en MongoDB se le han separado colección creado para cada cámara. Aquí es cómo realizar rango de fechas de las consultas.

    • Lo que deben ser las especificaciones de servidor (CPU, RAM, Disco)? alguna sugerencia?

    Todas las bases de datos NoSQL están construidos para escala de productos básicos de hardware. Pero por la forma de la pregunta, usted podría estar pensando en la mejora del rendimiento ampliación. Usted puede comenzar con un razonable máquina y a medida que aumenta la carga, se pueden añadir más servidores (escalar). Usted no necesita para planificar y comprar un servidor.

    • Debería considerar la posibilidad de Fragmentación/Replicación para este escenario (teniendo en cuenta el rendimiento en la escritura para sincronizar los conjuntos de réplicas)?

    MongoDB bloquea toda la db para una sola escritura (pero los rendimientos de otras operaciones) y está diseñado para sistemas que tienen más lecturas que escrituras. Así que esto depende de la situación de su sistema. Hay varias formas de fragmentación y debe ser específica de un dominio. Responde de manera genérica no es posible. Sin embargo, algunos ejemplos pueden ser dados como la fragmentación por la geografía, por ramas etc.

    Lea también Una llanura inglés introducción a la TAPA del Teorema de

    Actualizado con la respuesta a los comentarios sobre la fragmentación

    De acuerdo a sus documentación, debe considerar la implementación de un sharded clúster, si:

    • el conjunto de datos se aproxima o excede la capacidad de almacenamiento de un único nodo en el sistema.
    • el tamaño de su sistema activa del conjunto de trabajo pronto se supere la capacidad de la máxima cantidad de RAM de su sistema.
    • el sistema tiene una gran cantidad de actividad de escritura, una sola instancia de MongoDB no puede escribir datos lo suficientemente rápido como para satisfacer la demanda, y todos los demás
      enfoques no han reducido la contención.

    Así que basado en el último punto sí. La auto-fragmentación característica está integrada a escala escribe. En ese caso, usted tiene un bloqueo de escritura por fragmento, no por base de datos. Pero el mío es un teórico de respuesta. Te sugiero que te tomes una consulta de 10gen.com grupo.

    • Buena respuesta todavía, lo único que te aconsejaría es que MongoDB, dependiendo del tamaño del índice (etc) tiene un límite máximo de colecciones por DB en su defecto ns tamaño (que se recomienda para mantener a) de alrededor de 18 quilates de colecciones y desde la fragmentación funciona bien en una sola colección base parece una buena idea para promover el uso de una única colección para todas las cámaras. Sin embargo, +1 de traerle algún punto bueno como el bloqueo, etc.
    • Me puede decir, si puedo evitar global r/w bloqueo mediante Fragmento separado para cada cámara. Significa tener casi 100 fragmentos en la misma máquina? Me pregunto porque acabo de leer en la web que Mongo tiene bloqueo independiente para cada fragmento.
    • véase mi edición
  2. 4

    para saber si MongoDB es bueno para la celebración de tales datos, que finalmente
    será consultado en contra de los rangos de tiempo (por ejemplo, recuperar todas las imágenes de un
    cámara en particular entre una hora especificada)?

    Este quiestion es demasiado subjetivo para mí la respuesta. A partir de la experiencia personal con numerosas SQL soluciones (irónicamente no MS SQL) yo diría que ambos son igual de buenas, si se hace bien.

    También:

    Lo que deben ser las especificaciones de servidor (CPU, RAM, Disco)? alguna sugerencia?

    Depende de demasiadas variables que sólo usted sabe, sin embargo, un pequeño grupo de productos básicos de hardware funciona bastante bien. Realmente no puedo dar una respuesta objetiva a esta pregunta y se va a venir abajo de prueba.

    Como para un esquema que me iría a por un documento de la estructura:

    {
        _id: {},
        camera_name: "my awesome camera",
        images: [
            { 
                url: "http://I_like_S3_here.amazons3.com/my_image.png" ,
                //All your other fields per image
            }
        ]
    }

    Esto debería ser bastante fácil de mantener y actualizar tanto tiempo que no la incrustación mucho más profundo ya que entonces podría ser un poco de dolor, sin embargo, que depende de sus consultas.

    No sólo eso, sino que este debe ser bueno para la fragmentación ya que tienes todos los datos que necesita en un solo documento, si se fragmento en _id que probablemente podría conseguir la configuración perfecta aquí.

    Debería considerar la posibilidad de Fragmentación/Replicación para este escenario (teniendo en cuenta el rendimiento en la escritura para sincronizar los conjuntos de réplicas)?

    Posiblemente, muchas personas asumen que necesitan para shard, cuando en realidad sólo necesitan ser más inteligentes en la forma en que el diseño de la base de datos. MongoDB es muy de forma libre por lo que hay un montón de maneras de hacerlo mal, pero lo que se dice, también hay un montón de maneras de dong derecho. Personalmente me iba a mantener la fragmentación en la mente. La replicación puede ser muy útil también.

    Hay beneficios del uso de múltiples bases de datos en la misma máquina, por lo que una base de datos contendrá imágenes del día corriente para todas las cámaras, y el segundo va a ser utilizado para archivar día anterior las imágenes?

    Aunque MongoDBs bloqueo de escritura en el nivel de DB (en la actualidad), yo diría: No. El derecho y la estructura del documento el derecho fragmentación/replicación (si es necesario) debe ser capaz de manejar esto en un solo documento de una colección basada en la(s) bajo una única BBDD. No sólo eso, sino que puede dirigir, escribe y lee dentro de un clúster a ciertos servidores, así como para crear una situación de concurrencia entre ciertas máquinas en el clúster. Me gustaría promover el uso correcto de MongoDBs concurrencia cuenta con más de DB separación.

    Editar

    Después de leer la pregunta de nuevo he omitido en mi de la solución que se va a insertar 80k+ imágenes de cada cámara un día. Como tal, en lugar de la incrustados opción sería realmente hacer una fila por cada imagen en una colección llamada images y, a continuación, un camera recopilación y consulta de los dos como en SQL.

    La fragmentación de la images colección debe ser igual de fácil en camera_id.

    También asegúrese de que usted tome usted el trabajo conjunto en consideración con su servidor.

    • Hace uso de MongoDB bloqueo independiente para cada fragmento? y hay un límite en el número de fragmentos de una sola base de datos en una sola máquina?
    • Creo que esto responde a tu pregunta: mongodb.org/display/DOCS/How+hace+de simultaneidad+trabajo los MongoS es un fragmento, mientras que el Mongod es la base de datos en ese fragmento. Por lo que es un bloqueo por fragmento, pero que el fragmento ha bloqueo de db. Como ahora sé que sólo hay un límite de réplicas, no fragmentos: stackoverflow.com/questions/8686420/…
    • ¿Puede por favor explicar un poco como usted dijo: «por Lo que es un bloqueo por fragmento, pero que el fragmento ha bloqueo de db» ? También tu sugerencia para la fragmentación en camera_id, ¿eso significa una sola colección de imágenes se dividirá por MongoDB en diferentes fragmentos (1 fragmento de 1 cámara)? Es mejor esto a la 1 de la colección para 1 cámara y todavía uso camera_id como fragmento de la clave? (porque el número de imágenes para 1 cámara va a ser bastante alta como 30,00,000).
    • Debe significar un fragmento por la cámara, sin embargo MongoDB puede mover fragmentos para su mejor ajuste de posición dependiendo del espacio en los servidores, etc. Como para el bloqueo que significa que cada mongod que hace que un fragmento de clúster no puede responder a otros bloqueos de escritura (bloqueo de lectura es concurrente), mientras que se utilizan; sin embargo, cada mongod dentro de que grupo es inpedendant así que usted puede escribir a una computadora y el otro al mismo tiempo. Esta es la razón por la clave es tener un fragmento de la clave de que los saldos de escrituras a través de todos los fragmentos (si es mega importante)
    • A pesar de que se acerca mi anterior sobre la fragmentación camera_id, también se pueden administrar MongoDBs la fragmentación de ti mismo, así que como he dicho MongoDB es muy de forma libre, sin embargo, usted debe centrarse en el principiante cosas primero, en lugar de buceo directamente en la fabricación de MongoDB los trozos de cómo usted quiere manualmente.
  3. 3

    para saber si MongoDB es bueno para la celebración de tales datos, que finalmente
    será consultado en contra de los rangos de tiempo (por ejemplo, recuperar todas las imágenes de un
    cámara en particular entre una hora especificada)? Cualquier sugerencia acerca de
    Documento Basado en el diseño del esquema para mi caso?

    MongoDB puede hacer esto. Para un mejor rendimiento, se puede establecer un índice en el campo de tiempo.

    Lo que deben ser las especificaciones de servidor (CPU, RAM, Disco)? alguna sugerencia?

    Creo RAM y Disco sería importante.

    • Si usted no quiere hacer sharding a scale out, usted debería considerar la posibilidad de un mayor tamaño de disco, de modo que usted puede almacenar todos sus datos en ella.
    • Su caliente de datos debe caben en la memoria RAM. Si no, entonces usted debería considerar la posibilidad de una mayor memoria RAM, ya que el rendimiento de MongoDB depende principalmente de RAM.

    Debería considerar la posibilidad de Fragmentación/Replicación para este escenario (mientras
    teniendo en cuenta el rendimiento en la escritura para sincronizar los conjuntos de réplicas)?

    No conozco a muchas cámaras que tienen, incluso 1000 inserciones/segundo con un total de 1000 cámaras todavía debe ser fácil de MongoDB. Si usted está sobre el rendimiento de la plaquita, no creo que usted necesita para hacer la fragmentación(Excepto el tamaño de los datos son demasiado grandes que se tienen que separar en varias máquinas).

    Otro problema es la lectura de la frecuencia de su aplicación. Es muy alta, entonces usted puede considerar la posibilidad de fragmentación o de replicación de aquí.
    Y usted puede utilizar (timestamp + camera_id) como su fragmentación clave si su consulta sólo en una cámara en un intervalo de tiempo.

    Hay beneficios del uso de múltiples bases de datos en la misma máquina, así
    que una base de datos contendrá imágenes del día corriente para todas las cámaras, y
    el segundo va a ser utilizado para archivar día anterior las imágenes?

    Puede dividir la tabla en dos colecciones(archive y current). Y establecer el índice sólo en archive si sólo consulta la fecha en archive. Sin la sobrecarga de la creación del índice, el current colección de beneficio con insertar.

    Y usted puede escribir un programa diario para el volcado de los current datos en archive.

    • Gracias por la gran respuesta, en realidad estaba pensando en la misma línea para dividir los datos en dos grupos (hoy/actual y archive/edad). Y mi lectura de la frecuencia es de un promedio de 1 por 2 segundos. 1: Para las inserciones, puedo asumir que MongoDB v2.2 va a tener problemas, a un ritmo de 1000/segundo, pero lo que va a hacer con las peticiones de LECTURA al mismo tiempo (no bloquear la lee)? ¿Cómo puedo evitar esta lectura de bloqueo cuando se escribe siempre están ocurriendo. 2: ¿Qué os parece si puedo hacer dos bases de datos independientes/fragmentos (actuales y de archivo) para tener separados los bloqueos? A continuación, escribir siempre a la actual fragmento..
    • … a continuación, escribir siempre a la corriente de rayo (con índice de datetime) y en el día final mover todos los datos de la actual fragmento de archivar. Las lecturas para el día actual, será servido por el actual fragmento y para los días anteriores será servido por el archivo fragmento. Aquí no se puede pensar de algunas preocupaciones así, 1) lee para los días actuales son todavía vulnerables a r/w cerraduras, 2) tiene dos fragmentos en la misma máquina puede subir algunos conflictos de Memoria entre ambos para lecturas y escrituras y los índices, 3) al final del día si el movimiento de los datos de la actual fragmento de archivar tomar unos minutos, deben lee durante ese tiempo goto actual o archivo?

Dejar respuesta

Please enter your comment!
Please enter your name here