ClickHouse

简介 Yandex在2016年6月15日开源的一个数据分析的数据库，名字叫做ClickHouse ClickHouse存储层 ClickHouse从OLAP场景需求出发，定制开发了一套全新的高效列式存储引擎，并且实现了数据有序存储、主键索引、稀疏索引、数据Sharding、数据Partitioning、TTL、主备复制等丰富功能。以上功能共同为ClickHouse极速的分析性能奠定了基础。 列式存储 相比于行式存储，列式存储在分析场景下有着许多优良的特性。 1）如前所述，分析场景中往往需要读大量行但是少数几个列。在行存模式下，数据按行连续存储，所有列的数据都存储在一个block中，不参与计算的列在IO时也要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。 2）同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。 3）更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短。 4）自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。 5）高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。 官方数据显示，通过使用列存，在某些分析场景下

主题 ： MySQL 的各种JOIN 大纲 ： 1、徐老师从事多年官方MySQL工作，为众多企业提供MySQL帮助时，企业比较关心的问题是什么呢？ 2、随着MySQL 8.0的成熟和推广，相信越来越多的公司希望升级MySQL 8.0,但又会担心低版本到高版本的升级会不会有兼容问题，徐老师能否分享下相关经验？ 3、徐老师本次主题带来的是JOIN精彩内容，相比MySQL5.7，MySQL8.0在JOIN增强了哪些方面呢？ 4、过多的“left join”经常会导致SQL性能很慢，徐老师可否分享下您对“left join”的建议或者注意事项呢？ 扫一扫左边二维码， 立刻报名本次活动。 嘉宾自我介绍 徐轶韬 MySQL解决方案高级工程师 Oracle公司 MySQL解决方案工程师，为中国及东北亚地区的MySQL用户提供MySQL相关产品的售前咨询，企业级产品介绍服务以及推广和普及MySQL数据库在社区的使用 01 徐老师从事多年官方MySQL工作，为众多企业提供MySQL帮助时，企业比较关心的问题是什么呢？ 企业比较关心的问题主要有三点： 一、在使用软件的过程中能不能得到保障？通过哪些方式提供保障？可以提供哪种程度的保障？ 二、数据安全性。 三、合规的使用软件。 02 随着MySQL 8.0的成熟和推广，相信越来越多的公司希望升级MySQL 8.0

内容来源：宜信技术学院第11期技术沙龙|宜信数据中台全揭秘（一）数据中台整体介绍 主讲人：宜信数据中台解决方案架构师 裴国强 PPT下载：链接: https://pan.baidu.com/s/1eSkSdUo6FmYFmcE4xg0vjw 密码: 99uh 一、数据中台定位 1.1 ADX整体简介-中台定位 首先对中台的服务范围说明： 企业级：针对是整个企业的所有业务部门，横向贯穿整个业务线的数据，纵向贯穿整个数据生命周期，从最开始的数据采集（DB，日志，消息，文件），入湖，标准化，开发（批量作业，流式作业）维度表，最后到数据服务和数据应用。 复用：复用的范围包括，能力的复用，逻辑的复用，数据资产的复用，算法的复用。 能力：对平台能力进行抽象，对于不同平台的对能力的抽象，业务平台（流程控制，管理，审批，权限「等级，继承」，调度），数据平台（批量，流式，UDF，UDAF,数据质量，血缘分析，数据地图，调度，数据资产管理，权限，数据服务）。 分横向和纵向两个方面： 横向划分 大数据基础集群：更贴近硬件的平台，负责提供稳定及高可用的计算运行环境，及安全的数据存储环境 HDFS-数据湖的基础存储，存放表每天的快照，和增量数据。 KUDU-最新快照,用于即席查询，数据服务，流式数据快照。 ClickHouse-Clickhouse做DW和DM层的存储。 数据中台 ：对数据能力的抽象

