Hola que tal Rodrigo, ¿cómo estás? 1) Sobre tus requisitos funcionales en este caso ¿qué tan grandes esperas que sean estos archivos? Esto es importante para ver si necesitamos algo extra o si podrías cargar los archivos en memoria (que es muy rápido) y ejecutar el procesamiento ahí. 2) Sobre tus consultas ¿estás pensando en usar vistas para no ejecutar las consultas cada vez que un usuario necesita estos reportes? ¿qué tan dinámicos son estos reportes? 3) La plataforma tecnológica que mencionas se me hace muy acorde, **RHEL definitivamente es un sistema operativo listo para el enterprise** (asegúrate de adquirir la licencia con soporte por cualquier duda que llegaras a tener); ahora bien, naturalmente RHEL se lleva muy bien con **JBoss** por ser de la misma familia (aunque el licenciamiento es costoso). Sin embargo, si vas a tener pocos usuarios como veo que es tu caso, entonces Tomcat es más que suficiente. 4) En cuanto a hardware para el *Application Server + Web Server*, recomendaría que tengas al menos 4 GB de RAM dedicados, si es posible armar tu server base con **8 GB para no estar en el límite** y en cuanto a procesador, si te es posible recomiendo algo con mínimo 4 vCPUs + SSD (discos de estado sólido). 5) Para tu servidor de base de datos, Oracle será más que suficiente. Lo que estás pensando usar definitivamente cumplirá. 6) Tu stack para desarrollo es una belleza, punto. **Spring es para mi gusto el mejor framework de Java **que tenemos en estos momentos, te ahorrará mucho trabajo y estarás listo para lo que te pongan enfrente; asimismo Hibernate es un ORM muy maduro, así que no me quedan dudas de su capacidad. 7) En el front-end; Angular está listo igualmente para el enterprise, es genial para aplicaciones de prácticamente cualquier tamaño. Saludos y seguimos en contacto.

Hola Alex (estoy muy bien gracias, y tú que tal ??? XDDD), muy agradecido por tu detallada respuesta. 1 - Respondiendo tu primera pregunta sobre el tamaño del archivo a procesar; el tamaño promedio de un archivo es de unos 150.000 registros (300MB), y se hacen muchas cargas durante el día. Un poco de historia; yo en el pasado desarrolle una aplicación que solucionaba este requerimiento, la desarrolle en .NET > SQL SERVER. En la actualidad el cliente cambio de plataforma tecnológica y además nacieron nuevos requerimientos (es la razón de esta nueva aplicación 2.0 con java y stack de desarrollos desacoplados). En resumen, en esa oportunidad como solución ocupe bulk de SQL SERVER, básicamente en el FRONT de la aplicación validaba algunas cosas básicas del archivo, después leía y contaba las filas con JS, si eran mayor a 10.000 enviaba el archivo físico desde la app al servidor de aplicación, que este su vez le enviaba una copia al servido de base de datos con la finalidad que este ejecutara BULK localmente a una tabla de paso para su posterior proceso a la espera de que el cliente lo ejecute desde la app, en su defecto si eran menos de 10.000 usaba BULK pero en memoria, pero como eran menos datos, el servidor de aplicación se encargaba de esta tarea. fe de erratas (dejo el link de la documentación por si a alguien le sirve): SQL SERVER BULK LOCAL: https://docs.microsoft.com/en-us/sql/t-sql/statements/bulk-insert-transact-sql?view=sql-server-2017 BULK MEMORIA DESDE APP: https://msdn.microsoft.com/es-es/library/system.data.sqlclient.sqlbulkcopy(v=vs.110).aspx Ahora como solución, con java lo que pretendo es ocupar algo parecido a bulk; SQL LOADER: https://docs.oracle.com/cd/B19306_01/server.102/b14215/ldr_concepts.htm No sé si será la forma más óptima y más segura, pero probando>fallando>re-intentando pretendo llegar a algo parecido XDDD, ojalas no me equivoque, ahora quizás hay solución más elegante que alguien conozca y la pueda compartir seria hermoso XDD. 2- Sobre las consultas, también me hace ruido (estoy atento a opiniones y criticas), ya que antiguamente tenía un modelo relacional que básicamente cumplía ambas características, cargar y consultar, al final no creo que fuera lo óptimo, ya que el mismo motor y muchas veces una misma tabla se ocupaba tanto como cargar y leer, era un sistema de gestión de base de datos tanto OLTP y OLAP. Ahora pretendo modelar de mejor forma para quizás usar vistas para consultas de informes y tablas netamente para transacciones, idealmente particionadas por periodo ya que en el modelo anterior una tabla fácilmente llegaba a los 10 millones de datos al año, y claramente hacer cualquier ejecución DML con índice y todo era súper costosa y lenta para el motor, igual y Oracle tiene fama de ser la mejor base de datos SQL transaccional del mundo, así que le tengo fe XD. Mil disculpas por el testamento, pero creo que era necesario profundizar un poquito, quizás hay gente en algún momento requiera solucionar algo parecido, ojalas mi experiencia a otro le sirva de algo =). Saludos, Rodrigo Hinojosa

1) Ah mira que interesante no conocía el BULK de SQL Server, y tu solución me parece buena, ya que para archivos muy grandes pues cargarlos en memoria no es la mejor opción; esa validación que hiciste está excelente ya que te permite discriminar cuándo hacerlo en memoria y cuándo no. 2) Sobre las consultas, veo que definitivamente estamos hablando de una base de datos que crecerá de manera significativa, entonces hacer las consultas de manera directa efectivamente no será viable; en algún proyecto ya hace unos años nosotros decidimos usar una base de datos NoSQL para poder soportar una cantidad gigantesca de datos, la ventaja es que en nuestro caso no teniamos tantas transacciones; era una base de datos orientada a generación de reportes y búsquedas de información con full-search (es decir, necesitábamos velocidad en consulta). Nos cuentas más adelante, cómo está yendo todo, la experiencia que obtendrás es muy valiosa y eso no lo encuentras en Stack Overflow. Saludos y que tengas un excelente día.