搜索[数据库连接池]结果-低调大师优秀个人博客

精选列表

搜索[数据库连接池]，共10000篇文章

SQL Server日志文件过大大日志文件清理方法不分离数据库

原文: SQL Server日志文件过大大日志文件清理方法不分离数据库 SQL Server日志文件过大大日志文件清理方法，网上提供了很多分离数据库——〉删除日志文件-〉附加数据库 的方法，此方法风险太大

2017-12-26

阿里云Redis读写分离典型场景：如何轻松搭建电商秒杀系统https://yq.aliyun.com/articles/277885 文末有彩蛋，请务必记得看完整哦背景目前的阿里云redis不管主从版还是集群规格，slave作为备库不对外提供服务，只有在发生HA，slave提升为master后才承担读写。这种架构读写请求都在master上完成，一致性较高，但性能受到master数量的限制。经常有用户数据较少，但因为流量或者并发太高而不得不升级到更大的集群规格。为满足读多写少的业务场景，最大化节约用户成本，阿里云redis推出了读写分离规格，为用户提供透明、高可用、高性能、高灵活的读写分离服务。架构目前的redis集群模式有redis-proxy, master,slave, HA等几个角色，在读写分离中，新增readonly slave角色承担读流量，slave作为热备不提供服务，架构上保持对现有集群规格的兼容性。redis-proxy按权重将读写请求转发到master或者某个readonly slave上；HA负责监控DB节点的健康状态，异常时发起主从切换或重搭readonly slave，并更新路由。一般来说，根据master和readonly slave的数据同步方式，可以有两种架构：星型复制，链式复制。星型复制星型复制就是将所有的readonly slave直接和master保持同步，每个readonly slave之间相互独立，任何一个节点异常不影响到其他节点，同时因为复制链比较短，readonly slave上的复制延迟比较小。 redis是单进程单线程模型，主从之间的数据复制也在主线程中处理，readonly slave数量越多，数据同步对master的cpu消耗就越严重，集群的写入性能会随着readonly slave的增加而降低。此外，星型架构会让master的出口带宽随着readonly slave的增加而成倍增长。master上较高的CPU和网络负载又会抵消掉星型复制延迟较低的优势。可以看出，星型复制架构会带来比较严重的扩展问题，整个集群的性能会受限于master。链式复制链式复制将所有的readonly slave组织成一个复制链，如下图所示，master只需要将数据同步给slave和复制链上的第一个readonly slave。链式复制解决了星型复制的扩展问题，理论上可以无限增加readonly slave的数量，随着节点的增加整个集群的性能也可以基本上呈线性增长。链式复制的架构下，复制链越长，复制链末端的readonly slave和master之间的同步延迟就越大，考虑到读写分离主要使用在对一致性要求不高的场景下，这个缺点一般可以接受。但是如果复制链中的某个节点异常，会导致下游的所有节点数据都会大幅滞后，更加严重的是这可能带来全量同步，并且全量同步将一直传递到复制链的末端，这会对服务带来一定的影响，为了解决这个问题，读写分离的redis都使用阿里云优化后的binlog复制版本，最大程度的降低全量同步的概率。结合上述的讨论和比较，redis的读写分离选择链式复制的架构。透明、兼容读写分离和普通集群规格一样，都使用了redis-proxy做请求转发，多shard时部分命令使用存在一定的限制，但从主从升级单分片读写分离，或者从集群升级到多分片的读写分离集群可以做到完全兼容。规格主从版本读写分离（单shard）集群读写分离集群兼容性 100% 100% 部分命令使用受到限制部分命令使用受到限制在集群模式下，有部分命令使用必须限制所有key在同一个slot中，具体可以参考阿里云官网：https://help.aliyun.com/document_detail/26356.html?spm=5176.doc43829.6.562.NDJFXm 用户和redis-proxy建立连接，redis-proxy会识别出客户端连接发送过来的请求是读还是写，然后按照权重作负载均衡，将请求转发到后端不同的DB节点中，写请求转发给master，读操作转发给readonly slave（master默认也提供读，可以通过权重控制）。用户只需要购买读写分离规格的实例，直接使用任何客户端即可直接使用，业务不用做任何修改就可以开始享受读写分离服务带来的巨大性能提升，接入成本几乎为0。高可用高可用模块（HA）监控所有DB节点的健康状态，为整个实例的可用性保驾护航，master宕机时自动切换到新主。如果某个readonly slave宕机，HA也能及时感知，然后重搭一个新的readonly slave，下线宕机节点。除HA之外，redis-proxy也能实时感知每个readonly slave的状态。在某个readonly slave异常期间，redis-proxy会自动降低这个节点的权重，如果发现某个readonly slave连续失败超过一定次数以后，会暂时屏蔽异常节点，直到异常消失以后才会恢复其正常权重。 redis-proxy和HA一起做到尽量减少业务对后端异常的感知，提高服务可用性。性能对于读多写少的业务场景，直接使用集群版本往往不是最合适的方案，现在读写分离提供了更多的选择，业务可以根据场景选择最适合的规格，充分利用每一个readonly slave的资源。目前单shard对外售卖1master + 1/3/5 readonly slave多种规格（如果有更大的需求可以提工单反馈给我们），提供60W qps 和 192MByte/s的服务能力，在完全兼容所有命令的情况下突破单机的资源限制。后续将去掉规格限制，让用户根据业务流量随时自由的增加或减少readonly slave数量。规格 qps 带宽 1 master 8~10W读写 10~48MB 1 master + 1 readonly_slave 10W写 + 10W读 20~64MB 1 master + 3 readonly_slave 10W写 + 30W读 40~128MB 1 master + 5 readonly_slave 10W写 + 50W读 60~192MB 其他 redis主从异步复制，从readonly slave中可能读到旧的数据，使用读写分离需要业务可以容忍一定程度的数据不一致，后续将会给客户更灵活的配置和更大的自由，比如配置可以容忍的最大延迟时间。更多的购买和使用细节可以移步官网：https://promotion.aliyun.com/ntms/act/redisseparation.html 这里是彩蛋感谢各位小伙伴的耐心阅读，现在参加Redis读写分离微博转发活动还有机会获得2017年 FIFA世俱杯门票以及阿里云T恤点击云栖社区官方微博活动链接：https://weibo.com/1939498534/FydFv4EB1?ref=home&type=comment#_rnd1512444442357 ，12月6日抽取8名幸运用户2017年 FIFA世俱杯门票1张，12月12日抽20名幸运用户赠阿里云T恤1件。

