首页 文章 精选 留言 我的

精选列表

搜索[CEL策略],共10004篇文章
优秀的个人博客,低调大师

策略

trunk 主干,作为主干你要保证他的代码是可运行的。 branches 分支,代码来自主干,可以有很多分支,分支用于多个团队同步开发,最终要将代码合并到主干。例如:branches/member, branches/blog, branches/shop 分别来自不同的团队 tags 一般用于做快照,一旦建立永不更改 releases 发行本版,代码来自主干, 与tags功能一样,命名更直观。例如每个月为一个周期,发布一次代码 releases/v1.0, releases/1.5 .-----------------------------------------------------------------------> cart r100 ---> ... / ^ .----------------------> blog r3 ---> r4 ... ... r(10) ---> r(n) ---> r(...) --->/---> ... / ^ \ / .-> branches r1 ---> member r2 ---/---------> r4 ... r(10) --\----> r(14) ---> r(...)--/---> ... / ^ / \ \ \ / repositories ----> trunk r1 -----/----------/--------------> r(11) ---> r(12) ---> r(15) ---> r(...) ---> ... \ \ \ \ `-> tags r1 ------------------------------------------> v1.0.0 r(13) \ \ \ \ `--------------------------------------------------------------> v1.0.1 (r16) \ `--------------------------------------------------------------------------> v1.0.2 r(n) .> unstable 2.1.1 / \ unstable 1.1 unstable 2.1 unstable 3.1 ^ \ ^ \ / \ .-> branches ---> unstable 1.0 ---/ \ unstable 2.0 ---/ \ unstable 3.0 unstable---> ... / ^ \ ^ \ ^ \ ^ repositories ----> trunk --------/-----------------> stable ---/-----> stable ---/---> stable ---/-> stable ---> ... \ \ \ \ `-> tags ----------------------------> stable 1.0 \ \ \ \ \ `-------------------------------------------------------> stable 2.0 \ `-------------------------------------------------------------------> stable 3.0 怎样访问版本库 美工、页面人员采用WebDav访问Subversion。Photoshop,Dreamwaver 软件对WebDav有很好地支持,他们不需要学习如何使用Subversion。 开发者通过Svn客户端访问代码库,既可以使用开发IDE集成工具也可以使用单独工具。像TortoiseSVN等等。 Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a>comments powered by Disqus 原文出处:Netkiller 系列 手札 本文作者:陈景峯 转载请与作者联系,同时请务必标明文章原始出处和作者信息及本声明。

优秀的个人博客,低调大师

Databend join reorder 策略

