TiDB

由于目前的项目把mysql换成了TiDb，所以特意来了解下tidb。其实也不能说换，由于tidb和mysql几乎完全兼容，所以我们的程序没有任何改动就完成了数据库从mysql到TiDb的转换，TiDB 是一个分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的优缺点比较 )数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。下面是对有关资料的整理还有一些扩展内容以链接的方式展示，有兴趣可以点击了解一下。 一 TiDb简介 TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点： 1 高度兼容 MySQL 大多数情况下

关注微信公众号“程序员黄小斜”，选择“置顶或者星标” 一起成为更好的自己！ 作者：孙晓光 出处：http://itindex.net/ 知乎，在古典中文中意为“你知道吗？”，它是中国的 Quora，一个问答网站，其中各种问题由用户社区创建，回答，编辑和组织。 作为中国最大的知识共享平台，我们目前拥有 2.2 亿注册用户，3000 万个问题，网站答案超过 1.3 亿。 随着用户群的增长，我们的应用程序的数据大小无法实现。我们的 Moneta 应用程序中存储了大约 1.3 万亿行数据（存储用户已经阅读过的帖子）。 由于每月累计产生大约 1000 亿行数据且不断增长，这一数字将在两年内达到 3 万亿。在保持良好用户体验的同时，我们在扩展后端方面面临严峻挑战。 在这篇文章中，我将深入探讨如何在如此大量的数据上保持毫秒级的查询响应时间，以及 TiDB 是一个开源的 MySQL 兼容的 NewSQL 混合事务/分析处理（ HTAP）数据库，如何为我们提供支持获得对我们数据的实时洞察。 我将介绍为什么我们选择 TiDB，我们如何使用它，我们学到了什么，优秀实践以及对未来的一些想法。 我们的痛点 本节介绍了我们的 Moneta 应用程序的体系结构，我们尝试构建的理想体系结构，以及数据库可伸缩性作为我们的主要难点。 系统架构要求 知乎的 Post Feed 服务是一个关键系统

由于目前的项目把mysql换成了TiDb，所以特意来了解下tidb。其实也不能说换，由于tidb和mysql几乎完全兼容，所以我们的程序没有任何改动就完成了数据库从mysql到TiDb的转换，TiDB 是一个分布式 NewSQL (SQL 、 NoSQL 和 NewSQL 的优缺点比较 )数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。下面是对有关资料的整理还有一些扩展内容以链接的方式展示，有兴趣可以点击了解一下。 一 TiDb简介 　TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 HTAP (Hybrid Transactional and Analytical Processing) 数据库，结合了传统的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持无限的水平扩展，具备强一致性和高可用性。TiDB 的目标是为 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 场景提供一站式的解决方案。TiDB 具备如下核心特点： 1 高度兼容 MySQL 　大多数情况下

