¿Qué es el concepto Database Plus y qué desafíos puede resolver?

Fondo

Durante mucho tiempo, la unificación o la fragmentación fueron las dos predicciones más populares para el futuro de las bases de datos. Con el avance de la digitalización, un solo escenario no puede satisfacer las necesidades de aplicaciones diversificadas, lo que hace que la fragmentación de bases de datos sea una tendencia irreversible. Si bien , la base de datos comercial con la mayor participación de mercado, no tiene debilidades obvias, todo tipo de nuevas bases de datos todavía están ingresando al mercado. Hoy, más de

Un número cada vez mayor de escenarios de aplicaciones ha exacerbado la fragmentación de la base de datos, haciendo que la arquitectura de la base de datos, los protocolos, las funciones y los escenarios de aplicación sean cada vez más diversificados. En términos de arquitectura de base de datos, la base de datos centralizada que se desarrolla a partir de un sistema de una sola máquina coexiste con la nueva generación de bases de datos nativas distribuidas. En términos de protocolos de bases de datos, y , dos importantes ecosistemas de código abierto, así como los ecosistemas de servicios proporcionados por proveedores dependientes, también tienen un punto de apoyo en el sistema de bases de datos global.

Hoy en día, es normal que las empresas aprovechen bases de datos diversificadas. En mi mercado de experiencia, China, en la industria de Internet, MySQL junto con el software intermedio de fragmentación de datos es la arquitectura de referencia, con , , , y otros ecosistemas de big data como motores informáticos auxiliares para datos analíticos. Al mismo tiempo, todavía se pueden encontrar en uso algunos sistemas heredados (como heredado de la transformación de .NET o Oracle heredado de la subcontratación). En la industria financiera, Oracle o DB2 todavía se utilizan mucho como sistema central de transacciones. El nuevo negocio está migrando a MySQL o PostgreSQL. Además de las bases de datos transaccionales, las bases de datos analíticas también están cada vez más diversificadas.

Cuando afirmo que la fragmentación es una tendencia irreversible en el campo de las bases de datos, baso mis suposiciones en las tendencias anteriores. Un solo tipo de base de datos solo se puede aplicar a un determinado (oa unos pocos escenarios en el mejor de los casos) en el que sobresale.

Problemas con la fragmentación de la base de datos

Con la creciente variedad de bases de datos utilizadas por las empresas, también surgen varios problemas y puntos débiles.

1. Dificultades en la selección de arquitectura

Para cumplir con los requisitos comerciales flexibles, la arquitectura de la aplicación se puede transformar de monolítica a orientada a servicios y luego a microservicios. En este caso, la base de datos utilizada para almacenar los datos centrales se convierte en el foco del sistema distribuido.

En comparación con las aplicaciones sin estado, es mucho más difícil diseñar una base de datos con estado. Divide y vencerás es la mejor práctica para los sistemas distribuidos. Obviamente, los sistemas de bases de datos no pueden responder a todas las solicitudes de servicio con un solo producto y un clúster integrado.

En primer lugar, una sola categoría de base de datos no puede satisfacer todo tipo de necesidades de aplicaciones comerciales, manteniendo un alto rendimiento, baja latencia, consistencia sólida, eficiencia de operación y mantenimiento e incluso estabilidad. Es menos probable que una sola aplicación requiera la coexistencia de múltiples bases de datos, pero la probabilidad de que múltiples aplicaciones requieran múltiples bases de datos es mucho mayor.

En segundo lugar, no importa si estamos hablando de bases de datos independientes o clústeres de bases de datos distribuidas todo en uno, es difícil convertirse en el único soporte de almacenamiento para el backend de muchas aplicaciones de microservicio. Las bases de datos independientes no pueden soportar la creciente cantidad de datos y tráfico, por lo que cada vez más aplicaciones optan por adoptar soluciones distribuidas. Sin embargo, si varias aplicaciones usan un clúster de base de datos unificado, la carga en la CPU, la memoria, los discos y la red no se puede aislar por completo. En este caso, el consumo excesivo de recursos de una aplicación puede provocar la degradación de la calidad del servicio para muchas aplicaciones no relacionadas.

