• 关于

    分库 分区 分表

    的搜索结果

问题

是分库分表好还是分区好?

mq4096 2019-12-01 21:54:44 3755 浏览量 回答数 0

回答

什么是分表?分表是将一个大表按照一定的规则分解成多张具有独立存储空间的实体表,我们可以称为子表,每个表都对应三个文件,MYD数据文件,.MYI索引文件,.frm表结构文件。这些子表可以分布在同一块磁盘上,也可以在不同的机器上。app读写的时候根据事先定义好的规则得到对应的子表名,然后去操作它。什么是分区?分区和分表相似,都是按照规则分解表。不同在于分表将大表分解为若干个独立的实体表,而分区是将数据分段划分在多个位置存放,可以是同一块磁盘也可以在不同的机器。分区后,表面上还是一张表,但数据散列到多个位置了。app读写的时候操作的还是大表名字,db自动去组织分区的数据。mysql分表和分区有什么联系呢?1.都能提高mysql的性高,在高并发状态下都有一个良好的表现。2.分表和分区不矛盾,可以相互配合的,对于那些大访问量,并且表数据比较多的表,我们可以采取分表和分区结合的方式(如果merge这种分表方式,不能和分区配合的话,可以用其他的分表试),访问量不大,但是表数据很多的表,我们可以采取分区的方式等。3.分表技术是比较麻烦的,需要手动去创建子表,app服务端读写时候需要计算子表名。采用merge好一些,但也要创建子表和配置子表间的union关系。4.表分区相对于分表,操作方便,不需要创建子表。分表的几种方式:1、mysql集群它并不是分表,但起到了和分表相同的作用。集群可分担数据库的操作次数,将任务分担到多台数据库上。集群可以读写分离,减少读写压力。从而提升数据库性能。2、自定义规则分表大表可以按照业务的规则来分解为多个子表。通常为以下几种类型,也可自己定义规则。Range(范围)–这种模式允许将数据划分不同范围。例如可以将一个表通过年份划分成若干个分区。Hash(哈希)–这中模式允许通过对表的一个或多个列的Hash Key进行计算,最后通过这个Hash码不同数值对应的数据区域进行分区。例如可以建立一个对表主键进行分区的表。Key(键值)-上面Hash模式的一种延伸,这里的Hash Key是MySQL系统产生的。List(预定义列表)–这种模式允许系统通过预定义的列表的值来对数据进行分割。Composite(复合模式) –以上模式的组合使用  目前比较流行直接以标识字段取hash值,一般分库 跟分表都是基于相同字段,但是不同分母。

bruce.wang 2019-12-02 01:44:14 0 浏览量 回答数 0

回答

MERGE只能联合MyISAM表查询,分库比分表复杂,分表比分区复杂,没事就别去碰分表分库,除了要自己设计,还要修改业务SQL语句,比如你得路由 到哪张表,哪个库,还有跨表跨库事务又该怎么实现,MySQL本身都是不支持的,但分区是MySQL本身就支持的,分区合理,能明显减轻数据量很大的单表的压力, 所以还是先从SQL索引优化入手,需要的话,再考虑怎么根据业务合理分区吧。

小旋风柴进 2019-12-02 02:04:52 0 浏览量 回答数 0

阿里云爆款特惠专场,精选爆款产品低至0.95折!

爆款ECS云服务器8.1元/月起,云数据库低至1.5折,限时抢购!

问题

DRDS SQL 路由都有什么?

猫饭先生 2019-12-01 21:19:27 1001 浏览量 回答数 0

问题

Mysql 大数据 拆分 大家是怎么玩的?

小旋风柴进 2019-12-01 20:14:57 885 浏览量 回答数 1

回答

当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围: 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。;读/写分离: 经典的数据库拆分方案,主库负责写,从库负责读;缓存: 使用MySQL的缓存,另外对重量级、更新少的数据可以考虑使用应用级别的缓存; 还有就是通过分库分表的方式进行优化,主要有垂直分表和水平分表 垂直分区: 根据数据库里面数据表的相关性进行拆分。 例如,用户表中既有用户的登录信息又有用户的基本信息,可以将用户表拆分成两个单独的表,甚至放到单独的库做分库。 简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。 如下图所示,这样来说大家应该就更容易理解了。 垂直拆分的优点: 可以使得行数据变小,在查询时减少读取的Block数,减少I/O次数。此外,垂直分区可以简化表的结构,易于维护。 垂直拆分的缺点: 主键会出现冗余,需要管理冗余列,并会引起Join操作,可以通过在应用层进行Join来解决。此外,垂直分区会让事务变得更加复杂; 垂直分表 把主键和一些列放在一个表,然后把主键和另外的列放在另一个表中 适用场景 1、如果一个表中某些列常用,另外一些列不常用 2、可以使数据行变小,一个数据页能存储更多数据,查询时减少I/O次数 缺点 有些分表的策略基于应用层的逻辑算法,一旦逻辑算法改变,整个分表逻辑都会改变,扩展性较差 对于应用层来说,逻辑算法增加开发成本 管理冗余列,查询所有数据需要join操作 水平分区: 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。 水平拆分可以支撑非常大的数据量。 水平拆分是指数据表行的拆分,表的行数超过200万行时,就会变慢,这时可以把一张的表的数据拆成多张表来存放。举个例子:我们可以将用户信息表拆分成多个用户信息表,这样就可以避免单一表数据量过大对性能造成影响。 水品拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题,但由于表的数据还是在同一台机器上,其实对于提升MySQL并发能力没有什么意义,所以 水平拆分最好分库 。 水平拆分能够 支持非常大的数据量存储,应用端改造也少,但 分片事务难以解决 ,跨界点Join性能较差,逻辑复杂。 《Java工程师修炼之道》的作者推荐 尽量不要对数据进行分片,因为拆分会带来逻辑、部署、运维的各种复杂度 ,一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片,尽量选择客户端分片架构,这样可以减少一次和中间件的网络I/O。 水平分表: 表很大,分割后可以降低在查询时需要读的数据和索引的页数,同时也降低了索引的层数,提高查询次数 适用场景 1、表中的数据本身就有独立性,例如表中分表记录各个地区的数据或者不同时期的数据,特别是有些数据常用,有些不常用。 2、需要把数据存放在多个介质上。 水平切分的缺点 1、给应用增加复杂度,通常查询时需要多个表名,查询所有数据都需UNION操作 2、在许多数据库应用中,这种复杂度会超过它带来的优点,查询时会增加读一个索引层的磁盘次数 下面补充一下数据库分片的两种常见方案: 客户端代理: 分片逻辑在应用端,封装在jar包中,通过修改或者封装JDBC层来实现。 当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。 中间件代理: 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。 分库分表后面临的问题 事务支持 分库分表后,就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价; 如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。 跨库join 只要是进行切分,跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。 分库分表方案产品 跨节点的count,order by,group by以及聚合函数问题 这些是一类问题,因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案:与解决跨节点join问题的类似,分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行,因此很多时候它的速度要比单一大表快很多。但如果结果集很大,对应用程序内存的消耗是一个问题。 数据迁移,容量规划,扩容等问题 来自淘宝综合业务平台团队,它利用对2的倍数取余具有向前兼容的特性(如对4取余得1的数对2取余也是1)来分配数据,避免了行级别的数据迁移,但是依然需要进行表级别的迁移,同时对扩容规模和分表数量都有限制。总得来说,这些方案都不是十分的理想,多多少少都存在一些缺点,这也从一个侧面反映出了Sharding扩容的难度。 ID问题 一旦数据库被切分到多个物理结点上,我们将不能再依赖数据库自身的主键生成机制。一方面,某个分区数据库自生成的ID无法保证在全局上是唯一的;另一方面,应用程序在插入数据之前需要先获得ID,以便进行SQL路由. 一些常见的主键生成策略

