Apache ShardingSphere 元数据加载剖析

图片

 唐国城

小米软件工程师,主要负责 MIUI 浏览器服务端研发工作。热爱开源,热爱技术,喜欢探索,热衷于研究学习各种开源中间件,很高兴能参与到 ShardingSphere 社区建设中,希望在社区中努力提高自己,为 ShardingSphere 社区的发展做更多的工作。

元数据在 ShardingSphere 中加载的过程

一、概述

元数据是表示数据的数据。从数据库角度而言,则概括为数据库的任何数据都是元数据,因此如列名、数据库名、用户名、表名等以及数据自定义库表存储的关于数据库对象的信息都是元数据。而 ShardingSphere 中的核心功能如数据分片、加解密等都是需要基于数据库的元数据生成路由或者加密解密的列实现,由此可见元数据是 ShardingSphere 系统运行的核心,同样也是每一个数据存储相关中间件或者组件的核心数据。有了元数据的注入,相当于整个系统有了神经中枢,可以结合元数据完成对于库、表、列的个性化操作,如数据分片、数据加密、SQL 改写等。

而对于 ShardingSphere 元数据的加载过程,首先需要弄清楚在 ShardingSphere 中元数据的类型以及分级。在 ShardingSphere 中元数据主要围绕着 ShardingSphereMetaData 来进行展开,其中较为核心的是 ShardingSphereSchema。该结构是数据库的元数据,同时也为数据源元数据的顶层对象,在 ShardingSphere 中数据库元数据的结构如下图。对于每一层来说,上层数据来源于下层数据的组装,所以下面我们采用从下往上的分层方式进行逐一剖析。

图片

 ShardingSphere 数据库元数据结构图

二、ColumMetaData 和 IndexMetaData

ColumMetaData 和 IndexMetaData 是组成 TableMetaData 的基本元素,下面我们分开讲述两种元数据的结构以及加载过程。ColumMetaData 主要结构如下:

public final class ColumnMetaData {
    // 列名
    private final String name;
    // 数据类型
    private final int dataType;
    // 是否主键
    private final boolean primaryKey;
    // 是否自动生成
    private final boolean generated;
    // 是否区分大小写
    private final boolean caseSensitive;
}

其加载过程主要封装在 org.apache.shardingsphere.infra.metadata.schema.builder.loader.ColumnMetaDataLoader#load 方法中,主要过程是通过数据库链接获取元数据匹配表名加载某个表名下所有的列的元数据。核心代码如下:

/**
 * Load column meta data list.
 *
 * @param connection connection
 * @param tableNamePattern table name pattern
 * @param databaseType database type
 * @return column meta data list
 * @throws SQLException SQL exception
 */
public static Collection<ColumnMetaData> load(final Connection connection, final String tableNamePattern, final DatabaseType databaseType) throws SQLException {
    Collection<ColumnMetaData> result = new LinkedList<>();
    Collection<String> primaryKeys = loadPrimaryKeys(connection, tableNamePattern);
    List<String> columnNames = new ArrayList<>();
    List<Integer> columnTypes = new ArrayList<>();
    List<String> columnTypeNames = new ArrayList<>();
    List<Boolean> isPrimaryKeys = new ArrayList<>();
    List<Boolean> isCaseSensitives = new ArrayList<>();
    try (ResultSet resultSet = connection.getMetaData().getColumns(connection.getCatalog(), connection.getSchema(), tableNamePattern, "%")) {
        while (resultSet.next()) {
            String tableName = resultSet.getString(TABLE_NAME);
            if (Objects.equals(tableNamePattern, tableName)) {
                String columnName = resultSet.getString(COLUMN_NAME);
                columnTypes.add(resultSet.getInt(DATA_TYPE));
                columnTypeNames.add(resultSet.getString(TYPE_NAME));
                isPrimaryKeys.add(primaryKeys.contains(columnName));
                columnNames.add(columnName);
            }
        }
    }
    try (Statement statement = connection.createStatement(); ResultSet resultSet = statement.executeQuery(generateEmptyResultSQL(tableNamePattern, databaseType))) {
        for (int i = 0; i < columnNames.size(); i++) {
            isCaseSensitives.add(resultSet.getMetaData().isCaseSensitive(resultSet.findColumn(columnNames.get(i))));
            result.add(new ColumnMetaData(columnNames.get(i), columnTypes.get(i), isPrimaryKeys.get(i),
                    resultSet.getMetaData().isAutoIncrement(i + 1), isCaseSensitives.get(i)));
        }
    }
    return result;
}

