socket servidor recibir enviar datos con cliente chats asincronos java database architecture scalability bigdata

servidor - sockets en java con base de datos



Cómo tratar con múltiples resultados de bases de datos de diferentes servidores para una solicitud (5)

Pero para la escalabilidad; la recopilación de datos será recopilada por varias máquinas (monitor de rendimiento) que está conectada con bases de datos individuales.

Aproximadamente, ¿qué tipo de escala anticipa? ... es en cientos de bytes múltiples de Terra GB ... El motivo es en estos días que SQL Server y Oracle pueden manejar grandes volúmenes de datos. Una vez que los datos se recopilan en una base de datos central, el juego finaliza en lo que respecta a la búsqueda y el procesamiento.

Now Manager (Mgr) es responsable de la multidifusión de la solicitud a todos los monitores perf; para recopilar los datos de estadísticas generales para satisfacer una sola solicitud de interfaz de usuario.

Esta será una tarea importante para escribir esto y será realmente complejo en mi humilde opinión. Dicho esto no soy un experto en este aspecto.

Tengo información de estadísticas en la nube (datos estructurados: CSV); Que tengo que exponer al administrador y al usuario.

Pero para la escalabilidad; la recopilación de datos será recopilada por varias máquinas (monitor de rendimiento) que está conectada con bases de datos individuales.

Now Manager (Mgr) es responsable de la multidifusión de la solicitud a todos los monitores perf; para recopilar los datos de estadísticas generales para satisfacer una sola solicitud de interfaz de usuario.

Así que las preguntas son:

1) ¿Cómo haré que los datos del monitor múltiple se ordenen según la solicitud del cliente en Mgr. Cada monitor puede dar el resultado según la solicitud del cliente; ¿Pero todavía cómo combinar datos de máquinas múltiples a través de Java? Medios Cómo realizar la función de agregación / escalar de sql de memoria (por ejemplo, Groupby, orderby, avg) en todos los resultados recuperados de varios clústeres en MGR. ¿Cómo implemento la funcionalidad DB agregado / escalar de SQL en el lado de Java, cualquier API conocida? Creo que lo que necesito es reducir la parte de la técnica mapreduce en hadoop.

2) Una solicitud de la interfaz de usuario (suponga que seleccione el recuento (*) de la base de datos donde Memoria> 1000 MB) debe enviarse a varias máquinas. Ahora, ¿cómo enviar solicitudes paralelas a un monitor individual y consumir solo cuando se responden todos los nodos? ¿Significa cómo esperar el hilo del usuario hasta que consume todas las respuestas de los monitores de perf? Cómo desencadenar una solicitud REST paralela para una sola solicitud de UI en MGR.

3) ¿Debo autenticar al usuario de la interfaz de usuario en Mgr y en Perf monitor?

4) ¿Estás pensando en algún inconveniente en este enfoque?

Notas:

1) No elegí NoSql porque los datos están estructurados y no se requieren combinaciones.

2) No fui para node.js ya que soy nuevo para eso y puedo tardar más tiempo en desarrollarlo. Además, no estoy desarrollando ninguna crítica concurrente en la que los hilos simples sean los más adecuados. Aquí solo se realiza el empuje / recuperación de datos. No se produce ninguna modificación.

3) Quiero una base de datos individual para cada monitor O, al menos, dos instancias de bases de datos con múltiples agrupaciones para una instancia que permita un acceso más rápido a los datos estadísticos GRANDES en tiempo real.

Desea escalar su aplicación, pero diseñó un cuello de botella inherente. A saber: el Mgr.

Lo que haría es dividir el Mgr en al menos dos partes. Front-end y backend. El front-end podría ser simplemente un agregador y / o controlador que recopila todas las solicitudes de los diferentes servidores de UI, marca la hora de esas solicitudes y las pone en una cola (RabbitMQ, Kafka, Redis, lo que sea) haciendo un mensaje con el ID de sesión de UI o algo similar que identifique de manera única la fuente de la solicitud. Luego, solo tiene que esperar hasta que obtenga una respuesta en la cola (con un tema diferente, por supuesto).

