Tengo algunas instantáneas de una base de datos que no son series de tiempo. Por ejemplo:
Instantánea día 1:
+----+---------------+------------+------------+ | ID | Title | Category | Date | +----+---------------+------------+------------+ | 1 | My First Post | helloworld | 2015-01-01 | +----+---------------+------------+------------+
Instantánea día 2 (hoy se agrega una nueva publicación):
+----+----------------+------------+------------+ | ID | Title | Category | Date | +----+----------------+------------+------------+ | 1 | My first post | helloworld | 2015-01-01 | | 2 | My second post | other | 2015-01-02 | +----+----------------+------------+------------+
Instantánea día 3 (la publicación 2 se elimina hoy):
+----+---------------+------------+------------+ | ID | Title | Category | Date | +----+---------------+------------+------------+ | 1 | My First Post | helloworld | 2015-01-01 | +----+---------------+------------+------------+
Entonces, entre días, una fila de la tabla puede ser constante o no. Ahora, necesito poder usar una consulta como esta:
SELECT category, COUNT(*) from day1.My_table group by category
Esto es para una mesa de un día. Si queremos contar el promedio diario de publicaciones por categoría en un mes , debemos hacer algo como:
SELECT category, SUM(cnt) / 30
from (
SELECT category, COUNT(*) as cnt
from day1.My_table
group by category
UNION ALL SELECT category, COUNT(*) as cnt
from day2.My_table
group by category
UNION ALL ...
UNION ALL SELECT category, COUNT(*) as cnt
from day30.My_table
group by category
) group by category
Otro ejemplo, el número de publicaciones publicadas en un mes :
SELECT COUNT(distinct id)
from (
SELECT id
from day1.My_table
UNION ALL ...
UNION ALL SELECT id
from day30.My_table
)
Básicamente deberíamos considerar un peso. Si tenemos day1.My_table y day5.My_table, cada publicación que esté en el día 1 y no en el día 5 se contará como también en el día 2,3,4. Cada publicación que sea el día 1 y el día 5 contará como si estuviera en todos los días del mes (= hasta la próxima instantánea).
Entonces, en caso de que me gustaría considerar el número promedio de publicaciones por día de> = 6 meses, donde solo tengo 1 instantánea, asignaría a esa instantánea un peso de 30.
Entonces, la publicación promedio publicada en un mes para un rango> = hace 6 meses es:
SELECT category, SUM(cnt) / 30
from (
SELECT category, COUNT(*)*30 as cnt
from day1.My_table
group by category --- Note: I'm not considering the range defined from the user in this example.
) group by category;
Como el comentario también indicó, necesitaría hacer una consulta como:
Select category, AVG(*)
from [fromRange-toRange].MyTable;
Para una solución extrema, estoy considerando la idea de implementar un metalenguaje para permitir que el futuro usuario (por ejemplo, comercializando personas) haga una consulta como esta.
¿Crees que hay una manera de lograr esto en Drill sin el metalenguaje? Haría esto usando un UDF recursivo pero no pueden devolver consultas.
Cada instantánea es grande de 250 GB, y quiero poder comparar estos conjuntos de datos con otros datos externos (no sé de antemano el esquema de estos conjuntos de datos).
¿Hay alguna solución adecuada para Apache Drill? ¿O hay otra solución para este problema?
También se agradece cualquier metalenguaje o documento sobre este problema.
Editar: no tenemos datos transaccionales. Tenemos datos que cambian con el tiempo y pueden agregarse o eliminarse; Por esta razón, necesitamos instantáneas cotidianas. Tampoco sabemos de antemano las consultas que se realizarán, por lo que no podemos saber qué tipo de agregación se realizará. Además, cada fila tiene alrededor de 100 columnas, y hay, por ejemplo, 250 GB por instantánea (tablas Mysql). También necesitamos una búsqueda de texto completo en estos datos en cada fila, en cada día posible.
Un ejemplo de búsqueda podría ser "¿Cuántas publicaciones fueron sobre algún tema?" Por lo tanto, debe buscar en todas las publicaciones la palabra clave de algún tema. Cada instantánea puede tener o no las mismas filas. Además, dos instantáneas podrían tener la misma publicación, pero ligeramente modificadas.
fuente
table definitions/structures
Respuestas:
Pensemos fuera de la caja. En lugar de tener una "instantánea", tengamos un "registro". Lo que tienes actualmente es el estado "actual" de las cosas; agregar un "registro" proporcionaría el "historial", del cual podría derivarse la información "perdida".
Una forma de implementar el registro es tener un
TRIGGER
sobreINSERT
oUPDATE
en la tabla y hacer que el disparador escriba en el archivo de registro. Este registro no será agradable para las consultas ad hoc, así que haga un trabajo nocturno (o tal vez por hora) que resuma los cambios del día: ganancia (o pérdida) neta de número de publicaciones, etc. La información del "día2" y la información del "último mes" se puede derivar de esta tabla resumen con bastante rapidez. O quizás un segundo nivel de resumen que declara cuál era el estado para cada día. DudoUNION
que sea necesario. La "instantánea" no estaría involucrada.fuente
Entonces, lo que estaba buscando es un nuevo tipo de sistema relacionado con Datawarehousing: Data Lake System.
Puedes aprender más en Wikipedia :
fuente