作者：殷成文 2019 年 12 月 31 日，我们在 GitHub 上正式开源了 Chaos Mesh。作为一个云原生的混沌测试平台，Chaos Mesh 提供在 Kubernetes 平台上进行混沌测试的能力。本篇文章将围绕 Chaos Mesh 起源及原理等方面进行介绍，并结合具体案例带领大家一起探索混沌测试的世界。 现实世界中，各类故障可能会随时随地的发生，其中有很多故障我们无法避免，例如磁盘突然写坏，或者机房突然断网断电等等。这些故障可能会给公司造成巨大损失，因此提升系统对于故障的容忍度成为很多工程师努力的目标。 为了更方便地验证系统对于各种故障的容忍能力，Netflix 创造了一只名为 Chaos 的猴子，并且将它放到 AWS 云上，用于向基础设施以及业务系统中注入各类故障类型。这只 “猴子” 就是混沌工程起源。 在 PingCAP 我们也面临同样的问题，所以在很早的时候就开始探索混沌工程，并逐渐在公司内部实践落地。 在最初的实践中我们为 TiDB 定制了一套自动化测试平台，在平台中我们可以自己定义测试场景，并支持模拟各类错误情况。但是由于 TiDB 生态的不断成熟，各类周边工具 TiDB Binlog 、 TiDB Data Migration 、 TiDB Lightning 等的出现，测试需求也越来越多，逐渐出现了各个组件的的测试框架。但是混沌实验的需求是共有的

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：王军 运维难，难于上青天。 作为 PingCAP 员工，我们不仅平时自己用着 TiDB，也会自发的想让周围人也用上 TiDB。但在这个过程中，我们发现有以下问题： 上船难：官方推荐的部署方法 TiDB Ansible 限制较多，有一定的学习成本。对于运维同学比较容易上手，但是对于研发同学就比较不友好。用户手册详细但是复杂，其中也有各种各样的限制，特别是遇到错误的时候不好处理。 开船难：用上 TiDB 之后，后续对 TiDB 集群进行运维（如扩容，升级），尤其在 PD 的扩容和缩容，安全性高，但是操作还是有些复杂。 开发上船容易翻：经常见到开发人员不知道水有多深，跟着文档在自己机器上尝试用 TiDB Ansible 部署 TiDB，结果一不小心就把系统改得面目全非。 为了改进和解决这些痛点，我们组队参加了 TiDB Hackathon 2019 比赛，编写了 TiExciting 项目，并最终获得大家的认可拿到了三等奖。 当前的上船门槛有多高？ 在参赛前，我们先评估了一下之前的体感问题是不是真实存在的问题，因此我们在本次 Hackathon Ucloud 新集群上进行了一番实测： 队友 A：腾讯微信研发，从未接触过 TiDB，首次尝试部署： 按照 TiDB Ansible 超长的部署教程，部署 3

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：朱劲松，量化派研发中心系统架构师，主要参与了基础组件开发、API Gateway 等项目，现在致力于公司风控系统相关业务的架构设计和研发。 一、公司简介 量化派（QuantGroup）创办于 2014 年，是数据驱动的科技公司，是国家高新技术企业。量化派以「MOVE THE WORLD WITH DATA, ENLIGHTEN LIFE WITH AI」（数据驱动世界，智能点亮生活）为愿景，利用人工智能、机器学习、大数据技术。为金融、电商、旅游、出行、汽车供应链等多个领域的合作伙伴提供定制化的策略和模型，帮助提升行业效率。量化派已与国内外超过 300 家机构和公司达成深度合作，致力于打造更加有活力的共赢生态，推动经济的可持续发展。 我司从 2017 年年中开始调研 TiDB，并在用户行为数据分析系统中搭建 TiDB 集群进行数据存储，经过一年多的应用和研究，积累了丰富的经验。同时，TiDB 官方推出 2.0 GA 版本，TiDB 愈发成熟，稳定性和查询效率等方面都有很大提升。我们于 2018 年 7 月部署 TiDB 2.0.5 版本，尝试将其应用于风控业务中。风控系统主要是在用户申请放款时，根据风控规则结合模型和用户特征进行实时计算并返回放款结果。 二、业务背景 风控系统中用到的数据主要可以分为两部分：

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者介绍 刘春辉，Shopee DBA 洪超，Shopee DBA 一、业务场景 Shopee（ https://shopee.com/）是东南亚和台湾地区领先的电子商务平台，覆盖新加坡、马来西亚、菲律宾、印度尼西亚、泰国、越南和台湾等七个市场。Shopee 母公司 Sea（ https://seagroup.com/）为首家在纽约证券交易所上市的东南亚互联网企业。2015 年底上线以来，Shopee 业务规模迅速扩张，逐步成长为区域内发展最为迅猛的电商平台之一： 截止 2018 年第三季度 Shopee APP 总下载量达到 1.95 亿次，平台卖家数量超过 700 万。 2018 年第一季度和第二季度 GMV 分别为 19 亿美金和 22 亿美金，2018 上半年的 GMV 已达到 2017 全年水平。2018 年第三季度 GMV 达到了创纪录的 27 亿美元, 较 2017 年同期年增长率为 153%。 2018 年双 11 促销日，Shopee 单日订单超过 1100 万，是 2017 年双 11 的 4.5 倍；刚刚过去的双 12 促销日再创新高，实现单日 1200 万订单。 <center>图 1 Shopee 电商平台展示图</center> 我们从 2018 年初开始调研 TiDB，6

