知鸦日报2024-07-01

工具型产品是用于帮助用户解决特定问题的互联网产品，今天来聊聊它们有什么设计特性？

界面设计能力的提升可以通过临摹来实现。过去临摹国外飞机稿是常见的选择，但现在这种练习已经不合适了。国内的招聘和项目需求与国外设计风格不同，临摹国外作品只会产生负面影响。因此，要提高界面设计能力，需要聚焦在国内真实的招聘和项目需求上，选择更适合的临摹对象。

这篇文章主要讲述了需求文档的重要性和作者对于自己写的需求文档的反馈。作者发现，需求概述和需求详述部分受到了很强烈的反响，收获了很多赞。然而，其他模块的反响却平平。作者也发现，尽管自己审核通过了需求文档，但在评审会上仍然出现了很多问题，这让他感到很讽刺。作者希望能够持续开放评论，接受各方的批注和指正，提升自己的需求文档写作技能。

本文将分享京东零售在指标中台建设方面的实践经验。京东指标中台依据现代数据栈、Headless BI、数据虚拟化和数据编织等方法论，并结合自身了多运营模式，多运营视角，多数据维度等业务特点，构建了从指标定义到指标生产再到指标消费的全链路解决方案。指标中台技术不仅仅是一个技术实现，更是一种组织和管理数据的战略思维。指标中台技术是企业在数字化转型过程中的一种重要策略，它通过构建共享平台来整合企业的核心能力，从而提升业务效率和市场响应速度。随着技术的发展和市场的变化，中台技术将继续演进，为企业带来更多的创新和价值。

金融领域文档智能面临的挑战包括PDF文件过长、复杂版面、图像质量问题。为解决这些问题，文章介绍了文档分析与识别的技术综述。其中，图像处理是重要环节，包括文档检测、图像矫正和增强。最新研究表明，使用Swin-T替换ResNet-50能够显著提高精度，特别是在检测不完整或遗漏目标的情况下。此外，基于多模态融合的版面分析工作通过实验发现，采用VSR等多模态模型和基于Mask R-CNN技术能够改善版面分析的效果。

本文细致地描述了关于Redis Proxy RT上升后连接倾斜问题的排查过程和根本原因，最后给出了优化方案。

taro4.0已经beta版本好久了，去年底就关注到了相关的立项，据说今年的第二季度会发布正式版本。

这篇文章介绍了如何使用Spring的AbstractRoutingDataSource抽象类来实现动态数据源的功能。该类继承了AbstractDataSource类并实现了InitializingBean接口。通过配置targetDataSources属性，可以根据具体的数据源key来获取对应的DataSource对象。文章还提到了一些大型互联网公司使用的数据库中间件，如360的Atlas和阿里的DRDS。实现动态数据源的方法可以帮助实现读写分离。

SQL的Code Review主要是为了确保数据易用性和指标评估。在设计和开发阶段，可通过可视化来确定需要加工的指标并进行修改。在评估指标时，需要确认指标是否已生产，是否满足需求，并评估其产出时间和降级策略的适应性。为了提高易用性，我们需要可视化获取指标信息、模糊查询、明确加工口径和配置，并了解降级策略和任务属性。指标配置方面，需要考虑新增指标的配置、指标生产归属、降级策略的选择，以及生成执行的Hive SQL的优化。优化算法、异常兼容性和单表操作规避join等能力上的优化，能提升SQL的性能和稳健性，最终改善SQL执行质量。

这篇文章主要介绍了InnoDB存储引擎中记录的组成部分，包括可选标识、变长字段长度、记录头部、索引、事务ID和回滚指针。还提到了聚簇索引和二级索引的叶子节点和非叶子节点的存储方式，以及变长字段存储在overflow page中的规则。通过查阅资料和使用开源项目alibaba/innodb-java-reader，读者可以更好地理解B+树节点的索引页结构、点查和范围查询、索引页的内部结构以及每个行的组成。这些信息对于理解InnoDB的存储结构和实现事务隔离级别具有重要意义。

这篇文章主要介绍了一个通用的广告系统架构，包括MR、Spark的计算，使用Presto、Impala等查询的ROLAP类，以及面向数据的服务供BI、Dashboard、算法工程师使用。文章还提到了样式平台的作用，算法数据驱动业务流程，以及DMP的功能。

这篇文章介绍了作者对InnoDB的研究和理解的过程。作者通过阅读代码和文档，尝试自己实现，并制作了清晰易懂的图表来解释InnoDB的内部数据结构。作者已经实现了InnoDB的主要数据结构，并对表空间文件的存储格式进行了文档化。接下来作者计划撰写几篇关于一些有趣但未记录的结构的文章，并配以代码和图表进行说明。

