Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >HashMap的扩容机制—resize()「建议收藏」

HashMap的扩容机制—resize()「建议收藏」

作者头像
全栈程序员站长
发布于 2022-07-02 07:13:30
发布于 2022-07-02 07:13:30
31800
代码可运行
举报
运行总次数:0
代码可运行

大家好,又见面了,我是你们的朋友全栈君。

HashMap的扩容机制—resize()

什么时候扩容:当向容器添加元素的时候,会判断当前容器的元素个数,如果大于等于阈值(知道这个阈字怎么念吗?不念fa值,念yu值四声)—即当前数组的长度乘以加载因子的值的时候,就要自动扩容啦。

扩容(resize)就是重新计算容量,向HashMap对象里不停的添加元素,而HashMap对象内部的数组无法装载更多的元素时,对象就需要扩大数组的长度,以便能装入更多的元素。当然Java里的数组是无法自动扩容的,方法是使用一个新的数组代替已有的容量小的数组,就像我们用一个小桶装水,如果想装更多的水,就得换大水桶。

先看一下什么时候,resize();

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
/** 
 * HashMap 添加节点 
 * 
 * @param hash        当前key生成的hashcode 
 * @param key         要添加到 HashMap 的key 
 * @param value       要添加到 HashMap 的value 
 * @param bucketIndex 桶,也就是这个要添加 HashMap 里的这个数据对应到数组的位置下标 
 */  
void addEntry(int hash, K key, V value, int bucketIndex) {  
    //size:The number of key-value mappings contained in this map.  
    //threshold:The next size value at which to resize (capacity * load factor)  
    //数组扩容条件:1.已经存在的key-value mappings的个数大于等于阈值  
    //             2.底层数组的bucketIndex坐标处不等于null  
    if ((size >= threshold) && (null != table[bucketIndex])) {  
        resize(2 * table.length);//扩容之后,数组长度变了  
        hash = (null != key) ? hash(key) : 0;//为什么要再次计算一下hash值呢?  
        bucketIndex = indexFor(hash, table.length);//扩容之后,数组长度变了,在数组的下标跟数组长度有关,得重算。  
    }  
    createEntry(hash, key, value, bucketIndex);  
}  
  
/** 
 * 这地方就是链表出现的地方,有2种情况 
 * 1,原来的桶bucketIndex处是没值的,那么就不会有链表出来啦 
 * 2,原来这地方有值,那么根据Entry的构造函数,把新传进来的key-value mapping放在数组上,原来的就挂在这个新来的next属性上了 
 */  
void createEntry(int hash, K key, V value, int bucketIndex) {  
    HashMap.Entry<K, V> e = table[bucketIndex];  
    table[bucketIndex] = new HashMap.Entry<>(hash, key, value, e);  
    size++;  
}

我们分析下resize的源码,鉴于JDK1.8融入了红黑树,较复杂,为了便于理解我们仍然使用JDK1.7的代码,好理解一些,本质上区别不大,具体区别后文再说。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
    void resize(int newCapacity) {   //传入新的容量
        Entry[] oldTable = table;    //引用扩容前的Entry数组
        int oldCapacity = oldTable.length;
        if (oldCapacity == MAXIMUM_CAPACITY) {  //扩容前的数组大小如果已经达到最大(2^30)了
            threshold = Integer.MAX_VALUE; //修改阈值为int的最大值(2^31-1),这样以后就不会扩容了
            return;
        }
 
        Entry[] newTable = new Entry[newCapacity];  //初始化一个新的Entry数组
        transfer(newTable);                         //!!将数据转移到新的Entry数组里
        table = newTable;                           //HashMap的table属性引用新的Entry数组
        threshold = (int) (newCapacity * loadFactor);//修改阈值
    }