作者：唐刘 对于 80 后的男生来说，『七龙珠』是一部绕不开的经典漫画，里面的主角孙悟空掌握了一项强大的必杀技 - 元气弹，他通过收集万物的能量，汇聚成一个有巨大破坏力的能量球，然后发射给反派将其打败。每每在漫画里面看到这样的情况，年少的我就激动不已，梦想着有一天也可以自己举起双手，汇聚出元气弹。 当然，现在我们知道举起双手是不可能造出元气弹了，但从另一方面来说，如果我们能很好地利用好大家的力量，统一的往一个方向努力，解决某一个特定的问题，这不就是另一种元气弹的形式吗？在 PingCAP，我们每个季度都会做这样一次活动，叫做 Special Week（后面简称 SW），在 2019 年第四季度，我们 SW 的主题是 - Tools matter，很直白，就是工具很重要。 PingCAP 一直致力于跟社区一起构建 TiDB 的生态，这其中 Tools 扮演了非常重要的角色。大家可能会用 TiDB Data Migration（以下简称 DM）将 MySQL 的数据迁移到 TiDB，或者使用 TiDB Binlog 工具将 TiDB 的数据同步到下游其他的服务。 这次 Special Week 希望集思广益，从其他角度来改进 Tools，降低大家使用 TiDB 的门槛。 为了将 SW 相关的进度公开到社区。我们创建了一个 GitHub project 来放置所有的开发任务

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：赵钰莹 本文转载于 InfoQ。 原文链接 ： https://www.infoq.cn/article/EEKM947YbboGtD_zQuLw 作为混沌工程的重要推动者，Netflix 在混沌工程手册（ https://www.infoq.cn/article/AsN34J2T9QDXB0s-t9JN ）中谈到，在生产环境进行软件验证的想法通常会被嘲笑。过去，这句话基本都被翻译为“我们在发布之前不打算完善地验证这些代码”。在经典的测试链路中，寻找软件缺陷的普遍信条是离生产环境越远越好。例如，在单元测试中发现缺陷要比在集成测试中发现更好，这里的逻辑是：离生产环境越远，或者是离发布越远的时候，发现的缺陷就越容易被找到根本原因并彻底修复。 对于混沌工程而言，整个链路刚好反过来：在离生产环境越近的地方进行实验越好，理想的实践就是直接在生产环境中执行。对于软件工程师来说，最难的莫过于，系统用户永远不会如预期那样与系统进行交互，混沌工程是解决这一问题的理想方法，可以让开发者了解除代码之外，整个系统其他方面的情况，特别是状态、输入、以及第三方系统导致的难以预见的行为。 据了解，在 TiDB 的研发初期，PingCAP 就引入了混沌工程，以此保证 TiDB 在各种极端情况下的稳定性。在 ArchSummit

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文转载自微信公众号“ OPPO大数据 ”。 作者介绍 ：OPPO 数据分析与解决方案团队主要负责 OPPO 全集团的大数据分析和解决方案提供，团队成员多来自一线互联网公司及著名高校，在 OPPO 众多场景的大数据应用方面有很深经验，极大的支撑了业务迅速发展。 文章具体作者：羊欢，代凯，柳青，陈英乐。 OPPO 大数据中心在 2019 年初承接了接入某业务线核心数据的重要任务：一期目标是建立一个能提供准实时大数据查询服务的数据仓库。我们选用了之前从未在公司大规模正式使用过的 TiDB 作为核心数据库引擎。本文记录这次吃螃蟹的一些经验和教训，供大家参考。 前期工作 核心挑战 经过需求调研阶段，我们发现面临以下核心的挑战： 大数据能力支持 。从业务数据量看，当前虽然尚在 TB 级别，但增长速度非常快，业务本身有进行全量整合分析查询的需求。 数据接入困难 。数据分散且多样，跨国，多种 DB 类型，多网络环境，接入难度较大。 数据变动频繁 。核心数据存在生命周期，在生命周期内变动频繁，这与互联网的核心数据一旦生成就不再变化有较大不同。 服务实时性较高 。数据整合的速度和查询结果越实时，对业务价值就越大。 现有技术架构体系 公司数据中心目前承载着公司各业务系统积累的数据。 数据仓库方面的技术体系：