暂无个人介绍
看使用场景,如果本地测试可以用修改 hosts 文件的方式,如果是内部网络可以自建DNS服务器。在公网上则不支持,否则访问都能劫持了。
根据鸽笼原理,理论上是可能的,只是要找出这样一对相同的非常非常困难
不续费就被释放了,释放本身没有费用
可以基于OSS产品
E-MapReduce 基于开源生态,包括 Hadoop、Spark、Kafka、Flink、Storm等组件
微服务就是分布式的。dubbo可以用作服务间的RPC调用,除此之外服务间还可以通过RocketMQ进行异步通信。
目前Istio为代表的Service Mesh是一个很热的发展方向,也是CNCF对云原生的定义的核心技术之一,https://www.infoq.cn/article/DtxylyFwlyl7K5Jte*WI 一文有比较全面的分析。
作为企业,技术选型时肯定要考虑技术的成熟度,现有的SDK集成方式(Spring Cloud)仍然是主流且被证明过的。CNCF推动了一个产品的生态,但应用框架一直是spring的强项,如果两者发展都好,个人推测将来融合可能性比较大。
索引
索引是提高数据库表访问速度的方法。
分为聚集索引和非聚集索引。
聚集索引:对正文内容按照一定规则排序的目录。
非聚集索引:目录按照一定的顺序排列,正文按照另一种顺序排列,目录与正文之间保持一种映射关系。
把数据库索引比作字典查询索引,
聚集索引就是按照拼音查找,拼音栏中字的顺序就是查找得到的字的顺序。
非聚集索引就像按照偏旁部首查找,同是单人旁查到的字所在的页码可能是杂乱的,没有顺序的。
存储结构
内存中存储的数据是有限的,当需要在磁盘中进行查找时就涉及到了磁盘的 I/O 操作。
当磁盘驱动器执行读/写功能时。盘片装在一个主轴上,并绕主轴高速旋转,当磁道在读/写头(又叫磁头) 下通过时,就可以进行数据的读 / 写了。磁盘读取数据是以盘块(block)为基本单位的。位于同一盘块中的所有数据都能被一次性全部读取出来。而磁盘IO代价主要花费在查找时间Ts上。因此我们应该尽量将相关信息存放在同一盘块,同一磁道中。或者至少放在同一柱面或相邻柱面上,以求在读/写信息时尽量减少磁头来回移动的次数,避免过多的查找时间。
索引查找时产生磁盘I/O消耗,相对于内存存取,I/O存取的消耗要高几个数量级,所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘I/O操作次数的时间复杂度。树高度越小,I/O次数越少。
平衡树的高度过深进行多次磁盘IO,导致查询效率低下,而B树和B+树树中每个结点最多含有m个孩子,所以相对平衡树B树和B+树的高度比较低。
B树
每个节点都存储key和data,所有节点组成这棵树,并且叶子节点指针为null。
B+树
只有叶子节点存储data,叶子节点包含了这棵树的所有键值,叶子节点不存储指针。所有非终端节点看成是索引,节点中仅含有其子树根节点最大(或最小)的关键字,不包含查找的有效信息。B+树中所有叶子节点都是通过指针连接在一起。
总结:为什么使用B+树?
1.文件很大,不可能全部存储在内存中,故要存储到磁盘上
2.索引的结构组织要尽量减少查找过程中磁盘I/O的存取次数(为什么使用B-/+Tree,还跟磁盘存取原理有关,具体看下边分析)
为什么B+树比B树更适合做索引?
1.B+树磁盘读写代价更低
B+的内部结点并没有指向关键字具体信息的指针,即内部节点不存储数据。因此其内部结点相对B 树更小。如果把所有同一内部结点的关键字存放在同一盘块中,那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。
2.B+-tree的查询效率更加稳定
由于非终结点并不是最终指向文件内容的结点,而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同,导致每一个数据的查询效率相当。
在MySQL中,最常用的两个存储引擎是MyISAM和InnoDB,它们对索引的实现方式是不同的。
MyISAM data存的是数据地址。索引是索引,数据是数据。
InnoDB data存的是数据本身。索引也是数据。
原文地址:https://blog.csdn.net/qq_40180411/article/details/81431386
需要通过外部的接口获取,例如淘宝开放平台的接口:https://open.taobao.com/api.htm?docId=27432&docType=2
同一个VPC环境的ECS可以通过内网IP访问到。也支持外网IP申请,参见:https://help.aliyun.com/document_detail/26128.html