2012-05-16 11 views
8

Encontré algunas preguntas en la misma línea que esta, pero no incluyeron muchos detalles sobre la naturaleza de los datos que se almacenan, cómo se consulta, etc., así que pensé que valía la pena publicarlos.Mejor (NoSQL?) DB para pequeños documentos/registros, datos invariables, muchas escrituras, lecturas rápidas?

Mis datos es muy simple, tres campos: - un valor "datetimestamp" (fecha/hora) - dos cadenas, "A" y "B", ambas < 20 caracteres

Mi aplicación es muy escribir pesado (cientos por segundo). Todas las escrituras son nuevos registros; una vez insertado, los datos nunca se modifican.

Las lecturas regulares se realizan cada pocos segundos y se utilizan para completar algunos paneles en tiempo casi real. Consulto contra el valor de fecha/hora y uno de los valores de cadena. p.ej. obtenga todos los registros donde la fecha y hora de la fecha esté dentro de un cierto rango y el campo "B" sea igual a un valor de búsqueda específico. Estas consultas generalmente devuelven unos miles de registros cada una.

Por último, mi base de datos no necesita crecer sin límite; Buscaría depurar registros con más de 10 días de antigüedad ya sea borrándolos manualmente o usando una técnica de caché y caducidad si el DB la admite.

Inicialmente lo implementé en MongoDB, sin ser consciente de la forma en que maneja el bloqueo (escribe lecturas de bloque). A medida que escala, mis consultas se alargan cada vez más (más de 30 segundos ahora, incluso con la indexación adecuada). Ahora, con lo que he aprendido, creo que la gran cantidad de escrituras están muriendo de hambre en mis lecturas.

He leído la publicación kkovacs.eu comparando varias opciones de NoSQL, y aunque aprendí mucho, no sé si hay un claro ganador para mi caso de uso. Agradecería enormemente una recomendación de alguien familiarizado con las opciones.

¡Gracias de antemano!

+0

¿Qué graba que necesita cientos de escrituras por segundo para llenar una base de datos para cuadros de mandos en tiempo real? – eaolson

+0

¿Revisaste SQLite? –

+0

@eaolson Estoy grabando eventos a medida que ocurren, y no tengo control sobre la información que me llega. Las dos cadenas identifican un "qué" y un "dónde". Las consultas son principalmente cosas como "seleccionar todos los eventos en la ubicación [x] en los últimos 5 minutos". Los resultados se guardan en la memoria caché y se combinan con los resultados de consultas anteriores (a partir de divisiones temporales anteriores) y se grafican en el tablero de instrumentos. –

Respuesta

0

Decidir un producto NoSQL correcto no es una tarea fácil. Le sugiero que obtenga más información sobre NoSQL antes de hacer su elección, si realmente quiere asegurarse de que no termine confiando en la sugerencia o los favoritos de otra persona.

Hay un buen libro que ofrece muy buenos antecedentes sobre NoSQL y cualquiera que esté comenzando con NoSQL debería leer esto.

http://www.amazon.com/Professional-NoSQL-Wrox-Programmer/dp/047094224X

espero leer algunos de los capítulos en el libro realmente le ayudará. Hay comparaciones y explicaciones sobre lo que es bueno para cada trabajo y mucho más.

Buena suerte.

1

Me he enfrentado a un problema como este antes en un proceso de grabación del sistema de control de las medidas. Esto se hizo con PC IBM de 5 MHz, por lo que definitivamente es posible. Los casos de uso fueron más variados — resumen por minuto, hora, ocho horas de turno, día, semana, mes o año — por lo que el sistema registró todos los datos sin procesar, pero también se agrega sobre la marcha para las consultas más comunes (que fueron promedios de cinco minutos). En el caso de su tablero, parece que la agregación de cinco minutos es también un objetivo principal.

Quizás esto podría resolverse escribiendo un par de archivos de texto para cada flujo de entrada: uno con todos los datos sin formato; otro con la agregación de minutos múltiples. El tablero ignoraría los datos sin procesar. Una base de datos podría ser utilizada, por supuesto, para hacer lo mismo. Pero simplificar la aplicación podría significar que no se necesita RDB.Más simple de diseñar y mantener, más fácil de instalar en un microcontrolador, sistema integrado, etc., o un vecino más amigable en un host compartido.

Cuestiones relacionadas