2010-05-04 22 views
5

Tengo unos pocos valores de datos que debo almacenar en mi aplicación de rieles y quería saber si hay alguna alternativa para crear una tabla de base de datos solo para hacer esta simple tarea.Almacenar datos en Ruby on Rails sin base de datos

Antecedentes: Estoy escribiendo algunas herramientas de análisis y tablero para mi aplicación ruby ​​on rails y espero acelerar el tablero almacenando resultados que nunca cambian. En este momento, selecciono a todos los usuarios durante los últimos 30 días y los reorganizo para que pueda ver la cantidad de nuevos usuarios por día. Funciona de maravilla pero lleva bastante tiempo, en realidad solo debería calcular el día más reciente y simplemente almacenar el resto de la matriz en otro lugar.

¿Dónde está la mejor manera de almacenar esta matriz?

Crear una tabla de base de datos parece un poco exagerado, y no estoy seguro de que las variables globales sean la respuesta correcta. ¿Existe una mejor práctica para datos persistentes como este?

Si alguien ha hecho algo como esto antes, déjame saber lo que hiciste y cómo resultó.

Respuesta

11

Ruby tiene una tienda de valores clave basada en hash llamada PStore. Esto proporciona una persistencia transaccional simple basada en archivos.

+0

Me gusta mucho esto, no sabía que existía, basado en la descripción del problema, y ​​la experiencia ¿recomendaría este método sobre las otras sugerencias de "solo use el DB"? – Schneems

+0

Si su caso de uso es solo la serialización de una matriz, que suena como es, ¿por qué no? Si no funciona para usted, entonces es fácil cambiar a otra solución más adelante. –

1

Usar una base de datos liviana como sqlite no debería parecer una exageración. Alternativamente, puede usar soluciones de almacenamiento de claves como el gabinete de Tokio o incluso almacenar el arreglo en un archivo plano manualmente, pero realmente no veo ninguna exageración al usar sqlite.

+0

supongo que la exageración me siento vendría de escribir el esquema, la migración de la base de datos, se trata de dos adaptadores diferentes en mi proyecto Rails (actualmente usando MYSQL para todo lo demás), y luego escribiendo las consultas SQL (porque estos elementos no están vinculados con un modelo) ... cuando al final del día todo lo que quiero es [1,2,3,4,5] . No me importa hacer todo esto, solo tengo curiosidad por ver cómo otros se han acercado al mismo escenario. – Schneems

1

Si usted tiene una base de datos ya, no es realmente un gran problema para crear una tabla separada para el seguimiento de este tipo de cosas. Al hacer informes, a menudo es ventajoso para usted crear tablas de resumen derivadas exactamente como las que describe. Puede actualizarlos según sea necesario con una simple instrucción SQL y no hay que preocuparse de que su tienda temporal desaparezca de alguna manera.

Dicho esto, el tipo de informe que está intentando generar es en realidad algo que se puede hacer en tiempo real, excepto en conjuntos de datos extravagantemente grandes. La clave es tener índices que describan la operación de agrupación exacta que estás tratando de hacer. Por ejemplo, si está agrupando por fecha de calendario, puede crear un campo "fecha" y sincronizarlo con la hora "created_at" según sea necesario. Un índice en este campo de la fecha hará haciendo un GROUP BY created_date muy rápido:

SELECT created_date AS on_date, COUNT(id) AS new_users FROM users GROUP BY created_date 
+0

Desafortunadamente, no estoy haciendo esto solo para usuarios, sino también algunos otros elementos, como la cantidad de correos electrónicos enviados por día, que es de miles (por día), por lo que demorar los datos de los últimos 30 días es una eternidad. Luego, cuando obtengo los objetos, tengo que tomar created_at (objeto de fecha/hora) y evaluar iterar para agrupar los objetos. Tal vez haya una mejor manera, pero todavía no he podido dar en el clavo. – Schneems

+1

Agregar una columna indexable, donde es una fecha y no una fecha y hora, ayudará al generar los informes en primer lugar. Agregar datos de un día a la vez también es bastante eficiente, incluso para grandes volúmenes, pero el tiempo de configuración para agregar todos los datos históricos puede ser considerable. Insertar un recuento agrupado debería tomar solo unos segundos, y solo tendría que hacerse una vez al día como máximo, fácilmente como un trabajo en segundo plano o una tarea cron. En realidad, no cargue los modelos si todo lo que quiere hacer es contarlos. Solo usa SQL directamente. – tadman

Cuestiones relacionadas