2017-11-29

Android官方ORM数据库Room技术解决方案：@Embedded内嵌对象（二）

Android官方ORM数据库Room技术解决方案：@Embedded内嵌对象（二）（一）附录1简介了Android Room的基本使用。

2017-11-23

Hadoop之Hive本地与远程mysql数据库管理模式安装手册

1.安装mysql数据库步骤略过，虚拟机网络设置成host-only模式，两边系统都关闭防火墙，windows系统的360软件最好也关闭，有可能会影响通信。

2017-11-14

系出名门Android(9) - 数据库支持(SQLite), 内容提供器(ContentProvider)

[索引页] [源码下载] 系出名门Android(9) - 数据库支持(SQLite), 内容提供器(ContentProvider) 作者： webabcd 介绍在 Android 中使用 SQLite

2017-11-10

Druid（准）实时分析统计数据库——列存储+高效压缩

Druid是一个开源的、分布式的、列存储系统，特别适用于大数据上的（准）实时分析统计。且具有较好的稳定性（Highly Available）。其相对比较轻量级，文档非常完善，也比较容易上手。 Druid vs 其他系统 Druid vs Impala/Shark Druid和Impala、Shark 的比较基本上可以归结为需要设计什么样的系统 Druid被设计用于：一直在线的服务获取实时数据处理slice-n-dice式的即时查询查询速度不同： Druid是列存储方式，数据经过压缩加入到索引结构中，压缩增加了RAM中的数据存储能力，能够使RAM适应更多的数据快速存取。索引结构意味着，当添加过滤器来查询，Druid少做一些处理，将会查询的更快。 Impala/Shark可以认为是HDFS之上的后台程序缓存层。但是他们没有超越缓存功能，真正的提高查询速度。数据的获取不同： Druid可以获取实时数据。 Impala/Shark是基于HDFS或者其他后备存储，限制了数据获取的速度。查询的形式不同： Druid支持时间序列和groupby样式的查询，但不支持join。 Impala/Shark支持SQL样式的查询。 Druid vs Elasticsearch Elasticsearch(ES)是基于Apache Lucene的搜索服务器。它提供了全文搜索的模式，并提供了访问原始事件级数据。 Elasticsearch还提供了分析和汇总支持。根据研究，ES在数据获取和聚集用的资源比在Druid高。 Druid侧重于OLAP工作流程。Druid是高性能（快速聚集和获取）以较低的成本进行了优化，并支持广泛的分析操作。Druid提供了结构化的事件数据的一些基本的搜索支持。 Segment: Druid中有个重要的数据单位叫segment，其是Druid通过bitmap indexing从raw data生成的（batch or realtime）。segment保证了查询的速度。可以自己设置每个segment对应的数据粒度，这个应用中广告流量查询的最小粒度是天，所以每天的数据会被创建成一个segment。注意segment是不可修改的，如果需要修改，只能够修改raw data，重新创建segment了。架构 Druid本身包含5个组成部分：Broker nodes, Historical nodes, Realtime nodes, Coordinator Nodes和indexing services. 分别的作用如下： Broker nodes: 负责响应外部的查询请求，通过查询Zookeeper将请求划分成segments分别转发给Historical和Real-time nodes，最终合并并返回查询结果给外部； Historial nodes: 负责’Historical’ segments的存储和查询。其会从deep storage中load segments，并响应Broder nodes的请求。Historical nodes通常会在本机同步deep storage上的部分segments，所以即使deep storage不可访问了，Historical nodes还是能serve其同步的segments的查询； Real-time nodes: 用于存储和查询热数据，会定期地将数据build成segments移到Historical nodes。一般会使用外部依赖kafka来提高realtime data ingestion的可用性。如果不需要实时ingest数据到cluter中，可以舍弃Real-time nodes，只定时地batch ingestion数据到deep storage； Coordinator nodes: 可以认为是Druid中的master，其通过Zookeeper管理Historical和Real-time nodes，且通过Mysql中的metadata管理Segments Druid中通常还会起一些indexing services用于数据导入，batch data和streaming data都可以通过给indexing services发请求来导入数据。 Druid还包含3个外部依赖 Mysql：存储Druid中的各种metadata（里面的数据都是Druid自身创建和插入的），包含3张表：”druid_config”（通常是空的）, “druid_rules”（coordinator nodes使用的一些规则信息，比如哪个segment从哪个node去load）和“druid_segments”（存储每个segment的metadata信息）； Deep storage: 存储segments，Druid目前已经支持本地磁盘，NFS挂载磁盘，HDFS，S3等。Deep Storage的数据有2个来源，一个是batch Ingestion, 另一个是real-time nodes； ZooKeeper: 被Druid用于管理当前cluster的状态，比如记录哪些segments从Real-time nodes移到了Historical nodes；查询 Druid的查询是通过给Broker Nodes发送HTTP POST请求（也可以直接给Historical or Realtime Node），具体可见Druid官方文档。查询条件的描述是json文件，查询的response也是json格式。Druid的查询包含如下4种： Time Boundary Queries: 用于查询全部数据的时间跨度 groupBy Queries: 是Druid的最典型查询方式，非常类似于Mysql的groupBy查询。query body中几个元素可以这么理解： “aggregation”: 对应mysql”select XX from”部分，即你想查哪些列的聚合结果; “dimensions”: 对应mysql”group by XX”，即你想基于哪些列做聚合; “filter”: 对应mysql”where XX”条件，即过滤条件； “granularity”: 数据聚合的粒度; Timeseries queries: 其统计满足filter条件的”rows”上某几列的聚合结果，相比”groupBy Queries”不指定基于哪几列进行聚合，效率更高; TopN queries: 用于查询某一列上按照某种metric排序的最常见的N个values; 本文小结 Druid是一个开源的，分布式的，列存储的，适用于实时数据分析的系统，文档详细，易于上手； Druid在设计时充分考虑到了Highly Available，各种nodes挂掉都不会使得druid停止工作（但是状态会无法更新）； Druid中的各个components之间耦合性低，如果不需要streaming data ingestion完全可以忽略realtime node； Druid的数据单位Segment是不可修改的，我们的做法是生成新的segments替换现有的； Druid使用Bitmap indexing加速column-store的查询速度，使用了一个叫做CONCISE的算法来对bitmap indexing进行压缩，使得生成的segments比原始文本文件小很多；在我们的应用场景下（一共10几台机器，数据大概100列，行数是亿级别），平均查询时间<2秒，是同样机器数目的Mysql cluter的1/100 ~ 1/10； Druid的一些“局限”： Segment的不可修改性简化了Druid的实现，但是如果你有修改数据的需求，必须重新创建segment，而bitmap indexing的过程是比较耗时的； Druid能接受的数据的格式相对简单，比如不能处理嵌套结构的数据本文转自张昺华-sky博客园博客，原文链接：http://www.cnblogs.com/bonelee/p/6248172.html，如需转载请自行联系原作者