Hoy en día, la creación de la mayoría de las bases de datos distribuidas es costosa y requiere servidores independientes redundantes y de respaldo en el nodo de cómputo, el nodo de almacenamiento y los nodos de gobierno. La creación de una base de datos distribuida independiente para cada microservicio conducirá inevitablemente a un consumo de recursos innecesario y, en última instancia, se volverá insostenible para las empresas.

Finalmente, un gran número de empresas adoptan una arquitectura unificada. Basado en la solución de fragmentación de datos, la división y unificación de las bases de datos se completan en el lado de la aplicación. A medida que aumenta el número de bases de datos, la complejidad del diseño arquitectónico aumenta exponencialmente. A la larga, el equipo de desarrollo no podrá concentrarse en I+D, sino que tendrá que dedicar mucha energía al mantenimiento de los componentes subyacentes. Si bien la función de fragmentación de datos de Apache ShardingSphere puede resolver problemas relacionados, solo admite la fragmentación horizontal para una sola categoría de la base de datos, lo que está lejos de ser suficiente en el caso de bases de datos cada vez más diversificadas.

2. Numerosos desafíos técnicos

Cuando la coexistencia de bases de datos fragmentadas se convierta en la norma, los costos de desarrollo y la curva de aprendizaje para los equipos de I+D inevitablemente aumentarán constantemente. Aunque la mayoría de las bases de datos admiten la operación de SQL, todavía existen muchas diferencias entre las bases de datos en términos de dialectos de SQL. Si es necesario refinar cada base de datos, requerirá mucha energía de los equipos de I+D, y será difícil transmitir el conocimiento y la experiencia acumulados. Si usamos la base de datos heterogénea con un modelo estándar de granularidad gruesa, aniquilará las características de la propia base de datos.

3. Alta complejidad de operación y mantenimiento

Se necesita mucho tiempo y experiencia práctica para dominar las características de varias bases de datos y formular especificaciones efectivas de operación y mantenimiento. Además del trabajo de operación y mantenimiento más básico, las herramientas de soporte de los periféricos de la base de datos también son muy diferentes. El monitoreo, la copia de seguridad y otros trabajos automatizados de operación y mantenimiento compuestos por herramientas de soporte periféricas incurrirán en costos sustanciales de operación y mantenimiento.

4. Falta de colaboración y gestión unificada entre bases de datos.

Desde la perspectiva de una base de datos, su objetivo principal es mejorar su propia capacidad en lugar de mejorar la compatibilidad en línea con otras bases de datos. Las funciones como consultas correlacionadas y transacciones distribuidas en bases de datos heterogéneas no se pueden lograr dentro de la propia base de datos.

A diferencia del SQL relativamente estándar, el protocolo de la propia base de datos y las herramientas del ecosistema periférico carecen de un estándar unificado. Se ha dedicado una atención creciente a la gestión y el control unificados de bases de datos heterogéneas. Desafortunadamente, las bases de datos carecen de estándares de nivel superior, por lo que es difícil promover de forma eficaz la colaboración y la gestión unificada entre bases de datos.

¿Qué es Base de datos Plus?

es un concepto de diseño para sistemas de bases de datos distribuidos, diseñado para construir un ecosistema sobre bases de datos heterogéneas fragmentadas. El objetivo es proporcionar capacidades informáticas mejoradas y escalables a nivel mundial, al tiempo que se maximizan las capacidades informáticas de la base de datos original. La interacción entre aplicaciones y bases de datos se orienta hacia el estándar Database Plus, minimizando así el impacto de la fragmentación de la base de datos en los servicios de capa superior.

Connect, Enhance y Pluggable son las tres palabras clave que definen los valores fundamentales de Database Plus.

1. Connect: creación de estándares de nivel superior para bases de datos

En lugar de proporcionar un estándar completamente nuevo, Database Plus proporciona una capa intermedia que se puede adaptar a una variedad de dialectos SQL y protocolos de acceso a bases de datos, proporcionando una interfaz abierta para conectarse a varias bases de datos.

Gracias a la implementación del protocolo de acceso a la base de datos, Database Plus brinda la misma experiencia que una base de datos y puede admitir cualquier lenguaje de desarrollo y cliente de acceso a la base de datos. Además, Database Plus admite la máxima conversión entre dialectos SQL. Se puede usar un AST (árbol de sintaxis abstracta) que analiza SQL para regenerar SQL de acuerdo con las reglas de otros dialectos de bases de datos. La conversión de dialecto SQL hace posible que bases de datos heterogéneas accedan entre sí. De esta manera, los usuarios pueden usar cualquier dialecto de SQL para acceder a bases de datos subyacentes heterogéneas.