作者:王旭东 Databend 研发工程师 https://github.com/xudong963 join order 的重要性 Join order 是指在执行SQL查询时,决定多个表进行 join 的顺序。它是数据库查询优化的一个重要方面,对查询性能和效率有着重要的影响, 不同的 join order 对性能可能有数量级的影响。 优化器优化 join order 的核心流程 join plan 枚举 根据统计信息估算结果的大小 (cardinality estimation) 把 2 中的结果带入到代价模型计算枚举 plan 的 代价 (cost model) 本文中我们只关心第一步 join plan enumeration, 也就是 join reorder 算法。 join reorder 算法 贪心启发式算法 当需要 join 的表都数量过多时(通常超过10个),适合用贪心算法,其优势在于能够较快的找到还不错的 join order. 核心思想:从一张表拓展到 N 张表,每次选出使当前代价最小的一张表,加入到 join tree中,构建出 left-deep tree. 贪心算法也有很多拓展,主要拓展点是围绕如果 避免局部最优以及产生 bushy tree 枚举算法(top-down & bottom-up) 主流的两种 基于规则变换的 Top-down 枚举,可以结合 Top-down cascasde 框架通过记忆化的方式来实现 基于 DP 的 bottom-up 枚举, 典型代表 DPhyp 算法,其优势在于可以高效的产生 bushy tree 一般情况下,数据库系统会把贪心和枚举有效的结合,从而对任意数量的表 join 都能够在合理的时间内得到有效的 join order Databend join reorder 现状 databend 优化器基于 Rule 进行优化,每条 Rule 通过 pattern 来匹配 plan 中的 sub-tree。主要分为两个阶段,启发式优化和基于 cascades 框架的代价优化,两个阶段共用一套 Rule。 在启发式阶段优化结束后,会对优化后的 plan 执行 DPhyp 算法来尝试得到最优的 join order, 如果 Dphyp 优化失败,会在 CBO 中找到最优的 left-deep tree. (CBO 中不尝试进行 bushy tree 优化,因为如果 Dphyp 已经优化失败,那么尝试在 CBO 中进行 bushy tree 优化,搜索空间很有可能爆炸,如 tpcds 64) Databend 目前没有支持贪心算法 (下一阶段的 roadmap 会做相关支持来处理极端情况下的 case),首先会利用 dphyp 算法来得到最优解,如果 dphyp 失败(query 中存在不适合 dphyper 算法的 pattern),会在 cascades 框架中利用基于规则变换的 Top-down 枚举得到 left-deep tree. 如果表的数量过多,如超过十个,会在 dphyp 算法中放弃部分搜索空间来做 tradeoff。 Dphyp 的核心定义及算法 hypergraph 一个超图是一个由节点集合 V 和超边集合 E 组成的二元组 H = (V,E),其中: V是非空节点集合。 E是超边集合,超边是V的非空子集(u ⊂ V)和(v ⊂ V)的无序对(u,v),并且满足额外条件 u∩v = ∅。 有了超图就可以描述多节点之间连接。 对于上图,它们的 join condition 是 R1.a + R2.b + R3.c = R4.d + R5.e + R6.f 所以 hyperedge 就是 {R1, R2, R3} — {R4, R5, R6} csg-cmp-pair csg: connected-subgraph (连通子图) cmp: connected-complement (连通互补对) 如果两个 csg 之间没有交集,且存在超边连接,其中一个就是另一个的 cmp, 二者构成 csg-cmp-pair. 算法的核心就是通过递归无重复的枚举出所有的 csg-cmp-pair, 找出代价最小的包含所有点的 csg-cmp-pair. algorithm 算法核心:hypergraph 中的节点是有序的,节点从后往前迭代(递减),每个节点只考虑其自身及其之后(序列号更大)的节点,找到可能的连通子图及其连通互补图,构成 csg-cmp-pair, 计算并更新出其代价,当迭代到最小的节点后,会得到包含所有点的 csg-cmp-pair, 算法结束。 算法流程 EmitCsg: 寻找 {v} 的互补连通子图 a. 如果找到, EmitCsgCmp b. EnumerateCmpRec:扩展互补连通子图 如果扩展后的互补连通子图可以与 {v} 形成 csg-cmp-pair, 则 EmitCsgCmp 回到 b,继续扩展 EnumerateCsgRec: 扩展 {v} a. 得到扩展后的 {v’}, 对 {v’} 执行 1 b. 回到2,继续扩展 核心代码和数据结构定义可参考: (https://github.com/datafuselabs/databend/blob/main/src/query/sql/src/planner/optimizer/hyper_dp/dphyp.rs) Connect With Us Databend 是一款开源、弹性、低成本,基于对象存储也可以做实时分析的新式数仓。期待您的关注,一起探索云原生数仓解决方案,打造新一代开源 Data Cloud。 Databend Website GitHub Discussions Twitter Slack Channel

优秀的个人博客,低调大师

JuiceFS 缓存策略详解