这里就是使用一个容量更大的数组来代替已有的容量小的数组,transfer()方法将原有Entry数组的元素拷贝到新的Entry数组里。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
    void transfer(Entry[] newTable) {
        Entry[] src = table;                   //src引用了旧的Entry数组
        int newCapacity = newTable.length;
        for (int j = 0; j < src.length; j++) { //遍历旧的Entry数组
            Entry<K, V> e = src[j];             //取得旧Entry数组的每个元素
            if (e != null) {
                src[j] = null;//释放旧Entry数组的对象引用(for循环后,旧的Entry数组不再引用任何对象)
                do {
                    Entry<K, V> next = e.next;
                    int i = indexFor(e.hash, newCapacity); //!!重新计算每个元素在数组中的位置
                    e.next = newTable[i]; //标记[1]
                    newTable[i] = e;      //将元素放在数组上
                    e = next;             //访问下一个Entry链上的元素
                } while (e != null);
            }
        }
    }
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
    static int indexFor(int h, int length) {
        return h & (length - 1);
    }

newTable[i]的引用赋给了e.next,也就是使用了单链表的头插入方式,同一位置上新元素总会被放在链表的头部位置;这样先放在一个索引上的元素终会被放到Entry链的尾部(如果发生了hash冲突的话),这一点和Jdk1.8有区别,下文详解。在旧数组中同一条Entry链上的元素,通过重新计算索引位置后,有可能被放到了新数组的不同位置上。

从上面的for循环内部开始说起吧:详细解释下,这个转存的过程。和怎么个头插入法. Entry<K, V> e = src[j]; 这句话,就把原来数组上的那个链表的引用就给接手了,所以下面src[j] = null;可以放心大胆的置空,释放空间。告诉gc这个地方可以回收啦。 继续到do while 循环里面, Entry<K, V> next = e.next; int i = indexFor(e.hash, newCapacity);计算出元素在新数组中的位置 下面就是单链表的头插入方式转存元素啦

关于这个 单链表的头插入方式 的理解,我多说两句。 这地方我再看的时候,就有点蒙了,他到底怎么在插到新的数组里面的? 要是在插入新数组的时候,也出现了一个数组下标的位置处,出现了多个节点的话,那又是怎么插入的呢? 1,假设现在刚刚插入到新数组上,因为是对象数组,数组都是要默认有初始值的,那么这个数组的初始值都是null。不信的可以新建个Javabean数组测试下。 那么e.next = newTable[i],也就是e.next = null啦。然后再newTable[i] = e;也就是 说这个时候,这个数组的这个下标位置的值设置成这个e啦。 2,假设这个时候,继续上面的循环,又取第二个数据e2的时候,恰好他的下标和刚刚上面的那个下标相同啦,那么这个时候,是又要有链表产生啦、 e.next = newTable[i];,假设上面第一次存的叫e1吧,那么现在e.next = newTable[i];也就是e.next = e1; 然后再,newTable[i] = e;,把这个后来的赋值在数组下标为i的位置,当然他们两个的位置是相同的啦。然后注意现在的e,我们叫e2吧。e2.next指向的是刚刚的e1,e1的next是null。 这就解释啦:先放在一个索引上的元素终会被放到Entry链的尾部。这句话。

关于什么时候resize()的说明:

看1.7的源码上说的条件是: if ((size >= threshold) && (null != table[bucketIndex])) {。。。} 其中 size表示当前hashmap里面已经包含的元素的个数。 threshold:threshold = (int) Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1); 一般是容量值X加载因子。 而1.8的是: if (++size > threshold){} 其中 size:The number of key-value mappings contained in this map.和上面的是一样的 threshold:newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY); 也是一样的, 最后总结一下:就是这个map里面包含的元素,也就是size的值,大于等于这个阈值的时候,才会resize(); 具体到实际情况就是:假设现在阈值是4;在添加下一个假设是第5个元素的时候,这个时候的size还是原来的,还没加1,size=4,那么阈值也是4的时候, 当执行put方法,添加第5个的时候,这个时候,4 >= 4。元素个数等于阈值。就要resize()啦。添加第4的时候,还是3 >= 4不成立,不需要resize()。 经过这番解释,可以发现下面的这个例子,不应该是在添加第二个的时候resize(),而是在添加第三个的时候,才resize()的。 这个也是我后来再细看的时候,发现的。当然,这个咱可以先忽略,重点看如何resize(),以及如何将旧数据移动到新数组的