剑曼红尘 2020-03-31 11:34:39 0 浏览量 回答数 0

回答

一、数据库瓶颈 不管是IO瓶颈,还是CPU瓶颈,最终都会导致数据库的活跃连接数增加,进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是,可用数据库连接少甚至无连接可用。接下来就可以想象了吧(并发量、吞吐量、崩溃)。 1、IO瓶颈 第一种:磁盘读IO瓶颈,热点数据太多,数据库缓存放不下,每次查询时会产生大量的IO,降低查询速度 -> 分库和垂直分表。 第二种:网络IO瓶颈,请求的数据太多,网络带宽不够 -> 分库。 2、CPU瓶颈 第一种:SQL问题,如SQL中包含join,group by,order by,非索引字段条件查询等,增加CPU运算的操作 -> SQL优化,建立合适的索引,在业务Service层进行业务计算。 第二种:单表数据量太大,查询时扫描的行太多,SQL效率低,CPU率先出现瓶颈 -> 水平分表。 二、分库分表 1、水平分库 概念:以字段为依据,按照一定策略(hash、range等),将一个库中的数据拆分到多个库中。 结果: 每个库的结构都一样; 每个库的数据都不一样,没有交集; 所有库的并集是全量数据; 场景:系统绝对并发量上来了,分表难以根本上解决问题,并且还没有明显的业务归属来垂直分库。 分析:库多了,io和cpu的压力自然可以成倍缓解。 2、水平分表 概念:以字段为依据,按照一定策略(hash、range等),将一个表中的数据拆分到多个表中。 结果: 每个表的结构都一样; 每个表的数据都不一样,没有交集; 所有表的并集是全量数据; 场景:系统绝对并发量并没有上来,只是单表的数据量太多,影响了SQL效率,加重了CPU负担,以至于成为瓶颈。推荐:一次SQL查询优化原理分析 分析:表的数据量少了,单次SQL执行效率高,自然减轻了CPU的负担。 3、垂直分库 概念:以表为依据,按照业务归属不同,将不同的表拆分到不同的库中。 结果: 每个库的结构都不一样; 每个库的数据也不一样,没有交集; 所有库的并集是全量数据; 场景:系统绝对并发量上来了,并且可以抽象出单独的业务模块。 分析:到这一步,基本上就可以服务化了。例如,随着业务的发展一些公用的配置表、字典表等越来越多,这时可以将这些表拆到单独的库中,甚至可以服务化。再有,随着业务的发展孵化出了一套业务模式,这时可以将相关的表拆到单独的库中,甚至可以服务化。 4、垂直分表 概念:以字段为依据,按照字段的活跃性,将表中字段拆到不同的表(主表和扩展表)中。 结果: 每个表的结构都不一样; 每个表的数据也不一样,一般来说,每个表的字段至少有一列交集,一般是主键,用于关联数据; 所有表的并集是全量数据; 场景:系统绝对并发量并没有上来,表的记录并不多,但是字段多,并且热点数据和非热点数据在一起,单行数据所需的存储空间较大。以至于数据库缓存的数据行减少,查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈。 分析:可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据(可能会冗余经常一起查询的数据)放在一起作为主表,非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来,进而减少了随机读IO。拆了之后,要想获得全部数据就需要关联两个表来取数据。 但记住,千万别用join,因为join不仅会增加CPU负担并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据,应该在业务Service层做文章,分别获取主表和扩展表数据然后用关联字段关联得到全部数据。 三、分库分表工具 sharding-sphere:jar,前身是sharding-jdbc; TDDL:jar,Taobao Distribute Data Layer; Mycat:中间件。 注:工具的利弊,请自行调研,官网和社区优先。 四、分库分表步骤 根据容量(当前容量和增长量)评估分库或分表个数 -> 选key(均匀)-> 分表规则(hash或range等)-> 执行(一般双写)-> 扩容问题(尽量减少数据的移动)。 扩展:MySQL:分库分表与分区的区别和思考 五、分库分表问题 1、非partition key的查询问题 基于水平分库分表,拆分策略为常用的hash法。 端上除了partition key只有一个非partition key作为条件查询 映射法 基因法 注:写入时,基因法生成user_id,如图。关于xbit基因,例如要分8张表,23=8,故x取3,即3bit基因。根据user_id查询时可直接取模路由到对应的分库或分表。 根据user_name查询时,先通过user_name_code生成函数生成user_name_code再对其取模路由到对应的分库或分表。id生成常用snowflake算法。 端上除了partition key不止一个非partition key作为条件查询 映射法 冗余法 注:按照order_id或buyer_id查询时路由到db_o_buyer库中,按照seller_id查询时路由到db_o_seller库中。感觉有点本末倒置!有其他好的办法吗?改变技术栈呢? 后台除了partition key还有各种非partition key组合条件查询 NoSQL法 冗余法 2、非partition key跨库跨表分页查询问题 基于水平分库分表,拆分策略为常用的hash法。 注:用NoSQL法解决(ES等)。 3、扩容问题 基于水平分库分表,拆分策略为常用的hash法。 水平扩容库(升级从库法) 注:扩容是成倍的。 水平扩容表(双写迁移法) 第一步:(同步双写)修改应用配置和代码,加上双写,部署; 第二步:(同步双写)将老库中的老数据复制到新库中; 第三步:(同步双写)以老库为准校对新库中的老数据; 第四步:(同步双写)修改应用配置和代码,去掉双写,部署; 注:双写是通用方案。 六、分库分表总结 分库分表,首先得知道瓶颈在哪里,然后才能合理地拆分(分库还是分表?水平还是垂直?分几个?)。且不可为了分库分表而拆分。 选key很重要,既要考虑到拆分均匀,也要考虑到非partition key的查询。 只要能满足需求,拆分规则越简单越好。 七、分库分表示例 示例GitHub地址:https://github.com/littlecharacter4s/study-sharding 来源:cnblogs.com/littlecharacter/p/9342129.html 俩元

