数据库开发简介随着互联网的发展，数据量的增长其实一直呈爆发式增长，因为各种数据每时每刻都在不断地原样或者经过少量的改动和添加后被复制到互联网上。角落。为了适应互联网数据的海量增长，在后端和架构上，数据库的发展大致经历了“单库单表->主从读写分离->分表分表”-database->NoSQL->NewSQL”这样的过程。一开始，我们把所有的数据都堆在一个数据表里；后来为了提高性能，增加数据扩展能力，采用了“主从读写分离”和“分表分库”的方式。实例间的数据同步不会对现有业务造成太大影响。后者需要以适合业务逻辑的方式制定合理的分表分库策略；而后来出现的NoSQL则打破了传统关系数据库固有的一些局限性。它们有不同的类型。有的是为了解决高性能读写的需求，有的是为了解决海量数据存储的需求，有的是要求数据结构本身具有可扩展性；NoSQL不同的类型解决不同的问题，侧重点不同，今天出现的NewSQL更倾向于把数据库看成是一种黑盒服务。你仍然可以按照传统的数据库协议使用方式（比如传统的MySQL使用方式）来使用它，但是数据存储服务本身既可以拥有很高的读写性能，又可以轻松实现水平扩展。NewSQL并不是一个全新的东西。我们可以看成是之前积累的数据库技术结合分布式技术的综合解决方案。该服务在内部实现了高可用性、高性能和可扩展性。“热数据”与“冷数据”在简单了解了数据库的发展过程后，我们将介绍目前在数据存储中遇到的问题和一些业务背景。作为气象大数据服务商，随着我们积累的数据量和种类越来越多，我们发现我们迫切需要一个全球范围内统一的数据路径规划和规范。很多时候，我们从数据源获取的数据需要立即分发给在线用户，供内部项目使用。如果单纯的按需实现，数据流会很混乱。基于这种考虑，我们引入“热数据”（“在线数据”）和“冷数据”（“离线数据”）的概念：“热数据”是指需要实时分发给用户的数据，即，从数据源抓取后，需要将数据清洗并存储在一个可以快速分发的存储介质（如Redis）中，供API或面向用户的系统使用。“热点数据”线路需要重点保障服务质量和稳定性。为了保证数据的时效性，在数据处理中也是高优先级的数据。“热数据”可能是临时或短期存储的，以后的数据可能会覆盖现有数据。“冷数据”是指不需要立即分发给用户的数据。这些数据可能永远不会原样分发给用户，而是需要长期积累，这样我们才能在这个分析的基础上得出更高的层次。“冷数据”的典型使用场景是供内部数据评估系统评估和分析数据准确性，也可用于算法团队建模。设置这条数据线的原则是不影响“热点数据”的服务质量，特别是及时性和稳定性，同时也是为了满足一些线下项目的数据使用需求。这实际上并不是一个新概念。许多数据服务公司都有类似的设计。我们只是根据我们的业务特点借用了这样的概念，但它们的含义可能与您在其他地方看到的类似。含义各不相同。结合我们具体的业务场景，“热点数据”这条线其实一直在有效运行，即我们第一时间从数据源获取数据，存储到高性能的存储介质中，然后通过HTTP协议。它是实时更新的最新数据。对于某些类型的数据，我们还需要在可视化项目中查看历史变化并进行简单的聚合计算，这意味着数据需要积累一段时间，所以我们也需要一些可以存储的媒体执着地。以实时天气为例。收集完数据后，我们立即将最新的数据存储到Redis中。从数据积累的角度，我们也将新数据写入MySQL。之前我们也是这样做的，但是随着数据量的急剧膨胀，问题很快就会出现在MySQL中。对于“亿”行或更多行的MySQL单表，操作会变得越来越困难，大规模的抽取或数据插入操作可能导致整个MySQL无法提供服务，这对于在线业务来说非常重要。是不可接受的。离线数据中心的实现在提出“冷数据”的概念后，我们意识到那些长期存在的历史数据其实需要存储在“冷数据”的数据中心池中，而在线MySQL只需要保留最近的数据就是这样。另外，为了不改变现有项目使用数据的方式，降低数据库用户的使用门槛，我们需要兼容MySQL单表使用协议，无论是在线数据库还是“离线数据”数据中心.很快我们就开始考虑NewSQL的方案，TiDB顺理成章地进入了我们的视野。这是一个完美的解决方案，既能兼容现有的数据使用方式，又能实现数据的水平扩展，但我们不得不搭建一个最小版本的TiDB数据集群的成本相对于我们目前作为“线下”的角色来说还是有些高data”存储中心，而我们的股票服务基本都是基于阿里云的，所以我们最终选择了阿里云，最近推出了云数据库PolarDB。这期间我们也研究了很多其他的数据库解决方案，比如DRDS、OceanBase、GoogleCloudSpanner、AmazonAurora等。数据同步和数据过期有了离线数据存储中心后，我们开始考虑如何将“热数据”转化”变成“冷数据”，同时也让在线数据库能够自动过期超过时间窗的历史数据。另外，由于内部可视化项目也希望看到实时的直播数据，所以离线数据最好能快速获取最新的直播数据。既然是两个MySQL（集群）之间的实时数据传输，那么很自然的想到我们可以在主从节点之间做一个类似于binlog的数据同步机制。这种同步可以实现秒级延迟。在实时性方面是完全可以接受的。但是，这不能是简单的数据同步，因为离线数据无法同步在线数据的过期操作。更具体的，我们可以概括为：MySQL从主节点同步主节点的所有数据添加和数据修改操作，但不同步数据删除操作。经过研究，我们发现TiDB提供的同步工具Syncer可以实现这一点。我们只需要在配置中指定过滤掉DELETEDML语句即可。例子如下：[[skip-dmls]]db-name="weather_data"tbl-name="weather_now_history"type="delete"数据过期方案可以直接借助MySQL自带的EVENT和PROCEDURE完成机制。首先我们可以创建一个程序来删除数据：CREATEDEFINER=`weather`@`%`PROCEDURE`weather_data`.`del_old_data`(IN`date_inter`int)BEGINdeletefromweather_data.weather_now_historywheredatetime
