Base de datos columnar

[Arturo24]

Lo sentimos si esta es una pregunta extraña:

¿Tiene sentido tener una base de datos de columnas de historial y una base de datos en columnas actual y tener la actual anexar datos al historial?

Sé que el motor es muy eficiente para almacenar datos. En este momento utilizo archivos de texto simples exportados de una base de datos de acceso, pero constantemente la importación de los mismos archivos de texto una y otra vez parece que obtendrá super lento con el tiempo. Así que pensé que tener dos bases de datos columnares (y anexar corriente a la historia) podría funcionar. Pero no estoy seguro de si esto es lo que este sistema fue desinged para.

Cualquier pensamiento para este novato sería apreciado. Gracias

[edhans]

No tengo 100% claro en lo que le estás pidiendo @Arturo24, sino algunos puntos:

1. ¿Por qué no conectarse directamente a Microsoft Access frente a los archivos CSV? Sólo tiene que utilizar el conector de acceso.
2. Volver a importar los mismos archivos no será más lento con el tiempo. La importación es un borrado / importación / carga por lo que no se hará más grande y más grande. Power BI solo contiene lo que había en la última actualización. No se agrega a los datos existentes. Se eliminan los datos existentes.

Si desea mantener el historial y solo importar nuevos datos, entonces Actualización incremental es lo que necesita. Teorticamente puede realizar una actualización incremental en una base de datos de Access, ya que PQ doblará algunas instrucciones. Definitivamente no se puede contra los archivos CSV. Usted tiene que tener un servidor de base de datos (incluso el motor de Access JET) para que esto funcione. Pero sin tener su base de datos para jugar con no puedo confirmar que va a funcionar.

La actualización incremental está realmente hecha para conjuntos de datos MUY MUY grandes que se encuentran en SQL Server y otras bases de datos relacionales. No importaría mucho en Access a menos que los datos tengan más de unos pocos cientos de MB de tamaño, que serían millones de registros.

[Arturo24]

Buenas noches.  Primeramente puse esta pregunta en ingles y fue traducida al castellano.  Interestante!  Agradezco su respuesta.  Lo que pasa es que el Power BI que uso es de 64 GB y el MS Access que uso es de 32 GB.  Y eso prohibe una connecion directa.  Se que tener todo los CSV en el mismo archivo permite importar cada CSV mientras que tengan sus data en las misma forma (columnas con las mismas caracteristicas). 

Pero si son centenares de text files cada uno con millones de lineas se me hace un gasta do tiempo reimportar los datos que ya han estado en el Power BI, cada vez que hay uno nuevo csv.  Por eso se me ocurrio preguntar si era posible tener un BI database historial y otro con datos nuevos y solo aggregar lo nuevo a lo historial.  Pero de lo que me esta diciendo no es algo tipico usar dos distincto databases en el modelo power BI. 

De nuevo agradezco su respuesta y sigo investigando.

[edhans · Accepted solution]

Siempre debe usar la misma bitness de Power BI que usa para Office. Dicho esto, es posible que pueda instalar la versión de 64 bits del motor redistribuible de Microsoft Access 2010. Esto permitirá que Power BI 64bit lea los archivos ACCDB. Pero sea advertido, no puedo garantizar que la instalación de ese paquete de 64 bits no estropeará su versión de 32 bits de Office!

En cuanto al historial de retención de Power BI y solo obtener nuevos datos, eso es exactamente lo que hace la característica de actualización incremental, pero requiere una base de datos back-end que admita el plegado de consultas (Oracle, SAP, SQL Server, PostGRE SQL, etc., y posiblemente Access), pero no funcionará con ningún archivo plano de ningún tipo, ya que no hay ningún motor en el back-end para limitar los datos. Power Query debe procesar todos los datos para saber qué conservar y qué no conservar, por lo que sigue realizando el 95% del trabajo solo en la consulta. La carga toma comparativamente poco tiempo en absoluto. Así que si debes seguir con archivos CSV, solo cárgalo cada vez.

Tenga en cuenta que hay una solución interesante en este blog de Chris Webb,pero no estoy seguro de que lo utilizaría en producción, ya que constantemente tendrá que mantenerse al día con lo que está "cargado" y lo que no lo es y obtener invertido en el uso de ALM Toolkit para administrar los datos en la nube. Para mí es más interesante como un ejercicio que útil como herramienta de producción.