AA大大官 2020-03-31 12:45:48 0 浏览量 回答数 0

回答

DLA多库合并建仓是指通过DLA控制台向导将RDS中的分库分表数据聚合到统一的表中,以分区表的形式存储数据。您既可以全局地分析所有数据,又可以选择某个分区对分区数据进行聚焦分析,不影响RDS端的业务运行。

LiuWH 2020-03-23 10:58:55 0 浏览量 回答数 0

回答

a)可使用大数据开发套件,目前套件是不收费的:https://help.aliyun.com/document_detail/57121.htmlrds(mysql)支持分库分表导入:https://help.aliyun.com/knowledge_detail/49814.html注意,无论数据存储在同一数据库还是不同数据库,表结构必须是一致的。b)导出到MaxCompute, 必须指定一张表或者表的分区(如果是分区表)。https://help.aliyun.com/knowledge_detail/49824.htmlc)不支持。

云栖技术 2019-12-02 00:27:29 0 浏览量 回答数 0

回答

1、物理上用PCIe SSD搭建固态存储。2、利用MySQL主从复制机制和中间件MySQL-Proxy/Qihoo360 Atlas/Alibaba Cobar/TDDL/Amoeba和HAProxy/LVS实现读写分离和负载均衡。3、按照业务逻辑合理分区、分表、分库。4、Redis、Memcached做数据库缓存。

落地花开啦 2019-12-02 01:50:52 0 浏览量 回答数 0

回答

1、物理上用PCIe SSD搭建固态存储。2、利用MySQL主从复制机制和中间件MySQL-Proxy/Qihoo360 Atlas/Alibaba Cobar/TDDL/Amoeba和HAProxy/LVS实现读写分离和负载均衡。3、按照业务逻辑合理分区、分表、分库。4、Redis、Memcached做数据库缓存。

小旋风柴进 2019-12-02 02:04:57 0 浏览量 回答数 0

回答

前端优化(CND加速、建立独立图片服务器) 服务端优化(页面静态化、并发处理[异步|多线程]、队列处理) 数据库优化(数据库缓存[Memcachaed|Redis]、读写分离、分库分表、分区) Web服务器优化(负载均衡、反向代理)

珍宝珠 2019-12-02 03:16:32 0 浏览量 回答数 0

回答

优化索引、SQL 语句、分析慢查询; 设计表的时候严格根据数据库的设计范式来设计数据库; 使用缓存,把经常访问到的数据而且不需要经常变化的数据放在缓存中,能 节约磁盘IO; 优化硬件;采用SSD,使用磁盘队列技术(RAID0,RAID1,RDID5)等; 采用MySQL 内部自带的表分区技术,把数据分层不同的文件,能够提高磁 盘的读取效率; 垂直分表;把一些不经常读的数据放在一张表里,节约磁盘I/O; 主从分离读写;采用主从复制把数据库的读操作和写入操作分离开来; 分库分表分机器(数据量特别大),主要的的原理就是数据路由; 选择合适的表引擎,参数上的优化; 进行架构级别的缓存,静态化和分布式; 不采用全文索引; 采用更快的存储方式,例如 NoSQL存储经常访问的数据

茶什i 2019-12-02 03:09:06 0 浏览量 回答数 0

问题

ORM框架在大数据面前的处理问题

落地花开啦 2019-12-01 19:48:10 1205 浏览量 回答数 1

回答

不好回答,也不建议过早考虑。是不是可以这样理解“数据量可能会很大”,现在刚开始搞,数据量不大,但是以后备不住就成淘宝了,数据量必然很大。其实不管是采用分表、分区、Merge引擎的方式,都是可以随时进行的,而不需要在初期就做如此长远的打算,因为你计划了也不如变化,比如典型的hash方式,你留几位?留2位,那以后数据量大了还是不够,留6位?分的表比数据都多。而且数据量太大的时候光靠分是不行的,需要的是冗余才能提升性能,一套按user切,一套按交易时间切,如果你还想根据购买的商品查询交易记录,好的,再来一套按商品信息切。我觉得分库是不太需要考虑的,因为你可以使用分布式文件系统玩儿集群,所谓分库其实就是把数据分成常用的,几乎不用的,压箱底的这么几个类型分开。我没分过库,此段纯属臆测。

