• 关于

    查询处理怎么玩

    的搜索结果

问题

【精品问答】大数据技术问题之Flink百问

问问小秘 2019-12-01 21:59:43 7280 浏览量 回答数 1

回答

回 楼主狼鱼星的帖子 晕,钱退在云平台,还好我记得云账号。 ------------------------- Re上个月深圳站云栖大会的钱什么时候退? 阿里欠我一个道歉。 ------------------------- Re上个月深圳站云栖大会的钱什么时候退? 居然不能线上提现,阿里出来一个人解释一下,我购的门票,为啥不发门票,为啥不退到支付宝,为啥不能线上提现。 这是以门票为诱饵,打算强迫客户消费阿里云服务吗? ------------------------- 回 3楼狼鱼星的帖子 这就好比去商城买东西,商城收了钱,不给货,而是直接给一个购物卡。 阿里如果解决不了,只能让消费者协会来协调了。 ------------------------- 回 5楼cloudservice的帖子 你能否看懂我的诉求? 钱为什么不直接退给我,为什么不能线上提现? ------------------------- 回 5楼cloudservice的帖子 不给门票就算了,钱从哪里来,就退回哪里? 那有钱退到自己平台,还不让客户线上提现的道理。 ------------------------- 回 5楼cloudservice的帖子 还要我去写申请表,还要截图。 我怎么知道阿里会不按契约精神办事,收钱不给货。谁会没事保留一个缴费截图,搞这么复杂,是不想退款还是想怎么着? ------------------------- 回 5楼cloudservice的帖子 你们这种情况,我从来没有见过。 以技术大会门票为饵,欺骗客户注册云账号,然后把客户的钱退到自己平台的账号里,最后刁难客户,退不出钱来。 这是典型的欺诈。你们自己分析一下,有没有这个理。 ------------------------- Re回 13楼狼鱼星的帖子 买一个东西而已,谁会去保留交易记录。更诡异的是,这个平台还查询不了交易记录。 谁会想到阿里巴巴如此没有节操,收了钱确不发货。明明系统支持原路退款的,却把钱退到云账户,还要客户自己证明,有意思。 你们随便玩,我会在必要时候好好和你们玩玩,比如支付宝上市的时候。你们拖得越久,你们的竞争对手会越喜欢。 引用第14楼cloud_service于2016-06-06 13:43发表的 回 13楼(狼鱼星) 的帖子 : 您好,我们会积极配合您做款项退回的,但是需要您这边参考之前回复提供下提现需要的资料,提交后反馈您的工单编号我们会优先为您处理的,感谢您的支持。 [url=https://bbs.aliyun.com/job.php?action=topost&tid=281332&pid=794472][/url]

狼鱼星 2019-12-02 02:00:44 0 浏览量 回答数 0

回答

用上 FreeMarker 后,再也不需要 JSP了,JSP相对来说弱爆了,连 layout 功能都没有,layout 现在是基本配置了###### 引用来自“爪哇老妖”的答案 这个真可以有,JSP、Velocity、Freemarker这些都属于动态模版技术,HTML呢,直接就是静态模版技术,也许你会反问我可以用ajax来实现后台调用数据啊,可是我很担心你那页面的加载速度和用户体验,情况更严重的是,有些页面的效果是根据后台数据或参数来展示的,对于你的这个想法,持保留意见。。。 从加载速度方面来说,并没有想像中那么慢,在Chrome和Firefox上速度飞快,加载HTML的时候根本感觉不到它做了些什么,只是在IE上不太理想,页面巨大的话有时候确实会卡一下,不过随着IE版本的更新这个情况可能会慢慢解决掉。 用户体验方面感觉比原来刷页面的方式好的多,Ajax与后台交互,所以根本看不到讨厌的500错误页面了,用JS处理好后台返回的错误,提示信息更加易懂。 至于页面显示内容与数据库有关的问题,这都是交给后台组织好数据用JSON返回的,例如:{userid:1,operation: {'查询'}}和{userid:2,operation: {'查询','删除'}}之类,这样JS拿到JSON数据之后就知道该怎么构建页面了,当然,这些页面元素级的控制,完全可以放到数据库中去,动态的实时控制用户权限。 ######楼主说的情况跟extjs一样,抛弃动态页面,所有数据用js控制,展现,IE处理js虽然慢一点,但这是可控的,在加载的时候给个loading图片用户看起来比浏览器加载动态页面效果好些。要是js功底好,还可以写一些特效,用户体验就更好了。######+freemarker###### 看情况啊,可以有。 不过你说的情况,也有很多,尤其是网站很大,甚至页面的不同部分都是不同的小组做的话。 这时候不用落伍的iframe,就用ajax,jsonp了。 ###### 引用来自“闫晓沛”的答案 +freemarker 是直接访问freemarker的模板吗?这样也确实可以代替JSP,不过还是得走一下Java容器,感觉不如直接让Apache处理HTML的好 ###### 这个真可以有,JSP、Velocity、Freemarker这些都属于动态模版技术,HTML呢,直接就是静态模版技术,也许你会反问我可以用ajax来实现后台调用数据啊,可是我很担心你那页面的加载速度和用户体验,情况更严重的是,有些页面的效果是根据后台数据或参数来展示的,对于你的这个想法,持保留意见。。。 ######回复 @lovinglily : ”世界上不会有一个页面是预先设计好的,因为它有数据“乔布斯说的######意思是,静态页面预先设计好布局的话,并不是根本意义上根据后台数据动态改变,这对页面数据显示有影响是吧..######你能保证所有用户的浏览器都能处理你的这些数据?######跨浏览器确实是一个大问题,可以借助jQuery这样的JS库来解决,虽然有些时候也不是很完美,但是够用了######对于jsp freemarker 等之类的都是属于动态模板,要知道它们最终都是翻译成html代码给浏览器,所以没有替代这种说法。只能说哪种情况更适合你的应用了。如果动态交互更多 且动态判断多的情况下 你用ajax动态请求的方式显得很蹩脚,这中间有个取舍和平衡点######同意你的观点###### 引用来自“爪哇老妖”的答案 这个真可以有,JSP、Velocity、Freemarker这些都属于动态模版技术,HTML呢,直接就是静态模版技术,也许你会反问我可以用ajax来实现后台调用数据啊,可是我很担心你那页面的加载速度和用户体验,情况更严重的是,有些页面的效果是根据后台数据或参数来展示的,对于你的这个想法,持保留意见。。。 我能保证所有用户浏览器都能处理服务器发给它的HTML,很难保证用户浏览器能处理我页面里的所有Ajax数据请求。 ######回复 @xmut : js不可能运行的很慢,就算被我们喷的无地自容的IE6,其实也是大量的js在运行。一个页面的js不可能很多,多到不能处理的地步,否则是本身就设计有问题的######啥年代了,还在纠结浏览器能不能运行js。######没错,这样的项目架构确实存在禁用JS之后玩不转的情况,但是现在有几个项目不用JS的呢,我们可以把“开启JS”作为项目运行必需的环境提出来######确实!楼主把页面控制逻辑全部交给javascript,万一客户端javascript被禁用,或者javascript运行速度很慢,这反而影响了客户体验!######有还是没有 ,看项目的需要,没有不能替代的技术方案。

爱吃鱼的程序员 2020-06-04 16:49:07 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

1.产品2.UI3.CSS4.JS5.后端(Java/php/python)6.DBA(mysql/oracle)7.运维(OP) 8.测试(QA)9.算法(分类/聚类/关系抽取/实体识别)10.搜索(Lucene/Solr/elasticSearch)11.大数据工程师(Hadoop)12.Android13.IOS14.运营 一.产品1 工作内容:了解用户需求,做竞品调研,画产品原型,写产品文档,讲解产品需求,测试产品Bug,收集用户反馈,苦练金刚罩以防止程序员拿刀砍。2 需要技能:PPT,Word, Axure,XP,MVP,行业知识,沟通。 二. UI1 工作内容:收到产品原型,给原型上色,偶尔会自作主张调整下原型的位置,出不同的风格给老板和客户选,然后听他们的意见给出一个自己极不喜欢的风格,最好给Android,IOS或者是CSS做好标注,还有的需要直接帮他们切好图,最后要练出来象素眼,看看这些不靠谱的程序员们有没有上错色或者是有偏差。2 需要技能:PS,Illustrator,Sketch,耐性,找素材。 三. CSS1 工作内容:产品设计好原型,UI做出来了效果图,剩下的就是CSS工程师用代码把静态文件写出来的。 2 需要技能:环境【IDE(WEBStorm,Sublime,EditPlus),源码管理(SVN/Git) ,WEB服务器(nginx)】基础【PS,域名,Html,Html5,CSS,CSS3】扩展【自适应,响应式,Bootstrap,Less,Flex】 四 .JS 1 工作内容:JS工程师其实分成两类,在之前讲CSS的时候已经提到过,一个是套页面的,一个是前后端分离的。对这两个概念还是分不太清的,可以回过头去看CSS的部分。 2 需要技能:环境【IDE(WEBStorm,Sublime,EditPlus),源码管理(SVN/Git) ,WEB服务器(nginx)】基础【Http,REST,跨域,语法,组件,F12,Json,Websocket】框架【JQuery,AngularJS,Bower,RequireJS,GruntJS,ReactJS,PhoneGap】业务【金融,教育,医疗,汽车,房产等等等等各种行业】 五 .后端(Java/python/go) 1 工作内容:大部分的后端工程师都停留在功能实现的层面上。这是现在国内二流或者是三流的公司的现状,甚至是在某些一流的公司。很多时候都是架构师出了架构设计,更多的外包公司根本就是有DBA来做设计,然后后端程序员从JS到CSS到Java全写,完全就是一个通道,所有的复杂逻辑全部交给DB来做,这也是几年前DBA很受重视的原因。 2 需要技能:环境【IDE(Idea/Eclipse,Maven,jenkins,Nexus,Jetty,Shell,Host),源码管理(SVN/Git) ,WEB服务器(nginx,tomcat,Resin)】基础【Http,REST,跨域,语法,Websocket,数据库,计算机网络,操作系统,算法,数据结构】框架【Spring,AOP,Quartz,Json TagLib,tiles,activeMQ,memcache,redis,mybatis,log4j,junit等等等等等】业务【金融,教育,医疗,汽车,房产等等等等各种行业】。 六 .DBA  1 工作内容:如果你做了一个DBA,基本上会遇到两种情况。一种是你的后端工程师懂架构,知道怎么合便使用DB,知道如何防止穿透DB,那么恭喜你,你只是需要当一个DB技术兜底的顾问就好,基本上没什么活可以做,做个监控,写个统计就好了。你可以花时间在MongoDB了,Hadoop了这些,随便玩玩儿。再按照我之前说的,做好数据备份。如果需求变动比较大,往往会牵涉到一些线上数据的更改,那么就在发布的时候安静的等着,等着他们出问题。。。。如果不出问题就可以回家睡觉了。 2 需要技能:环境【Linux,Mysql,Oracle,MongoDB,Hadoop】工具【各种DB的版本,工具,备份,日志等】。 七. 运维  1 工作内容:运维的工作大概分成几个部分,我对于修真院学习运维的少年们都这么说,大概是:A。基础环境的搭建和常用软件的安装和配置(兼网管的还有各种程控机),常用软件指的是SVN,Git,邮箱这种,更细节的内容请参考修真院对于运维职业的介绍。B。日常的发布和维护,如刚刚讲到的一样,测试环境和线上环境的发布和记录,原则上,对线上所有的变更都应该有记录。C。数据的备份和服务的监控&安全配置。各种数据,都要做好备份和回滚的手段,提前准备好各种紧急预案,服务的监制要做好。安全始终都是不怎么被重点考虑的问题,因为这个东西无底洞,你永远不知道做到什么程度算是比较安全了,所以大多数都是看着情况来。D。运维工具的编写。这一点在大的云服务器商里格外常见,大公司也是一样的。E。Hadoop相关的大数据体系架构的运维,确实有公司在用几百台机器做Hadoop,所以虽然不常见,我还是列出来吧。 2 需要技能:环境【Linux,Mysql,Oracle,MongoDB,Hadoop,nginx,apache,F5,lvs,vpn,iptable,svn,git,memcache,redis】工具【linux 常用工具,Mysql常用工具,Jenkins,zabbix,nagios】自动化运维【openstack,docker,ansible】语言【shell,python】 八 .QA  1 工作内容:QA需要了解需求,很多公司会要求QA写测试用例,我觉得是扯淡。完全是在浪费时间。通常开发三周,QA测试的时间只有一周到一周半。还有关于提前写测试用例的,都不靠谱。 2 需要技能:流程【Bug修复流程,版本发布流程】工具【禅道,BugZilla,Jira,Excel表格来统计Bug数,自动化测试】性格【严谨,耐心】 九. 算法工程师  1 工作内容:算法工程师的工作内容,大部分时间都是在调优。就是调各种参数和语料,寻找特征,验证结果,排除噪音。也会和Hadoop神马的打一些交道,mahout神马的,我那个时候还在用JavaML。现在并不知道有没有什么更好用的工具了。有的时候还要自己去标注语料---当然大部分人都不爱做这个事儿,会找漂亮的小编辑去做。2 需要技能:基础【机器学习,数据挖掘】工具【Mahout,JavaML等其他的算法工具集】 十. 搜索工程师  1 工作内容: 所以搜索现在其实分成两种。一种是传统的搜索。包括:A。抓取 B。解析C。去重D。处理E。索引F。查询另一种是做为架构的搜索。并不包括之前的抓取解析去重,只有索引和查询。A。索引B。查询 2 需要技能:环境【Linux】框架【Luence,Slor,ElasticSearch,Cassandra,MongoDB】算法【倒排索引,权重计算公式,去重算法,Facet搜索的原理,高亮算法,实时索引】 十一. 大数据工程师  1 工作内容:工作内容在前期会比较多一些,基础搭建还是一个挺讲究的事儿。系统搭建好之后呢,大概是两种,一种是向大数据部门提交任务,跑一圈给你。一种是持续的文本信息处理中增加新的处理模块,像我之前说的增加个分类啦,实体识别神马的。好吧第一种其实我也不记得是从哪得来的印象了,我是没有见到过的。架构稳定了之后,大数据部门的工作并不太多,常常会和算法工程师混到一起来。其他的应该就是大数据周边产品的开发工作了。再去解决一些Bug什么的。2 需要技能:环境【Linux】框架【Hadoo,spark,storm,pig,hive,mahout,zookeeper 】算法【mapreduce,hdfs,zookeeper】。 十二. Android工程师  1 工作内容:Android工程师的日常就是听产品经理讲需求,跟后端定接口,听QA反馈哪款机器不兼容,闹着申请各种测试机,以及悲催的用Android做IOS的控件。 2 需要技能:环境【Android Studio,Maven,Gradle】基础【数据结构,Java,计算机网络】组件【IM,地图,支付,拍照,视频,音频,统计,分享,手势密码】 十三. IOS工程师  1 工作内容:IOS工程师的工作内容真的挺简单的,听需求,定接口。做个适配,抛弃一下iphone4。还有啥。。马丹,以我为数不多的IOS知识来讲,真的不知道还有啥了。我知道的比较复杂的系统也是各种背景高斯模糊,各种渐变,各种图片滤镜处理,其他并没有什么。支付,地图,统计这些东西。 嗯。2 需要技能:环境【Xcode】基础【数据结构,Object,计算机网络】组件【IM,地图,支付,拍照,视频,音频,统计,分享,手势密码】

行者武松 2019-12-02 01:21:45 0 浏览量 回答数 0

问题

ES 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?【Java问答学堂】28期

剑曼红尘 2020-05-28 09:45:28 15 浏览量 回答数 1

问题

【Java问答学堂】10期 es 在数据量很大的情况下(数十亿级别)如何提高查询效率啊?

剑曼红尘 2020-04-28 14:16:56 0 浏览量 回答数 1

回答

面试官心理分析 这个问题是肯定要问的,说白了,就是看你有没有实际干过 es,因为啥?其实 es 性能并没有你想象中那么好的。很多时候数据量大了,特别是有几亿条数据的时候,可能你会懵逼的发现,跑个搜索怎么一下 5~10s,坑爹了。第一次搜索的时候,是 5~10s,后面反而就快了,可能就几百毫秒。 你就很懵,每个用户第一次访问都会比较慢,比较卡么?所以你要是没玩儿过 es,或者就是自己玩玩儿 demo,被问到这个问题容易懵逼,显示出你对 es 确实玩儿的不怎么样? 面试题剖析 说实话,es 性能优化是没有什么银弹的,啥意思呢?就是不要期待着随手调一个参数,就可以万能的应对所有的性能慢的场景。也许有的场景是你换个参数,或者调整一下语法,就可以搞定,但是绝对不是所有场景都可以这样。 性能优化的杀手锏——filesystem cache 你往 es 里写的数据,实际上都写到磁盘文件里去了,查询的时候,操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 里面去。 es 的搜索引擎严重依赖于底层的 filesystem cache,你如果给 filesystem cache 更多的内存,尽量让内存可以容纳所有的 idx segment file 索引数据文件,那么你搜索的时候就基本都是走内存的,性能会非常高。 性能差距究竟可以有多大?我们之前很多的测试和压测,如果走磁盘一般肯定上秒,搜索性能绝对是秒级别的,1秒、5秒、10秒。但如果是走 filesystem cache,是走纯内存的,那么一般来说性能比走磁盘要高一个数量级,基本上就是毫秒级的,从几毫秒到几百毫秒不等。 这里有个真实的案例。某个公司 es 节点有 3 台机器,每台机器看起来内存很多,64G,总内存就是 64 * 3 = 192G。每台机器给 es jvm heap 是 32G,那么剩下来留给 filesystem cache 的就是每台机器才 32G,总共集群里给 filesystem cache 的就是 32 * 3 = 96G 内存。而此时,整个磁盘上索引数据文件,在 3 台机器上一共占用了 1T 的磁盘容量,es 数据量是 1T,那么每台机器的数据量是 300G。这样性能好吗? filesystem cache 的内存才 100G,十分之一的数据可以放内存,其他的都在磁盘,然后你执行搜索操作,大部分操作都是走磁盘,性能肯定差。 归根结底,你要让 es 性能要好,最佳的情况下,就是你的机器的内存,至少可以容纳你的总数据量的一半。 根据我们自己的生产环境实践经验,最佳的情况下,是仅仅在 es 中就存少量的数据,就是你要用来搜索的那些索引,如果内存留给 filesystem cache 的是 100G,那么你就将索引数据控制在 100G 以内,这样的话,你的数据几乎全部走内存来搜索,性能非常之高,一般可以在 1 秒以内。 比如说你现在有一行数据。id,name,age .... 30 个字段。但是你现在搜索,只需要根据 id,name,age 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段,就会导致说 90% 的数据是不用来搜索的,结果硬是占据了 es 机器上的 filesystem cache 的空间,单条数据的数据量越大,就会导致 filesystem cahce 能缓存的数据就越少。其实,仅仅写入 es 中要用来检索的少数几个字段就可以了,比如说就写入 es id,name,age 三个字段,然后你可以把其他的字段数据存在 mysql/hbase 里,我们一般是建议用 es + hbase 这么一个架构。 hbase 的特点是适用于海量数据的在线存储,就是对 hbase 可以写入海量数据,但是不要做复杂的搜索,做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索,拿到的结果可能就 20 个 doc id,然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据,给查出来,再返回给前端。 写入 es 的数据最好小于等于,或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms,然后再根据 es 返回的 id 去 hbase 里查询,查 20 条数据,可能也就耗费个 30ms,可能你原来那么玩儿,1T 数据都放 es,会每次查询都是 5~10s,现在可能性能就会很高,每次查询就是 50ms。 数据预热 假如说,哪怕是你就按照上述的方案去做了,es 集群中每个机器写入的数据量还是超过了 filesystem cache 一倍,比如说你写入一台机器 60G 数据,结果 filesystem cache 就 30G,还是有 30G 数据留在了磁盘上。 其实可以做数据预热。 举个例子,拿微博来说,你可以把一些大V,平时看的人很多的数据,你自己提前后台搞个系统,每隔一会儿,自己的后台系统去搜索一下热数据,刷到 filesystem cache 里去,后面用户实际上来看这个热数据的时候,他们就是直接从内存里搜索了,很快。 或者是电商,你可以将平时查看最多的一些商品,比如说 iphone 8,热数据提前后台搞个程序,每隔 1 分钟自己主动访问一次,刷到 filesystem cache 里去。 对于那些你觉得比较热的、经常会有人访问的数据,最好做一个专门的缓存预热子系统,就是对热数据每隔一段时间,就提前访问一下,让数据进入 filesystem cache 里面去。这样下次别人访问的时候,性能一定会好很多。 冷热分离 es 可以做类似于 mysql 的水平拆分,就是说将大量的访问很少、频率很低的数据,单独写一个索引,然后将访问很频繁的热数据单独写一个索引。最好是将冷数据写入一个索引中,然后热数据写入另外一个索引中,这样可以确保热数据在被预热之后,尽量都让他们留在 filesystem os cache 里,别让冷数据给冲刷掉。 你看,假设你有 6 台机器,2 个索引,一个放冷数据,一个放热数据,每个索引 3 个 shard。3 台机器放热数据 index,另外 3 台机器放冷数据 index。然后这样的话,你大量的时间是在访问热数据 index,热数据可能就占总数据量的 10%,此时数据量很少,几乎全都保留在 filesystem cache 里面了,就可以确保热数据的访问性能是很高的。但是对于冷数据而言,是在别的 index 里的,跟热数据 index 不在相同的机器上,大家互相之间都没什么联系了。如果有人访问冷数据,可能大量数据是在磁盘上的,此时性能差点,就 10% 的人去访问冷数据,90% 的人在访问热数据,也无所谓了。 document 模型设计 对于 MySQL,我们经常有一些复杂的关联查询。在 es 里该怎么玩儿,es 里面的复杂的关联查询尽量别用,一旦用了性能一般都不太好。 最好是先在 Java 系统里就完成关联,将关联好的数据直接写入 es 中。搜索的时候,就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。 document 模型设计是非常重要的,很多操作,不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就那么多,不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作,尽量在 document 模型设计的时候,写入的时候就完成。另外对于一些太复杂的操作,比如 join/nested/parent-child 搜索都要尽量避免,性能都很差的。 分页性能优化 es 的分页是较坑的,为啥呢?举个例子吧,假如你每页是 10 条数据,你现在要查询第 100 页,实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上,如果你有个 5 个 shard,那么就有 5000 条数据,接着协调节点对这 5000 条数据进行一些合并、处理,再获取到最终第 100 页的 10 条数据。 分布式的,你要查第 100 页的 10 条数据,不可能说从 5 个 shard,每个 shard 就查 2 条数据,最后到协调节点合并成 10 条数据吧?你必须得从每个 shard 都查 1000 条数据过来,然后根据你的需求进行排序、筛选等等操作,最后再次分页,拿到里面第 100 页的数据。你翻页的时候,翻的越深,每个 shard 返回的数据就越多,而且协调节点处理的时间越长,非常坑爹。所以用 es 做分页的时候,你会发现越翻到后面,就越是慢。 我们之前也是遇到过这个问题,用 es 作分页,前几页就几十毫秒,翻到 10 页或者几十页的时候,基本上就要 5~10 秒才能查出来一页数据了。 有什么解决方案吗? 不允许深度分页(默认深度分页性能很差) 跟产品经理说,你系统不允许翻那么深的页,默认翻的越深,性能就越差。 类似于 app 里的推荐商品不断下拉出来一页一页的 类似于微博中,下拉刷微博,刷出来一页一页的,你可以用 scroll api,关于如何使用,自行上网搜索。 scroll 会一次性给你生成所有数据的一个快照,然后每次滑动向后翻页就是通过游标 scroll_id 移动,获取下一页下一页这样子,性能会比上面说的那种分页性能要高很多很多,基本上都是毫秒级的。 但是,唯一的一点就是,这个适合于那种类似微博下拉翻页的,不能随意跳到任何一页的场景。也就是说,你不能先进入第 10 页,然后去第 120 页,然后又回到第 58 页,不能随意乱跳页。所以现在很多产品,都是不允许你随意翻页的,app,也有一些网站,做的就是你只能往下拉,一页一页的翻。 初始化时必须指定 scroll 参数,告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时,否则可能因为超时而失败。 除了用 scroll api,你也可以用 search_after 来做,search_after 的思想是使用前一页的结果来帮助检索下一页的数据,显然,这种方式也不允许你随意翻页,你只能一页页往后翻。初始化时,需要使用一个唯一值的字段作为 sort 字段。 往期回顾: 【Java问答学堂】1期 为什么使用消息队列?消息队列有什么优点和缺点?Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 【Java问答学堂】2期 如何保证消息队列的高可用? 【Java问答学堂】3期 如何保证消息不被重复消费?或者说,如何保证消息消费的幂等性? 【Java问答学堂】4期 如何保证消息的可靠性传输?(如何处理消息丢失的问题?) 【Java问答学堂】5期 如何保证消息的顺序性? 【Java问答学堂】6期 如何解决消息队列的延时以及过期失效问题? 【Java问答学堂】7期 如果让你写一个消息队列,该如何进行架构设计? 【Java问答学堂】8期 es 的分布式架构原理能说一下么(es 是如何实现分布式的啊)? 【Java问答学堂】9期 es 写入数据的工作原理是什么啊?es 查询数据的工作原理是什么啊?

剑曼红尘 2020-04-28 14:17:05 0 浏览量 回答数 0

回答

回 2楼(zc_0101) 的帖子 您好,       您的问题非常好,SQL SERVER提供了很多关于I/O压力的性能计数器,请选择性能计算器PhysicalDisk(LogicalDisk),根据我们的经验,如下指标的阈值可以帮助你判断IO是否存在压力: 1.  % Disk Time :这个是磁盘时间百分比,这个平均值应该在85%以下 2.  Current Disk Queue Length:未完成磁盘请求数量,这个每个磁盘平均值应该小于2. 3.  Avg. Disk Queue Length:磁盘请求队列的平均长度,这个每个磁盘平均值也应该小于2 4.  Disk Transfers/sec:每次磁盘传输数量,这个每个磁盘的最大值应该小于100 5.  Disk Bytes/sec:每次磁盘传入字节数,这个在普通的磁盘上应该在10M左右 6.  Avg. Disk Sec/Read:从磁盘读取的平均时间,这个平均值应该小于10ms(毫秒) 7.  Avg. Disk Sec/Write:磁盘写入的平均时间,这个平均值也应该小于10ms(毫秒) 以上,请根据自己的磁盘系统判断,比如传统的机械臂磁盘和SSD有所不同。 一般磁盘的优化方向是: 1. 硬件优化:比如使用更合理的RAID阵列,使用更快的磁盘驱动器,添加更多的内存 2. 数据库设置优化:比如创建多个文件和文件组,表的INDEX和数据放到不同的DISK上,将数据库的日志放到单独的物理驱动器,使用分区表 3. 数据库应用优化:包括应用程序的设计,SQL语句的调整,表的设计的合理性,INDEX创建的合理性,涉及的范围很广 希望对您有所帮助,谢谢! ------------------------- 回 3楼(鹰舞) 的帖子 您好,      根据您的描述,由于查询产生了副本REDO LOG延迟,出现了架构锁。我们知道SQL SERVER 2012 AlwaysOn在某些数据库行为上有较多变化。我们先看看架构锁: 架构锁分成两类: 1. SCH-M:架构更改锁,主要发生在数据库SCHEMA的修改上,从你的描述看,没有更改SCHEMA,那么可以排除这个因素 2. SCH-S:架构稳定锁,主要发生在数据库的查询编译等活动 根据你的情况,应该属于SCH-S导致的。查询编译活动主要发生有新增加了INDEX, 更新了统计信息,未参数化的SQL语句等等 对于INDEX和SQL语句方面应,我想应该不会有太多问题。 我们重点关注一下统计信息:SQL SERVER 2012 AG副本的统计信息维护有两种: 1. 主体下发到副本 2. 临时统计信息存储在TEMPDB 对于主体下发的,我们可以设置统计信息的更新行为,自动更新时,可以设置为异步的(自动更新统计信息必须首先打开): USE [master] GO ALTER DATABASE [Test_01]     SET AUTO_UPDATE_STATISTICS_ASYNC ON WITH NO_WAIT GO 这样的话查询优化器不等待统计信息更新完成即编译查询。可以优化一下你的BLOCK。 对于临时统计信息存储在TEMPDB里面也是很重要的,再加上ALWAYSON的副本数据库默认是快照隔离,优化TEMPDB也是必要的,关于优化TEPDB这个我想大部分都知道,这里只是提醒一下。 除了从统计信息本身来解决,在查询过程中,可以降低查询的时间,以尽量减少LOCK的时间和范围,这需要优化你的SQL语句或者应用程序。 以上,希望对您有所帮助。谢谢! ------------------------- 回 4楼(leamonjxl) 的帖子 这是一个关于死锁的问题,为了能够提供帮助一些。请根据下列建议进行: 1.    跟踪死锁 2.    分析死锁链和原因 3.    一些解决办法 关于跟踪死锁,我们首先需要打开1222标记,例如DBCC TRACEON(1222,-1), 他将收集的信息写入到死锁事件发生的服务器上的日志文件中。同时建议打开Profiler的跟踪信息: 如果发生了死锁,需要分析死锁发生的根源在哪里?我们不是很清楚你的具体发生死锁的形态是怎么样的。 关于死锁的实例也多,这里不再举例。 这里只是提出一些可以解决的思路: 1.    减少锁的争用 2.    减少资源的访问数 3.    按照相同的时间顺序访问资源 减少锁的争用,可以从几个方面入手 1.    使用锁提示,比如为查询语句添加WITH (NOLOCK), 但这还取决于你的应用是否允许,大部分分布式的系统都是可以加WITH (NOLOCK), 金融行业可能需要慎重。 2.    调整隔离级别,使用MVCC,我们的数据库默认级别是READ COMMITED. 建议修改为读提交快照隔离级别,这样的话可以尽量读写不阻塞,只不过MVCC的ROW VERSION保存到TEMPDB下面,需要维护好TEMPDB。当然如果你的整个数据库隔离级别可以设置为READUNCOMMINTED,这些就不必了。 减少资源的访问数,可以从如下几个方面入手: 1.    使用聚集索引,非聚集INDEX的叶子页面与堆或者聚集INDEX的数据页面分离。因此,如果对非聚集INDEX 操作的话,会产生两个锁,一个是基本表,一个是非聚集INDEX。而聚集INDEX就不一样,聚集INDEX的叶子页面和表的数据页面相同,他只需要一个LOCK。 2.    查询语句尽量使用覆盖INDEX, 使用全覆盖INDEX,就不需要访问基本表。如果没有全覆盖,还会通过RID或者CLUSTER INDEX访问基本表,这样产生的LOCK可能会与其他SESSION争用。 按照相同的时间顺序访问资源: 确保每个事务按照相同的物理顺序访问资源。两个事务按照相同的物理顺序访问,第一个事务会获得资源上的锁而不会被第二个事务阻塞。第二个事务想获得第一个事务上的LOCK,但被第一个事务阻塞。这样的话就不会导致循环阻塞的情况。 ------------------------- 回 4楼(leamonjxl) 的帖子 两种方式看你的业务怎么应用。这里不仅是分表的问题,还可能存在分库,分服务器的问题。取决与你的架构方案。 物理分表+视图,这是一种典型的冷热数据分离的方案,大致的做法如下: 1.    保留最近3个月的数据为当前表,也即就是我们说的热数据 2.    将其他数据按照某种规则分表,比如按照年或者季度或者月,这部分是相对冷的数据 分表后,涉及到几个问题: 第一问题是,转移数据的过程,一般是晚上业务比较闲来转移,转移按照一定的规则来做,始终保持3个月,这个定时任务本身也很消耗时间 再者,关于查询部分,我想你们的数据库服务器应该通过REPLICATION做了读写分离的吧,主库我觉得压力不会太大,主要是插入或者更新,只读需要做视图来包含全部的数据,但通过UNION ALL所有分表的数据,最后可能还是非常大,在某些情况下,性能不一定好。这个是不是业务上可以解决。比如,对于1年前的历史数据,放在单独的只读上,相对热的数据放在一起,这样压力也会减少。 分区表的话,因为涉及到10亿数据,要有好的分区方案,相对比较简单一点。但对于10亿的大表,始终是个棘手的问题,无论分多少个分区,单个服务器的资源也是有限的。可扩展性方面也存在问题,比如在只读上你没有办法做服务器级别的拆分了。这可能也会造成瓶颈。 现在很多企业都在做分库分表,这些的要解决一些高并发,数据量大的问题。不知是否考虑过类似于中间件的方案,比如阿里巴巴的TDDL类似的方案,如果你有兴趣,可以查询相关资料。 ------------------------- 回 9楼(jiangnii) 的帖子 阿里云数据库不仅提供一个数据库,还提供数据库一种服务。阿里云数据库不仅简化了基础架构的部署,还提供了数据库高可用性架构,备份服务,性能诊断服务,监控服务,专家服务等等,保证用户放心、方便、省心地使用数据库,就像水电一样。以前的运维繁琐的事,全部由阿里云接管,用户只需要关注数据库的使用和具体的业务就好。 关于优化和在云数据库上处理大数据量或复杂的数据操作方面,在云数据库上是一样的,没有什么特别的地方,不过我们的云数据库是使用SSD磁盘,这个比普通的磁盘要快很多,IO上有很大的优势。目前单个实例支持1T的数据量大小。陆续我们会推出更多的服务,比如索引诊断,连接诊断,容量分析,空间诊断等等,这些工作可能是专业的DBA才能完成的,以后我们会提供自动化的服务来为客户创造价值,希望能帮助到客户。 谢谢! ------------------------- 回 12楼(daniellin17) 的帖子 这个问题我不知道是否是两个问题,一个是并行度,另一个是并发,我更多理解是吞吐量,单就并行度而言。 提高并行度需要考虑的因素有: 1.    可用于SQL SERVER的CPU数量 2.    SQL SERVER的版本(32位/64位) 3.    可用内存 4.    执行的查询类型 5.    给定的流中处理的行数 6.    活动的并发连接数量 7.    sys.configurations参数:affinity mask/max server memory (MB)/ max degree of parallelism/ cost threshold for parallelism 以DOP的参数控制并行度为例,设置如下: SELECT * FROM sys.configurations WITH (NOLOCK) WHERE name = 'max degree of parallelism' EXEC sp_configure 'max degree of parallelism',2 RECONFIGURE WITH OVERRIDE 经过测试,DOP设置为2是一个比较适中的状态,特别是OLTP应用。如果设置高了,会产生较多的SUSPEND进程。我们可以观察到资源等待资源类型是:CXPACKET 你可以用下列语句去测试: DBCC SQLPERF('sys.dm_os_wait_stats',CLEAR) SELECT * FROM sys.dm_os_wait_stats WITH (NOLOCK) ORDER BY 2 DESC ,3 DESC 如果是吞吐量的话。优化的范围就很广了。优化是系统性的。硬件配置我们选择的话,大多根据业务量来预估,然后考虑以下: 1.    RAID的划分,RAID1适合存放事务日志文件(顺序写),RAID10/RAID5适合做数据盘,RAID10是条带化并镜像,RAID5条带化并奇偶校验 2.    数据库设置,比如并行度,连接数,BUFFER POOL 3.    数据库文件和日志文件的存放规则,数据库文件的多文件设置规则 4.    TEMPDB的优化原则,这个很重要的 5.    表的设计方面根据业务类型而定 6.    CLUSTERED INDEX和NONCLUSTERED INDEX的设计 7.    阻塞分析 8.    锁和死锁分析 9.    执行计划缓冲分析 10.    存储过程重编译 11.    碎片分析 12.    查询性能分析,这个有很多可以优化的方式,比如OR/UNION/类型转换/列上使用函数等等 我这里列举一个高并发的场景: 比如,我们的订单,比如搞活动的时候,订单刷刷刷地增长,单个实例可能每秒达到很高很高,我们分析到最后最常见的问题是HOT PAGE问题,其等待类型是PAGE LATCH竞争。这个过程可以这么来处理,简单列几点,可以参考很多涉及高并发的案例: 1.    数据库文件和日志文件分开,存放在不同的物理驱动器磁盘上 2.    数据库文件需要与CPU个数形成一定的比例 3.    表设计可以使用HASH来作为表分区 4.    表可以设置无序的KEY/INDEX,比如使用GUID/HASH VALUE来定义PRIMARY KEY CLUSTER INDEX 5.    我们不能将自增列设计为聚集INDEX 这个场景只是针对高并发的插入。对于查询而言,是不适合的。但这些也可能导致大量的页拆分。只是在不同的场景有不同的设计思路。这里抛砖引玉。 ------------------------- 回 13楼(zuijh) 的帖子 ECS上现在有两种磁盘,一种是传统的机械臂磁盘,另一种是SSD,请先诊断你的IO是否出现了问题,本帖中有提到如何判断磁盘出现问题的相关话题,请参考。如果确定IO出现问题,可以尝试使用ECS LOCAL SSD。当然,我们欢迎你使用云数据库的产品,云数据库提供了很多有用的功能,比如高可用性,灵活的备份方案,灵活的弹性方案,实用的监控报警等等。 ------------------------- 回 17楼(豪杰本疯子) 的帖子 我们单个主机或者单个实例的资源总是有限的,因为涉及到很大的数据量,对于存储而言是个瓶颈,我曾使用过SAN和SAS存储,SAN存储的优势确实可以解决数据的灵活扩展,但是SAN也分IPSAN和FIBER SAN,如果IPSAN的话,性能会差一些。即使是FIBER SAN,也不是很好解决性能问题,这不是它的优势,同时,我们所有DB SERVER都连接到SAN上,如果SAN有问题,问题涉及的面就很广。但是SAS毕竟空间也是有限的。最终也会到瓶颈。数据量大,是造成性能问题的直接原因,因为我们不管怎么优化,一旦数据量太大,优化的能力总是有限的,所以这个时候更多从架构上考虑。单个主机单个实例肯定是抗不过来的。 所以现在很多企业在向分布式系统发展,对于数据库而言,其实有很多形式。我们最常见的是读写分离,比如SQL SERVER而言,我们可以通过复制来完成读写分离,SQL SERVER 2012及以后的版本,我们可以使用ALWAYSON来实现读写分离,但这只能解决性能问题,那空间问题怎么解决。我们就涉及到分库分表,这个分库分表跟应用结合得紧密,现在很多公司通过中间件来实现,比如TDDL。但是中间件不是每个公司都可以玩得转的。因此可以将业务垂直拆分,那么DB也可以由此拆分开来。举个简单例子,我们一个典型的电子商务系统,有订单,有促销,有仓库,有配送,有财务,有秒杀,有商品等等,很多公司在初期,都是将这些放在一个主机一个实例上。但是这些到了一定规模或者一定数据量后,就会出现性能和硬件资源问题,这时我们可以将它们独立一部分获完全独立出来。这些都是一些好的方向。希望对你有所帮助。 ------------------------- 回 21楼(dt) 的帖子 问: 求大数据量下mysql存储,优化方案 分区好还是分表好,分的过程中需要考虑事项 mysql高并发读写的一些解决办法 答: 分区:对于应用来说比较简单,改造较少 分表: 应用需较多改造,优点是数据量太大的情况下,分表可以拆分到多个实例上,而分区不可以。 高并发优化,有两个建议: 1.    优化事务逻辑 2.    解决mysql高并发热点,这个可以看看阿里的一个热点补丁: http://www.open-open.com/doc/view/d58cadb4fb68429587634a77f93aa13f ------------------------- 回 23楼(aelven) 的帖子 对于第一个问题.需要看看你的数据库架构是什么样的?比如你的架构具有高可用行?具有读写分离的架构?具有群集的架构.数据库应用是否有较冷门的功能。高并发应该不是什么问题。可扩展性方面需要考虑。阿里云数据库提供了很多优势,比如磁盘是性能超好的SSD,自动转移的高可用性,没有任何单点,自动灵活的备份方案,实用的监控报警,性能监控服务等等,省去DBA很多基础性工作。 你第二个问题,看起来是一个高并发的场景,这种高并发的场景容易出现大量的LOCK甚至死锁,我不是很清楚你的业务,但可以建议一下,首先可以考虑快照隔离级别,实现行多版本控制,让读写不要阻塞。至于写写过程,需要加锁的粒度降低最低,同时这种高并发也容易出现死锁,关于死锁的分析,本帖有提到,请关注。 第三个问题,你用ECS搭建自己的应用也是可以的,RDS数据库提供了很多功能,上面已经讲到了。安全问题一直是我们最看重的问题,肯定有超好的防护的。 ------------------------- 回 26楼(板砖大叔) 的帖子 我曾经整理的关于索引的设计与规范,可以供你参考: ----------------------------------------------------------------------- 索引设计与规范 1.1    使用索引 SQL SERVER没有索引也可以检索数据,只不过检索数据时扫描这个表而异。存储数据的目的,绝大多数都是为了再次使用,而一般数据检索都是带条件的检索,数据查询在数据库操作中会占用较大的比例,提高查询的效率往往意味着整个数据库性能的提升。索引是特定列的有序集合。索引使用B-树结构,最小优化了定位所需要的键值的访问页面量,包含聚集索引和非聚集索引两大类。聚集索引与数据存放在一起,它决定表中数据存储的物理顺序,其叶子节点为数据行。 1.2    聚集索引 1.2.1    关于聚集索引 没聚集索引的表叫堆。堆是一种没有加工的数据,以行标示符作为指向数据存储位置的指针,数据没有顺序。聚集索引的叶子页面和表的数据页面相同,因此表行物理上按照聚集索引列排序,表数据的物理顺序只有一种,所以一个表只有一个聚集索引。 1.2.2    与非聚集索引关系 非聚集索引的一个索引行包含指向表对应行的指针,这个指针称为行定位器,行定位器的值取决于数据页保存为堆还是被聚集。若是堆,行定位器指向的堆中数据行的行号指针,若是聚集索引表,行定位器是聚集索引键值。 1.2.3    设计聚集索引注意事项     首先创建聚集索引     聚集索引上的列需要足够短     一步重建索引,不要使用先DROP再CREATE,可使用DROP_EXISTING     检索一定范围和预先排序数据时使用,因为聚集索引的叶子与数据页面相同,索引顺序也是数据物理顺序,读取数据时,磁头是按照顺序读取,而不是随机定位读取数据。     在频繁更新的列上不要设计聚集索引,他将导致所有的非聚集所有的更新,阻塞非聚集索引的查询     不要使用太长的关键字,因为非聚集索引实际包含了聚集索引值     不要在太多并发度高的顺序插入,这将导致页面分割,设置合理的填充因子是个不错的选择 1.3    非聚集索引 1.3.1    关于非聚集索引 非聚集索引不影响表页面中数据的顺序,其叶子页面和表的数据页面时分离的,需要一个行定位器来导航数据,在将聚集索引时已经有说明,非聚集索引在读取少量数据行时特别有效。非聚集索引所有可以有多个。同时非聚集有很多其他衍生出来的索引类型,比如覆盖索引,过滤索引等。 1.3.2    设计非聚集索引     频繁更新的列,不适合做聚集索引,但可以做非聚集索引     宽关键字,例如很宽的一列或者一组列,不适合做聚集索引的列可作非聚集索引列     检索大量的行不宜做非聚集索引,但是可以使用覆盖索引来消除这种影响 1.3.3    优化书签查找 书签会访问索引之外的数据,在堆表,书签查找会根据RID号去访问数据,若是聚集索引表,一般根据聚集索引去查找。在查询数据时,要分两个部分来完成,增加了读取数据的开销,增加了CPU的压力。在大表中,索引页面和数据页面一般不会临近,若数据只存在磁盘,产生直接随机从磁盘读取,这导致更多的消耗。因此,根据实际需要优化书签查找。解决书签查找有如下方法:     使用聚集索引避免书签查找     使用覆盖索引避免书签查找     使用索引连接避免数据查找 1.4    聚集与非聚集之比较 1.4.1    检索的数据行 一般地,检索数据量大的一般使用聚集索引,因为聚集索引的叶子页面与数据页面在相同。相反,检索少量的数据可能非聚集索引更有利,但注意书签查找消耗资源的力度,不过可考虑覆盖索引解决这个问题。 1.4.2    数据是否排序 如果数据需要预先排序,需要使用聚集索引,若不需要预先排序就那就选择聚集索引。 1.4.3    索引键的宽度 索引键如果太宽,不仅会影响数据查询性能,还影响非聚集索引,因此,若索引键比较小,可以作为聚集索引,如果索引键够大,考虑非聚集索引,如果很大的话,可以用INCLUDE创建覆盖索引。 1.4.4    列更新的频度 列更新频率高的话,应该避免考虑所用非聚集索引,否则可考虑聚集索引。 1.4.5    书签查找开销 如果书签查找开销较大,应该考虑聚集索引,否则可使用非聚集索引,更佳是使用覆盖索引,不过得根据具体的查询语句而看。 1.5    覆盖索引 覆盖索引可显著减少查询的逻辑读次数,使用INCLUDE语句添加列的方式更容易实现,他不仅减小索引中索引列的数据,还可以减少索引键的大小,原因是包含列只保存在索引的叶子级别上,而不是索引的叶子页面。覆盖索引充当一个伪的聚集索引。覆盖索引还能够有效的减少阻塞和死锁的发生,与聚集索引类似,因为聚集索引值发生一次锁,非覆盖索引可能发生两次,一次锁数据,一次锁索引,以确保数据的一致性。覆盖索引相当于数据的一个拷贝,与数据页面隔离,因此也只发生一次锁。 1.6    索引交叉 如果一个表有多个索引,那么可以拥有多个索引来执行一个查询,根据每个索引检索小的结果集,然后就将子结果集做一个交叉,得到满足条件的那些数据行。这种技术可以解决覆盖索引中没有包含的数据。 1.7    索引连接 几乎是跟索引交叉类似,是一个衍生品种。他将覆盖索引应用到交叉索引。如果没有单个覆盖索引查询的索引而多个索引一起覆盖查询,SQL SERVER可以使用索引连接来完全满足查询而不需要查询基础表。 1.8    过滤索引 用来在可能没有好的选择性的一个或者多个列上创建一个高选择性的关键字组。例如在处理NULL问题比较有效,创建索引时,可以像写T-SQL语句一样加个WHERE条件,以排除某部分数据而检索。 1.9    索引视图 索引视图在OLAP系统上可能有胜算,在OLTP会产生过大的开销和不可操作性,比如索引视图要求引用当前数据库的表。索引视图需要绑定基础表的架构,索引视图要求企业版,这些限制导致不可操作性。 1.10    索引设计建议 1.10.1    检查WHERE字句和连接条件列 检查WHERE条件列的可选择性和数据密度,根据条件创建索引。一般地,连接条件上应当考虑创建索引,这个涉及到连接技术,暂时不说明。 1.10.2    使用窄的索引 窄的索引有可减少IO开销,读取更少量的数据页。并且缓存更少的索引页面,减少内存中索引页面的逻辑读取大小。当然,磁盘空间也会相应地减少。 1.10.3    检查列的唯一性 数据分布比较集中的列,种类比较少的列上创建索引的有效性比较差,如果性别只有男女之分,最多还有个UNKNOWN,单独在上面创建索引可能效果不好,但是他们可以为覆盖索引做出贡献。 1.10.4    检查列的数据类型 索引的数据类型是很重要的,在整数类型上创建的索引比在字符类型上创建索引更有效。同一类型,在数据长度较小的类型上创建又比在长度较长的类型上更有效。 1.10.5    考虑列的顺序 对于包含多个列的索引,列顺序很重要。索引键值在索引上的第一上排序,然后在前一列的每个值的下一列做子排序,符合索引的第一列通常为该索引的前沿。同时要考虑列的唯一性,列宽度,列的数据类型来做权衡。 1.10.6    考虑索引的类型 使用索引类型前面已经有较多的介绍,怎么选择已经给出。不再累述。 ------------------------- 回 27楼(板砖大叔) 的帖子 这两种都可以吧。看个人的喜好,不过微软现在的统一风格是下划线,比如表sys.all_columns/sys.tables,然后你再看他的列全是下划线连接,name     /object_id    /principal_id    /schema_id    /parent_object_id      /type    /type_desc    /create_date    /modify_date 我个人的喜好也是喜欢下划线。    

石沫 2019-12-02 01:34:30 0 浏览量 回答数 0

问题

如何保证消息队列的高可用?【Java问答学堂】20期

剑曼红尘 2020-05-18 11:21:10 2 浏览量 回答数 1

回答

Python 的 Decorator在使用上和Java/C#的Annotation很相似,就是在方法名前面加一个@XXX注解来为这个方法装饰一些东西。但是,Java/C#的Annotation也很让人望而却步,太TMD的复杂了,你要玩它,你需要了解一堆Annotation的类库文档,让人感觉就是在学另外一门语言。 而Python使用了一种相对于Decorator Pattern和Annotation来说非常优雅的方法,这种方法不需要你去掌握什么复杂的OO模型或是Annotation的各种类库规定,完全就是语言层面的玩法:一种函数式编程的技巧。如果你看过本站的《函数式编程》,你一定会为函数式编程的那种“描述你想干什么,而不是描述你要怎么去实现”的编程方式感到畅快。(如果你不了解函数式编程,那在读本文之前,还请你移步去看看《函数式编程》) 好了,我们先来点感性认识,看一个Python修饰器的Hello World的代码。 Hello World 下面是代码:文件名:hello.py def hello(fn): def wrapper(): print "hello, %s" % fn.__name__ fn() print "goodby, %s" % fn.__name__ return wrapper @hellodef foo(): print "i am foo" foo() 当你运行代码,你会看到如下输出: [chenaho@chenhao-air]$ python hello.pyhello, fooi am foogoodby, foo 你可以看到如下的东西: 1)函数foo前面有个@hello的“注解”,hello就是我们前面定义的函数hello 2)在hello函数中,其需要一个fn的参数(这就用来做回调的函数) 3)hello函数中返回了一个inner函数wrapper,这个wrapper函数回调了传进来的fn,并在回调前后加了两条语句。 Decorator 的本质 对于Python的这个@注解语法糖- Syntactic Sugar 来说,当你在用某个@decorator来修饰某个函数func时,如下所示: @decoratordef func(): pass 其解释器会解释成下面这样的语句: func = decorator(func) 尼玛,这不就是把一个函数当参数传到另一个函数中,然后再回调吗?是的,但是,我们需要注意,那里还有一个赋值语句,把decorator这个函数的返回值赋值回了原来的func。 根据《函数式编程》中的first class functions中的定义的,你可以把函数当成变量来使用,所以,decorator必需得返回了一个函数出来给func,这就是所谓的higher order function 高阶函数,不然,后面当func()调用的时候就会出错。 就我们上面那个hello.py里的例子来说, @hellodef foo(): print "i am foo" 被解释成了: foo = hello(foo) 是的,这是一条语句,而且还被执行了。你如果不信的话,你可以写这样的程序来试试看: def fuck(fn): print "fuck %s!" % fn.__name__[::-1].upper() @fuckdef wfg(): pass 没了,就上面这段代码,没有调用wfg()的语句,你会发现, fuck函数被调用了,而且还很NB地输出了我们每个人的心声! 再回到我们hello.py的那个例子,我们可以看到,hello(foo)返回了wrapper()函数,所以,foo其实变成了wrapper的一个变量,而后面的foo()执行其实变成了wrapper()。 知道这点本质,当你看到有多个decorator或是带参数的decorator,你也就不会害怕了。 比如:多个decorator @decorator_one@decorator_twodef func(): pass 相当于: func = decorator_one(decorator_two(func)) 比如:带参数的decorator: @decorator(arg1, arg2)def func(): pass 相当于: func = decorator(arg1,arg2)(func) 这意味着decorator(arg1, arg2)这个函数需要返回一个“真正的decorator”。 带参数及多个Decrorator 我们来看一个有点意义的例子:html.py def makeHtmlTag(tag, args, *kwds): def real_decorator(fn): css_class = " class='{0}'".format(kwds["css_class"]) if "css_class" in kwds else "" def wrapped(*args, **kwds): return "<"+tag+css_class+">" + fn(*args, **kwds) + "</"+tag+">" return wrapped return real_decorator @makeHtmlTag(tag="b", css_class="bold_css")@makeHtmlTag(tag="i", css_class="italic_css")def hello(): return "hello world" print hello() 输出: hello world 在上面这个例子中,我们可以看到:makeHtmlTag有两个参数。所以,为了让 hello = makeHtmlTag(arg1, arg2)(hello) 成功,makeHtmlTag 必需返回一个decorator(这就是为什么我们在makeHtmlTag中加入了real_decorator()的原因),这样一来,我们就可以进入到 decorator 的逻辑中去了—— decorator得返回一个wrapper,wrapper里回调hello。看似那个makeHtmlTag() 写得层层叠叠,但是,已经了解了本质的我们觉得写得很自然。 你看,Python的Decorator就是这么简单,没有什么复杂的东西,你也不需要了解过多的东西,使用起来就是那么自然、体贴、干爽、透气,独有的速效凹道和完美的吸收轨迹,让你再也不用为每个月的那几天感到焦虑和不安,再加上贴心的护翼设计,量多也不用当心。对不起,我调皮了。 什么,你觉得上面那个带参数的Decorator的函数嵌套太多了,你受不了。好吧,没事,我们看看下面的方法。 class式的 Decorator 首先,先得说一下,decorator的class方式,还是看个示例: class myDecorator(object): def __init__(self, fn): print "inside myDecorator.__init__()" self.fn = fn def __call__(self): self.fn() print "inside myDecorator.__call__()" @myDecoratordef aFunction(): print "inside aFunction()" print "Finished decorating aFunction()" aFunction() 输出: inside myDecorator.__init__() Finished decorating aFunction() inside aFunction() inside myDecorator.__call__() 上面这个示例展示了,用类的方式声明一个decorator。我们可以看到这个类中有两个成员:1)一个是__init__(),这个方法是在我们给某个函数decorator时被调用,所以,需要有一个fn的参数,也就是被decorator的函数。2)一个是__call__(),这个方法是在我们调用被decorator函数时被调用的。上面输出可以看到整个程序的执行顺序。 这看上去要比“函数式”的方式更易读一些。 下面,我们来看看用类的方式来重写上面的html.py的代码:html.py class makeHtmlTagClass(object): def __init__(self, tag, css_class=""): self._tag = tag self._css_class = " class='{0}'".format(css_class) if css_class !="" else "" def __call__(self, fn): def wrapped(*args, **kwargs): return "<" + self._tag + self._css_class+">" + fn(*args, **kwargs) + "</" + self._tag + ">" return wrapped @makeHtmlTagClass(tag="b", css_class="bold_css")@makeHtmlTagClass(tag="i", css_class="italic_css")def hello(name): return "Hello, {}".format(name) print hello("Hao Chen") 上面这段代码中,我们需要注意这几点:1)如果decorator有参数的话,__init__() 成员就不能传入fn了,而fn是在__call__的时候传入的。2)这段代码还展示了 wrapped(args, *kwargs) 这种方式来传递被decorator函数的参数。(其中:args是一个参数列表,kwargs是参数dict,具体的细节,请参考Python的文档或是StackOverflow的这个问题,这里就不展开了) 用Decorator设置函数的调用参数 你有三种方法可以干这个事: 第一种,通过 **kwargs,这种方法decorator会在kwargs中注入参数。 def decorate_A(function): def wrap_function(*args, **kwargs): kwargs['str'] = 'Hello!' return function(*args, **kwargs) return wrap_function @decorate_Adef print_message_A(args, *kwargs): print(kwargs['str']) print_message_A() 第二种,约定好参数,直接修改参数 def decorate_B(function): def wrap_function(*args, **kwargs): str = 'Hello!' return function(str, *args, **kwargs) return wrap_function @decorate_Bdef print_message_B(str, args, *kwargs): print(str) print_message_B() 第三种,通过 *args 注入 def decorate_C(function): def wrap_function(*args, **kwargs): str = 'Hello!' #args.insert(1, str) args = args +(str,) return function(*args, **kwargs) return wrap_function class Printer: @decorate_C def print_message(self, str, *args, **kwargs): print(str) p = Printer()p.print_message() Decorator的副作用 到这里,我相信你应该了解了整个Python的decorator的原理了。 相信你也会发现,被decorator的函数其实已经是另外一个函数了,对于最前面那个hello.py的例子来说,如果你查询一下foo.__name__的话,你会发现其输出的是“wrapper”,而不是我们期望的“foo”,这会给我们的程序埋一些坑。所以,Python的functool包中提供了一个叫wrap的decorator来消除这样的副作用。下面是我们新版本的hello.py。文件名:hello.py from functools import wrapsdef hello(fn): @wraps(fn) def wrapper(): print "hello, %s" % fn.__name__ fn() print "goodby, %s" % fn.__name__ return wrapper @hellodef foo(): '''foo help doc''' print "i am foo" pass foo()print foo.__name__ #输出 fooprint foo.__doc__ #输出 foo help doc 当然,即使是你用了functools的wraps,也不能完全消除这样的副作用。 来看下面这个示例: from inspect import getmembers, getargspecfrom functools import wraps def wraps_decorator(f): @wraps(f) def wraps_wrapper(*args, **kwargs): return f(*args, **kwargs) return wraps_wrapper class SomeClass(object): @wraps_decorator def method(self, x, y): pass obj = SomeClass()for name, func in getmembers(obj, predicate=inspect.ismethod): print "Member Name: %s" % name print "Func Name: %s" % func.func_name print "Args: %s" % getargspec(func)[0] 输出: Member Name: method Func Name: method Args: [] 你会发现,即使是你你用了functools的wraps,你在用getargspec时,参数也不见了。 要修正这一问,我们还得用Python的反射来解决,下面是相关的代码: def get_true_argspec(method): argspec = inspect.getargspec(method) args = argspec[0] if args and args[0] == 'self': return argspec if hasattr(method, '__func__'): method = method.__func__ if not hasattr(method, 'func_closure') or method.func_closure is None: raise Exception("No closure for method.") method = method.func_closure[0].cell_contents return get_true_argspec(method) 当然,我相信大多数人的程序都不会去getargspec。所以,用functools的wraps应该够用了。 一些decorator的示例 好了,现在我们来看一下各种decorator的例子: 给函数调用做缓存 这个例实在是太经典了,整个网上都用这个例子做decorator的经典范例,因为太经典了,所以,我这篇文章也不能免俗。 from functools import wrapsdef memo(fn): cache = {} miss = object() @wraps(fn) def wrapper(*args): result = cache.get(args, miss) if result is miss: result = fn(*args) cache[args] = result return result return wrapper @memodef fib(n): if n < 2: return n return fib(n - 1) + fib(n - 2) 上面这个例子中,是一个斐波拉契数例的递归算法。我们知道,这个递归是相当没有效率的,因为会重复调用。比如:我们要计算fib(5),于是其分解成fib(4) + fib(3),而fib(4)分解成fib(3)+fib(2),fib(3)又分解成fib(2)+fib(1)…… 你可看到,基本上来说,fib(3), fib(2), fib(1)在整个递归过程中被调用了两次。 而我们用decorator,在调用函数前查询一下缓存,如果没有才调用了,有了就从缓存中返回值。一下子,这个递归从二叉树式的递归成了线性的递归。 Profiler的例子 这个例子没什么高深的,就是实用一些。 import cProfile, pstats, StringIO def profiler(func): def wrapper(*args, **kwargs): datafn = func.__name__ + ".profile" # Name the data file prof = cProfile.Profile() retval = prof.runcall(func, *args, **kwargs) #prof.dump_stats(datafn) s = StringIO.StringIO() sortby = 'cumulative' ps = pstats.Stats(prof, stream=s).sort_stats(sortby) ps.print_stats() print s.getvalue() return retval return wrapper 注册回调函数 下面这个示例展示了通过URL的路由来调用相关注册的函数示例: class MyApp(): def __init__(self): self.func_map = {} def register(self, name): def func_wrapper(func): self.func_map[name] = func return func return func_wrapper def call_method(self, name=None): func = self.func_map.get(name, None) if func is None: raise Exception("No function registered against - " + str(name)) return func() app = MyApp() @app.register('/')def main_page_func(): return "This is the main page." @app.register('/next_page')def next_page_func(): return "This is the next page." print app.call_method('/')print app.call_method('/next_page') 注意:1)上面这个示例中,用类的实例来做decorator。2)decorator类中没有__call__(),但是wrapper返回了原函数。所以,原函数没有发生任何变化。 给函数打日志 下面这个示例演示了一个logger的decorator,这个decorator输出了函数名,参数,返回值,和运行时间。 from functools import wrapsdef logger(fn): @wraps(fn) def wrapper(*args, **kwargs): ts = time.time() result = fn(*args, **kwargs) te = time.time() print "function = {0}".format(fn.__name__) print " arguments = {0} {1}".format(args, kwargs) print " return = {0}".format(result) print " time = %.6f sec" % (te-ts) return result return wrapper @loggerdef multipy(x, y): return x * y @loggerdef sum_num(n): s = 0 for i in xrange(n+1): s += i return s print multipy(2, 10)print sum_num(100)print sum_num(10000000) 上面那个打日志还是有点粗糙,让我们看一个更好一点的(带log level参数的): import inspectdef get_line_number(): return inspect.currentframe().f_back.f_back.f_lineno def logger(loglevel): def log_decorator(fn): @wraps(fn) def wrapper(*args, **kwargs): ts = time.time() result = fn(*args, **kwargs) te = time.time() print "function = " + fn.__name__, print " arguments = {0} {1}".format(args, kwargs) print " return = {0}".format(result) print " time = %.6f sec" % (te-ts) if (loglevel == 'debug'): print " called_from_line : " + str(get_line_number()) return result return wrapper return log_decorator 但是,上面这个带log level参数的有两具不好的地方,1) loglevel不是debug的时候,还是要计算函数调用的时间。2) 不同level的要写在一起,不易读。 我们再接着改进: import inspect def advance_logger(loglevel): def get_line_number(): return inspect.currentframe().f_back.f_back.f_lineno def _basic_log(fn, result, *args, **kwargs): print "function = " + fn.__name__, print " arguments = {0} {1}".format(args, kwargs) print " return = {0}".format(result) def info_log_decorator(fn): @wraps(fn) def wrapper(*args, **kwargs): result = fn(*args, **kwargs) _basic_log(fn, result, args, kwargs) return wrapper def debug_log_decorator(fn): @wraps(fn) def wrapper(*args, **kwargs): ts = time.time() result = fn(*args, **kwargs) te = time.time() _basic_log(fn, result, args, kwargs) print " time = %.6f sec" % (te-ts) print " called_from_line : " + str(get_line_number()) return wrapper if loglevel is "debug": return debug_log_decorator else: return info_log_decorator 你可以看到两点,1)我们分了两个log level,一个是info的,一个是debug的,然后我们在外尾根据不同的参数返回不同的decorator。2)我们把info和debug中的相同的代码抽到了一个叫_basic_log的函数里,DRY原则。 一个MySQL的Decorator 下面这个decorator是我在工作中用到的代码,我简化了一下,把DB连接池的代码去掉了,这样能简单点,方便阅读。 import umysqlfrom functools import wraps class Configuraion: def __init__(self, env): if env == "Prod": self.host = "coolshell.cn" self.port = 3306 self.db = "coolshell" self.user = "coolshell" self.passwd = "fuckgfw" elif env == "Test": self.host = 'localhost' self.port = 3300 self.user = 'coolshell' self.db = 'coolshell' self.passwd = 'fuckgfw' def mysql(sql): _conf = Configuraion(env="Prod") def on_sql_error(err): print err sys.exit(-1) def handle_sql_result(rs): if rs.rows > 0: fieldnames = [f[0] for f in rs.fields] return [dict(zip(fieldnames, r)) for r in rs.rows] else: return [] def decorator(fn): @wraps(fn) def wrapper(*args, **kwargs): mysqlconn = umysql.Connection() mysqlconn.settimeout(5) mysqlconn.connect(_conf.host, _conf.port, _conf.user, _conf.passwd, _conf.db, True, 'utf8') try: rs = mysqlconn.query(sql, {}) except umysql.Error as e: on_sql_error(e) data = handle_sql_result(rs) kwargs["data"] = data result = fn(*args, **kwargs) mysqlconn.close() return result return wrapper return decorator @mysql(sql = "select * from coolshell" )def get_coolshell(data): ... ... ... .. 线程异步 下面量个非常简单的异步执行的decorator,注意,异步处理并不简单,下面只是一个示例。 from threading import Threadfrom functools import wraps def async(func): @wraps(func) def async_func(*args, **kwargs): func_hl = Thread(target = func, args = args, kwargs = kwargs) func_hl.start() return func_hl return async_func if name == '__main__': from time import sleep @async def print_somedata(): print 'starting print_somedata' sleep(2) print 'print_somedata: 2 sec passed' sleep(2) print 'print_somedata: 2 sec passed' sleep(2) print 'finished print_somedata' def main(): print_somedata() print 'back in main' print_somedata() print 'back in main' main() 其它 关于更多的示例,你可以参看: Python Decorator Library来源:网络

51干警网 2019-12-02 01:10:47 0 浏览量 回答数 0

回答

Re我和iDBCloud登录数据库的故事 11到13年做DBA的时候,最早接触的是iDB,我的理解之所以叫iDB应该是表达我的数据库的含义吧,估计我还是上学的时候就已经有了,目前iDB已经迭代到3.0,明年初会发布4.0,从DBA视角上看iDB就是可以review业务SQL,自动执行线上DDL,业务数据提取的申请和审批,WEB上的数据查询,最近做产品经理后才有机会系统的审视iDB(一个包含研发支撑、安全管控的企业级数据库管理产品),支撑了淘宝、天猫、支付宝(现在叫蚂蚁金服)的研发流程,保障了每年的双十一,但iDB Cloud与iDB不是一个产品,iDB是企业版的数据库管理产品,iDB Cloud则定位于个人版数据管理,相比企业中的流程约束,iDB Cloud更期望给大家提供在约束下的易用性最大化的灵活数据管理服务! ------------------------- Re我和iDBCloud登录数据库的故事 这个月实例信息-实时性能UI改版发布,新版看起来还是比较舒服的!这个我在5元RDS大促时买的,没有跑业务,所以指标都是0,哈哈 实时性能的原型取自阿里DBA团队的传奇(朱旭)之手:orzdba,貌似很久之前已经开源,谷歌下便知! 翻出之前做DBA使用orzdba观察测试机器压测的截图,orzdba是用perl写的,检查项还是蛮多的,比如io吞吐量、rt、主机的load、swap、innodb row、innodb状态,这些是iDB Cloud没有的功能,iDB Cloud通过用户登录账号访问数据库,只能拿到MySQL进程内存中的状态信息,没有权限拿到主机指标,不过innodb相关信息是可以拿到的,但是考虑一般只有DBA才会关注这些细节,所以没开放,不知道大家还会关注什么指标?有没有办法拿到主机的指标? ------------------------- 回5楼ringtail的帖子 刷新页面,类似关闭并重新打开,啥都没了,这个应该是正常的行为,话说为什么要刷新呢,我记得首页性能指标每5分钟自动刷新,即使点击页面上提供的刷新是没啥事的,而实时性能是每4秒更新一行的,还有什么场景要刷洗整个页面是我没想到的吗? ------------------------- 回7楼ringtail的帖子 目前据我所知,真心还做不到刷新不丢iDB Cloud已经打开的选项卡、sql语句和执行结果什么的,现在只能在刷新时加一个“导航确认”,减少手痒式误刷新,哈哈 ------------------------- Re我和iDBCloud登录数据库的故事 翻工单时,发现有人关心使用iDB Cloud是否会收取流量费,我也没搞清楚,于是问了几个同事,终于把场景基本覆盖了,最终结论: 只要你不把你的RDS实例切换成外网(公网)模式的同时再导出或查询数据就不会收取流量费! 由于那几个工单已经关闭,我就在这里回复下大家,希望那几个朋友能看到 ------------------------- 回9楼yzsind的帖子 一定不会辜负领导的期望,努力工作,争取升职加薪,当上总经理,出任ceo,迎娶白富美,想想还有点小激动 ------------------------- 回10楼佩恩六道的帖子 可能文字不好理解整体的流量计费情况,中午用我那小学的美术细胞,完成了一副“巨作”! ------------------------- Re我和iDBCloud登录数据库的故事 刚才看到一个工单(iDB Cloud点击登录无效),这个工单已经处理完毕,但我觉得可以把售后同学的方法和大家分享下! 以后遇到点击登录无效、登录后菜单栏点击无效、页面展示不全,很可能是浏览器兼容设置的问题! 浏览器兼容设置的问题: 1.检查浏览器是否安装了AdBlockPlus(火狐浏览器的一个扩展),用火狐浏览器的用户遇到类似问题要注意这一点 2.IE浏览器的话就调整下兼容性模式(http://jingyan.baidu.com/article/fcb5aff791bb47edaa4a7115.html ),并进入开发者模式再测试下IDB Cloud 如果上述2招还是解决不了,记得留言给我! ------------------------- Re我和iDBCloud登录数据库的故事 今天看工单时发现有个朋友反馈,包含mediumblob类型字段的表在做导出后,导出文件中没有mediumblob类型字段! 其实导出时默认是不会导出BLOB类型字段,但是在导出-高级选项中是可以选择导出BLOB,但是BLOB字段只能以16进制格式导出,试想一个WORD文档或者一首歌曲,16进制导出后,没啥意义! BOLB字段支持WEB界面上传和下载,是原文件呀,哈哈! ------------------------- Re我和iDBCloud登录数据库的故事 未来几天休假,去考驾照 ------------------------- Re我和iDBCloud登录数据库的故事 看工单和论坛中,有用户会抱怨产品不好用,然后就消失了,真的好可惜! 作为产品经理是很想倾听这些抱怨背后的真实想法,期待可以直接对话,无论是功能缺失,还是操作不便,哪怕是使用上的一种感觉或产品散发的味道不对都可以,不求需求,只求对话! ------------------------- Re我和iDBCloud登录数据库的故事 感谢你的关注和支持! 产品说到底不是产品经理个人的,也不是哪个企业的,而是用户的产品,水能载舟亦能覆舟,产品经理和企业只不过在帮用户把需求实现而已,所以我们会一直坚持下去,坚持和用户一起把iDB Cloud做得更好 ------------------------- Re我和iDBCloud登录数据库的故事 最近几天公司感冒发烧的同学很多,我也是坚持了好几天才沦陷的,这是在我记忆中来杭州4年第一次发烧,看来20多年在东北积累的体质终于被消耗殆尽,不过意外收获是在高烧间隔清醒之际对最近自己的所作所为反倒有了一些悔悟,有些是工作上,有些是做人上 ------------------------- 回24楼zhouzhenxing的帖子 可以的,iDB Cloud对RDS公网和私网模式都是支持的! 你可以在RDS控制台-账号管理中 新建你的数据库账号,然后还是在RDS控制台的右上角,点击“登录数据库”就可以进入iDB Cloud了,建议你先自己试着玩玩,有困惑的话我们一同讨论 ------------------------- 回24楼zhouzhenxing的帖子 iDB Cloud在官网上有2个手册,写的比较官方,可能对你用处不大,我其实不太喜欢写什么手册,如果一个产品做的体验不好,只能靠手册来弥补还是有点low,不过我已经在想如何不low了,还是那句话 有困惑的话我们一同讨论 http://help.aliyun.com/doc/view/13526530.html?spm=0.0.0.0.6W7Qx1 http://help.aliyun.com/view/11108238_13861850.html?spm=5176.7224961.1997285473.4.Irtizv ------------------------- Re我和iDBCloud登录数据库的故事 都说在产品上做加法容易,做减法难,我理解无论产品功能还是工作上,给予总会得到别人的喜欢,而要求或收回时会得到对方的负面情绪,因此趋利避害,尽量不做减法,但有时候很难避免,这就要想想为什么要做减法? 多数都是之前错误选择,做了过多的加法,因为普通的加法很好做,人们往往会趋之如骛,但是真正、正确的加法是要在拒绝几十到上百种选择基础上的最终选择,将复杂解决方案以极简形式展现出来,而不是解决方案和功能的堆积,所以未经严格挑选的加法对产品是有害的,工作也一样,不要贸然接受新工作,保证核心精力投入到核心工作上,摊子铺得太大,一定会遇到心力瓶颈,而心力一旦枯竭,再强的脑力也无法施展,任何一项工作都是以大量心力付出为前提,脑力提升我找到了一些办法,心力提升却一筹莫展,所以只好专注,要不全心投入,要不置身事外,今后功能和工作都要适时做做减法了! ------------------------- Re我和iDBCloud登录数据库的故事 今天有个同事转给我一个工单,说从深圳云管理系统界面的iDB Cloud上看到库是utf8,而后端开发人员说库是gbk的,我查看了工单中截图附件(RDS控制台-参数设置),虽然从工单中无法完全断定用户遇到的问题,我还是大胆猜测下: 我看到截图上的character_set_server参数,首先character_set_server是RDS唯一开放的关于字符集的参数,但其实这个参数与用户在iDB Cloud上看到数据是否乱码没有关系,character_set_server其实就是默认的内部操作字符集,只有当字段->表->库都没有设置CHARACTER SET,才会使用character_set_server作为对应字段-表-库的默认字符集! 透露一个秘诀(传男也传女): (1)让你的字段-表-库的字符集都是utf8; (2)在iDB Cloud-命令窗口执行set names utf8;#会将character_set_client、character_set_connection和character_set_results都设置成utf8 只要让(1)和(2)字符集保持一致(utf8、gbk、latin1等),乱码就搞定了! 不清楚为什么截图会变成上面这样!把在iDB Cloud-命令窗口上执行的命令和结果也粘下 mysql>set names gbk; 执行成功,花费 7.59 ms. mysql>show  variables like '%char%'; +--------------------------+----------------------------------+ | Variable_name            | Value                            | +--------------------------+----------------------------------+ | character_set_client     | gbk                              | | character_set_connection | gbk                              | | character_set_database   | gbk                              | | character_set_filesystem | binary                           | | character_set_results    | gbk                              | | character_set_server     | gbk                              | | character_set_system     | utf8                             | | character_sets_dir       | /u01/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------+ 共返回 8 行记录,花费 10.51 ms. mysql>set names utf8; 执行成功,花费 7.32 ms. mysql>show  variables like '%char%'; +--------------------------+----------------------------------+ | Variable_name            | Value                            | +--------------------------+----------------------------------+ | character_set_client     | utf8                             | | character_set_connection | utf8                             | | character_set_database   | gbk                              | | character_set_filesystem | binary                           | | character_set_results    | utf8                             | | character_set_server     | gbk                              | | character_set_system     | utf8                             | | character_sets_dir       | /u01/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------+ 共返回 8 行记录,花费 10.32 ms. ------------------------- Re我和iDBCloud登录数据库的故事 你的专属BUG: 发现时间 资深用户 专属BUG 2015-02-03 23:06 啊啊啊啊8  实例信息-实时性能-参数说明-【delete】 表示InnoDB存储引擎表的写入(删除)记录行数 ------------------------- Re我和iDBCloud登录数据库的故事 用户“夫子然”反馈说iDB Cloud感觉没phpMyAdmin方便! 非常感谢这个用户的反馈,我先谈下我的理解,每个人使用产品都有一些固定的用例(use case),我无法承诺针对任何人的任何用例,都做到最短操作路径(方便),这个用户抛出的问题也是我一直在思考的,虽然无法100%,但是我们可以覆盖主流用例,只要绝大多数的常规操作室是方便的,少数非经常用的操作路径长点,应该能接受吧,我们已经在行动! 今天iDB Cloud发布了2.0.2,一个主要变化就是在左侧对象列表上增加了“列”和“索引”,正是我们分析数据看到在众多数据库对象中表的操作是最频繁的,而在表的操作中“列“和”索引“是最频繁的,这个版本将对“列”和“索引”的操作前置,缩短了主流用例路径,与用户“夫子然”的建议不谋而合,这只是开始,只要我们深挖,与功能和体验死磕,终有一天会让大家说iDB Cloud比phpMyAdmin方便! ------------------------- 回31楼sqlserverdba的帖子 非常感谢! 有你们作为后盾,有用户支持,才有iDB Cloud的现在和未来! ------------------------- 消失了几天,终于把科目三和科目四搞定了,昨天终于拿到驾照了之前在【17楼】总结了科目二的一些体会,今天也分享下科目三的一点点感受! 考试前几天,教练说是智能考(据说智能考比较简单,通过率很高),结果就留出考前2天练车时间,结果阴差阳错的换成了人工考(貌似是我们车是4个大老爷们,听教练说他一年最多抽到2次人工考就算多的啦,对此我只能呵呵),现在的问题就来了,4个人2天练车时间,一个人半天,那就从早到晚的练呗,我先简单描述下整个过程! 1.心态(1)从开始练车到考试通过,心情没有特别大的起伏,不过考前失眠还是有的,哈哈(2)另外三个人,有的信心满满,有的吊儿郎当,有的不言不语,我应该也属于不言不语那种 2.练习(1)4个人轮流练,虽然一天下来很累,但还能挺住,开的时好时坏,不过总体上在变好(2)开车的时候几乎意识不到什么的,关键是在后座自己去琢磨,回忆自己错在哪里,为什么会错 3.考试(1)考试单上说7:00考试,结果在寒风中等了1个小时,终于盼来了考官,一共5辆车考试,我们是第二辆车(2)第一辆车是2男2女,2女都挂,当时我们第二辆车是被要求跟在第一辆车后面的,所以看的一清二楚,比如连续3次手刹未放下导致起步失败、4档走转弯到对向车道等(3)接下来到我们了,4男0女,结果挂了2男(信心满满和吊儿郎当) 上面只是简单介绍了科目三过程,下面才是干货! 每年都有成千上万的人拿到驾照,我不认为自己牛,只是把我个人的应对方法和背后的原因拿出来分享下!练车其实就是教练的心智模型-翻译-语言-反译-我们的心智模型,让我们知道在什么情况做什么动作,预测路况,只要我们关于开车拥有了自己的心智模,开车就变成了一种本能,就像一旦学会了骑自行车,很难失去这种技能,在练车之前,我们是有自己关于开车的心智模型的,正所谓没吃过猪肉也见过猪跑,但是我们想想自己关于开车的心智模型是正确的吗?显然不是,不信你就试试去开车吧,抛开被交警抓之外,我想应该也能开起来,至于开的好不好,会不会一直开得好,我说不准,但是绝大多数人一定是开不好的,所以我们报驾校,除了硬性法律规定,驾校教练的确交会了很多东西,虽然很多是应试的技巧,这里就顺便说下这些技巧,技巧具体内容每家教练都会教的,而我想说的技巧其实就是“语言”,通过教练的“心智模型”-翻译出来的“语言”,接下来我们要做什么,“反译”将教练开车技巧的“语言”理解,首先你要虚心去接受,然后再去观察或运用,根据反馈把坏的放弃,把好的保留以便修正自己关于开车的“心智模型”,而“心智模型”最快速的形成方式就是亲身体验,所以一定要实战、要开车,还要经常开车,不断改进关于开车的“心智模型”,拿3个案例具体说下吧!【吊儿郎当】这两天都是下午才过来练车,开车时教练说一句话,他有十句等着,其中五句是解释自己为什么要这么做,另外五句是在问如果这种情况应该怎么做,如果那种情况怎么做,总是在关注自己想象中的场景,而不关注自己正在体验的场景,所以学来学去还是最初始的关于开车的“心智模型”,失败在“反译”这一步,认为只要听过就会了,结果被考官判直接挂掉并不予补考机会 【信心满满】与我们一直练车,对教练的话言听计从,而且也理解了,如果是上学时的考试或科目三智能考试一定没问题,但是面对人工考,评判是由交警而不是电脑,结果转向时没有观察后视镜,被考官迫停在路中间后开始补考,然后还是转向时没有观察后视镜,在路中间起步,之前学的技巧中没有应对的方法,结果还是挂了,教练也很惋惜,如果说他的失败,败于没有改进自己关于开车的“心智模型”,其实“反译”他做的很好,但是在运用、观察和反馈分析上做的不好,“心智模型”不是统一的标准,一定是个性化的,一定是自己认为是好的反馈、行为积累起来的,也只有“心智模型”才能在任何情况下帮助你做出判断,判断效果就取决于“心智模型”是否成熟,成熟的“心智模型”可以让在紧张、突发等情况下依然做出正确的判断,因为那是一种本能 【我】总说别人不好之处,也谈谈我自己,自然这些都是我事后分析总结的,练车过程中可没有感受到,我做的事情也很简单,就是“反译”和改进我的“心智模型”,“反译”,教练说什么,我就听什么,开车时来不及想,就在后座时在脑中模拟上演之前的场景并不断上演我不断修正的剧本,比如我的离合器总是抬的很快,经常熄火,特别是在路况复杂、指令突然时根本来不及思考如何应对,只能靠本能的时候,往往还是会快速抬离合器,因为我的“心智模型”中就是这么认为的,你可以说是离合器太低、座位太靠后,这些都是理由,如果是理由,那就去解决吧!我是这样做的,强制自己将抬离合器的动作拆成3步,即使不开车时也经常练习,慢慢的就变成了“心智模型”的一部分,自然在任何场景下都不会再出现离合器抬快熄火的情况了,这只是一个细节,其他细节也是类似,慢慢我的“心智模型”就建立起来了,开车技巧是很有用的,关键是你要理解这些技巧是要解决什么问题,你要解决相同问题时的做法是否相同,如果有不同之处是否正确,要去不断验证,如果是正确的,就改进到你的“心智模型”吧! PD不光光是要把产品做好,我认为一个好PD应该能让整个世界变得更好! ------------------------- Re我和iDBCloud登录数据库的故事 近期iDB Cloud将更名:DMS DMS (data management service) 数据管理服务 iDB Cloud从RDS起步,目前已经覆盖包括RDS、ADS、TAE,未来2个月还会覆盖万网和DRDS,同时ECS也开始兼容,“DMS”请各位新老用户,继续支持! ------------------------- Re我和iDBCloud登录数据库的故事 1.使用HTTPS iDB Cloud这个4月份中旬版本就会支持HTTPS,敬请期待! 2.设置账号是否允许登录iDB 3.31 会发布一个版本,这版本其中一个功能就是授权登录,允许实例owner设置该实例是否允许别人访问,允许谁可以访问 有如此心犀相通的用户,夫复何求!!! 还有什么建议? ------------------------- 回38楼pillowsky的帖子 好的,我先逐条对照分析下 ------------------------- Re我和iDBCloud登录数据库的故事 RDS数据库?RDS控制台-账号管理,检查下账号对不对,不行就重置密码 ------------------------- Re我和iDBCloud登录数据库的故事 3.31 DMS(原iDB Cloud) 在RDS上新版本发布! 【实例授权】 DMS for MySQL 2.1发布! 【会话统计】 DMS for SQL Server 2.0发布! 【E-R图】 【对象列表】 ------------------------- Re我和iDBCloud登录数据库的故事 你是想听客服回复?算了,我还是从DMS PD 看RDS的视角来分享下吧! RDS是一个数据库,在数据库之外包装了一些东西,帮用户做了备份恢复、HA、监控等,回到你提到的账号,root账号在MySQL里是权限最大的,也是风险最大的,为了保证RDS这些备份恢复、HA能7*24小时为你服务,所以就不能让你的账号去影响到这些组件,不然你一个误操作把实例关闭了怎么办,但是我承认目前RDS在控制台上提供的账号的确限制比较死,所以在RDS上你是无法获取root账号的,话说你要root权限做什么,你说的数据库创建在RDS控制台上提供功能了 ------------------------- 回46楼苗教授的帖子 客气了,也不知道能不能帮上你! 如果从外看RDS的使用的话,可以在RDS控制台上去管理RDS实例(用用就熟悉了),或者直接调用OPEN API来完成实例管理操作,然后针对RDS实例中数据管理,就可以登录DMS,有几个常用链接发你看看,有问题可以在这里继续探讨! DMS: http://idb.rds.aliyun.com/ DMS 功能介绍: http://docs.aliyun.com/#/rds/getting-started/database-manage&login-database OPEN API: http://docs.aliyun.com/?spm=5176.383715.9.5.1LioEO#/rds/open-api/abstract RDS控制台: https://rds.console.aliyun.com/console/index#/

佩恩六道 2019-12-02 01:21:37 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站