La puerta de enlace de la base de datos es la mejor interpretación de Connect. Es el requisito previo para que Database Plus proporcione una solución para la fragmentación de bases de datos. Esto se logra mediante la creación de una capa de acoplamiento abierta común ubicada en la capa superior de la base de datos, para agrupar todo el tráfico de acceso de las bases de datos fragmentadas.

2. Enhance: motor de mejora de la computación de la base de datos

Después de décadas de desarrollo, las bases de datos ahora cuentan con su propio optimizador de consultas, motor de transacciones, motor de almacenamiento y otras capacidades de computación y almacenamiento probadas y modelos de diseño. Con el advenimiento de la era distribuida y nativa de la nube, las capacidades originales de computación y almacenamiento de la base de datos se dispersarán y entretejerán en un nivel de nuevas capacidades distribuidas y nativas de la nube.

Database Plus adopta una filosofía de diseño que enfatiza las prácticas de bases de datos tradicionales, mientras que al mismo tiempo se adapta a la nueva generación de bases de datos distribuidas. Ya sea centralizado o distribuido, Database Plus puede reutilizar y mejorar las capacidades informáticas nativas y de almacenamiento de una base de datos.

La mejora de las capacidades se refiere principalmente a tres aspectos: distribución, control de datos y control de tráfico.

La fragmentación de datos, el escalado elástico, la alta disponibilidad, la división de lectura/escritura, las transacciones distribuidas y las consultas federadas de bases de datos heterogéneas basadas en la división vertical son capacidades que Database Plus puede proporcionar a nivel global para bases de datos heterogéneas distribuidas. No se enfoca en la base de datos en sí, sino en la parte superior de la base de datos fragmentada, enfocándose en la colaboración global entre múltiples bases de datos.

Además de la mejora distribuida, las mejoras de control de tráfico y control de datos se encuentran en la estructura del silo. Las capacidades incrementales para el control de datos incluyen cifrado de datos, desensibilización de datos, marca de agua de datos, trazabilidad de datos, auditoría de SQL, etc.

Las capacidades incrementales para el control del tráfico incluyen la biblioteca de sombras, la versión gris, el firewall SQL, la lista negra y la lista blanca, el disyuntor y la limitación de velocidad, etc. Todos son proporcionados por la capa del ecosistema de la base de datos. Sin embargo, debido a la fragmentación de la base de datos, es una gran cantidad de trabajo proporcionar una capacidad de mejora completa para cada base de datos, y no existe un estándar unificado. Database Plus proporciona a los usuarios como usted la permutación y combinación de tipos de bases de datos compatibles y mejoras al proporcionar un punto de apoyo.

3. Conectable: construyendo un ecosistema funcional orientado a bases de datos

La capa común de Database Plus podría inflarse debido al acoplamiento con un número cada vez mayor de tipos de bases de datos y capacidad de mejora adicional. La capacidad de conexión derivada de Connect and Enhance no solo es la base de la capa común de Database Plus, sino también la garantía efectiva de infinitas posibilidades de expansión del ecosistema.

La arquitectura conectable permite a Database Plus construir verdaderamente un ecosistema funcional orientado a bases de datos, unificando y administrando las capacidades globales de bases de datos heterogéneas. No es solo para la distribución de bases de datos centralizadas, sino también para la integración de funciones de silo de bases de datos distribuidas.

El diseño de microkernel y la arquitectura conectable son valores centrales del concepto Database Plus, que está orientado hacia una capa de plataforma común en lugar de una función específica.

Exploración de ShardingSphere en Database Plus

El proyecto Apache ShardingSphere tiene una larga historia. De ser un middleware de fragmentación de base de datos de código abierto a ser el iniciador del concepto Database Plus. Actualmente, Apache ShardingSphere sigue el concepto de desarrollo de Database Plus y ha completado la mayoría de sus cimientos de acuerdo con los tres valores fundamentales de Database Plus.

1. Conectar capas

ShardingSphere admite protocolos de bases de datos como MySQL, PostgreSQL, y MySQL, PostgreSQL, openGauss, SQL Server, Oracle y todos los dialectos de SQL que admiten el estándar SQL 92.