a123456678 2019-12-02 02:59:47 0 浏览量 回答数 0

回答

试试利用merge存储引擎来实现分表###### 1.应该不可以,以前找过类似解决办法没实现 2. PARTITION BY RANGE (RIGHT(uid,1)) ######昨天解决问题了,可以分区,alter table XXX partition by hash(uid) partitions 10; 2个问题都解决了 谢谢你们###### 1、有数据了 也可以进行分区的.(之前刚分过) 2、应该是可以的...主要是函数的写法 ######alter table XXX partition by hash(uid) partitions 10; 可以解决这2个问题,已找到解决办法,供参考###### 在数据库层的话那就不好办了. 可以试着吧分区计算移到逻辑层来: 那这些都不是问题了. 对于已经有数据的表, 记下主键Id值=x, 查询的时候当Id<=x就查询不动, Id >x 就使用分区定位.uid % 10 即可取到数据表或者数据服务器索引.  ######alter table XXX partition by hash(uid) partitions 10; 供参考######跨分区查询的话准备死翘翘吧

kun坤 2020-06-09 13:40:53 0 浏览量 回答数 0

回答

Java基础知识:Java集合类(Array,Set,Map, List等) 与 泛型。JVM (内存分区,GC算法,内存调优,避免频繁的GC等)Java 多线程(线程并发,线程通信等,java集合类中有线程相关的集合实现)Java IO(File, Socket, NIO, AIO, Netty)Java序列化(和远程通信相关)反射 注解 等。Classloader 加载原理。设计模式(AOP, Proxy, Factory, Singleton, Strategy等)Web开发方向servlet是基础,现代意义上的Web开发一般不会直接使用jsp做显示层。需要做前后端分离,前后端mvc,因此从java后端来说需要掌握:ServeltFilter开发框架如Spring (核心是设计模式)数据库(操作,并发,事务,分库分表,SQL优化等)

程序员诗人 2019-12-02 01:31:58 0 浏览量 回答数 0

回答

当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。 读/写分离 经典的数据库拆分方案,主库负责写,从库负责读。 垂直分区 根据数据库里面数据表的相关性进行拆分。例如,用户表中既有用户的登录信息又有用户的基本信息,可以将用户表拆分成两个单独的表,甚至放到单独的库做分库。 简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。如下图所示,这样来说大家应该就更容易理解了。 垂直拆分的优点: 可以使得列数据变小,在查询时减少读取的Block数,减少I/O次数。此外,垂直分区可以简化表的结构,易于维护。 垂直拆分的缺点:主键会出现冗余,需要管理冗余列,并会引起Join操作,可以通过在应用层进行Join来解决。此外,垂直分区会让事务变得更加复杂; 水平分区 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。水平拆分可以支撑非常大的数据量。 水平拆分是指数据表行的拆分,表的行数超过200万行时,就会变慢,这时可以把一张的表的数据拆成多张表来存放。 举个例子:我们可以将用户信息表拆分成多个用户信息表,这样就可以避免单一表数据量过大对性能造成影响。 水平拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题,但由于表的数据还是在同一台机器上,其实对于提升MySQL并发能力没有什么意义,所以水平拆分最好分库。 水平拆分能够支持非常大的数据量存储,应用端改造也少,但分片事务难以解决 ,跨节点Join性能较差,逻辑复杂。 推荐尽量不要对数据进行分片,因为拆分会带来逻辑、部署、运维的各种复杂度,一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。 如果实在要分片,尽量选择客户端分片架构,这样可以减少一次和中间件的网络I/O。下面补充一下数据库分片的两种常见方案: 客户端代理:分片逻辑在应用端,封装在jar包中,通过修改或者封装JDBC层来实现。当当网的 Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。 中间件代理:在应用和数据中间加了一个代理层,分片逻辑统一维护在中间件服务中。我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。

pandacats 2019-12-23 10:38:11 0 浏览量 回答数 0

回答

作为应届毕业生,招聘不看重开发经营,基础知识一定要牢固。当然只看书本知识很难真正的理解这些基础知识,一定的编码实践是需要的。Java方向主要分为应用系统开发和移动开发(Android),牢固掌握基础知识后,挑选自己感兴趣的方向和平台即可。需要掌握(理解原理)的Java基础知识:Java集合类(Array,Set,Map, List等)Java内存管理(内存分区,GC算法,内存调优,避免频繁的GC等)Java多线程(线程并发,线程通信等,java集合类中有线程相关的集合实现)Java IO(File, Socket, NIO, AIO, Netty)Java序列化(和远程通信相关)classloader设计模式(AOP, Proxy, Factory, Singleton, Strategy等)Web开发方向servlet是基础,现代意义上的Web开发一般不会直接使用jsp做显示层。需要做前后端分离,前后端mvc,因此从java后端来说需要掌握:ServeltFilter开发框架如Spring (核心是设计模式)数据库(操作,并发,事务,分库分表,SQL优化等)理解和掌握这些基础知识,面试就不是问题了。

ericwz 2019-12-02 01:31:58 0 浏览量 回答数 0

问题

MaxCompute常见问题:SQL常见问题

行者武松 2019-12-01 22:09:50 1190 浏览量 回答数 0

回答

像传统的数据库,让大家去排队,尽量利用性能,只能一定程度上缓解这个问题。业界上有2种操作,一个是采用云原生的架构,采用存储计算分离,像PolarDB可以做一写多读。现在PolarDB一个实例可以做一个大到接近100T的存储,上面可以做一写多读16个节点。按照当时并发的需求,尤其是对只读并发高的应用,就按量去弹出来的只读节点,一两分钟就弹出一个新的节点,峰值过去之后就可以释放了。 如果写的并发特别多可以采用PolarDB 2.0,所有的计算节点每一个计算节点都可以做写和读。 写和写的冲突问题可以在多写和多读的时候,就要想办法在共享状态这一层。 还有一种解决方法是用分布式,或者有些传统企业用的中间件分库分表或者分布式数据库。因为可以把并发并行的或者分布式放到多个节点上去。这里面也有挑战,挑战非常大,因为一旦对数据进行了分库以后,每个分区都非常容易被并行化。很多时候要做跨区域的查询,依赖两个或三个Partition或者Share上的数据,就需要做跨库的事务处理和查询,这个对系统性能影响非常非常大。但在很多应用场景上,可能并发是很高但做跨库的这种冲突事务的量可能不会太高。