下面举个例子说明下扩容过程。

这句话是重点—-hash(){return key % table.length;}方法,就是翻译下面的一行解释:

假设了我们的hash算法就是简单的用key mod 一下表的大小(也就是数组的长度)。

其中的哈希桶数组table的size=2, 所以key = 3、7、5,put顺序依次为 5、7、3。在mod 2以后都冲突在table[1]这里了。这里假设负载因子 loadFactor=1,即当键值对的实际大小size 大于 table的实际大小时进行扩容。接下来的三个步骤是哈希桶数组 resize成4,然后所有的Node重新rehash的过程。

下面我们讲解下JDK1.8做了哪些优化。经过观测可以发现,我们使用的是2次幂的扩展(指长度扩为原来2倍),所以,

经过rehash之后,元素的位置要么是在原位置,要么是在原位置再移动2次幂的位置。对应的就是下方的resize的注释。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
/** 
 * Initializes or doubles table size.  If null, allocates in 
 * accord with initial capacity target held in field threshold. 
 * Otherwise, because we are using power-of-two expansion, the 
 * elements from each bin must either stay at same index, or move 
 * with a power of two offset in the new table. 
 * 
 * @return the table 
 */  
final Node<K,V>[] resize() {  }

看下图可以明白这句话的意思,n为table的长度,图(a)表示扩容前的key1和key2两种key确定索引位置的示例,图(b)表示扩容后key1和key2两种key确定索引位置的示例,其中hash1是key1对应的哈希值(也就是根据key1算出来的hashcode值)与高位与运算的结果。

元素在重新计算hash之后,因为n变为2倍,那么n-1的mask范围在高位多1bit(红色),因此新的index就会发生这样的变化:

因此,我们在扩充HashMap的时候,不需要像JDK1.7的实现那样重新计算hash,只需要看看原来的hash值新增的那个bit是1还是0就好了,是0的话索引没变,是1的话索引变成“原索引+oldCap”,可以看看下图为16扩充为32的resize示意图:

这个设计确实非常的巧妙,既省去了重新计算hash值的时间,而且同时,由于新增的1bit是0还是1可以认为是随机的,因此resize的过程,均匀的把之前的冲突的节点分散到新的bucket了。这一块就是JDK1.8新增的优化点。有一点注意区别,JDK1.7中rehash的时候,旧链表迁移新链表的时候,如果在新表的数组索引位置相同,则链表元素会倒置,但是从上图可以看出,JDK1.8不会倒置。有兴趣的同学可以研究下JDK1.8的resize源码,写的很赞,如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
final Node<K,V>[] resize() {
    Node<K,V>[] oldTab = table;
    int oldCap = (oldTab == null) ? 0 : oldTab.length;
    int oldThr = threshold;
    int newCap, newThr = 0;
    if (oldCap > 0) {
        // 超过最大值就不再扩充了,就只好随你碰撞去吧
        if (oldCap >= MAXIMUM_CAPACITY) {
            threshold = Integer.MAX_VALUE;
            return oldTab;
        }
        // 没超过最大值,就扩充为原来的2倍
        else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                  oldCap >= DEFAULT_INITIAL_CAPACITY)
             newThr = oldThr << 1; // double threshold
     }
     else if (oldThr > 0) // initial capacity was placed in threshold
         newCap = oldThr;
     else {               // zero initial threshold signifies using defaults
         newCap = DEFAULT_INITIAL_CAPACITY;
         newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
     }
     // 计算新的resize上限
     if (newThr == 0) {
 
         float ft = (float)newCap * loadFactor;
         newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                   (int)ft : Integer.MAX_VALUE);
     }
     threshold = newThr;
     @SuppressWarnings({"rawtypes""unchecked"})
         Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
    table = newTab;
    if (oldTab != null) {
        // 把每个bucket都移动到新的buckets中
        for (int j = 0; j < oldCap; ++j) {
            Node<K,V> e;
            if ((e = oldTab[j]) != null) {
                oldTab[j] = null;
                if (e.next == null)
                    newTab[e.hash & (newCap - 1)] = e;
                else if (e instanceof TreeNode) //如果是红黑树节点
                    ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                else { // 链表优化重hash的代码块
                    Node<K,V> loHead = null, loTail = null;
                    Node<K,V> hiHead = null, hiTail = null;
                    Node<K,V> next;
                    do {
                        next = e.next;
                        // 原索引
                        if ((e.hash & oldCap) == 0) {
                            if (loTail == null)
                                loHead = e;
                            else
                                loTail.next = e;
                            loTail = e;
                        }
                        // 原索引+oldCap
                        else {
                            if (hiTail == null)
                                hiHead = e;
                            else
                                hiTail.next = e;
                            hiTail = e;
                        }
                    } while ((e = next) != null);
                    // 原索引放到bucket里
                    if (loTail != null) {
                        loTail.next = null;
                        newTab[j] = loHead;
                    }
                    // 原索引+oldCap放到bucket里
                    if (hiTail != null) {
                        hiTail.next = null;
                        newTab[j + oldCap] = hiHead;
                    }
                }
            }
        }
    }
    return newTab;
}