Luego, en su backend (el otro lado de la cola) puede configurar tantos nodos como requiera su carga y hacer que realicen la misma tarea. A saber: retire las solicitudes de la cola y llame a esas API de monitoreo de rendimiento según sea necesario. Puede escalar estos nodos de back-end tanto como desee ya que no tienen ningún estado, todo el estado que debe almacenarse ya es parte de los mensajes en la cola que Redis / Kafka / RabbitMQ persistirán automáticamente en usted. o cualquier otra cosa que elijas.

También puede usar Apache Storm o algo similar para hacer esto por usted en el backend, ya que fue diseñado para este tipo de aplicaciones.

Apache Storm también ha incorporado la capacidad de fusión expuesta a través de la API Trident .

Nota sobre la autenticación: debe autenticar las solicitudes HTTP en el extremo frontal y entonces estará bien. Simplemente asigne ID únicas (lo más probable es que las ID de sesión) a los usuarios conectados a su administrador y utilice esta ID interna cuando reenvíe sus solicitudes a los servidores posteriores.

Ahora, ¿cómo enviar solicitudes paralelas a un monitor individual y consumir solo cuando se responden todos los nodos? ¿Significa cómo esperar el hilo del usuario hasta que consume todas las respuestas de los monitores de perf? Cómo desencadenar una solicitud REST paralela para una sola solicitud de UI en MGR.

Bueno, si tiene tantas preguntas sobre el manejo de las conexiones de usuario y el servicio a los clientes con respuestas, le sugiero que elija un libro sobre la API de servlets de Java. Es posible que desee leer este, por ejemplo: Servlet y JSP: un tutorial (una serie de tutoriales) . Está un poco desactualizado pero bien escrito.

Pero con el debido respeto, si tiene tantas preguntas sobre estos temas tan fundamentales, entonces sería mejor dejar el diseño de la arquitectura a alguien más experimentado.

Lo que haría es colocar una capa de Hazelcast o Infinispan o algo así en su Monitor de rendimiento en lugar de Hazelcast. El monitor de rendimiento como una lógica puede ser parte de DataGrid. Entonces MySQL funcionará como un almacenamiento persistente de esta cuadrícula de datos. En este sentido, puede tener más de un Mysql y cada mysql solo contendrá una parte de los datos. Solo funcionará como una capacidad de extensión para ir más allá de su RAM máxima. A medida que aumenta la escala de su monitor de rendimiento, también escalará sus capacidades persistentes.

Young luego Map Mapuce u otras funciones distribuidas para la agregación pueden llevar a una cantidad masiva de paralelismo y capacidad de servidor para un número significativamente mayor de solicitudes. También dicha arquitectura se escala horizontalmente. Al final debería verse algo así:

Y solo en otra nota para decir que no es necesario en general tener 1 MySQL para cada hazelcast. Eso depende de cuál sea el objetivo. También olvidé el Administrador del diagrama, pero las cosas son simples: puede funcionar como puerta de acceso a la Cuadrícula de datos o, alternativamente, puede combinarse con la cuadrícula.

No estoy seguro de si mi respuesta sería útil para usted, ya que esta pregunta se ha publicado algunas veces.

Me gustaría responderlo en función de su pregunta, los problemas del enfoque actual y la solución propuesta ...

1) ¿Cómo haré que los datos del monitor múltiple se ordenen según la solicitud del cliente en Mgr. Cada monitor puede dar el resultado según la solicitud del cliente; ¿Pero todavía cómo combinar datos de máquinas múltiples a través de Java? Medios Cómo realizar la función de agregación / escalar de sql de memoria (por ejemplo, Groupby, orderby, avg) en todos los resultados recuperados de varios clústeres en MGR. ¿Cómo implemento la funcionalidad DB agregado / escalar de SQL en el lado de Java, cualquier API conocida? Creo que lo que necesito es reducir la parte de la técnica mapreduce en hadoop.