问问小秘 2020-05-22 11:51:50 0 浏览量 回答数 0

回答

每5秒钟内就有1万条数据插入,该不会是一个长事务吧? 还是每次写一条就提交呢? ######@苗威 : 嗯嗯,我这次也就是准备用这个方法解决,谢谢你啦,嘿嘿######@李密 : 一次写一批,与一般的处理方法不一样,可以纵向分表,分库######@李密 : 1万左右的数据,就不用存硬盘了,用内存,java缓存组件也行,memcached也行,Mysql Memory引擎 也行,使用过的删掉,新的添上去。######@李密 : 这个就算作是一种“分区表”的应用啦。对每个运营商指定对应的表,然后在应用层做映射。 1W/5sec的插入加上高并发读取算不小的负荷,不知道使用pgsql(配合分区表)是否能解决性能问题。######@李密 : 能解决问题的方法就是好方法###### 这张表因为要和游戏通信,包含很多必须的字段,字段总数有16个,目前服务器200台,以后估计至少500台,那时候插入和查询数量就更恐怖了,所以我越来越担心以后这个项目问题会卡在这个表上 (昨天(22:10) by 李密) 可以通过把字段分表方式避免单表过大。不过以你远期规模使用现在这种数据库结构肯定会崩溃。如果可行(楼主有权设计修改表结构),建议楼主考虑重新设计数据库表甚至更换数据库(有钱换oracle,免费换pgsql)。 另外,并发读写巨大,磁盘性能很重要,要么用SCSI/SAS阵列要么直接上SSD(但SSD的寿命也许需要考虑)。   已经运营两个月了,表内目前数据1000多万。 一年就6千万,如果不做分区表(以时间划分)那么迟早崩溃 java项目+mysql都在这一台服务器上 楼上还有朋友说读写分离,现在连数据库都不是独立服务器,估计再跑几个月就会葛屁的   关于pgsql和mysql比较的一些帖子 http://www.oschina.net/question/126398_23854 http://www.oschina.net/question/96003_13994 http://www.oschina.net/question/129318_19029    ###### redis和Mysql Memory引擎 都行,10W条数据没问题###### @苗威 : 嗯嗯,谢谢你这么耐心帮我,嘿嘿,以后多向你请教###### @李密: 客气,我也只有些理论基础,分表可以水平分,和垂直分,水平分是各个运营商分,垂直分是把所有的邀请码分成若干张表,比如用最后一个字符分,邀请码如果是字符串最好能换成int存,压缩会加快很多查找速度######抽空我研究下,目前想临时采用分表把这个问题解决下,给每个运营商动态分配一个礼品表,运营商两年内也不会超过200个,表的数量也不会有太多,先分表。威哥,你觉得这样设计有重大缺陷不?因为之前我还没这样做过######是 innodb 还是 myisam 呢 ######薯哥哥,是innodb表######锁表应该是在innodB下发生的吧..myisam直接坏表了 ######是innodb######这种情况充分说明内存缓存设计的重要性 ######天啊..大并发居然用innodB..   我测试过innodB的写入性能是非常低的,cpu效率不高..插入爆慢.. 建议读写分离..写可以innodB,读还是myisam吧..###### @gamespoerleveling : 没用的,读库同样存在数据更新问题。在从innodb写库同步到myisam读库时如果读库正好是访问高峰,那么就会遇到楼主现在同样的锁表情况。 总而言之,在大数据量大并发下mysql就是个坑爹的杯具~###### @mark35 : 我是说的读写分离...读myisam的表###### @hulei : 坏不坏表不好说, 但表锁的代价肯定比行锁高!######myisam是表锁啊,这种程度的数据输入myisam必坏表啊。######在myisam上大并发读写将会更悲摧的~###### 引用来自“红薯”的答案 每5秒钟内就有1万条数据插入,该不会是一个长事务吧? 还是每次写一条就提交呢? 每次写一条就提交,但特别频繁,我之前ORACLE也碰到过这种情况。 ######那paulwong最后是怎么解决呢?可以分享下吗?######所有clinet直连 mysql server ?应该有数据库中间层吧###### 这样的业务逻辑就感觉有问题,以前在唯晶的时候,也做过类似的 为什么要每分钟过来1w,3w的记录?直接生成个百万条记录分给他们去用就行了, 就只有检索和更新了###### @陈俊贤 : 楼主这种应用采用读写分离意义不大并且还可能产生问题:通常情况下查询都会是有效查询,查询到记录就会产生关联写(改写激活码使用状态)。读写分离后数据肯定不是实时同步,那么当记录修改后(激活码已使用)在同步到读库这段时间中读库的该条记录查询结果都是老状态(激活码未使用),事务就不能保证一致了!###### @mark35 : 读写分离只是执行缓刑,不改这个逻辑,死刑是早晚的事###### @陈俊贤 : 读写分离不能根本解决问题的。或者说大家觉得读写分离是银弹那多半是因为mysql本来实在低能,用上读写分离就有效提高性能。但实际上即使使用读写分离也同样存在节点更新问题(写库同步到读库)。###### @李密 : 那就读写分离,照你说的话以后多半会崩掉###### @mark35 : 目前卡的类别已经达到500种以上,所以以后生成量更恐怖了。。。

黄二刀 2020-05-27 20:08:00 0 浏览量 回答数 0

回答

