Escalabilidad y Sharding - InterSystems...El banco de inversión tiene un servicio de benchmarking...

Escalabilidad y ShardingPierre-Yves Duquesnoy – Sales Engineer

2 | © InterSystems Corporation. All rights reserved. |

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


Escalabilidad Vertical


Incremento de la capacidad de un servidor con más CPU, memoria, Red y I/O

Beneficios Retos

• Arquitectura simple

• Ajuste granular a las

necesidades

• Complejidad en Software

• Requiere dimensionamiento

previo

• Ratio Precio/Rendimiento no

lineal

• Limitaciones Hardware

Escalabilidad Vertical


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.


Escalabilidad Horizontal


Escalabilidad Horizontal

Extiende un Clúster añadiendo más servidores para adaptarse a la carga

Beneficios Retos

• Linealidad precio/rendimiento

• Aprovecha sistemas Cloud,

servidores básicos / virtuales

• Permite escalabilidad elástica

• Complejidad de Software

• Énfasis en Redes


Escalabilidad Horizontal de Usuarios


Escalabilidad Horizontal de Usuarios


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


Escalabilidad Horizontal de Datos


Escalabilidad Horizontal de Datos


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


Escalabilidad independiente de datos y usuarios

Sharding SQL de InterSystems


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

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 master

shard

servershard

server

Arquitectura de Sharding SQL


Arquitectura – Procesamiento de Petición SQL

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

aplicación

shard master

shard master

shard

servershard

server


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

DM

DS DS DS DS

AM AM AM


Arquitectura – Query Shards

Son Servidores de aplicación para añadir capacidad de procesamiento SQL a cada Shard:

• Data Shards (DS) persiste los datos

• 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

DS

analytic ingest

DS DS

QS QS QS

DM


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


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

Casos de uso


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

Caso de uso 1Sistema de Trading multi-activos

Acceso en tiempo real y almacenamiento en Nube privada


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

TIS/Persistor

Data

Server

AS AS AS

Data

Server

Data

Server


Caso 1: Almacenamiento

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)

Rainstor

Historico

Sybase IQ

6 meses

Sybase ASE

7 días

Caché

intradía


Caso 1: InterSystems IRIS permite un acceso tiempo real

Arquitectura propuesta:

• Sistema de trading y TIS siguen almacenando en los DS

• Supresión del los AS costosos

• 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

• 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%

TSS/Hermes & client apps

TIS/Persistor

DS DS DS

QS QS QS

DM


Caso 1: Almacenamiento con InterSystems IRIS

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…

TSS/Hermes

TIS/Persistor

DS DS DS

QS QS QS

DM

ASE/IQ/Rainstor clients

DS DS DS

QS QS QS

DM

Caso de uso 2Servicio de Benchmarking

Triunfa donde Hadoop y un DataWarehouse tradicional fracasan


Caso 2: Antecedentes

El banco de inversión tiene un servicio de benchmarking con 18000 métricas

• 14 000 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


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


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

Preguntas?

Gracias!

Date post:	09-Mar-2021
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Escalabilidad y Sharding - InterSystems...El banco de inversión tiene un servicio de benchmarking...

Documents