Java proporcionó Java DB en la compilación como parte de la distribución de Java, que también está disponible como base de datos Apache Derby. Esta base de datos se puede utilizar como base de datos SQL en memoria. JavaDB y Apache Derby almacenan los datos en el disco. Así que no perderá los datos después de reiniciar. Consulte aquí http://www.oracle.com/technetwork/java/javadb/overview/index.html https://db.apache.org/derby/

Para Map-Reduce, la colección Java simple basada en el enfoque funcionaría. No creo que necesites ningún marco especial Map-Reduce en este caso. Sin embargo, debe considerar Sin memoria, ancho de banda de red, etc. cuando lea datos de múltiples fuentes

2) Una solicitud de la interfaz de usuario (suponga que seleccione el recuento (*) de la base de datos donde Memoria> 1000 MB) debe enviarse a varias máquinas. Ahora, ¿cómo enviar solicitudes paralelas a un monitor individual y consumir solo cuando se responden todos los nodos? ¿Significa cómo esperar el hilo del usuario hasta que consume todas las respuestas de los monitores de perf? Cómo desencadenar una solicitud REST paralela para una sola solicitud de UI en MGR.

Idealmente, el tipo de aplicación de NodeJS es la mejor suite en este caso donde la aplicación obtiene una devolución de llamada cuando hay una respuesta de la llamada HTTP. Sin embargo, puede implementar el patrón de observador como se explica aquí. ¿Cómo realizo una devolución de llamada JAVA entre clases?

3) ¿Debo autenticar al usuario de la interfaz de usuario en Mgr y en Perf monitor?

Debe estar basado en su requerimiento

4) ¿Estás pensando en algún inconveniente en este enfoque?

Hay varios inconvenientes con este enfoque

  • Los datos no se deben extraer a petición de la interfaz de usuario. Al menos, los datos deben estar disponibles en la base de datos centralizada siempre que haya una solicitud para generar los datos. La extracción de datos desde varios puntos finales es costosa.
  • Las estadísticas deben recopilarse periódicamente para mantener el historial y los informes deben generarse en función de la ventana de tiempo móvil.
  • JVM podría salir de memoria si los datos de gran tamaño deben procesarse. Se requiere un manejo adecuado.
  • Los datos grandes pueden transferirse a través de la red cada vez que hay una nueva solicitud. Podría ser para los mismos datos de nuevo.

Notas:

1) No elegí NoSql porque los datos están estructurados y no se requieren combinaciones.

Ningún SQL no significa que no haya una estructura seguida. Incluso la base de datos NoSQL es la mejor opción para dichos datos en los que no actualiza los registros, no se requieren transacciones, etc.

2) No fui para node.js ya que soy nuevo para eso y puedo tardar más tiempo en desarrollarlo. Además, no estoy desarrollando ninguna crítica concurrente en la que los subprocesos individuales sean los más adecuados. Aquí solo se realiza el empuje / recuperación de datos. No se produce ninguna modificación.

NodeJS no será una buena opción ya que es de un solo hilo. NodeJS no debe utilizarse cuando tiene que realizar un trabajo intensivo de CPU. Como el tuyo.

3) Quiero una base de datos individual para cada monitor O, al menos, dos instancias de bases de datos con múltiples agrupaciones para una instancia que permita un acceso más rápido a los datos estadísticos GRANDES en tiempo real.

** Preferiría sugerirle que almacene datos en cualquier base de datos que pueda escalar horizontalmente, que procese los datos cuando llegue o el procesamiento por lotes para que su experiencia de usuario sea buena. **

No reinvente la rueda, use algunas buenas herramientas de monitoreo de BAM y bases de datos existentes, tienen muchos tableros y estadísticas integrados, fáciles de conectar con Java y flujos de trabajo.