2017-11-08

android EnMicroMsg.db安卓微信数据库获得密码的源码

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 //主要实现过程，其中paramString2为手机串号,paramLong为uin this .cSb=getMessageDigest((paramString2+paramLong).getBytes()).substring( 0 , 7 ); Stringstr= "PRAGMAkey=\"" + this .cSb+ "\";" ; // package com.gracecode.android.signature.wechat; import java.security.MessageDigest; public final class MD5 { public static final StringgetMessageDigest( byte []paramArrayOfByte) { char []arrayOfChar1={ 48 , 49 , 50 , 51 , 52 , 53 , 54 , 55 , 56 , 57 , 97 , 98 , 99 , 100 , 101 , 102 }; try { MessageDigestlocalMessageDigest=MessageDigest.getInstance( "MD5" ); localMessageDigest.update(paramArrayOfByte); byte []arrayOfByte=localMessageDigest.digest(); int i=arrayOfByte.length; char []arrayOfChar2= new char [i* 2 ]; int j= 0 ; int k= 0 ; while ( true ) { if (j>=i) return new String(arrayOfChar2); int m=arrayOfByte[j]; int n=k+ 1 ; arrayOfChar2[k]=arrayOfChar1[( 0xF &m>>> 4 )]; k=n+ 1 ; arrayOfChar2[n]=arrayOfChar1[(m& 0xF )]; j++; } } catch (ExceptionlocalException) { } return null ; } 本文转自张宇 51CTO博客，原文链接：http://blog.51cto.com/zhangyu/1415004，如需转载请自行联系原作者

