Escalabilidad y Sharding. Pierre-Yves Duquesnoy Sales Engineer

Transcripción

1 Escalabilidad y Sharding Pierre-Yves Duquesnoy Sales Engineer

2 La importancia de la Escalabilidad La plataforma InterSystems IRIS permite: La Escalabilidad Vertical y Horizontal Escalar en Número de Usuarios y en tamaño de Datos Acceder a los datos con aplicaciones SQL y mediante Apache Spark Escoger las mejores opciones de escalabilidad adaptadas a la aplicación y los requerimientos del negocio 2 InterSystems Corporation. All rights reserved.

4 Escalabilidad Vertical Incremento de la capacidad de un servidor con más CPU, memoria, Red y I/O Beneficios Arquitectura simple Ajuste granular a las necesidades Retos Complejidad en Software Requiere dimensionamiento previo Ratio Precio/Rendimiento no lineal Limitaciones Hardware 4 InterSystems Corporation. All rights reserved.

5 Ejecución SQL Paralelizada Uso simultáneo de múltiples cores para la ejecución de una query SQL 1 proceso por core = escalabilidad vertical Beneficios máximos para agregaciones y tablas grandes Disponible desde 2015 Con la opción SQL %PARALLEL, automático en el futuro. 5 InterSystems Corporation. All rights reserved.

7 Escalabilidad Horizontal Extiende un Clúster añadiendo más servidores para adaptarse a la carga Beneficios Linealidad precio/rendimiento Aprovecha sistemas Cloud, servidores básicos / virtuales Permite escalabilidad elástica Retos Complejidad de Software Énfasis en Redes 7 InterSystems Corporation. All rights reserved.

10 Servidores de Aplicación ECP El InterSystems Enterprise Cache Protocol es un potente mecanismo para distribuir datos e lógica de aplicación en varias instancias. Desacopla la ejecución de código de los datos: Servidor de Aplicación ECP sirve peticiones de usuario de un espacio de memoria local Servidor de Datos ECP graba datos en disco Escalabilidad horizontal de la memoria caché: Cada instancia tiene una memoria caché independiente, sincronizada con los datos en disco Memoria caché repartida en varias instancias Transparente para la aplicación 10 InterSystems Corporation. All rights reserved.

13 Sharding SQL de InterSystems SQL Sharding permite particionar una tabla y repartirla sobre múltiples instancias (Shards) Reparte el trabajo de un query SQL en múltiples Shards Permite la carga en paralelo y el uso de frameworks externos como Apache Spark, interactuando directamente con los Shards Escalabilidad horizontal de la memoria caché : la memoria de varios servidores se suma para mantener más datos en memoria Transparente para la aplicación 13 InterSystems Corporation. All rights reserved.

15 Sharding SQL de InterSystems

16 Arquitectura de Sharding SQL 2 roles principales en un clúster de Sharding: 1 Shard Master (DM) Punto de entrada al Namespace particionado Almacena Definiciones de tablas, código, datos de tablas no particionadas shard master Múltiples Shard Servers (DS) Almacenamiento y memoria caché escalable para tablas particionadas Tablas particionadas en múltiples servidores Shard Servers (DS) Tablas no particionadas accesibles desde Shard Server vía ECP BBDD de Código compartida entre todos los Shard Servers Transparente para la aplicación, sin acceso directo para los usuarios shard server shard server 16 InterSystems Corporation. All rights reserved.

17 Arquitectura Procesamiento de Petición SQL aplicación 1. La aplicación envía petición SQL al shard master 2. El Shard master analiza la petición para particionarla y envía peticiones localizadas a los Shard servers 3. Los Shard Servers resuelven las peticiones localizadas y envían los resultados al Master vía ECP 4. El Shard master agrega los resultados recibidos y devuelve la respuesta a la aplicación shard master shard server shard master shard server 17 InterSystems Corporation. All rights reserved.

18 Arquitectura Shard Master App Servers Shard Master Application Servers (AM) permite escalar en usuarios, mientras los Shard Server (DS) permiten escalar en procesamiento SQL Se usa ECP para leer tablas no particionadas del Shard Master Data Server (DM) Se conecta directamente a los Shard Server para las tablas particionadas AM AM AM DM DS DS DS DS 18 InterSystems Corporation. All rights reserved.

19 Arquitectura Query Shards Son Servidores de aplicación para añadir capacidad de procesamiento SQL a cada Shard: Data Shards (DS) persiste los datos analytic ingest Query Shards (QS) ejecutan SQL contra el Data Shard vía ECP La ingestión de datos se hace directamente en el Data Shard y no interfiere con la carga Analítica que se hace en el Query Shard DM QS QS QS DS DS DS 19 InterSystems Corporation. All rights reserved.

20 Joins SQL entre tablas particionadas Joins en el mismo Shard (Cosharded joins) Joins con condición de igualdad sobre la clave de sharding (equi-joins) se pueden ejecutar localmente en el Shard. Muy eficientes, muy buena escalabilidad (en número de tablas y número de Shards) Joins entre servidores de Shard Se pueden hacer Joins sobre cualquier conjunto de tablas particionadas Cada Shard Server accede a datos de otros Shard via ECP Eficiente algoritmo de asignación de conjuntos a cada servidor de Shard Joins entre tablas particionadas y no-particionadas El Shard server accede a las tablas del Shard Master via ECP 20 InterSystems Corporation. All rights reserved.