La interfaz abstracta de nivel superior de las capas de conexión está abierta para que otras bases de datos se interconecten, incluidos los protocolos de base de datos, el análisis de SQL y el acceso a la base de datos.

2. Mejorar capas

La mejora de funciones de ShardingSphere se divide en la capa del kernel y la capa de funciones opcional.

La capa del núcleo contiene optimizadores de consultas, transacciones distribuidas, motor de ejecución, motor de permisos y otras funciones muy relacionadas con el núcleo de la base de datos, así como un motor de programación, gobierno distribuido y otras funciones muy relacionadas con la distribución.

Cada módulo de la función del núcleo debe existir, pero se puede cambiar a un tipo de implementación diferente. Tome el optimizador de consultas como ejemplo. Si el SQL que se va a ejecutar se puede empujar perfectamente a la base de datos backend, se utiliza un motor de empuje computacional basado en la interacción entre el SQL original y la base de datos. Si el SQL que se va a ejecutar requiere consultas correlacionadas en varios orígenes de datos, se utiliza un motor de consultas federado basado en la interacción entre el árbol del plan de consultas y la base de datos.

Además de la fragmentación de datos y la división de lectura/escritura más típicas, los módulos funcionales como la alta disponibilidad, el escalado elástico, el cifrado de datos y la biblioteca paralela se están mejorando gradualmente.

3. Capas conectables

El proyecto se ha transformado por completo del modelo de arquitectura original centrado en MySQL más fragmentación de datos al microkernel actual más arquitectura conectable. ShardingSphere es completamente conectable desde los tipos de bases de datos y las mejoras que brindan conectividad hasta sus capacidades de kernel.

El núcleo y la periferia de la arquitectura ShardingSphere se componen de tres capas de modelos realizados por microkernel, interfaz conectable y complementos. Se realiza una sola dependencia entre capas, lo que significa que el micronúcleo no necesita percibir complementos en absoluto y los complementos no necesitan depender unos de otros. Para un proyecto a gran escala con más de 200 módulos, el desacoplamiento y aislamiento de la arquitectura es una garantía efectiva de colaboración abierta entre comunidades para minimizar el impacto de los errores.

Resumen Database Plus es el concepto de desarrollo que impulsa ShardingSphere, y ShardingSphere es el mejor practicante del concepto Database Plus. A medida que ShardingSphere madure cada vez más, el rompecabezas de Database Plus habrá encontrado un excelente ejemplo.

Las ventajas de Base de datos Plus

Database Plus trae demasiados beneficios para que podamos enumerarlos todos en este artículo. Este artículo solo ilustrará su impacto en el diseño de la arquitectura del sistema y la selección de tecnología.

1. Adaptabilidad a escenarios de aplicación flexibles

Puede personalizar completamente las funciones según sus necesidades. La fragmentación de datos ya no es indispensable cuando se utiliza ShardingSphere, y hay muchos usuarios de ShardingSphere que utilizan la función de cifrado de datos de forma independiente. La capacidad conectable de ShardingSphere no solo se limita a la capa de acceso a la base de datos y al propio módulo de mejora de funciones.

Tome la fragmentación de datos como ejemplo. Como parte conectable del módulo de fragmentación de datos, el algoritmo de fragmentación se puede personalizar por completo. Ya sea que se trate de algoritmos estándar de hash, rango, tiempo y otros algoritmos de fragmentación, o algoritmos de fragmentación personalizados, todos se pueden configurar de forma libre y flexible de acuerdo con sus necesidades en un intento por lograr un rendimiento óptimo.

2. Capacidad de soporte backend de microservicios para arquitectos

Apache ShardingSphere es la mejor solución para la unificación de bases de datos en el backend de los microservicios. Como se mencionó anteriormente, diferentes microservicios comparten un conjunto de clústeres de bases de datos distribuidas, que no pueden verse como una solución perfecta y elegante en términos de asimetría de diseño de arquitectura o aislamiento de recursos incontrolable. La creación de un clúster de base de datos distribuida para cada conjunto de microservicios provocaría un desperdicio de recursos innecesario.