2017-11-07

SQL Server-数据库架构和对象、定义数据完整性（二）

数据库架构和对象 数据库包含架构，而架构又包含对象，架构可以看做是表、视图、存储过程等对象的容器。

2017-11-05

nodejs-ORM 操作数据库中间件waterline的使用

waterline和Sails.js同一团队开发，支持几乎所有的主流数据库,是nodejs下一款非常强大的orm，可以显著提升开发效率一.waterline支持的数据库 二.waterline的配置

2017-11-05

11 月全球数据库排名：PostgreSQL保持上升趋势一路高涨

【大咖・来了第7期】10月24日晚8点观看《智能导购对话机器人实践》 DB-Engines 发布了 2017年 11月份的数据库排名。

2017-11-03

MySQL数据库root账户密码忘记两种处理方法（保有效）

想学习更多MySQL5.7最新数据库技术，可以看下我录制的视频教程：https://ke.qq.com/course/251737

2017-10-31

DBA经验谈：3个最严重的数据库安全问题

本文讲的是 DBA经验谈：3个最严重的数据库安全问题， 数据库的安全问题一直以来就是DBA的噩梦，那些不安全的Web应用程序、没有有效的认证管理以及管理配置不当的分段都可能让数据库处于危险之中。

2017-09-03

历程剖析：阿里云自研HTAP数据库的技术发展之路

摘要：8月24日，阿里云数据库技术峰会到来，本次技术峰会邀请到了阿里集团和阿里云数据库老司机们，为大家分享了一线数据库实践经验和技术干货。

2017-09-03

阿里云发布数据库产品HybridDB 兼容23种数据类型

12月9日，阿里云宣布数据库产品 HybridDB 正式商业化。HybridDB（ApsaraDB HybridDB）是一款在线MPP大规模并行处理数据仓库的服务。

2017-08-31