先略过红黑树的情况,描述下简单流程,在JDK1.8中发生hashmap扩容时,遍历hashmap每个bucket里的链表,每个链表可能会被拆分成两个链表,不需要移动的元素置入loHead为首的链表,需要移动的元素置入hiHead为首的链表,然后分别分配给老的buket和新的buket。

补充一下jdk 1.8中,HashMap扩容时红黑树的表现

扩容时,如果节点是红黑树节点,就会调用TreeNode的split方法对当前节点作为跟节点的红黑树进行修剪

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
...
else if (e instanceof TreeNode) //如果是红黑树节点
                    ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
...
代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
    //参数介绍
    //tab 表示保存桶头结点的哈希表
    //index 表示从哪个位置开始修剪
    //bit 要修剪的位数(哈希值)
    final void split(HashMap<K,V> map, Node<K,V>[] tab, int index, int bit) {
        TreeNode&lt;K,V&gt; b = this;
        // Relink into lo and hi lists, preserving order
        TreeNode<K,V> loHead = null, loTail = null;
        TreeNode<K,V> hiHead = null, hiTail = null;
        int lc = 0, hc = 0;
        for (TreeNode<K,V> e = b, next; e != null; e = next) {
            next = (TreeNode<K,V>)e.next;
            e.next = null;
            //如果当前节点哈希值的最后一位等于要修剪的 bit 值
            if ((e.hash &amp; bit) == 0) {
                    //就把当前节点放到 lXXX 树中
                if ((e.prev = loTail) == null)
                    loHead = e;
                else
                    loTail.next = e;
                //然后 loTail 记录 e
                loTail = e;
                //记录 lXXX 树的节点数量
                ++lc;
            }
            else {  //如果当前节点哈希值最后一位不是要修剪的
                    //就把当前节点放到 hXXX 树中
                if ((e.prev = hiTail) == null)
                    hiHead = e;
                else
                    hiTail.next = e;
                hiTail = e;
                //记录 hXXX 树的节点数量
                ++hc;
            }
        }


        if (loHead != null) {
            //如果 lXXX 树的数量小于 6,就把 lXXX 树的枝枝叶叶都置为空,变成一个单节点
            //然后让这个桶中,要还原索引位置开始往后的结点都变成还原成链表的 lXXX 节点
            //这一段元素以后就是一个链表结构
            if (lc <= UNTREEIFY_THRESHOLD)
                tab[index] = loHead.untreeify(map);
            else {
            //否则让索引位置的结点指向 lXXX 树,这个树被修剪过,元素少了
                tab[index] = loHead;
                if (hiHead != null) // (else is already treeified)
                    loHead.treeify(tab);
            }
        }
        if (hiHead != null) {
            //同理,让 指定位置 index + bit 之后的元素
            //指向 hXXX 还原成链表或者修剪过的树
            if (hc <= UNTREEIFY_THRESHOLD)
                tab[index + bit] = hiHead.untreeify(map);
            else {
                tab[index + bit] = hiHead;
                if (loHead != null)
                    hiHead.treeify(tab);
            }
        }
    }