http://www.fuchaoqun.com/2009/04/efficient-pagination-using-mysql######既然这样为啥不横向分表呢,把基础信息和附带信息分开,这样也减少了单表的容量,同时也加快了查询基础信息数据的速度,至于附加信息可以通过异步方式查询一次,微博头像信息就是这样实现的######@光头程序员 嗯######回复 @光头程序员 : 也就是水平分区和垂直分区。水平分区是按照一个字段,比如说按照时间分成几个区;垂直分表是把一个表分成两部分,比如说一个基本信息表有很多大字段的备注,这些备注不常用,我们就可以把它分到另一个表中######回复 @钟晓骏 : 你是来回答问题的吗######懂的好多,真怀疑你是不是女女了。。。还没见过哪个女的程序员像你这么厉害的~或许是我还没碰到###### 百万级的数据?有排序? 有一种思路是这样的:将主键以及排序字段冗余成一张新表(静态表),然后每次列表的时候都是通过这张表分页显示,然后从主表中ajax异步加载当前页所有ID的信息(指定主键查询) 这样不用分表什么的,最大限度减少工作量,而且主表就不用负担这方面的排序列表消耗了,索引空间也可以节约下来 不知道这样可不可以 ######我也是这么看的###### 引用来自“小小程序员”的答案 百万级的数据?有排序? 有一种思路是这样的:将主键以及排序字段冗余成一张新表(静态表),然后每次列表的时候都是通过这张表分页显示,然后从主表中ajax异步加载当前页所有ID的信息(指定主键查询) 这样不用分表什么的,最大限度减少工作量,而且主表就不用负担这方面的排序列表消耗了,索引空间也可以节约下来 不知道这样可不可以 普通数据库对付百万级别的数据还不至于要如此折腾,另外如果索引都正确建立的话,另建一张信表是没有太大意义的。(走的都是索引查询) ######难不成楼主要一次性把所有数据全部加载展示出来?###### 引用来自“huan”的答案 引用来自“小小程序员”的答案 百万级的数据?有排序? 有一种思路是这样的:将主键以及排序字段冗余成一张新表(静态表),然后每次列表的时候都是通过这张表分页显示,然后从主表中ajax异步加载当前页所有ID的信息(指定主键查询) 这样不用分表什么的,最大限度减少工作量,而且主表就不用负担这方面的排序列表消耗了,索引空间也可以节约下来 不知道这样可不可以 普通数据库对付百万级别的数据还不至于要如此折腾,另外如果索引都正确建立的话,另建一张信表是没有太大意义的。(走的都是索引查询) 理论上是这样,但是查询的速度不仅仅是索引,还有内存、磁盘等因素。 我的意思是,这样的话可以大大减少主表所使用的I/O以及碎片(明显,这些都会制约查询) 而且查询表如何是静态表(比动态表快四倍?)的话,应该会好很多吧 ######为什么不分页?###### 引用来自“小小程序员”的答案 引用来自“huan”的答案 引用来自“小小程序员”的答案 百万级的数据?有排序? 有一种思路是这样的:将主键以及排序字段冗余成一张新表(静态表),然后每次列表的时候都是通过这张表分页显示,然后从主表中ajax异步加载当前页所有ID的信息(指定主键查询) 这样不用分表什么的,最大限度减少工作量,而且主表就不用负担这方面的排序列表消耗了,索引空间也可以节约下来 不知道这样可不可以 普通数据库对付百万级别的数据还不至于要如此折腾,另外如果索引都正确建立的话,另建一张信表是没有太大意义的。(走的都是索引查询) 理论上是这样,但是查询的速度不仅仅是索引,还有内存、磁盘等因素。 我的意思是,这样的话可以大大减少主表所使用的I/O以及碎片(明显,这些都会制约查询) 而且查询表如何是静态表(比动态表快四倍?)的话,应该会好很多吧 优化时尽量优先考虑通用的技术方式,最后再考虑特定软件的专有方式。

kun坤 2020-06-07 21:56:45 0 浏览量 回答数 0

问题

分布式系统 CAP 定理 P 代表什么含义【Java问答学堂】55期

剑曼红尘 2020-07-10 14:49:59 12 浏览量 回答数 1

回答

OceanBase相对于传统关系数据库的创新首先是运维方面的。将数据库故障切换(高可用)、异地容灾/多活、负载均衡、分布式架构弹性扩容缩容(DB不停服务)全部做到数据库内核里面了,这些是数据库的固有属性,还拿不掉。不需要人工介入(当然机器坏了还是要运维负责去安排维修的,不同之处是运维可以很从容的去处理机器故障)。当然这个固有能力的成本就是数据至少要三副本。 其次就是硬件成本方面。OceanBase架构是shared-nothing架构,不需要共享存储。只需要普通的x86服务器;不需要小机,也不支持小机平台。只需要普通的SSD(OceanBase读写模型里随机写很少,不伤SSD寿命)。 第三就是分布式,可以大规模部署OceanBase集群,同时又支持多租户管理,对机器资源的使用非常灵活,机器利用率高(有负载均衡在,不怕某些机器太闲某些机器太忙)。曾经最大的OceanBase集群机器数超过100台(主要是业务数据量是上百亿级别的)。OceanBase的分区表能力就是分布式水平拆分常用手段之一(另外一个是分布式中间件的分库分表方案)。还有更多就不细说了。

茶什i 2019-12-02 03:18:55 0 浏览量 回答数 0

问题

【精品问答】带你进入数据库领域

谙忆 2020-04-07 20:45:48 12 浏览量 回答数 1

回答