如何避免数据库“勒索事件”和“从删库到跑路”的尴尬

2017-08-31

十分钟看懂时序数据库II——预处理

作为物联网领域数据存储的首选，时序数据库也越来越多进入人们的视野。早在2016年7月，百度云在其天工物联网平台上发布了国内首个多租户的分布式时序数据库产品TSDB。

2017-08-31

十分钟看懂时序数据库I——存储篇

2017年时序数据库忽然火了起来。

2017-08-31

【数据蒋堂】第15期：开放的计算能力为数据库瘦身

如果能够实现独立的计算引擎，使计算不再依赖于数据库提供，那么就可以为数据库瘦身了。内部来源的中间数据不必再以数据表的形式落地在数据库中，而可以放到文件系统中，由外部计算引擎提供进一步的计算能力。

2017-08-31

阿里云ECS无法连接阿里云数据库的一般原因

阿里云的数据库种类较多，但是网络连接问题出现以及排查和解决方式大部分是一样的，所以以下以RDS控制台为例子进行说明，控制台会与redis，mongodb，ocs等有差别，主要目的是为了举一反三第一章

2017-08-08

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

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

WebStorm

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

精选列表

SQL Server日志文件过大大日志文件清理方法不分离数据库

云数据库HBase大数据存储及实时分析场景应用解析

阿里云数据库全新功能Redis读写分离，全维度技术解析

Android官方ORM数据库Room技术解决方案：@Embedded内嵌对象（二）

Hadoop之Hive本地与远程mysql数据库管理模式安装手册

系出名门Android(9) - 数据库支持(SQLite), 内容提供器(ContentProvider)

Druid（准）实时分析统计数据库——列存储+高效压缩

android EnMicroMsg.db安卓微信数据库获得密码的源码

SQL Server-数据库架构和对象、定义数据完整性（二）

nodejs-ORM 操作数据库中间件waterline的使用

11 月全球数据库排名：PostgreSQL保持上升趋势一路高涨

MySQL数据库root账户密码忘记两种处理方法（保有效）

DBA经验谈：3个最严重的数据库安全问题

历程剖析：阿里云自研HTAP数据库的技术发展之路

阿里云发布数据库产品HybridDB 兼容23种数据类型

如何避免数据库“勒索事件”和“从删库到跑路”的尴尬

十分钟看懂时序数据库II——预处理

十分钟看懂时序数据库I——存储篇

【数据蒋堂】第15期：开放的计算能力为数据库瘦身

阿里云ECS无法连接阿里云数据库的一般原因

资源下载

腾讯云软件源

Rocky Linux

Sublime Text

WebStorm

欢迎您来访！

精选列表

SQL Server日志文件过大 大日志文件清理方法 不分离数据库

云数据库HBase大数据存储及实时分析场景应用解析

阿里云数据库全新功能Redis读写分离，全维度技术解析

Android官方ORM数据库Room技术解决方案：@Embedded内嵌对象（二）

Hadoop之Hive本地与远程mysql数据库管理模式安装手册

系出名门Android(9) - 数据库支持(SQLite), 内容提供器(ContentProvider)

Druid（准）实时分析统计数据库——列存储+高效压缩

android EnMicroMsg.db安卓微信数据库获得密码的源码

SQL Server-数据库架构和对象、定义数据完整性（二）

nodejs-ORM 操作数据库中间件waterline的使用

11 月全球数据库排名：PostgreSQL保持上升趋势 一路高涨

MySQL数据库root账户密码忘记两种处理方法（保有效）

DBA经验谈：3个最严重的数据库安全问题

历程剖析：阿里云自研HTAP数据库的技术发展之路

阿里云发布数据库产品HybridDB 兼容23种数据类型

如何避免数据库“勒索事件”和“从删库到跑路”的尴尬

十分钟看懂时序数据库II——预处理

十分钟看懂时序数据库I——存储篇

【数据蒋堂】第15期：开放的计算能力为数据库瘦身

阿里云ECS无法连接阿里云数据库的一般原因

资源下载

腾讯云软件源

Rocky Linux

Sublime Text

WebStorm

欢迎您来访！

SQL Server日志文件过大大日志文件清理方法不分离数据库

11 月全球数据库排名：PostgreSQL保持上升趋势一路高涨