对于一个由对象存储和数据库组合驱动的文件系统,缓存是本地客户端与远端服务之间高效交互的重要纽带。读写的数据可以提前或者异步载入缓存,再由客户端在后台与远端服务交互执行异步上传或预取数据。相比直接与远端服务交互,采用缓存技术可以大大降低存储操作的延时并提高数据吞吐量。 数据一致性 JuiceFS 提供「关闭再打开(close-to-open)」一致性保证,即当两个及以上客户端同时读写相同的文件时,客户端 A 的修改在客户端 B 不一定能立即看到。但是,一旦这个文件在客户端 A 写入完成并关闭,之后在任何一个客户端重新打开该文件都可以保证能访问到最新写入的数据,不论是否在同一个节点。 「关闭再打开」是 JuiceFS 提供的最低限度一致性保证,在某些情况下可能也不需要重新打开文件才能访问到最新写入的数据。例如多个应用程序使用同一个 JuiceFS 客户端访问相同的文件(文件变更立即可见),或者在不同节点上通过 tail -f 命令查看最新数据。 元数据缓存 JuiceFS 支持在内核和客户端内存(即 JuiceFS 进程)中缓存元数据以提升元数据的访问性能。 内核元数据缓存 内核中可以缓存三种元数据:属性(attribute)、文件项(entry)和目录项(direntry),可以通过以下挂载参数控制缓存时间: --attr-cache value 属性缓存时长,单位秒 (默认值: 1) --entry-cache value 文件项缓存时长,单位秒 (默认值: 1) --dir-entry-cache value 目录项缓存时长,单位秒 (默认值: 1) JuiceFS 默认会在内核中缓存属性、文件项和目录项,缓存时长 1 秒,以提高 lookup 和 getattr 的性能。当多个节点的客户端同时使用同一个文件系统时,内核中缓存的元数据只能通过时间失效。也就是说,极端情况下可能出现节点 A 修改了某个文件的元数据(如 chown),通过节点 B 访问未能立即看到更新的情况。当然,等缓存过期后,所有节点最终都能看到 A 所做的修改。 客户端内存元数据缓存 注意:此特性需要使用 0.15.0 及以上版本的 JuiceFS。 JuiceFS 客户端在 open() 操作即打开一个文件时,其文件属性(attribute)会被自动缓存在客户端内存中。如果在挂载文件系统时设置了 --open-cache 选项且值大于 0,只要缓存尚未超时失效,随后执行的 getattr() 和 open() 操作会从内存缓存中立即返回结果。 执行 read() 操作即读取一个文件时,文件的 chunk 和 slice 信息会被自动缓存在客户端内存。在缓存有效期内,再次读取 chunk 会从内存缓存中立即返回 slice 信息。 提示:您可以查阅「JuiceFS 如何存储文件」了解 chunk 和 slice 是什么。 默认情况下,对于一个元数据已经被缓存在内存的文件,超过 1 小时没有被任何进程访问,其所有元数据缓存会被自动删除。 数据缓存 JuiceFS 对数据也提供多种缓存机制来提高性能,包括内核中的页缓存和客户端所在节点的本地缓存。 内核数据缓存 注意:此特性需要使用 0.15.0 及以上版本的 JuiceFS。 对于已经读过的文件,内核会把它的内容自动缓存下来,随后再打开该文件,如果文件没有被更新(即 mtime 没有更新),就可以直接从内核中的缓存读取该文件,从而获得最好的性能。得益于内核缓存,重复读取 JuiceFS 中相同文件的速度会非常快,延时可低至微秒,吞吐量可以到每秒数 GiB。 JuiceFS 客户端目前还未默认启用内核的写入缓存功能,从 Linux 内核 3.15 开始,FUSE 支持「writeback-cache 模式」这意味着可以非常快速地完成 write() 系统调用。你可以在挂载文件系统时设置 -o writeback_cache 选项开启 writeback-cache 模式。当需要频繁写入非常小的数据(如 100 字节左右)时,建议启用此挂载选项。 客户端读缓存 JuiceFS 客户端会根据读取模式自动预读数据放入缓存,从而提高顺序读的性能。默认情况下,会在读取数据时并发预读 1 个 block 缓存在本地。本地缓存可以设置在基于机械硬盘、SSD 或内存的任意本地文件系统。 本地缓存可以在挂载文件系统时通过以下选项进行调整: --prefetch value 并发预读 N 个块 (默认: 1) --cache-dir value 本地缓存目录路径;使用冒号隔离多个路径 (默认: "$HOME/.juicefs/cache" 或 "/var/jfsCache") --cache-size value 缓存对象的总大小;单位为 MiB (默认: 1024) --free-space-ratio value 最小剩余空间比例 (默认: 0.1) --cache-partial-only 仅缓存随机小块读 (默认: false) 此外,如果希望将 JuiceFS 的本地缓存存储在内存中有两种方式,一种是将 --cache-dir 设置为 memory,另一种是将其设置为 /dev/shm/<cache-dir>。这两种方式的区别是前者在重新挂载 JuiceFS 文件系统之后缓存数据就清空了,而后者还会保留,性能上两者没有太大差别。 JuiceFS 客户端会尽可能快地把从对象存储下载的数据(包括新上传的小于 1 个 block 大小的数据)写入到缓存目录中,不做压缩和加密。因为 JuiceFS 会为所有写入对象存储的 block 对象生成唯一的名字,而且所有 block 对象不会被修改,因此当文件内容更新时,不用担心缓存的数据失效问题。 当缓存在使用空间到达上限(即缓存大小大于等于 --cache-size)或磁盘将被存满(即磁盘可用空间比例小于 --free-space-ratio)时会自动进行清理,目前的规则是根据访问时间,优先清理不频繁访问的文件。 数据缓存可以有效地提高随机读的性能,对于像 Elasticsearch、ClickHouse 等对随机读性能要求更高的应用,建议将缓存路径设置在速度更快的存储介质上并分配更大的缓存空间。 客户端写缓存 写入数据时,JuiceFS 客户端会把数据缓存在内存,直到当一个 chunk 被写满或通过 close() 或 fsync() 强制操作时,数据才会被上传到对象存储。在调用 fsync() 或 close() 时,客户端会等数据写入对象存储并通知元数据服务后才会返回,从而确保数据完整。 在某些情况下,如果本地存储是可靠的,且本地存储的写入性能明显优于网络写入(如 SSD 盘),可以通过启用异步上传数据的方式提高写入性能,这样一来 close() 操作不会等待数据写入到对象存储,而是在数据写入本地缓存目录就返回。 异步上传功能默认关闭,可以通过以下选项启用: --writeback 后台异步上传对象 (默认: false) 当需要短时间写入大量小文件时,建议使用 --writeback 参数挂载文件系统以提高写入性能,写入完成之后可考虑取消该选项重新挂载以使后续的写入数据获得更高的可靠性。另外,像 MySQL 的增量备份等需要大量随机写操作的场景时也建议启用 --writeback。 警告:当启用了异步上传,即挂载文件系统时指定了 --writeback 时,千万不要删除 <cache-dir>/<UUID>/rawstaging 目录中的内容,否则会导致数据丢失。 当缓存磁盘将被写满时,会暂停写入数据,改为直接上传数据到对象存储(即关闭客户端写缓存功能)。启用异步上传功能时,缓存本身的可靠性与数据写入的可靠性直接相关,对数据可靠性要求高的场景应谨慎使用。 总结 最后,分享一个用户们经常会问到的问题**「为什么设置了缓存容量为 50 GiB,但实际占用了 60 GiB 的空间?」** 对于总量相同的缓存数据,在不同的文件系统上会有不同的容量计算规则。JuiceFS 目前是通过累加所有被缓存对象的大小并附加固定的开销(4KiB)来估算得到的,这与 du 命令得到的数值并不完全一致。 为防止缓存盘被写满,当缓存目录所在文件系统空间不足时,客户端会尽量减少缓存用量。 通过上述介绍,我们对 JuiceFS 的缓存机制的原理有了进一步了解。JuiceFS 本身作为底层文件系统,提供了包括元数据缓存、数据读写缓存等多种缓存机制,最大限度的保证了数据的一致性。希望大家通过本文的了解能更好的应用 JuiceFS。 推荐阅读:知乎 x JuiceFS:利用 JuiceFS 给 Flink 容器启动加速 如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟! (0ᴗ0✿)

