Hilo iniciado por Isabel Pizarroso el 9 de junio de 2014
-
Entradas
-
Hola,
Trabajo en un proyecto para una empresa que tiene una gran cantidad de datos en una base de datos transaccional. Debido a que tenemos un proceso en el cual hay que mostrar casi 100000 de registros en un grid dentro de un formulario (la fuente de datos seria la base de datos transaccional), mi pregunta es:
Si duplico la base de datos transaccional en ax (la cual esta continuamente cambiando y es un Sistema que siempre debe estar) voy a tener un volumen de datos solo en una tabla de 50Gb… Voy a tener problemas de rendimiento en la base de datos y sobre todo renderizando la gran cantidad de informacion que necesito mostrar (y filtrar por todos los campos) en el formulario de AX? Afectara el rendimiento cuando tenemos multiples usuarios haciendo la tarea en ax???
Gracias
Hola Isa,
1Millon de registros en un grid, entiendo que con paginacion verdad? No conozco AX pero si tuviera que mostrar 1Millon de registros integros en una pagina web.. 50Gb!!! directamente te diria.. NO SE HA INVENTADO NAVEGADOR QUE LO SOPORTE Y/O PROTOCOLO DE COMUNICACION.. es broma, pero me parece algo impensable.
Con paginacion, cuales serian las limitaciones de AX? Suponiendo unos 200Millones de registros en la tabla, tras aplicar filtros se quedarian en 1Millon posibles que el grid presentaria. Puedo tener problemas de concurrencia?
Buenas Isa. la verdad que me sorprende cómo se ha llegado a definir un grid filtrado con 1 millon de registros posibles.
Creo que se está confundiendo el ERP con una herramienta de BI y no es así. Al tener volumenes tan altos de datos no es posible explotarlo dentro de un formulario de AX, es una aberración a las propias capacidades que te ofrece la plataforma.
No sería mejor plantearlo a través de la herramienta PowerView y PowerPivot con el Addin que permite modificar datos en Excel y se integran en AX?
Hola Antonio, la verdad es que yo trabajo para un cliente y nuestro partner nos plantea esta solución….pero más o menos es en esto en lo que estamos luchando en este momento; de todas formas el Solution architect de mi empresa va a seguir con esta discusión, yo soy funcional y me pierdo un poco con todo este tema.
Muchas Gracias
IPA
Buenas Isa, además de los registros que se muestren por grid, afectará al rendimiento si en ese grid contiene campos de métodos display o si el formulario presenta Parts que aparecen a partir de la versión 2012. En AX 2012 el rendimiento de los formulario se degradaba mucho por la utilización de los Parts, por lo que si en un formulario tienes parts y métodos display en el grid hará mil consultas y entonces irá a pedales la visualización, si auditas las trazas de SQL verás los select que hace cada vez que te posiciones en un registro.
No conozco un documento como tal que te diga las limitaciones de registros por grid porque no sólo es la visualización de los datos, por grid puedes indicar el número de registros que puedes mostrar, sino que en los métodos active puede haber lógica que controle los datos y eso puede penalizar. De todas formas si la tabla en muy grande se puede particionar en SQL server para que el acceso sea más óptimo y ponerla un otro disco o partición de disco.
Muchas gracias Adolfo, esta claro que la solucion pasa por hacer una performance de la SQL, pero nuestra duda real, es si Ax soprtara ese volumen de datos sin explotar antes????
El partner nos asegura que si se puede y que si lo soporta, pero….yo no estoy tan segura.
Estoy casi seguro de que si lo soporta, que yo sepa no hay límite en la cantidad de registros que puede mostrar el cliente. Los grid utilizan un mecanismo de caché para leer los datos por bloques de la base de datos, conforme se utilizan los controles de scroll, etc.
Ahora bien, el rendimiento va a ser malo incluso con estos mecanismos. En el mometo en la grid haya controles display el rendimiento disminuirá. Y si se realizan ciertos filtros sobre campos no indexados en la tabla, o cualquier función que obligue al sistema a leer la tabla entera (como exportar a Excel o algo así), probablemente el rendimiento sea tan malo que no sea utilizable en la práctica.
Lo mejor sería replantearse esa solución (sea cual sea) para tomar como punto de partida un subconjunto más pequeño o más agregado de los datos, como el propio sistema hace, por ejemplo, con la tabla InventSum, para resolver los problemas que supone manejar las tablas de transacciones.
Hay gente propensa a decir siempre que sí, en muchos casos porque quien lo dice no es quien tiene que hacerlo. En realidad, siendo rigurosos, si la pregunta es si se puede o no se puede, la respuesta es: sí se puede. Ahora bien, si la pregunta es si después de hacerlo, alguien podrá utilizarlo, la respuesta más fiable es: no lo creo.
Hola Isabe, como te fue con tu proyecto, si aun tienes problemas te recomiendo contratar los servicio de un consultor que maneje de forma avanzada la administración del motor de SQL, ya que AX depende de SQL y no a la inversa, si requieres trabajar con millones de datos solo tienes que estructurar bien la tabla los indices y las estadísticas y sobretodo las particiones de esta, puedes tener terabytes en un tabla y trabajar sin problemas, al final nadie analiza o trabaja a detalle con millones de datos, solo sumatorias y afectaciones por cálculos sobre muchos campos.
Saludos.
- Debes estar registrado para responder a este debate.