OceanBase 1.4分区表用法 业务数据做水平拆分,有如下几种方案 分库分表:通过分布式数据库中间件做分库分表拆分和路由等。如DRDS,MyCat,TDSQL等。分区:Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片,对应用透明。如Google的Spanner,PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range,以及支持二级分区(hash+hash,hash+range,key+key,range+range等)。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表,还是分区的方案,都会面临一个问题,就是当一个Query 要取不同机器(节点)上的数据的时候,如果保证取出来的数据是一致的(指来自于同一个时间点或版本)。 分库分表方案解决不了这个问题, OB1.4也不能解决这个问题。OB2.0 新增全局时间服务,能提供全局一致性快照读功能,所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案(弱一致读) SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题,在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表,这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库,至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备(F5)或软件(LVS,SLB等)都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点,从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点(ObServer)里的数据(Partition)分布,从而间接改变打到各个节点(ObServer)上的流量,从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细,请查看 《 OceanBase负载均衡的魅力 》 示例演示:租户视角查看负载均衡历史。 这里是新建了一个分区表(8个分区),在插入数据后,触发了负载均衡机制,把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库,跟其他同行产品相比,有一个独特的地方,就是支持多租户,即支持集群资源(CPU/MEM/DISK等)的做租户管理。 OceanBase集群,至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池,然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池,并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例,只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认,以后还支持Oracle兼容模式的租户)。     假设OceanBase集群已经搭建好了,在创建租户之前,先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建(很简单)     接楼上。     清点了OceanBase集群资源使用情况后,选定一个规格,就可以快速创建出一个租户(demo_t) 示例:OB1.4下创建租户(2步) SQL: # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户,重新登录新建租户 ,用户名是:root@demo_t#集群名,密码默认是空。 登录后新建Database,并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊,开发和运维需要留意一下。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。

mq4096 2019-12-02 00:56:00 0 浏览量 回答数 0

回答

OceanBase 1.4分区表用法 业务数据做水平拆分,有如下几种方案 分库分表:通过分布式数据库中间件做分库分表拆分和路由等。如DRDS,MyCat,TDSQL等。分区:Oracle 12c的sharding, OceanBase 1.0及以后的版本存储级别切片,对应用透明。如Google的Spanner,PingCap的TiDB 这里只演示OceanBase的分区用法。 OceanBase的分区策略支持hash/list/range,以及支持二级分区(hash+hash,hash+range,key+key,range+range等)。详细用法请参见 OceanBase官网 文档里 的 OB分区表用法 。 无论是分库分表,还是分区的方案,都会面临一个问题,就是当一个Query 要取不同机器(节点)上的数据的时候,如果保证取出来的数据是一致的(指来自于同一个时间点或版本)。 分库分表方案解决不了这个问题, OB1.4也不能解决这个问题。OB2.0 新增全局时间服务,能提供全局一致性快照读功能,所以解决了这个问题。 这里演示一下 OB1.4 里规避这个跨节点读的方案(弱一致读) SQL: SELECT @@version;drop table if exists t_parttable;create table t_parttable(    id bigint not null primary key,     name varchar(50) not NULL,      KEY name_ind(NAME) LOCAL ) DEFAULT CHARSET=utf8mb4 partition by hash(mod(id,1000)) partitions 8;insert into t_parttable(id, name) values(1,'a'),(2,'A'),(3,'b'),(4,'B'),(5,'c'),(6,'C'),(7,'d'),(8,'D');set session ob_query_timeout=1000000; select * from t_parttable where name='a';explain select * from t_parttable where name='a';select /*+read_consistency(weak)*/ * from t_parttable where name='a';select * from t_parttable partition(p1);select * from t_parttable partition(p2); 该问题,在OceanBase 2.0后版本已经解了 ------------------------- OB租户负载均衡历史查看 接楼上建的表,这里演示一下如何在租户里查看负载均衡的历史。 OB作为一个分布式数据库,至少包含3个节点。其负载均衡的原理跟传统负载均衡的原理大不一样。 传统负载均衡设备(F5)或软件(LVS,SLB等)都是通过在某一协议层作为流量入口然后分配流量给后端不同的节点,从而去改变后端节点的压力。 OceanBase的负载均衡是自己通过调整每个节点(ObServer)里的数据(Partition)分布,从而间接改变打到各个节点(ObServer)上的流量,从而改变各个节点的压力。 有关OceanBase负载均衡的原理详细,请查看 《 OceanBase负载均衡的魅力 》 示例演示:租户视角查看负载均衡历史。 这里是新建了一个分区表(8个分区),在插入数据后,触发了负载均衡机制,把8个分区分散到多个节点上。 SQL: # 查看分区表的数据SHOW CREATE TABLE db_bin.t_parttable;SELECT /*+read_consistency(weak)*/ * FROM db_bin.t_parttable ORDER BY id ;# 查看租户的资源单元(Unit)分布SELECT tenant_name, unit_id,zone,svr_ip,max_cpu,round(max_memory/1024/1024/1024) max_mem_gb FROM gv$unit;# 查看租户的负载均衡历史SELECT str_to_date(h.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create, h.zone, t.database_name, t.tablegroup_name, t.table_name, t.part_num,h.partition_id,h.data_size, h.data_src_ip,  h.dest_unit_id, h.dest_ip, h.result_code, h.COMMENT , h.rs_svr_ip FROM gv$unit_load_balance_event_history h JOIN gv$TABLE t ON (h.table_id=t.table_id)WHERE t.table_name NOT LIKE '%recycle%' AND t.database_name='db_bin'ORDER BY gmt_create DESC LIMIT 100; ------------------------- OB sys租户查看集群使用信息     OceanBase作为一款通用的分布式关系型数据库,跟其他同行产品相比,有一个独特的地方,就是支持多租户,即支持集群资源(CPU/MEM/DISK等)的做租户管理。 OceanBase集群,至少是三节点。OceanBase把三个节点的机器资源能力聚合成一个大的资源池,然后做二次资源管理和分配。为每个租户分配一个特定规格的小的资源池,并且随时可以动态调整。 租户对于业务开发来说就是一个体的实例,只是开发不需要关注这个实例在哪个节点上。租户的使用体验类似于 MySQL (默认,以后还支持Oracle兼容模式的租户)。     假设OceanBase集群已经搭建好了,在创建租户之前,先清点一下现有集群的资源使用状况。下面是示例     SQL: # 查看集群节点资源使用情况SELECT svr_ip, s.zone, s.cpu_total, s.cpu_assigned, s.cpu_assigned_percent, round(s.mem_total/1024/1024/1024) mem_total_gb, round(s.mem_assigned/1024/1024/1024) mem_ass_gb, s.mem_assigned_percentFROM __all_virtual_server_stat sORDER BY zone,svr_ip;# 查看资源单元规格定义SELECT NAME, max_cpu, min_cpu, round(max_memory/1024/1024/1024) max_mem_gb , round(min_memory/1024/1024/1024) min_mem_gb FROM __all_unit_config ORDER BY unit_config_id LIMIT 10;# 查看已有租户及其资源池信息SELECT t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('yq_Pool','app_pool')  ORDER BY p.resource_pool_id; ------------------------- OceanBase租户创建(很简单)     接楼上。     清点了OceanBase集群资源使用情况后,选定一个规格,就可以快速创建出一个租户(demo_t) 示例:OB1.4下创建租户(2步) SQL: # 清理已经创建的同名租户DROP tenant IF EXISTS demo_t;DROP resource pool demo_pool;# 创建新的资源池(Resource Pool)CREATE resource pool demo_pool unit='S0_unit_config', unit_num=2;# 创建租户 CREATE tenant IF NOT EXISTS demo_t resource_pool_list=('demo_pool') SET VARIABLES ob_tcp_invited_nodes='%';# 查看已有租户及其资源池信息SELECT now() cur_time, str_to_date(t.gmt_create,'%Y-%m-%d %h:%i:%s') gmt_create,  t.tenant_name, p.name pool_name, c.name config_name, p.unit_count, p.zone_list, t.`locality`FROM __all_resource_pool p JOIN __all_unit_config c ON (p.unit_config_id=c.unit_config_Id)  LEFT JOIN __all_tenant t ON (p.tenant_id=t.tenant_id)WHERE p.NAME IN ('demo_pool')  ORDER BY p.resource_pool_id;     退出当前sys租户,重新登录新建租户 ,用户名是:root@demo_t#集群名,密码默认是空。 登录后新建Database,并创建账户访问DB。 ------------------------- OceanBase里索引创建特征 OceanBase里创建索引稍微有点特殊,开发和运维需要留意一下。 如果是在create table里带上了索引(包括唯一索引,也就是唯一性约束),是立即生效的。OB 1.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,但是索引不是立即生效。需要等到OB集群发起大合并之后才会生效。其中唯一索引需要等待两次大合并。所以运维建索引后需要安排1-2次大合并操作。OB 2.x 版本里在表存在的情况下新建的索引(包括唯一索引),命令立即返回,索引也不是立即生效,但是索引开始后台异步创建,创建时间取决于数据量。 示例如下: 1. OB 1.x 版本的索引 2. OB 2.x版本的索引 ------------------------- 回 9楼(xcb296) 的帖子 有什么想了解的 可以先说一下。 这个主要是根据用户问题来做的。

