1. 瓶颈1.1. 在网络带宽有限、存储昂贵的时期1.2. 移动设备正日益成为人们访问互联网的首选的今天1.3. 数据压缩成了缓解这些瓶颈的关键2. 字典转换2.1. dictionarytransforms2.2. 完全改变了人们对数据压缩的认知2.2.1. 压缩变成了一种对各种类型的数据都有用的算法2.3. 事实上今天所有的主流压缩算法（比如GZIP或者7-Zip）都会在核心转换步骤中使用字典转换3. 基本字典转换3.1. 统计压缩主要关注数据流中单个符号的出现概率3.2. 这一概率与其周围可能出现的符号无关3.3. 符号字典3.4. 任何出现可以重复使用的相似内容分组的地方，都会有“短语

1. 压缩算法可归为两类1.1. 统计压缩（即VLC）1.2. 字典压缩（如LZ78）1.3. 从不同的角度利用了给定数据流中存在的统计冗余信息2. 上下文变换2.1. contextualtransform2.2. 给定一组相邻的符号集，对它们进行某种方式的变换使其更容易压缩3. 行程编码3.1. run-lengthencoding，RLE3.2. 过去40多年来看似很简单、实则很高效的编码技术3.3. 单字符上下文模型3.3.1. 对任何给定的符号，在编码时我们都只考虑它的前一个符号3.3.1.1. 如果这两个符号是相同的，那么行程继续3.3.1.2. 如果不相同，那么当前行程终止3.4

概述Hive的执行计划描述了一个hiveSQL语句的具体执行步骤，通过执行计划解读可以了解hiveSQL语句被解析器转换为相应程序语言的执行逻辑。通过执行逻辑可以知晓HiveSQL运行流程，进而对流程进行优化，实现更优的数据查询处理。同样，通过执行计划，还可以了解到哪些不一样的SQL逻辑其实是等价的，哪些看似一样的逻辑其实是执行代价完全不一样。如果说Hive优化是一堵技术路上的高墙，那么关于Hive执行计划，就是爬上这堵高墙的一架梯子。不同版本的Hive会采用不同的方式生成的执行计划。主要区别就是基于规则生成hive执行计划，和基于成本代价来生成执行计划。而hive早期版本是基于规则生成执行计

1. 在线备份2. 离线备份2.1. 关闭MySQL做备份是最简单、最安全的2.2. 所有获取一致性副本的方法中最好的2.3. 损坏或不一致的风险最小2.4. 根本不用关心InnoDB缓冲池中的脏页或其他缓存2.5. 不需要担心数据在尝试备份的过程中被修改2.5.1. 服务器不对应用提供访问3. 备份时间3.1. 将备份复制到目的地需要多久4. 备份负载4.1. 在将备份复制到目的地时对服务器性能的影响有多大4.2. 在备份服务器上压缩而不是在MySQL服务器上4.3. PerconaXtraBackup和MySQLEnterpriseBackup这样的工具都有限流选项，可在使用pv时加--r

我从数据库中获取了一个unix时间戳，我正在尝试从中创建一个人类可读的日期。我是这样用的longt1=[timelongLongValue];NSDate*date=[NSDatedateWithTimeIntervalSince1970:t1];其中time是时间戳。当我打印日期时，我得到1956-02-1819:04:01+0000代替2013-01-0212:31:03+0000时间戳是1356765933449 最佳答案 正如鲍里斯在他的回答中正确指出的那样，这是一个整数溢出问题。我不知道你的time对象是什么，但不是sig

1. 每个人都知道需要备份，但并不是每个人都能意识到需要的是可恢复的备份1.1. 如果你没有提前做好备份规划，也许以后会发现已经错失了一些最佳的选择1.2. 在服务器已经配置好以后，才想起应该使用LVM，以便获取文件系统的快照——但这时已经太迟了1.3. 如果你没有计划做定期的恢复演练，当真的需要恢复时，就会发现并没有那么顺利2. 不要掉进副本就是备份的陷阱2.1. 副本对生成备份而言是一个干涉较少的源，但它不是备份本身2.2. 确保备份可以通过DROPTABLE测试2.2.1. “遭受黑客攻击”的测试2.2.2. 能通过数据中心失败的测试2.2.3. 如果是基于备库生成备份，需要通过从源重建

作为可观测性体系之一的分布式追踪一直是一个备受争议的话题。作为过去每届全球知名大会KubeCon以及国内各种技术峰会所扯的老牌技术，曾一度被寄予厚望，被认为会彻底改变系统观测认知。然而，五年已经过去了。。。一、什么是DistributedTtracing?通常来讲，分布式跟踪是一种在分布式系统和微服务中传播的请求，生成有关这些请求的高质量数据，并使其可供分析的方法。分布式追踪(DistributedTracing)是一种用于监测分布式系统中请求流程的技术。它可以追踪一个请求在不同的微服务中的执行情况，并将这些信息整合到一个完整的请求链路图中，以便于监测和调试。分布式追踪通常通过在请求的不同阶段

1. “快速、精确和实现简单”1.1. 三者永远只能满足其二，必须舍掉一个2. 排序优化2.1. 无论如何排序都是一个成本很高的操作，所以从性能角度考虑，应尽可能避免排序或者尽可能避免对大量数据进行排序2.2. 文件排序（filesort）2.2.1. MySQL需要自己进行排序，如果数据量小则在内存中进行，如果数据量大则需要使用磁盘2.2.2. 完全是在内存中排序不需要任何磁盘文件时也是如此2.3. 排序算法2.3.1. 两次传输排序（旧版本使用）2.3.1.1. 读取行指针和需要排序的字段，对其进行排序，然后再根据排序结果读取所需要的数据行2.3.1.2. 即需要从数据表中读取两次数据，第

Hellofolks，我是Luga，今天我们来聊一下可观测生态领域相关的技术-DistributedTracing(分布式追踪)。什么是“DistributedTracing-分布式追踪”?DistributedTracing(分布式追踪)是一种用于监测和分析分布式应用程序的技术和方法。它旨在追踪和记录应用程序中的请求和操作，从而提供对应用程序的全局视图和性能分析。在分布式系统中，应用程序通常由多个微服务或组件组成，这些组件可能分布在不同的计算机、容器或云环境中。这种分布式环境使得监测和调试应用程序变得更加困难，因为单个请求可能会在多个组件之间传递，并涉及多个网络调用。从本质上来讲，分布式追踪

1. MySQL的客户端/服务器通信协议1.1. MySQL的客户端和服务器之间的通信协议是“半双工”的1.2. 在任何时刻，要么是由服务器向客户端发送数据，要么是由客户端向服务器发送数据，这两个动作不能同时发生1.3. 当查询的语句很长的时候，参数max_allowed_packet就特别重要了1.4. 一般的服务器响应给用户的数据通常很多，由多个数据包组成1.5. 当服务器开始响应客户端请求时，客户端必须完整地接收整个返回结果，而不能简单地只取前面几条结果，然后让服务器停止发送数据1.5.1. 在必要的时候一定要在查询中加上LIMIT限制1.6. 当客户端从服务器取数据时，看起来是一个拉数