21 Otras características de InterSystems IRIS Mirroring Proporciona Alta disponibilidad Para todos los componentes de datos de los clusters (DM & DS) Reintento automático de la petición en caso de failover de un nodo Connector de IRIS para Apache Spark Aprovecha la topología de Shard Los Spark workers se conectan directamente a los shards para ejecutar peticiones locales, y realizar las agregaciones en Spark JDBC Conexiones directas a los Shards en paralelo Alto rendimiento de inserción 21 InterSystems Corporation. All rights reserved.

22 Casos de uso

23 Casos de uso Sistema de Trading multi-activos Banco de inversión global 13% del volumen de acciones mundiales, 2000 Millones transacciones /día, 6TB de datos /día Usa Plataform de Datos InterSystems Evaluación de InterSystems IRIS para acceso tiempo real a los datos, reemplazando servidores ECP, Sybase ASE, Sybase IQ y Rainstor Mejora de rendimiento SQL de 300% y reducción de costes de 70% Servicio de Benchmarking Otro banco global evaluando InterSystems IRIS para reemplazar un sistema de benchmark existente en Sybase IQ. InterSystems IRIS es hasta 2x más rápido que otra BBDD en memoria, y entre 3x y 20x más rapido que Sybase IQ 23 InterSystems Corporation. All rights reserved.

24 Caso de uso 1 Sistema de Trading multi-activos Acceso en tiempo real y almacenamiento en Nube privada

25 Caso 1: Entorno InterSystems existente Sistema de trading graba transacciones intra-día a cientos de instancias Caché vía SQL: Instancias de Datos (DS) y Aplicaciones (AS) Conectadas con ECP Todas en servidores físicos AS con 128GB RAM, DS con 40GB Para evitar carga adicional sobre los AS Replicación SQL a Sybase ASE Sybase ASE sirve las peticiones SQL que no son de trading TSS/Hermes AS AS AS Data Server Data Server TIS/Persistor Data Server 25 InterSystems Corporation. All rights reserved.

26 Caso 1: Almacenamiento Caché intradía Sybase ASE 7 días Sybase IQ 6 meses Rainstor Historico Replicación online (tiempo quasi-real): del Sistema de trading a instancias Sybase ASE (7 días) Fin de día: copia de datos de Caché a Sybase IQ (6meses) y Rainstor (para siempre) 26 InterSystems Corporation. All rights reserved.

27 Caso 1: InterSystems IRIS permite un acceso tiempo real Arquitectura propuesta: TSS/Hermes & client apps Sistema de trading y TIS siguen almacenando en los DS Supresión del los AS costosos DM Cluster InterSystems IRIS en la nube 1 o más InterSystems IRIS Shard Master(s) Para cada DS, 1 o más Query Shard(s) 40GM de RAM/node, almacenamiento económico Proporciona: Tiemp real, Escalabilidad Horizontal QS DS QS DS TIS/Persistor QS DS Reemplazo de los InterSystems AS y los Sybase ASE para las peticiones intra-día Mejora del rendimiento 300% Reducción de coste del 70% 27 InterSystems Corporation. All rights reserved.

28 Caso 1: Almacenamiento con InterSystems IRIS TSS/Hermes ASE/IQ/Rainstor clients DM DM QS QS QS QS QS QS DS DS DS DS DS DS TIS/Persistor La replicación nativa de InterSystems IRIS mueve datos de Caché a los Shard de InterSystems IRIS. El cluster en la nube puede mantener datos el tiempo necesario, 7días, 30 días o 6 meses 28 InterSystems Corporation. All rights reserved.

29 Caso de uso 2 Servicio de Benchmarking Triunfa donde Hadoop y un DataWarehouse tradicional fracasan

30 Caso 2: Antecedentes El banco de inversión tiene un servicio de benchmarking con métricas de Fuentes externas, 4000 métricas internas 8TB de Datos Los Gestores de activos usan el servicio Para comparar la cartera de sus clientes con las métricas En fin de día La plataforma de estrategia de trading tiempo-real Usa el servicio para toma decisiones durante el día 30 InterSystems Corporation. All rights reserved.

31 Caso 2: Retos El banco tiene peta-bytes de datos en Hadoop Joins SQL Complejos Múltiples almacenes de datos SQL optimizados para las distintas aplicaciones/clientes. Sybase ASE no aguanta la demanda de las aplicaciones/clientes. Requerimientos de baja latencia Soluciones In-memory costosas y/o inestables 31 InterSystems Corporation. All rights reserved.

32 Caso 2: InterSystems IRIS VMs de InterSystems IRIS en nube privada cada VM tiene 4 cores, 32GB RAM, 200GB disco interno Estrategias de Sharding con claves distintas (indexid, businessdate) InterSystems IRIS es hasta 2x más rápido que otras BBDD distribuidas en memoria Hasta 3x~10x más rápido que Sybase IQ en muchas pruebas siempre más rápido globalmente 32 InterSystems Corporation. All rights reserved.

33 Preguntas?

34 Gracias!