从上述代码可以看到,HashMap 扩容时对红黑树节点的修剪主要分两部分,先分类、再根据元素个数决定是还原成链表还是精简一下元素仍保留红黑树结构。

1.分类

指定位置、指定范围,让指定位置中的元素 (hash & bit) == 0 的,放到 lXXX 树中,不相等的放到 hXXX 树中。

2.根据元素个数决定处理情况

符合要求的元素(即 lXXX 树),在元素个数小于等于 6 时还原成链表,最后让哈希表中修剪的痛 tab[index] 指向 lXXX 树;在元素个数大于 6 时,还是用红黑树,只不过是修剪了下枝叶;

不符合要求的元素(即 hXXX 树)也是一样的操作,只不过最后它是放在了修剪范围外 tab[index + bit]。

小结

(1) 扩容是一个特别耗性能的操作,所以当程序员在使用HashMap的时候,估算map的大小,初始化的时候给一个大致的数值,避免map进行频繁的扩容。

(2) 负载因子是可以修改的,也可以大于1,但是建议不要轻易修改,除非情况非常特殊。

(3) HashMap是线程不安全的,不要在并发的环境中同时操作HashMap,建议使用ConcurrentHashMap。

(4) JDK1.8引入红黑树大程度优化了HashMap的性能。

(5) 还没升级JDK1.8的,现在开始升级吧。HashMap的性能提升仅仅是JDK1.8的冰山一角。