万级TPS亿级流水-中台账户系统架构设计 标签：高并发 万级TPS 亿级流水 账户系统 背景 业务模型 应用层设计 数据层设计 日切对账 背景 我们需要给所有前台业务提供统一的账户系统，用来支撑所有前台产品线的用户资产管理，统一提供支持大并发万级TPS、亿级流水、数据强一致、风控安全、日切对账、财务核算、审计等能力，在万级TPS下保证绝对的数据准确性和数据溯源能力。 注：资金类系统只有合格和不合格，哪怕数据出现只有0.01分的差错也是不合格的，局部数据不准也就意味着全局数据都不可信。 本文只分享系统的核心模型部分的设计，其他常规类的（如压测验收、系统保护策略-限流、降级、熔断等）设计就不做多介绍，如果对其他方面有兴趣欢迎进一步交流。 业务模型 基本账户管理： 根据交易的不同主体，可以分为 个人账户 、 机构账户 。 账户余额 在使用上没有任何限制，很纯粹的账户存储、转账管理，可以满足90%业务场景。 子账户功能： 一个用户可以开通多个子账户，根据余额属性不同可以分为基本账户、过期账户，根据币种不同可以分为人民币账户、虚拟币账户，根据业务形态不同可以自定义。 （不同账户的特定功能是通过账户上的 账户属性 来区分实现。） 过期账户管理： 该账户中的余额是会随着 进账流水 到期自动过期。 如：在某平台充值1000元送300元，其中300元是有过期时间的，但是1000元是没有时间限制的

本文源码： GitHub·点这里 || GitEE·点这里 一、幂等性概念 1、幂等简介 编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。就是说，一次和多次请求某一个资源会产生同样的作用影响。 2、HTTP请求 遵循Http协议的请求，越来越强调Rest请求风格，可以更好的规范和理解接口的设计。 GET：用于获取资源，不应有副作用，所以是幂等的； POST：用于创建资源，重复提交POST请求可能产生两个不同的资源，有副作用不满足幂等性； PUT：用于更新操作，重复提交PUT请求只会对其URL中指定的资源有副作用，满足幂等性； DELETE：用于删除资源，有副作用，但它应该满足幂等性； HEAD：和GET本质是一样的，但HEAD不含有呈现数据，仅是HTTP头信息，没有副作用，满足幂等性； OPTIONS：用于获取当前URL所支持的请求方法，满足幂等性； 二、场景业务分析 1、订单支付 实际开发中，经常会面对订单支付问题，基本流程如下： 客户端发起订单支付请求 ； 支付前系统本地相关业务处理 ； 请求第三方支付服务执行扣款； 第三方支付返回处理结果； 本地服务基于支付结果响应客户端； 该业务流程中要处理相当复杂的问题，比如事务，分布式事务，接口延迟超时，客户端重复提交等等，这里只基于幂等接口角度来看该流程，其他问题后续再聊。 2、幂等接口

最近想支持一下nosql，难搞，每个nosql server，都很难一天掌握安装和基础用法，所以先决定选用clickhouse ,apache drill (操作文件),Cassandra，这三个下手 hadoop系列也挺好的，但确实没时间搞了，想在9月份之前把beetlsql3搞出来，感觉臣妾做不到哇。 发一个网友修改的springboot-plus项目截图，挺好看，希望他能坚持完善plus项目,希望9月能继续把plus完善一下，比如支持多库。 至于微服务支持，我还是觉得大部分后台管理系统，不需要微服务 来源： oschina 链接： https://my.oschina.net/xiandafu/blog/4298195

本文源码： GitHub·点这里 || GitEE·点这里 一、幂等性概念 1、幂等简介 编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。就是说，一次和多次请求某一个资源会产生同样的作用影响。 2、HTTP请求 遵循Http协议的请求，越来越强调Rest请求风格，可以更好的规范和理解接口的设计。 GET：用于获取资源，不应有副作用，所以是幂等的； POST：用于创建资源，重复提交POST请求可能产生两个不同的资源，有副作用不满足幂等性； PUT：用于更新操作，重复提交PUT请求只会对其URL中指定的资源有副作用，满足幂等性； DELETE：用于删除资源，有副作用，但它应该满足幂等性； HEAD：和GET本质是一样的，但HEAD不含有呈现数据，仅是HTTP头信息，没有副作用，满足幂等性； OPTIONS：用于获取当前URL所支持的请求方法，满足幂等性； 二、场景业务分析 1、订单支付 实际开发中，经常会面对订单支付问题，基本流程如下： 客户端发起订单支付请求 ； 支付前系统本地相关业务处理 ； 请求第三方支付服务执行扣款； 第三方支付返回处理结果； 本地服务基于支付结果响应客户端； 该业务流程中要处理相当复杂的问题，比如事务，分布式事务，接口延迟超时，客户端重复提交等等，这里只基于幂等接口角度来看该流程，其他问题后续再聊。 2、幂等接口