En comparación con el clúster de base de datos distribuida pesado, ShardingSphere-Proxy ahorra una gran cantidad de recursos, sentando una buena base para que cada clúster de microservicio tenga un conjunto independiente de clústeres de base de datos. Sin embargo, incluso si se refina la división de microservicios, todavía se necesitan muchos recursos para crear un conjunto de para cada conjunto de microservicios. En este caso, se puede usar , que consume menos recursos, y se implementa con el código de la aplicación como una biblioteca de clases sin huella de recursos adicional.

ShardingSphere-Proxy y ShardingSphere-JDBC se pueden usar en una implementación híbrida para satisfacer necesidades como la facilidad de uso, la adaptación entre idiomas, el alto rendimiento y la gestión de recursos. Además, ShardingSphere-Proxy y ShardingSphere-JDBC se pueden enrutar entre sí en solicitudes SQL con diferentes características a través Traffic Rule para minimizar el impacto del uso de recursos de la aplicación.

Traffic Rule puede enviar las solicitudes que consumen más recursos informáticos a ShardingSphere-Proxy, que tiene recursos exclusivos de acuerdo con las características de SQL definidas por el usuario (como el cálculo agregado y las consultas de ruta completa sin claves de fragmentación), al tiempo que reserva operaciones transaccionales ligeras al final de la aplicación de microservicio. . Esto coincide con el concepto de informática perimetral, lo que significa que la capacidad informática de ShardingSphere-JDBC en aplicaciones de microservicios es similar a la de los nodos informáticos perimetrales. ShardingSphere-Proxy, que se utiliza para la informática central, puede implementar clústeres independientes para servir a múltiples grupos de microservicios según las necesidades comerciales.

El uso flexible de ShardingSphere-Proxy, ShardingSphere-JDBC y Traffic Rule seguirá respaldando la inspiración y la creatividad en el diseño de los arquitectos. En broma, el uso adecuado de ShardingSphere para un diseño de sistema elegante puede considerarse como el umbral para un buen arquitecto.

3. DistSQL brinda una experiencia de operación de base de datos nativa a los administradores de bases de datos

Mientras mejoraba funciones como la fragmentación y el cifrado de datos, la versión anterior de Apache ShardingSphere adoptaba principalmente la configuración YAML . Para los desarrolladores, la configuración flexible de YAML es conveniente de usar, pero la configuración de YAML en realidad es un inconveniente para los administradores de bases de datos. Además de cambiar los hábitos operativos de SQL de los DBA, no puede conectarse con sistemas de terceros, como permisos, seguridad, órdenes de trabajo, monitoreo y auditoría.

La nueva versión de Apache ShardingSphere agrega el modo de operación DistSQL. Esto le permite usar las funciones mejoradas a través de SQL en cualquier terminal de base de datos como MySQL, Cli o Navicat. DistSQL coincide con todas las potentes funciones, como la fragmentación de datos, el cifrado de datos y la división de lectura/escritura. Puede configurar todas las funciones utilizando la sintaxis SQL, como CREATE , ALTER , DROP o SHOW , con las que el DBA está familiarizado. DistSQL también admite la gestión y el control de declaraciones autorizadas y registra todas las operaciones de los usuarios a través de una plataforma de auditoría SQL.

La estructura de la tabla de la base de datos son los metadatos de la base de datos y la configuración de la función de mejora son los metadatos de Database Plus. DistSQL no solo mejora la facilidad de uso, sino que también completa el rompecabezas final para el lanzamiento, operación y mantenimiento de Apache ShardingSphere.

4. El modelo sin proxy contribuye a un rendimiento óptimo

En el campo de Service Mesh, Istio más Envoy es la arquitectura más extendida. Gestiona Envoy a través de la implementación de Sidecar sin interferir en las aplicaciones, proporcionando lo que se denomina Proxy Service Mesh. Reduce los costos de desarrollo, uso y actualización, pero su rendimiento se reduce debido a la adición de la capa Proxy/Sidecar en los enlaces de acceso.

Proxyless Service Mesh adopta otro modelo de diseño, que se deriva de la implementación del protocolo xDS por parte de gRPC. La nueva versión de Istio permite que el código de la aplicación pase directamente por el SDK proporcionado por Istio Agent a través de la programación gRPC plus xDS, mejorando notablemente la eficiencia de la comunicación.

