首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    使用shell批量生成数据整合式迁移的脚本(r8笔记第52天)

    对于数据整合式迁移,基本就是小霸王的二合一,四合一,八合一这样的节奏,把几个尽可能相关业务的数据库中的数据整合到一个库里。彼此还是独立的schema,倒也是相安无事。 在这种整合式迁移中,比较让人纠结的部分就是性能不是排第一位,而是迁移前的准备比较琐碎。 如果环境中有大量的db link,那就好像蜘蛛网一般,每个环境之间都有着千丝万缕的联系,如果准备不当,出了一点小的差错,那可能就是伤筋动骨的影响了。或者环境中存在这大量 的连接用户,有的环境关联业务多,连接用户可能几十上百个。这个时候准备脚本的时候就感觉

    04

    工具分享丨分析GreatSQL Binglog神器

    事务控制事件涵盖了事务的起始时间、起始位置、结束时间和结束位置。通过这些详细信息,我们能够计算事务的大小,进而评估其是否属于大型事务,以及是否可能引起主从同步的延迟问题,及时发现大事务,可避免复制故障。 简介 本文分享的神器的名字就叫做binlog_summary,出自陈臣老师的手笔,也是开源的Python脚本文件,开源地址:https://github.com/slowtech/dba-toolkit/blob/master/mysql/binlog_summary.py 下载 运行此工具需要有Python环境,若没有python环境请自行下载 下载binlog_summary.py脚本,并授权 $ wget https://raw.githubusercontent.com/slowtech/dba-toolkit/master/mysql/binlog_summary.py $ chmod 755 binlog_summary.py 先用./binlog_summary.py -h查看下帮助 $ ./binlog_summary.py -h usage: binlog_summary.py [-h] [-f BINLOG_TEXT_FILE] [--new] [-c {tps,opr,transaction}] [--start START_DATETIME] [--stop STOP_DATETIME] [--sort SORT_CONDITION] [-e] [--limit LIMIT] options: -h, --help show this help message and exit -f BINLOG_TEXT_FILE, --file BINLOG_TEXT_FILE Binlog text file, not the Raw binary file --new Make a fresh start -c {tps,opr,transaction}, --command {tps,opr,transaction} Command type: [tps, opr, transaction],tps: transaction per second, opr: dml per table, transaction: show transaction info --start START_DATETIME Start datetime, for example: 2004-12-25 11:25:56 --stop STOP_DATETIME Stop datetime, for example: 2004-12-25 11:25:56 --sort SORT_CONDITION Sort condition: time or size, you can use it when command type is transaction -e, --extend Show transaction info in detail,you can use it when command type is transaction --limit LIMIT Limit the number of rows to display 其中参数介绍:

    01

    akka-typed(8) - CQRS读写分离模式

    前面介绍了事件源(EventSource)和集群(cluster),现在到了讨论CQRS的时候了。CQRS即读写分离模式,由独立的写方程序和读方程序组成,具体原理在以前的博客里介绍过了。akka-typed应该自然支持CQRS模式,最起码本身提供了对写方编程的支持,这点从EventSourcedBehavior 可以知道。akka-typed提供了新的EventSourcedBehavior-Actor,极大方便了对persistentActor的应用开发,但同时也给编程者造成了一些限制。如手工改变状态会更困难了、EventSourcedBehavior不支持多层式的persist,也就是说通过persist某些特定的event然后在event-handler程序里进行状态处理是不可能的了。我这里有个例子,是个购物车应用:当完成支付后需要取个快照(snapshot),下面是这个snapshot的代码:

    02

    akka-typed(10) - event-sourcing, CQRS实战

    在前面的的讨论里已经介绍了CQRS读写分离模式的一些原理和在akka-typed应用中的实现方式。通过一段时间akka-typed的具体使用对一些经典akka应用的迁移升级,感觉最深的是EvenSourcedBehavior和akka-cluster-sharding了。前者是经典akka中persistenceActor的替换,后者是在原有组件基础上在使用方面的升级版。两者都在使用便捷性方面提供了大幅度的提升。在我看来,cluster-sharding是分布式应用的核心,如果能够比较容易掌握,对开发正确的分布式系统有着莫大的裨益。但这篇讨论的重点将会集中在EventSourcedBehavior上,因为它是实现CQRS的关键。而CQRS又是大数据应用数据采集(输入)管理最新的一个重要模式。

    03

    oracle分区两大陷阱

    1.个别场景不能从根本上提高查询速度 在Oracle10g时不支持自动生成分区,技术人员都是手动创建一年或者半年的分区或者当超过限制时把数据都load到最大值分区,但是一年半年过后要么出现数据无法插入或者某个分区数据剧增,这个时候出现了Oracle11g的自动分区功能,但是自动分区名称不能人为设置。如果说数据量过大或者出现跨分区查询会出现性能问题。 举个栗子:线上有一个日志储存系统,每天大概存储1000W左右的数据,支持分页排序并且按照日期查询功能(如果不排序,这个数据量对于Oracle是小ks)于是我们采用了分区+覆盖索引(如果想进一步了解.....)查询的的功能,性能稍微提升。但是一段时间后发现还是拖死系统。(因为这就是CAP问题,想从根本上解决问题,请建议公司采用nosql(habase、ELK)实现)。 如果有这样一种这样场景,工资小于等于5000,大于5000并且小于等于12000,大于12000并且小于25000,大于等于25000分别按照这些工资级别创建分区则非常高效,因为可以指定分区进行查询(` select * from TBL_OPR_CNT partition(5000_part);`),因为指定分区查询,效率直接提升。

    03

    Akka-CQRS(9)- gRPC,实现前端设备与平台系统的高效集成

    前面我们完成了一个CQRS模式的数据采集(录入)平台。可以预见:数据的产生是在线下各式各样的终端系统中,包括web、桌面、移动终端。那么,为了实现一个完整的系统,必须把前端设备通过某种网络连接形式与数据采集平台集成为一体。有两种方式可以实现需要的网络连接:Restful-api, gRPC。由于gRPC支持http/2通讯协议,支持持久连接方式及双向数据流。所以对于POS设备这样的前端选择gRPC作为网络连接方式来实现实时的操作控制应该是正确的选择,毕竟采用恒久连接和双向数据流效率会高很多。gRPC是google公司的标准,基于protobuffer消息:一种二进制序列化数据交换机制。gRPC的优势在这里就不再细说,读者可以参考前面有关gRPC的讨论博文。

    02
    领券