实时数据库

上篇博客提到 Flink SQL 如何 Join 两个数据流，有读者反馈说如果不打算用 SQL 或者想自己实现底层操作，那么如何基于 DataStream API 来关联维表呢？实际上由于 Flink DataStream API 的灵活性，实现这个需求的方式是非常多样的，但是大部分用户很难在设计架构时就考虑得很全面，可能会走不少弯路。 针对于此，笔者根据工作经验以及社区资源整理了用 DataStream 实现 Join 维表的常见方式，并给每种的方式优劣和适用场景给出一点可作为参考的个人观点。 衡量指标 总体来讲，关联维表有三个基础的方式：实时数据库查找关联（Per-Record Reference Data Lookup）、预加载维表关联（Pre-Loading of Reference Data）和维表变更日志关联（Reference Data Change Stream），而根据实现上的优化可以衍生出多种关联方式，且这些优化还可以灵活组合产生不同效果（不过为了简单性这里不讨论同时应用多种优化的实现方式）。对于不同的关联方式，我们可以从以下 7 个关键指标来衡量（每个指标的得分将以 1-5 五档来表示）: 实现简单性: 设计是否足够简单，易于迭代和维护。 吞吐量: 性能是否足够好。 维表数据的实时性: 维度表的更新是否可以立刻对作业可见。 数据库的负载:

文 | 陈肃 DataPipeline CTO 随着企业应用复杂性的上升和微服务架构的流行，数据正变得越来越以应用为中心。 服务之间仅在必要时以接口或者消息队列方式进行数据交互，从而避免了构建单一数据库集群来支撑不断增长的业务需要。以应用为中心的数据持久化架构，在带来可伸缩性好处的同时，也给数据的融合计算带来了障碍。 由于数据散落在不同的数据库、消息队列、文件系统中，计算平台如果直接访问这些数据，会遇到可访问性和数据传输延迟等问题。在一些场景下，计算平台直接访问应用系统数据库会对系统吞吐造成显著影响，通常也是不被允许的。 因此，在进行跨应用的数据融合计算时，首先需要将数据从孤立的数据源中采集出来，汇集到可被计算平台高效访问的目的地，此过程被称为ETL，即数据的抽取（Extract）、转换（Transform）和加载（Load）。 ETL并不是什么新鲜事物。 该领域的传统公司，例如Informatica，早在1993年就已经成立，并且提供了成熟的商业化解决方案。开源工具，例如Kettle、DataX等，在很多企业中也得到了广泛的应用。 传统上，ETL是通过批量作业完成的。即定期从数据源加载（增量）数据，按照转换逻辑进行处理，并写入目的地。根据业务需要和计算能力的不同，批量处理的延时通常从天到分钟级不等。在一些应用场景下，例如电子商务网站的商品索引更新，ETL需要尽可能短的延迟

第一、Otter 基于数据库增量日志解析，准实时同步到本机房或异地机房的Mysql/Oralce数据库，一个分布式数据库同步系统； 基本工作原理图如下： 基于Canal开源产品，获取数据库增量日志数据； 典型管理系统架构，manager(WEB 管理) + node(工作节点) manager运行时推送同步配置到node节点； node节点将同步状态反馈到manager上； 基于zookeeper，解决分布式状态调度的，允许多node节点之间协同工作； 能解决什么？ 1.异构库同步 mysql -> mysql/oracle （目前开源版本只支持mysql增量，目标库可以是mysql或者是oracle，取决于canal的功能） 2.单机房同步（数据库之间RTT < 1ms） 数据库版本升级； 数据表迁移； 异步二级索 来源： CSDN 作者： 杨鑫newlfe 链接： https://blog.csdn.net/u012965373/article/details/104563852

一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之(MR) 在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。 MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。 2) 多进程、多线程并行执行

从各个角度总结了电商平台中的架构实践，由于时间仓促，定了个初稿，待补充完善，欢迎大家一起交流。 转载请声明出处： http://blog.csdn.net/yangbutao/article/details/12242441 作者：杨步涛 关注分布式架构、大数据、搜索、开源技术 QQ:306591368 技术Blog： http://blog.csdn.net/yangbutao 一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之

从各个角度总结了电商平台中的架构实践，由于时间仓促，定了个初稿，待补充完善，欢迎大家一起交流。 转载请声明出处： http://blog.csdn.net/yangbutao/article/details/12242441 作者：杨步涛 关注分布式架构、大数据、搜索、开源技术 QQ:306591368 技术Blog： http://blog.csdn.net/yangbutao 一、 设计理念 1. 空间换时间 1) 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag） 反向代理缓存 应用端的缓存(memcache) 内存数据库 Buffer、cache机制（数据库，中间件等） 2) 索引 哈希、B树、倒排、bitmap 哈希索引适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 1) 任务切分、分而治之