En el campo de las bases de datos distribuidas, el diseño de la arquitectura de división almacenamiento/computación ha sido ampliamente aceptado. El diseño de dividir los nodos de cómputo y almacenamiento es algo similar al modelo arquitectónico de Proxy Service Mesh. ShardingSphere-Proxy también está diseñado con el modelo mencionado anteriormente. Puede reducir efectivamente los costos de desarrollo, uso y actualización para los usuarios, pero su rendimiento se reduce inevitablemente.

Para aplicaciones sensibles al rendimiento, ShardingSphere-JDBC, que coincide con el concepto de diseño de Proxyless Service Mesh, es sin duda más aplicable y se puede utilizar para maximizar el rendimiento del sistema. Una prueba de rendimiento reciente con 16 servidores del modelo TPC-C utilizando ShardingSphere más openGauss logró más , batiendo récords de rendimiento.

Resumen El concepto de diseño Proxyless de gRPC nació recientemente, mientras que el proyecto ShardingSphere-JDBC existe desde que comenzó el proyecto de código abierto en 2016. Por lo tanto, ShardingSphere-JDBC no se refirió al concepto de diseño de Proxyless. Nació en base a la demanda de empresas enfocadas en Internet de Asia, para un rendimiento máximo que incluye alta concurrencia y baja latencia.

Lo mismo ocurre con el diseño del concepto Database Plus, que surgió para resolver los cuellos de botella empresariales del mundo real. ShardingSphere es el mejor ejemplo de Database Plus, ya que su diseño se deriva de escenarios comerciales reales. La vertical china de Internet donde pasé la mayor parte de mi experiencia profesional es, sin duda, uno de los escenarios más completos del mundo. Por lo tanto, un concepto de diseño nacido en tales escenarios también debe tener un amplio espacio para el desarrollo.

Plan futuro

Aunque el concepto de Database Plus ha sido testigo de más y más iteraciones, Apache ShardingSphere todavía tiene un largo camino por recorrer. La puerta de enlace de la base de datos y la consulta federada heterogénea son las piezas funcionales importantes del rompecabezas para completar el concepto de Database Plus.

1. puerta de enlace de la base de datos

Aunque Apache ShardingSphere admite la interconexión de bases de datos heterogéneas, no puede lograr la conversión de dialectos entre bases de datos. En la planificación de rutas de ShardingSphere, la conversión de dialecto SQL es una función importante para lograr la puerta de enlace de la base de datos. Ya no es una tarea difícil para los usuarios acceder a MongoDB en dialecto MySQL a través del protocolo de base de datos de PostgreSQL.

2. Consulta federada heterogénea

Apache ShardingSphere actualmente solo admite consultas federadas entre bases de datos homogéneas. En la planificación de rutas de ShardingSphere, también se incluirá en la agenda la consulta federada entre bases de datos heterogéneas. Ya no estará muy lejos para los usuarios consultar MySQL y HBase con un solo SQL.

Conclusión

La comunidad ha estado activa en código abierto durante 7 años. A través de la perseverancia, la comunidad ha madurado. Nos gustaría extender nuestra más sincera bienvenida a cualquier desarrollador o colaborador que esté entusiasmado con el código abierto y la codificación para colaborar con nosotros. Entre nuestros logros recientes de los que estamos especialmente orgullosos, la arquitectura conectable y la filosofía de fragmentación de datos de Apache ShardingSphere han sido reconocidas por la comunidad académica. , se publicó en la ICDE de este año, una de las principales conferencias en el campo de las bases de datos.

El autor Zhang Liang, fundador y director ejecutivo de , se desempeñó como jefe del equipo de arquitectura y base de datos de muchas grandes empresas de Internet conocidas. Está entusiasmado con el código abierto y es el fundador y presidente de PMC de Apache ShardingSphere, y otros proyectos de código abierto conocidos.

Ahora es miembro de , , y y tiene más de 10 años de experiencia en el campo de la arquitectura y la base de datos. Aboga por un código elegante y ha logrado grandes logros en tecnología de bases de datos distribuidas e investigación académica. Se ha desempeñado como productor y orador en docenas de importantes cumbres tecnológicas y de la industria nacionales e internacionales, incluidas ApacheCon, QCon, AWS Summit, DTCC, SACC y DTC. Además, ha publicado el libro “Future Architecture: From Service to Cloud Native” así como el artículo “Apache ShardingSphere: A Holistic and Pluggable Platform for Data Sharding” publicado en la ICDE de este año, una de las principales conferencias en el campo de las bases de datos.