mq4096 2019-12-02 00:56:01 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

回答

你这是几年工作经验(多少钱的岗位)问到这些问题的? Q1:如果对时效性要求不是太高的话,首先考虑静态化。静态资源请求处理耗系统资源少,不会请求数据库。数据库方面可以加个缓存,或者查询频率高的直接全部放redis。(再接着问的话再接着往深里回答) Q2:数据库性能问题?这题太抽象,反问一句具体场景,再具体问题具体分析。这块我也不熟。但是数据库一般就分表、表分区、分库、索引。 Q3:简单的实现可以是 nginx用upstream做负载(apache同样可以),静态资源直接urlrewrite到专门服务器上,对后端请求通过upstream配置分发到不同服务器上,这里主要做一些session复制或者自己实现一套无session的用户跟踪机制。或者更复杂的,在第一个server前搞个lvs。原理主要就是多服务器处理请求。其实负载这些都是专业的运维搞更好,术业有专攻。并且小公司的项目并发也不会高到哪里去,真高了也就有钱找专业的运维了。 ######我才两年多,回答的不错,赞!###### Q1就是扯淡,没有具体场景,方案完全不一样。 ######回答这种题目也没什么扯淡的吧,主要还是考你知不知道这方面的知识。你可以在交流过程中自己把场景限定下来,然后给出解决方案的思路,这种问题没有标准答案,面试官也会根据你的回答来深入探讨,看面试者的水平在什么level。###### 现在企业数据量庞大,应用越来越普及 所以性能问题很明显,重要性比较突出 ###### 现在普通的笔记本都安装64位,内存好大 不做集群自己试试那就等于浪费 ######不排除有的公司是为了拿这个来考验你的实力!也不排除它这个公司就有那么大的数据流量。######可以参考一下我的博客关于系统调优的###### 哈,我给楼主正确答案吧。问你问题的,最近正在考虑这些,而且自己琢磨出来一套方案了,想看看是否有共鸣,或者让别人说些更sb的方案好bs一下,然后乐乐,别无其他,答的有点上路子,但被bs,是最佳状态。如果你一不小心,呼呼呼,顺着他的思路,说了很多他暂时还没想到的,基本他会10分钟内容去找技术总监“来了个狠的,招架不住,大哥,帮一把吧。。。” 如果你遇到这种情况,就是技术总监,过了5分钟慢悠悠的来了,一般他不会如pm那样问直接问题,而是随意聊聊,大体套路就是”刚才我同事已经和你交流了不少,你的水平很不错“云云。随后会尽可能了解你的整体情况后,再下手做技术对答。 不过面试时,能把pm说晕,让技术总监出来的,基本上也就大家交个朋友了,因为暂需岗位和你的人力已经不匹配了。。就当喝下午茶。这种事情我干过。 补充说一点,pm这个级别出来面试,一般都会从自己的视角面来谈技术。所以通常会问自己正在琢磨的问题。你就是提出一个足以否定他们的更好多方案也不会改变他们已经实施的计划。 ######我顶######我刚毕业1年,也问我这些。问我集群,问我给数据库优化,问我hadoop###### 引用来自“张子游”的答案 我刚毕业1年,也问我这些。问我集群,问我给数据库优化,问我hadoop 确实,现在不少公司对应届生也问这样的问题(比如某刚被百度收购的p2p视频公司) ######我觉得就是看你有多少招数来应对这些问题,不能一点都没有啊,等真遇到这问题了你搞不定就麻烦了。

kun坤 2020-05-29 13:03:17 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 企业建站模板