这篇文章介绍了一个名为innodb_ruby的库和命令行工具。它提供了一种解析和转储InnoDB记录的方法，包括解析索引页和递归索引。通过加载一个"describer"类，可以获取记录的详细信息，并将其转储。作者还提供了一些示例页面转储，以及如何使用工具进行索引递归。这个工具对于理解和分析InnoDB数据库非常有用。

InnoDB是MySQL中的一种数据存储引擎，它使用“空间”来管理数据存储。每个空间都有一个32位整数的空间ID，用于标识该空间。每个空间又被划分为页面，通常每个页面大小为16 KiB。页面包含头部和尾部，用于标识页面类型、空间ID、页面号等信息。空间文件由多个页面组成，每个文件都有一个必需的超级结构，用于跟踪空间大小和空闲的、碎片的、满的扩展。每个空间还包含一个INODE页面，用于存储和文件段相关的列表。系统空间是InnoDB中的特殊空间，其中包含了一些固定页面号的页面，用于存储关键信息。每个表的空间文件由多个页面组成，其中包括根索引页面和存储表数据的页面。下一步我们将介绍InnoDB中的空闲空间管理。

这篇文章深入解析了InnoDB的内部结构和页面管理方法。它提到了INODE页面和文件段的结构，以及文件段的FREE和NOT_FULL列表。每个索引使用一个文件段用于叶子页面和一个文件段用于非叶子（内部）页面。文章还介绍了如何将整个多层结构连接在一起，包括索引根页面指向两个INODE（文件段），每个INODE都有一个片段数组和整个扩展的列表。这篇文章详细介绍了InnoDB的内部结构和页面管理的细节，包括索引如何使用文件段。下一步，文章将介绍用户角度最重要的页面类型-索引页面的结构。

这篇文章详细介绍了使用innodb_ruby库和命令行工具来检查InnoDB表的页面管理结构。作者通过示例展示了空表和包含100万行数据的表的页面管理结构，其中叶子索引文件段的页面利用率为85.52%。文章还提到了InnoDB的“段填充因子”，该因子在原始MySQL中为87.5%，但在Twitter MySQL中可以进行配置。此外，作者还指出，内部索引文件段由于只有三个页面，所以文件段列表为空。总之，这篇文章详细介绍了innodb_ruby工具的使用和InnoDB表的页面管理结构。

这篇文章主要讲述了InnoDB索引页的物理结构。索引页包括FIL头和尾、FSEG头、索引头、系统记录和用户记录。索引头存储了索引页的相关信息，如索引ID、记录格式、最大事务ID等。系统记录包括infimum和supremum，分别代表页中最低和最高的键值。用户记录按插入顺序添加到页中，并通过“next record”指针连接在一起，可以轻松按升序扫描。通过“next page”指针，可以从页到页按升序扫描整个索引。因此，实现升序表扫描也很容易。文章还提到了页目录的作用和页中的自由空间。

这篇文章深入介绍了InnoDB索引的逻辑结构。它解释了索引树中不同类型的节点的作用，包括叶子节点和非叶子节点。文章还提供了一个例子来说明如何使用innodb_space工具查看索引页的摘要信息、记录数量以及记录的链接顺序。此外，文章还展示了如何使用page-dump模式查看记录的内容，并解释了记录字段的含义。最后，文章展示了使用index-recurse模式递归整个索引的输出结果，并给出了一个示例的多层索引树的结构。根据更详细的上下文，这些信息可以更好地回答问题。

这篇文章进一步介绍了InnoDB记录的物理结构，特别是二级索引记录。二级索引记录的结构与聚集索引类似，但在叶子页中会包含聚集键字段。非叶子页的记录结构比较简单，只包含指向子页的页号。文章还提到了二级索引记录的每行开销和每页开销，以及页面目录的作用。下一篇文章将描述页面目录及其在高效检索记录中的作用。

这篇文章进一步介绍了InnoDB内部的“页面目录”结构，并提供了一些实际示例。页面目录是一个固定宽度的数据结构，用于优化搜索。每4个记录中的一个会被添加到页面目录中，以便快速定位记录。文章还展示了页面目录在逻辑层面的样子，并说明了它如何提高搜索效率。通过使用B+树结构和页面目录，可以避免比较大量记录来查找目标记录。然而，读者需要注意，这些功能是用于说明和学习目的，不应在实际环境中使用。文章还提供了一个基本的搜索算法，从根页面开始，进行线性搜索直到找到不超过搜索关键字的最高键的单个记录。如果当前页面是叶子页面，则返回该记录，如果当前页面是非叶子页面，则加载该记录所指向的子页面，然后返回到步骤2。同时，文章还提供了一些收集的统计数据进行查看。