DATA GUARD的最主要的功能是冗灾。当然根据配置的不同,DATA GUARD还可以具备以下特点：高可用、性能提升、数据保护以及故障恢复等。 DATA GUARD可以分为物理STANDBY和逻辑STANDBY两种。二者的最大差别在于，物理STANDBY应用的是主库的归档日志，而逻辑STANDBY 应用的是主库的归档日志中提取的SQL语句。由于二者这一点的区别，决定了物理STANDBY无论从逻辑结构和物理结构都是和主库保持一致，而逻辑 STANDBY则只需保证逻辑结构一致，且逻辑STANDBY在应用SQL语句的时候， 数据库 可以处于打开的状态。 如果从DATA GUARD的保护模式分，可以分为三种不同的保护模式： 保护最大化：这种模式的配置可以保证主库和备库的同步，任何情况下主库的损毁都不会导致已提交数据的丢失。如果主库和备库之间的网络出现问题，或者备库本身出现问题，都会导致主库停止数据处理。 可用最大化：这种模式和上面一种类似，也是会保证主库和备库的同步，区别在于，当网络或备库不可用时，主库仍然可以继续处理。 性能最大化：主库和备库是异步的。这种模式可能在主库出现损毁时，丢失一部分数据。但是这种模式对主库负荷最小，因此具有最好的性能 ========================================================================

1.C#跨平台物联网通讯框架ServerSuperIO（SSIO）介绍 《连载 | 物联网框架ServerSuperIO教程》1.4种通讯模式机制。 《连载 | 物联网框架ServerSuperIO教程》2.服务实例的配置参数说明 《连载 | 物联网框架ServerSuperIO教程》- 3.设备驱动介绍 《连载 | 物联网框架ServerSuperIO教程》-4.如开发一套设备驱动，同时支持串口和网络通讯。 《连载 | 物联网框架ServerSuperIO教程》- 5.轮询通讯模式开发及注意事项。 《连载 | 物联网框架ServerSuperIO教程》- 6.并发通讯模式开发及注意事项 《连载 | 物联网框架ServerSuperIO教程》- 7.自控通讯模式开发及注意事项 《连载 | 物联网框架ServerSuperIO教程》- 8.单例通讯模式开发及注意事项 《连载 | 物联网框架ServerSuperIO教程》- 9. 协议过滤器，解决一包多发、粘包、冗余数据 《连载 | 物联网框架ServerSuperIO教程》- 10.持续传输大块数据流的两种方式（如：文件） 《连载 | 物联网框架ServerSuperIO教程》- 11.实现设备（驱动）与设备（驱动）交互和级联控制。 《连载 | 物联网框架ServerSuperIO教程》- 12.服务接口的开发，以及与云端双向交互

设计理念 1 时间换空间 1.1 多级缓存，静态化 客户端页面缓存（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客户端可以继续用cache，减少流量)，ETag）， 反向代理缓存，应用端的缓存(memcache)，内存数据库，Buffer、cache机制（数据库，中间件等）。 1.2 索引 哈希、B树、倒排、bitmap 哈希索引:适合综合数组的寻址和链表的插入特性，可以实现数据的快速存取。 B树索引:适合于查询为主导的场景，避免多次的IO，提高查询的效率。 倒排索引:实现单词到文档映射关系的最佳实现方式和最有效的索引结构，广泛用在搜索领域。 Bitmap:是一种非常简洁快速的数据结构，他能同时使存储空间和速度最优化（而不必空间换时间），适合于海量数据的的计算场景。 2. 并行与分布式计算 2.1 任务切分、分而治之(MR) 在大规模的数据中，数据存在一定的局部性的特征，利用局部性的原理将海量数据计算的问题分而治之。 MR模型是无共享的架构，数据集分布至各个节点。处理时，每个节点就近读取本地存储的数据处理(map)，将处理后的数据进行合并(combine)、排序(shuffle and sort)后再分发(至reduce节点)，避免了大量数据的传输，提高了处理效率。 2.2 多进程

因为我要同步的数据是实时数据，每日更新，所以选择用这个方式 确保要连接的两台服务器上安装的mysql版本差不多 这里我使用了navicat工具 1.分别给两个数据库创建一个用户名密码都一致的账户，主机填所在服务器的ip 2.在作为主库（master）的服务器上打开命令行，进入mysql。赋予所有权给从服务器。 grant replication slave on *.* to '用户名l'@'从库ip' identified by '密码'; 然后刷新 flush privileges； 3.修改主库所在服务器的配置文件my.ini、xxx.ini 等等 ① 修改server-id项的值，只要不是1都可以，确保值唯一 ② 配置文件中没有就添加下列项 日志文件以mysql-bin开头 4.配置好之后，重启mysql 5.查看master的状态 show master status； 第一次出错，是因为有一个配置文件的值没有修改，和其他配置文件起了冲突。 File和position两个值在配置slave时会用到 6.修改从库（slave）所在服务器的mysql配置文件 ①server-id = （除1之外的任意值） ②replicate-do-db = （从库被同步的数据库） 7.配置好之后，重启mysql 8.在slave服务器上打开命令行编辑器，或者直接用navicat打开命令行。