IndexMetaData 其实是表中的索引的名称,所以没有复杂的结构属性,只有一个名称,所以不展开赘述,重点讲述一下加载过程。加载过程和 column 类似,主要流程在 org.apache.shardingsphere.infra.metadata.schema.builder.loader.IndexMetaDataLoader#load 方法中,基本流程同样也是通过数据库链接获取相关数据库和表的元数据中的 indexInfo 组织核心的 IndexMetaData,实现代码如下:

public static Collection<IndexMetaData> load(final Connection connection, final String table) throws SQLException {
    Collection<IndexMetaData> result = new HashSet<>();
    try (ResultSet resultSet = connection.getMetaData().getIndexInfo(connection.getCatalog(), connection.getSchema(), table, false, false)) {
        while (resultSet.next()) {
            String indexName = resultSet.getString(INDEX_NAME);
            if (null != indexName) {
                result.add(new IndexMetaData(indexName));
            }
        }
    } catch (final SQLException ex) {
        if (ORACLE_VIEW_NOT_APPROPRIATE_VENDOR_CODE != ex.getErrorCode()) {
            throw ex;
        }
    }
    return result;
}

三、TableMetaData

该类型是组成 ShardingSphereMetaData 的基本元素,其结构如下:

public final class TableMetaData {
    // 表名
    private final String name;
    // 列元数据
    private final Map<String, ColumnMetaData> columns;
    // 索引元数据
    private final Map<String, IndexMetaData> indexes;
    //省略一些方法
}

从上述结构可以看出,TableMetaData 其实是由 ColumnMetaData 和 IndexMetaData 组装而来,所以 TableMetaData 的加载过程可以理解为是一个中间层,具体的实现还是 ColumnMetaDataLoader 和 IndexMetaDataLoader 拿到表名以及相关链接进行数据加载。所以比较简单的 TableMetaData 加载过程主要在 org.apache.shardingsphere.infra.metadata.schema.builder.loader.TableMetaDataLoader#load 方法,其加载的核心流程如下:

public static Optional<TableMetaData> load(final DataSource dataSource, final String tableNamePattern, final DatabaseType databaseType) throws SQLException {
    // 获取链接
    try (MetaDataLoaderConnectionAdapter connectionAdapter = new MetaDataLoaderConnectionAdapter(databaseType, dataSource.getConnection())) {
        // 根据不同的数据库类型,格式化表名的模糊匹配字段
        String formattedTableNamePattern = databaseType.formatTableNamePattern(tableNamePattern);
        // 加载ColumnMetaData和IndexMetaData组装TableMetaData
        return isTableExist(connectionAdapter, formattedTableNamePattern)
                ? Optional.of(new TableMetaData(tableNamePattern, ColumnMetaDataLoader.load(
                        connectionAdapter, formattedTableNamePattern, databaseType), IndexMetaDataLoader.load(connectionAdapter, formattedTableNamePattern)))
                : Optional.empty();
    }
}

四、SchemaMetaData

经过下两层的分析,很明显这一层是元数据暴露的最外层,最外的层的结构为 ShardingSphereSchema,其主要结构为:

/**
 * ShardingSphere schema.
 */
@Getter
public final class ShardingSphereSchema {

    private final Map<String, TableMetaData> tables;

    @SuppressWarnings("CollectionWithoutInitialCapacity")
    public ShardingSphereSchema() {
        tables = new ConcurrentHashMap<>();
    }