这篇文章主要介绍了一些InnoDB数据库的bug。文章列举了几个bug的具体情况和影响。其中包括插入过程中导致页面严重低填充、浪费了62个页面、预留了过多的磁盘空间、未能合并低填充页面、在目标页面已满的情况下未考虑合并相邻页面等。这些bug的发现是通过使用innodb_space工具来检查生产表时发现的。这些bug的修复将提高InnoDB数据库的性能和空间利用率。

在InnoDB中，如果一个表没有声明主键或适用的唯一索引，它会自动添加一个名为ROW_ID的隐藏列，并根据该列对数据进行聚集。所有使用ROW_ID列的表共享同一个全局序列计数器，该计数器存储在系统表空间中。为了确保生成的ID不冲突，计数器每生成256个ID就会被写入磁盘。具有隐式聚集键的表可能在操作（无关的）表的删除过程中出现随机插入停顿，并且并行插入多个具有隐式键的表可能受到性能限制。每生成的256个值都会导致对SYS页面修改的日志写入和刷新。

本文讨论了InnoDB中的双写缓冲区的分配和使用。双写缓冲区是InnoDB的页面刷新策略的一部分，用于在将页面写入最终目的地之前，将它们写入一个连续的临时区域。作者发现，在分配双写缓冲区时，会多余地分配一些页面，这些页面永远不会被使用。这是因为代码在分配完所需的页面后，仍然分配了一些额外的页面来填满片段数组。尽管这种浪费很小，但作者认为代码可以进行优化和重写。文章提供了使用innodb_ruby工具来查看文件段的详细信息，并总结了这个问题的一些解决方案。

InnoDB实现了多版本并发控制（MVCC），允许用户以不同版本的数据进行交互。每当记录被修改时，当前版本的数据会被存储为“撤销记录”在“撤销日志”中。读取索引时，事务使用“读视图”来控制事务所能看到的记录版本。长时间运行的事务会导致非常旧的读视图，需要将很多行的版本回滚到旧版本，这会降低事务的速度。此外，长时间运行的事务会延迟撤销日志的清理，导致撤销日志的大小增加。删除记录并不是真正的删除，其他事务仍然需要看到记录的存在。InnoDB通过运行“purge”进程来删除标记为删除的记录，并释放撤销日志页和将其从全局历史列表中取消链接，以便重新使用。

文章中介绍了在MySQL CLI中执行一系列命令的情况。长时间运行的事务导致其他查询命令执行时间较长。此外，文章还指出了事务的隐藏可见性，以及此情况在生产系统中可能导致的严重后果。为了解决这个问题，文章提出了一些建议，包括限制单个事务消耗的undo空间、限制给定用户消耗的聚合undo空间以及限制给定用户事务读视图的年龄。

MySQL 5.6中引入了可调整的页面大小功能，可以使用4 KB或8 KB的页面代替默认的16 KB页面。文章提到了一个InnoDB的bug，导致在分配内部页面时浪费了一些磁盘空间。该bug的浪费比例取决于页面大小，使用8 KB页面时浪费约为1.5%，使用4 KB页面时浪费约为6.2%。此外，文章还提到了关于扩展大小的一些有趣情况，以及在与InnoDB压缩混合使用时该bug会更严重。总的来说，使用4k页面时，每4个扩展中就有一个是无法使用的。

这篇文章主要讲了通过插入键的顺序来构建索引比随机顺序更有效率。通过可视化工具innodb_ruby中的“-illustrate”模式，可以清晰地展示索引的结构。以键顺序插入的索引页面会按照顺序从文件开头开始写入，而随机顺序插入的索引页面会导致每个页面都被频繁修改，影响性能。此外，可视化工具还展示了随机插入造成页分裂更频繁，有些页面严重填充不足，导致平均页填充率非常低。此外，有观察力的读者还会注意到，有序插入的索引比随机插入的索引要小很多。随机插入的索引比有序插入的索引大41％，而且还有206个多余的页面未使用，实际磁盘空间使用率增加了57％。

Pipeline作为多媒体框架引擎的核心思想，历史源远流长，从Gstreamer时代开始，逐渐大行其道，其设计思想在广义多媒体各个子领域都在广泛使用。