发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/148261.html原文链接:https://javaforall.cn

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
腾讯私有云MySQL解决方案—TDSQL
TDSQL是腾讯提供的一套完整的MySQL数据库集群化管理解决方案,作为私有云TStack平台重要的数据库产品能力,旨在解决高可用、高性能、分布式、配套设施等方面问题。 TDSQL除了在腾讯内部有大量的使用场景,在外部市场中也有诸多应用场景;2014年被WeBank选中,作为其核心交易系统的数据库解决方案,以私有云方式交付;2015年,在腾讯云上正式推出。目前已经为500+机构提供数据库的公有云及专有云服务,客户覆盖计费、第三方支付、银行、保险、互联网金融、物联网、互联网+、政务等领域。 TDSQL私有云版
腾讯云TStack
2018/03/21
7.2K0
腾讯私有云MySQL解决方案—TDSQL
「TEG+系列」破局者 - 腾讯金融级数据库TDSQL
一 背景 金融行业的数据库市场,尤其是银行的核心交易系统,一直是Oracle、DB2这类传统商业数据库的天下,但是: 2014年,微众银行选用TDSQL作为其核心交易系统的数据库解决方案; 2015年,腾讯金融云正式推出TDSQL数据库解决方案,在公有云以及私有云上投入商用,覆盖包括银行、保险、互联网金融、物联网等多个行业领域。 这标志着TDSQL已经开始进入这个领域,虽然目前,金融、传统行业的核心数据库依然是Oracle、DB2们占主导,但是TDSQL对外开放仅两年,已经为40个金融政企机构提供数
TEG云端专业号
2018/03/13
1.6K0
「TEG+系列」破局者 - 腾讯金融级数据库TDSQL
TDSQL在微众银行的大规模实践之路
2014年:基于分布式的基础架构 微众银行在2014年成立之时,就非常有前瞻性的确立了微众银行的IT基础架构的方向:摒弃传统的基于商业IT产品的集中架构模式,走互联网模式的分布式架构。众所周知,传统银行IT架构体系非常依赖于传统的商业数据库,商业存储以及大中型服务器设备,每年也需要巨大的IT费用去维护和升级,同时这种集中式的架构,也不便于进行高效的实现水平扩展。从过往经验来看,当时除了oracle等少数传统的商业数据库,能满足金融级银行场景的数据库产品并不多。当时腾讯有一款金融级的分布式数据库产品TD
腾讯技术工程官方号
2019/08/20
1.5K0
TDSQL在微众银行的大规模实践之路
都说30而已,30后的技术人怎么走?
| 作者:杨壮壮 ,腾讯PCG运营开发工程师 ,目前主要从事 MDB(MySQL 云管平台)的后台开发与技术运营的工作,是一个做开发的DBA。熟悉腾讯自研数据库TDSQL的架构原理、集群管理维护、内核SQL优化等。MDB团队承载着整个PCG 关系型数据库的管理与运维工作,支撑着腾讯视频、看点等业务稳定运行。 1 Part1 前言 在今年的三月份,我们举办过一届数据库武林大会,在这场活动沙龙中,有辩手犀利地指出,数据库运维的薪资水平和数据库使用人数并不成正比,有数据表明一些小众但强大的数据库,其DBA的平均
腾讯云数据库 TencentDB
2020/08/19
7630
亿级客户和PB级数据规模的金融级数据库实战历程
点击▲关注 腾讯云数据库 | 导语 微众银行在2014年成立之时,就非常有前瞻性的确立了分布式架构的基础架构。当时,腾讯有一款金融级的分布式数据库产品TDSQL,其业务场景和对数据库的可靠性要求,和银行场景非常类似。微众银行和腾讯TDSQL团队合作,共同将TDSQL打造为适合银行核心场景使用的金融级分布式数据库产品,并将TDSQL用于微众银行的核心系统数据库。本文是对整个实践历程的总结。 一、背景介绍 微众银行在2014年成立之时,就非常有前瞻性的确立了微众银行的IT基础架构的方向:摒弃传统的基于商业IT
腾讯云数据库 TencentDB
2019/08/17
2.2K0
亿级客户和PB级数据规模的金融级数据库实战历程
腾讯云为金融换“心“
如果说核心系统是金融机构业务系统的“心脏”,那么数据库则是“心脏”的“心脏”,业务数据就像流淌在业务系统中的“血液”,拥有一颗健壮的“心脏”是系统高效处理业务和维持正常运转的必备条件。由于金融级数据库技术的高度复杂性,国内金融机构的核心系统长期依赖国外商用数据库产品,金融机构不但无法自主掌控核心系统的“心脏”,而且还需要长期投入高昂的软硬件成本,同时互联网业务的爆发性增长也导致“心脏”压力骤增,成本呈指数级增加。因此,如何实现金融级数据库的自主可控和降本增效,为核心系统平稳换“心”,成为金融行业关注的焦点
腾讯云数据库 TencentDB
2020/06/22
3.5K0
图说TDSQL | 下一个十年的金融业务场景,腾讯怎么做?
随着互联网的不断发展和逐渐普及,各行各业也纷纷选择了上云之路,腾讯云数据库致力于运用领先技术,助力企业上云,腾讯云自研的金融级分布式数据库TDSQL 是一款具备强一致高可用、全球部署架构、分布式水平扩展、高性能、企业级安全等特性的数据库产品,《图说TDSQL》栏目将以图文结合的形式,带大家了解TDSQL的方方面面。
腾讯云数据库 TencentDB
2020/03/19
9940
TDSQL在巴黎ICDE上设立展台,掌声送给它!
导读:TDSQL腾讯金融级分布式数据库,是由腾讯技术工程事业群计费平台部针对OLTP场景开发的高一致性数据库产品。ICDE,即International Conference on DataEngineering,由美国电气及电子工程师学会IEEE发起并组织,是与SIGMOD,VLDB并列的三大数据库领域的顶级会议之一。由腾讯技术工程事业群计费与高校关系的TDSQL在Salle des Textiles大厅设立的展台,吸引了包括图灵奖获得者Michael StoneBraker教授在内的行业人士驻足围观,获
腾讯技术工程官方号
2018/05/11
9340
腾讯成联合国全球合作伙伴,TDSQL如何支撑史上最大规模全球会议
受全球疫情影响,联合国75周年的数千场活动将搬到线上进行,在腾讯会议和企业微信上展开。
分布式数据库TDSQL
2020/03/31
3.7K0
腾讯成联合国全球合作伙伴,TDSQL如何支撑史上最大规模全球会议
TDSQL亮相国际数据库顶级会议ICDE
导读:TDSQL腾讯金融级分布式数据库,是由腾讯技术工程事业群计费平台部针对OLTP场景开发的高一致性数据库产品。ICDE,即International Conference on DataEngineering,由美国电气及电子工程师学会IEEE发起并组织,是与SIGMOD,VLDB并列的三大数据库领域的顶级会议之一。由腾讯技术工程事业群计费平台部和腾讯高校合作团队合作在巴黎ICDE2018上设立的TDSQL展台,吸引了包括图灵奖获得者Michael StoneBraker教授在内的行业人士驻足交流。 2
腾讯高校合作
2018/06/04
6970
解密Midas、Webank、金融云背后的核心数据库TDSQL【海量服务之道2.0】
如果,你在寻找一款数据库,希望: •在任何情况下,数据都不丢失或错乱; •能7*24小时不间断的对外提供服务,即使故障也不会中断; •能支撑业务量10倍以上的弹性伸缩,不用担心会被压垮; •能快速响应请求,为用户提供最爽的体验; •没学习门槛,能快速上手; •便宜,少花点钱; 那么,TDSQL就是你的菜! TDSQL(Tencent Distributed mySQL-腾讯分布式MySQL)是由腾讯技术工程事业群计费平台部针对金融联机交易场景开发的高一致性数据库集群产品。其底层基于MySQL,针对金融OLT
腾讯大讲堂
2018/02/12
1.2K0
解密Midas、Webank、金融云背后的核心数据库TDSQL【海量服务之道2.0】
微众银行数据库架构编年史
微众银行在成立之初,IT基础建设就没有选择传统的IOE集中式架构路线,转而选择采用了基于单元化的分布式架构。在这种大的背景下,微众银行的数据库的架构演进,也是
marsz
2024/12/25
2430
连载 | 深入浅出理解云数据库,年薪百万DBA之路 · 第三回
为帮助开发者更好的了解和运用数据库,腾讯云数据库团队特出品《深入浅出理解云数据库》系列文章,从数据库的基本概念到云数据库特性及应用,从数据库基础原理知识到腾讯云经典实战案例解读,带你走进云数据库的世界。关注“腾讯云数据库”微信公众号,开启2020年的DB修炼之旅。 第一回请点击:数据库的基本概念和云数据库特性 第二回请点击:云数据库的市场应用及基础原理知识 1 PartⅠ 腾讯云数据库产品总览 接下来的章节中我们以腾讯云数据库为例,来详细解读云数据库的功能和特性等。 首先来让我们用一张表来看清楚腾讯
腾讯云数据库 TencentDB
2020/02/14
1.6K0
连载 | 深入浅出理解云数据库,年薪百万DBA之路 · 第三回
客户心声|福建海峡银行TDSQL国产分布式数据库应用实践
数据库选型一直是困扰客户的难题,不仅要考虑底层的数据库技术,还需要结合企业业务特点、企业未来规划做决策。如何快速掌握数据库选型秘诀呢?答案无疑是看市场怎么做,看市场的同行是如何选择的。 近期,腾讯云数据库TDSQL助力福建海峡银行新一代核心业务系统正式上线(点击查看详情),为城商行提供核心改造解决方案。新核心关键业务系统采用“微服务+分布式”架构,改造历时14个月,依托腾讯云企业级分布式数据库TDSQL良好的兼容性、成熟的迁移能力和技术服务支持,海峡银行快速完成了核心系统的国产数据库替换,并基于腾讯云数据库
腾讯云数据库 TencentDB
2022/07/19
2.4K0
客户心声|福建海峡银行TDSQL国产分布式数据库应用实践
腾讯分布式数据库TDSQL金融级能力的架构原理解读
为帮助开发者更好地了解和学习分布式数据库技术,2020年3月,腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出为期3个月的国产数据库专题线上技术沙龙《你想了解的国产数据库秘密,都在这!》,邀请数十位鹅厂资深数据库专家每周二和周四晚上在线深入解读TDSQL、CynosDB/CDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践等。三月为TDSQL专题月,本文将带来直播回顾第一篇《腾讯自研分布式数据库TDSQL核心架构及特性拆解》。
分布式数据库TDSQL
2020/03/18
6.7K0
腾讯分布式数据库TDSQL金融级能力的架构原理解读
NewSQL 在微众银行核心批量场景的应用
本文由微众银行数据库负责人胡盼盼撰写,介绍了微众银行自 2014 年以来从传统 RDBMS 到 NewSQL 的架构演进,以及 TiDB 在微众银行核心批量场景的应用。
PingCAP
2021/11/10
7270
破解分布式数据库的高可用难题:TDSQL高可用方案实现
腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中,3月12日张文的分享已经结束,没来得及参与的小伙伴不用担心,以下就是直播的视频和文字回顾。
腾讯云数据库 TencentDB
2020/03/25
3.8K0
腾讯云数据库,双料第一!
刚刚,IDC发布报告《中国金融行业分布式事务型数据库市场份额,2023:技术验证结束,迎接高速增长》:
小腾资讯君
2024/07/18
2430
一杯咖啡时间完成部署!TDSQL全球灵活部署实践
腾讯云数据库国产数据库专题线上技术沙龙已圆满结束,本期带来毕汉斌分享的《从0到1搭建一个高可用的TDSQL集群》直播视频和文字回顾。 关注“腾讯云数据库”公众号,回复“0331毕汉斌”,即可下载直播分享PPT。 1 前言 为帮助开发者更好地了解和学习分布式数据库技术,2020年3月-5月,腾讯云数据库、云加社区联合腾讯TEG数据库工作组特推出国产数据库专题线上技术沙龙,邀请数十位鹅厂资深数据库专家在线深入解读TDSQL、CDB/CynosDB、TBase三款鹅厂自研数据库的核心架构、技术实现原理和最佳实践
腾讯云数据库 TencentDB
2020/06/24
9440
一文带你了解TDSQL的这一面
随着互联网时代的到来,企业的在线业务量也随之骤增,海量的数据访问和存储压力已经触达了传统集中式数据库的能力边界,无法为客户带来更快更稳定的业务性能。同时,无论是国家层面还是企业层面,对数据库技术自主可控的要求也更加迫切,特别是企业数据库业务层面存在以下三个痛点: 业务迁移费时费力 改造难:与原数据库数据和语法兼容性不足,导致用户需要对原有业务系统进行大量改造。 扩容难:为满足业务的快速增长带来的业务的计算与存储需求,用户需要对原有业务进行扩容。传统的数据库扩容代价大,需要中断业务数据搬迁等才能完成扩容操作。
腾讯云数据库 TencentDB
2023/01/18
1.1K0
一文带你了解TDSQL的这一面
推荐阅读
相关推荐
腾讯私有云MySQL解决方案—TDSQL
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
本文部分代码块支持一键运行,欢迎体验
本文部分代码块支持一键运行,欢迎体验