    public ShardingSphereSchema(final Map<String, TableMetaData> tables) {
        this.tables = new ConcurrentHashMap<>(tables.size(), 1);
        tables.forEach((key, value) -> this.tables.put(key.toLowerCase(), value));
    }

和 schema 的概念契合,一个 schema 含有若干个表。ShardingSphereSchema 的属性是一个 map 结构,key 为 tableName,value 是表名对应表的元数据。主要是通过构造函数完成初始化。所以,还是重点对于表元数据的加载,下面我们从入口跟进。

整个元数据加载的核心入口在 org.apache.shardingsphere.infra.context.metadata.MetaDataContextsBuilder#build 中。在 build 中主要是通过配置的规则,组装和加载相对应的元数据,核心代码如下:

/**
 * Build meta data contexts.
 * 
 * @exception SQLException SQL exception
 * @return meta data contexts
 */
public StandardMetaDataContexts build() throws SQLException {
    Map<String, ShardingSphereMetaData> metaDataMap = new HashMap<>(schemaRuleConfigs.size(), 1);
    Map<String, ShardingSphereMetaData> actualMetaDataMap = new HashMap<>(schemaRuleConfigs.size(), 1);
    for (String each : schemaRuleConfigs.keySet()) {
        Map<String, DataSource> dataSourceMap = dataSources.get(each);
        Collection<RuleConfiguration> ruleConfigs = schemaRuleConfigs.get(each);
        DatabaseType databaseType = DatabaseTypeRecognizer.getDatabaseType(dataSourceMap.values());
        // 获取配置的规则
        Collection<ShardingSphereRule> rules = ShardingSphereRulesBuilder.buildSchemaRules(each, ruleConfigs, databaseType, dataSourceMap);
        // 加载actualTableMetaData和logicTableMetaData
        Map<TableMetaData, TableMetaData> tableMetaDatas = SchemaBuilder.build(new SchemaBuilderMaterials(databaseType, dataSourceMap, rules, props));
        // 组装规则元数据
        ShardingSphereRuleMetaData ruleMetaData = new ShardingSphereRuleMetaData(ruleConfigs, rules);
        // 组装数据源元数据
        ShardingSphereResource resource = buildResource(databaseType, dataSourceMap);
        // 组装数据库元数据
        ShardingSphereSchema actualSchema = new ShardingSphereSchema(tableMetaDatas.keySet().stream().filter(Objects::nonNull).collect(Collectors.toMap(TableMetaData::getName, v -> v)));
        actualMetaDataMap.put(each, new ShardingSphereMetaData(each, resource, ruleMetaData, actualSchema));
        metaDataMap.put(each, new ShardingSphereMetaData(each, resource, ruleMetaData, buildSchema(tableMetaDatas)));
    }
    // 
    OptimizeContextFactory optimizeContextFactory = new OptimizeContextFactory(actualMetaDataMap);
    return new StandardMetaDataContexts(metaDataMap, buildGlobalSchemaMetaData(metaDataMap), executorEngine, props, optimizeContextFactory);
}

通过上述代码可以看出在 build 方法中,主要基于配置的 schemarule 加载了数据库的基本数据如数据库类型、数据库连接池等,通过这些数据完成对于 ShardingSphereResource 的组装;完成 ShardingSphereRuleMetaData 如配置规则、加密规则、认证规则等数据组装;完成 ShardingSphereSchema 中的必要数据库元数据的加载。跟踪找到表元数据的加载方法即 org.apache.shardingsphere.infra.metadata.schema.builder.SchemaBuilder#build,在这个方法中,分别加载了 actualTableMetaData 以及 logicTableMetaData,那么什么是 actualTable,什么是 logicTable 呢?简单的来说对于 t_order_1、t_order_2 算是 t_order 的节点,所以在概念上来分析,t_order 是 logicTable,而 t_order_1 和 t_order_2 是 actualTable。明确了这两个概念后,我们再来一起看 build 方法,主要分为以下两步:

1. actualTableMetaData 加载

actualTableMetaData 是系统分片的基础表,在 5.0.0-beta 版本中,我们采用了数据库方言的方式利用 SQL 进行元数据的查询加载,所以基本流程就是首先通过通过 SQL 进行数据库元数据的查询加载,如果没找到数据库方言加载器,则采用 JDBC 驱动连接进行获取,再结合 ShardingSphereRule 中配置的表名,进行配置表的元数据的加载。核心代码如下所示:

private static Map<String, TableMetaData> buildActualTableMetaDataMap(final SchemaBuilderMaterials materials) throws SQLException {
    Map<String, TableMetaData> result = new HashMap<>(materials.getRules().size(), 1);
    // 数据库方言SQL加载元数据
    appendRemainTables(materials, result);
    for (ShardingSphereRule rule : materials.getRules()) {
        if (rule instanceof TableContainedRule) {
            for (String table : ((TableContainedRule) rule).getTables()) {
                if (!result.containsKey(table)) {
                    TableMetaDataBuilder.load(table, materials).map(optional -> result.put(table, optional));
                }
            }
        }
    }
    return result;
}

2. logicTableMetaData 加载

由上述的概念可以看出 logicTable 是 actualTable 基于不同的规则组装而来的实际的逻辑节点,可能是分片节点也可能是加密节点或者是其他,所以 logicTableMetaData 是以 actualTableMetaData 为基础,结合具体的配置规则如分库分表规则等关联的节点。在具体流程上,首先获取配置规则的表名,然后判断是否已经加载过 actualTableMetaData,通过 TableMetaDataBuilder#decorate 方法结合配置规则,生成相关逻辑节点的元数据。核心代码流程如下所示:

private static Map<String, TableMetaData> buildLogicTableMetaDataMap(final SchemaBuilderMaterials materials, final Map<String, TableMetaData> tables) throws SQLException {
    Map<String, TableMetaData> result = new HashMap<>(materials.getRules().size(), 1);
    for (ShardingSphereRule rule : materials.getRules()) {
        if (rule instanceof TableContainedRule) {
            for (String table : ((TableContainedRule) rule).getTables()) {
                if (tables.containsKey(table)) {
                    TableMetaData metaData = TableMetaDataBuilder.decorate(table, tables.get(table), materials.getRules());
                    result.put(table, metaData);
                }
            }
        }
    }
    return result;
}

至此,核心元数据加载完成,封装成一个 Map 进行返回,供各个需求场景进行使用。

元数据加载优化分析

虽然说元数据是我们系统的核心,是必不可少的,但是在系统启动时进行数据加载,必然会导致系统的负载增加,系统启动效率低。所以我们需要对加载的过程进行优化,目前主要是以下两方面的探索:

一、使用 SQL 查询替换原生 JDBC 驱动连接

在 5.0.0-beta 版本之前,采用的方式是通过原生 JDBC 驱动原生方式加载。在 5.0.0-beta 版本中,我们逐步采用了使用数据库方言,通过 SQL 查询的方式,多线程方式实现了元数据的加载。进一步提高了系统数据加载的速度。详细的方言 Loader 可以查看 org.apache.shardingsphere.infra.metadata.schema.builder.spi.DialectTableMetaDataLoader 的相关实现。

二、减少元数据的加载次数

对于系统通用的资源的加载,我们遵循一次加载,多处使用。当然在这个过程中,我们也要权衡空间和时间,所以我们在不断的进行优化,减少元数据的重复加载,提高系统整体的效率。

更多详细功能,欢迎下载使用 Apache ShardingSphere 5.0.0-beta。

欢迎大家扫码关注

欢迎关注我们

相关推荐

官宣|Apache ShardingSphere 5.0.0 正式发布

11 月 10 日,是 Apache ShardingSphere 进入 Apache 基金会的三周年纪念日。在这特殊的一天,我们很高兴的宣布 Apache ShardingSphere 迎来了 5.0.0 GA 版本的正式发布。经过近两年的优化和打磨,ShardingSphere 5.0.0 GA 版正式开启了以可插拔架构为核心的全新阶段,实现了由过去数据分片单一应用场景到现在复杂应用环境下综合数据治理的身份转变与能力提升。5.0.0 具体版本发布信息如下:1 新特性 支持注释解析 .

SphereEX的博客 733

SphereEx 获数百万美元天使融资,接力 ShardingSphere 开启 Database Plus 新篇章

5月14日,数据前沿技术领域初创公司 SphereEx 获得来自红杉中国种子基金、初心资本的数百万美元天使轮融资。SphereEx是一家致力于构建新型分布式数据基础设施的公司,秉承开源、共享、生态、平台理念,致力于数据领域前沿技术创新。其研发的分布式中间件ShardingSphere,具备“平台化、可插拔、云原生”等核心技术特点,是大规模数据应用、数据增值应用的理想解决方案。SphereEx的核心创始团队来自Apache顶级项目 ShardingSphere、头部互联网公司、及知名基础设施软件提供商。.

SphereEX的博客 644

DBPlusEngine 1.7.2 发布:数据安全闭环与联邦查询突破

ShardingSphere 原厂企业版,支撑企业核心系统安全治理与联邦查询升级。

SphereEX的博客 390

SphereEx-DBPlusEngine 1.5.0 功能解读:CDC

数据库日志(以 MySQL 为例) binlog 是 MySQL 记录变更数据的"二进制日志",它可以看做是一个消息队列,队列中按顺序保存了 MySQL 中详细的增量变更信息,通过消费队列中的变更条目,下游系统或工具实现了与 MySQL 的实时数据同步。前一段时间,面向新一代数据架构的数据库增强引擎 SphereEx-DBPlusEngine 正式发布 1.5.0 版本,新增 CDC 和数据库防火墙两大重磅功能,本篇文章笔者就给大家详细介绍 CDC 功能的实现逻辑和技术细节。使用网络通道的情况下需要。

SphereEX的博客 472

SphereEx-DBPlusEngine 1.5.0 版本发布

近日,面向新一代数据架构的数据库增强引擎 SphereEx-DBPlusEngine 正式发布 1.5.0 版本,新增 CDC 和数据库防火墙两大重磅功能,并在数据安全方面做了重要的增强。增加了对实时数据变更的捕获和管理能力,并增强了对数据访问的监控和拦截能力,帮助企业降低业务风险,提升效率。

SphereEX的博客 365

【版本更新】Apache ShardingSphere 5.4.0 版本正式发布!

SphereEX的博客 580

畅聊新版本!尽在本周六 ShardingSphere 线上圆桌会!

👏 欢迎大家「预约」直播,提前锁定精彩内容,与三位资深社区贡献者一起共究 ShardingSphere 5.4.0 与 ShardingSphere-On-Cloud 0.3.0 的技术魅力!😉 就在本周六(7 月 1 日), ShardingSphere 线上圆桌(第二期)栏目内容即将播出啦!👋 嗨~ ShardingSphere 社区的小伙伴们下午好!🤩 转载议程海报还能赢取「互动福利」!惊喜多多,详情见下方海报哦~👇 👇。

SphereEX的博客 203

围“桌”详谈|本周六直播,一起聊聊「发版」那些事儿!

🎉围“桌”详谈|本周六,来一起聊聊「发版」那些事儿!⏰7 月 1 日下午两点,我们邀请了 ShardingSphere PMC 端正强、ShardingSphere Committer 江龙滔、ShardingSphere Committer 苗立尧三位资深的社区贡献者做客「社区线上直播间」,将为大家详细解答新版本带来的重点功能更新及对应的性能突破!🌟 活动还设有「技术实战」、「有奖问答」等趣味环节,期待与大家一起解锁!

SphereEX的博客 244

倒计时 1 天 | SphereEx 在 2023 亚马逊云科技中国峰会等你来打卡!

📢倒计时 1 天 | SphereEx 即将亮相 2023 亚马逊云科技中国峰会!✨SphereEx 联合创始人 & CTO 潘娟 将在大会期间将向业界介绍如何充分发挥弹性伸缩、自动备份、容错处理等云计算的优势,提高分布式数据库的可靠性和性能。同时,也将分享在分布式数据库应用中安全性的重要性和实践方法,从多个方面保护数据的安全性。👏扫描下方二维码预约参观,通过二维码进行预约的小伙伴在上海展会现场可凭借手机号领取精美礼品一份!还可以在现场参与抽奖,更多好礼等你拿!

SphereEX的博客 300

倒计时2天,解锁亚马逊云科技中国峰会 Dev Lounge 玩法

在此次圆桌讨论中,ShardingSphere PMC & SphereEx 联合创始人兼 CTO 潘娟受邀与多位行业专家共同分享他们在利用开源进行数据分析和挖掘方面的研究成果、经验和启示。开发者们将有机会与专家面对面交流,同时了解最新的数据分析和挖掘技术洞察,掌握趋势和机遇。数据对于企业和个人来说都至关重要,而大数据和人工智能的不断发展,为各种应用场景带来了更多的机会。那么,如何利用开源分析和挖掘数据价值,成为了许多开发者关注的话题。海报二维码扫码报名,6月27-28日,我们上海等你,不见不散!

SphereEX的博客 281

逛开发者集市啦,ShardingSphere 在亚马逊云科技中国峰会等你!

2023亚马逊云科技中国峰会将于6月27日-28日在上海世博中心盛大开幕。本次峰会以“共见·价值成就”为主题,与合作伙伴展望云计算趋势及合作发展战略,分享行业解决方案,共同探讨协同销售策略和全新的 APN 计划,助力合作伙伴成就更多价值。同时,峰会将聚焦构建新技术加速的产品创新、新架构提升的业务弹性、云计算引领的创新模式,围绕价值加速实现,企业敏捷稳健,行业全新机遇等热门话题,携手众多业内技术领导者,践行者一同,把握时代机遇。本次峰会特设开发者会客厅区域,为开发者提供一站式等丰富体验。

SphereEX的博客 399

ShardingSphere 荣获一等奖!2022 年中国开源创新大赛成绩单公布

2022年中国开源创新大赛”在国家中央网信办信息化发展局的指导下,由中国互联网发展基金会、中国网络空间研究院、中国互联网投资基金联合主办,大赛以“开源创新,共建生态”为主题,围绕国家在开源人才培养和开源生态建设方面的重大战略需求,聚焦“卡脖子”相关技术领域,旨在助力开源生态的高质量发展,激发开源创新活力,推动我国科技创新及产业转型升级。5 月 31 日,“2022 年中国开源创新大赛”正式颁奖。

SphereEX的博客 309

创新能力加速产业发展,SphereEx 荣获“中关村银行杯”『大数据与云计算』领域 TOP1

SphereEx 凭借自身在数据库领域产品与理念的双重创新优势,荣获2022 中关村国际前沿科技创新大赛“中关村银行杯”『大数据与云计算』领域的第一名。

SphereEX的博客 348

Pisanix v0.2.0 发布|新增动态读写分离支持

Pisanix 于今天发布了 v0.2.0 版本,在此前版本基础上,本次更新新增了动态读写分离支持,下面将进行详细介绍。

SphereEX的博客 375

Database Plus 的云上之旅:SphereEx 正式开源 ShardingSphere on Cloud 解决方案

作为 Database Plus 设计哲学的最佳实践,Apache 顶级开源项目 ShardingSphere 通过各行业多年的生产环境检验,受到了众多社区爱好者的关注和追捧。而随着 Kubernetes 成为容器编排的事实标准,其引领的云原生风暴迅速席卷了技术世界。Apache ShardingSphere 作为一个拥有开放生态的数据库增强引擎,其设计理念和 Kubernetes 有着诸多相似之处,而在这股云原生浪潮之下,社区对 ShardingSphere 上云的呼声也越来越高,于是 **SphereE

SphereEX的博客 303

DistSQL 深度解析:打造动态化的分布式数据库

本文将以数据分片为例,深度解析 Sharding 相关 DistSQL 的应用场景和使用技巧。同时,通过实践案例将一系列 DistSQL 语句进行串联,为读者展现一套完整实用的 DistSQL 分片管理方案。

SphereEX的博客 409

Pisa-Proxy SQL 解析之 Lex & Yacc

在上篇文章《Pisa-Proxy 之 SQL 解析实践》中介绍了 Pisa-Proxy 的核心模块之一 SQL 解析器的相关内容。在 MySQL 和 PostgreSQL 中 SQL 解析是通过 Yacc 实现的,同样 Pisa- Proxy 的 SQL 解析器是由类似 Yacc 这样的工具实现的,所以本篇文章会围绕 SQL 解析器为大家介绍一些编译原理和 Lex & Yacc 的使用,同时也会为读者展示如何通过 Lex & Yacc 实现一个简单的 SQL 解析器。从而帮助大家更好地理解 Pisa-Pro

SphereEX的博客 993

终于可以一行代码也不用改了!ShardingSphere 原生驱动问世

ShardingSphere-JDBC 驱动的出现,使 ShardingSphere 的易用性获得了前所未有的加强

SphereEX的博客 827

开源者的自我修养|为 ShardingSphere 贡献了千万行代码的程序员,后来当了 CEO

浅谈开源人的17年成长路线,热爱才能坚持

SphereEX的博客 376

开源二三事|ShardingSphere 与 Database Mesh 之间不得不说的那些事

前段时间,以 Apache ShardingSphere 核心团队组建的创业公司 SphereEx,正式对外推出了 Database Mesh 2.0 概念以及与之相配套的开源产品 Pisanix,这引发了社区间对于 ShardingSphere 和 Database Mesh 的不少争论与思考。许多用户都很清楚,SphereEx 是由 Apache ShardingSphere 核心团队创立的。那么有部分用户就提出了疑问,既然已经有了 Apache ShardingSphere 这样一个如此成功的开源项目

SphereEX的博客 366

Pisa-Proxy 之 SQL 解析实践

本文将以 Pisa-Proxy 实践为例,为大家展现 Pisa-Proxy 中的 SQL 解析实现,遇到的问题及优化

SphereEX的博客 543

基于 ShardingSphere 的得物数据库中间件平台“彩虹桥”演进之路

得物与 ShardingSphere 的完美结合实践

SphereEX的博客 571

Apache ShardingSphere 5.1.2 发布|全新驱动 API + 云原生部署,打造高性能数据网关

此次更新带来 ShardingSphere 原生驱动、Helm Chart、SQL 翻译等全新功能,打造极具生产力的数据网关

SphereEX的博客 600

在 Pisa-Proxy 中,如何利用 Rust 实现 MySQL 代理

在 Database Mesh 中,Pisanix 是一套以数据库为中心的治理框架,为用户提供了诸多治理能力

SphereEX的博客 779

ShardingSphere 异构迁移最佳实践:将3.5亿量级的顾客系统 RTO 减少60倍

Apache ShardingSphere 助力当当 3.5 亿用户量级顾客系统重构,由 PHP+SQL Server 技术栈无缝转型为 Java+ShardingSphere+MySQL,性能、可用性及维护性均得到显著提升,是 ShardingSphere 异构迁移最佳实践。

SphereEX的博客 329

SphereEx 正式开源面向 Database Mesh 的解决方案 Pisanix

今天,SphereEx 正式对外推出了面向 Database Mesh 的开源解决方案-- Pisanix v0.1.0 版本。Pisanix 从设计之初就吸收了 Database Mesh 的核心思想:通过可编程实现高性能扩展,应对云上数据库治理挑战。这标志着 Database Mesh 不再停留于纸上,而成为了一个真正可以实现和落地的框架。.........

SphereEX的博客 523

做数据时代的加油站,ShardingSphere 为易车数据库架构演进提供新动力

做数据时代的加油站,ShardingSphere 为易车数据库架构演进提供新动力

SphereEX的博客 255

数据库治理的云原生之道 —— Database Mesh 2.0

本文将带领各位读者回顾 Database Mesh 诞生的背景,重新审视 Database Mesh 1.0 的价值,并为大家介绍 Database Mesh 2.0 的新概念、新思路和新特性,共同探讨 Database Mesh 的未来之路。

SphereEX的博客 508

ShardingSphere 在东南亚|与科技保险公司 Fuse 的技术融合

ShardingSphere 在东南亚|与科技保险公司 Fuse 的技术融合

SphereEX的博客 247

SphereEx 正式成为 CNCF 会员,持续完善云原生环境下的数据库基础设施

近日,SphereEx 正式成为全球知名开源组织 CNCF(云原生计算基金会,Cloud Native Computing Foundation)银牌会员。

SphereEX的博客 285
上一篇: ElasticJob 3.0.0:打造面向互联网生态和海量任务的分布式调度解决方案
下一篇: Apache ShardingSphere:由开源驱动的分布式数据库中间件生态
SphereEx
SphereEx 企业官方账号 企业官方账号
博客等级 码龄6年 69粉丝 137原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值