2010-11-25 14 views
6

Después de analizar algunos gigabytes de archivos de registro con grep y similares me preguntaba cómo hacer esto más fácil utilizando una base de datos para registrar las cosas. ¿Qué base de datos sería apropiada para este propósito? Una base de datos de vanillia SQL funciona, por supuesto, pero proporciona muchas garantías transaccionales, etc. que no necesita aquí, y que pueden hacer que sea más lento si trabaja con gigabytes de datos y tasas de inserción muy rápidas. Entonces, una base de datos NoSQL que podría ser la respuesta correcta (compare this answer para algunas sugerencias). Algunos de los requisitos para la base de datos serían:¿Qué base de datos usaría para registrar (es decir, als archivo de registro de reemplazo)

  • capacidad para hacer frente gigabytes o incluso terabytes de datos
  • inserción rápida
  • múltiples Indizes en cada entrada debe ser posible (por ejemplo, tiempo, identificador de sesión, URL, etc. .)
  • Si es posible, almacena los datos en una forma comprimida, ya que los archivos de registro suelen ser extremadamente repetitivos.

Actualización: Ya hay algunas preguntas de SO para esto: Database suggestion for processing/reporting on large amount of log file type data y What are good NoSQL and non-relational database solutions for audit/logging database. Sin embargo, me interesa saber qué bases de datos cumplen con cada requisito.

Respuesta

1

Según sus necesidades, Splunk podría ser una buena opción. Es más que solo una base de datos, pero obtienes todo tipo de informes. Además, está diseñado para ser un reemplazo de archivo de registro, por lo que ya han resuelto los problemas de escala.

5

Después de haber probado muchas soluciones NoSQL, mis mejores opciones serían:

  • riak + riak búsqueda de gran escalabilidad
  • unnormalized datos en MySQL/PostgreSQL
  • mongodb si no le importa esperar
  • couchdb si sabes lo que estás buscando

Riak + Riak Search escalar fácilmente (¡REALMENTE!) Y permitir consultas de forma gratuita sobre sus datos. También puede combinar fácilmente esquemas de datos e incluso comprimir datos con innostore como back-end.

MongoDB es molesto para escalar varios gigabytes de datos si realmente desea usar índices y no ralentizar a un rastreo. Es realmente rápido teniendo en cuenta el rendimiento de un solo nodo y ofrece la creación de índices. Tan pronto como su conjunto de datos de trabajo ya no cabe en la memoria, se convierte en un problema ...

mysql/postgresql sigue siendo bastante rápido y permite consultas de forma libre gracias a los índices b + tree habituales. Mire postgres para partial indexes si algunos de los campos no aparecen en cada registro. También ofrecen tablas comprimidas y como el esquema es fijo, no guarda los nombres de sus filas una y otra vez (eso es lo que suele ocurrir con muchas de las soluciones nosql)

CouchDB es bueno si ya conoce las consultas desea ver, sus vistas incrementales de mapa/reducir son un gran sistema para eso.

Cuestiones relacionadas