优秀的个人博客,低调大师

IOS内测分发策略

当苹果应用没有上交appstore审核,出于开始内侧阶段时,我们如何邀请别人测试和使用? plist苹果安装包实现 使用七牛云存储解决ios7.1的app部署问题 推荐两个现在比较流行的app内测辅助网站 蒲公英 和Fir。这样的创业网站都是抓住了企业开发app,在appstore提交之前需要内测的需求,前者通过企业证书发包用户上传的应用,而后者则更多依赖UDID。这样的网站的确为开发者提供了便利,但是作为创业公司想要发展还需要突破一些瓶颈,减少对苹果平台的依赖。作为IOS开发者及发布者,对于发布应用到这些网站其实本身也存在一定的风险,app随时可能因为不可控因素,下载安装出现问题。

优秀的个人博客,低调大师

SpringBoot ~ 同源策略配置

CROS(Cross-Origin Resource Sharing)是由W3C制定的一种跨域资源共享技术标准,其目的就是为了解决前端的跨域请求。 SpringBoot配置跨域有2种方式,一是方法注解配置,二是全局配置 注解配置 @RestController @RequestMapping("/cors") public class RestfulCorsController { @RequestMapping("/") @CrossOrigin(value = "http://localhost:5000",allowedHeaders = "*",maxAge = 1800) public Map<String,String> itemOperator(@RequestBody ModelMap params){ Map<String,String> map = new HashMap<>(); map.put("name", (String) params.get("name")); System.out.println(params); return map; } } 全局配置 @Configuration public class WebMvcConfig implements WebMvcConfigurer { /* * 配置全局跨域请求 * */ @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/cors/**"). allowedHeaders("*"). allowedMethods("*"). maxAge(1800). allowedOrigins("*"); registry.addMapping("/**"). allowedHeaders("*"). allowedMethods("*"). maxAge(1800). allowedOrigins("http://localhost:5000"); } }

资源下载

更多资源
Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册