最新

在进行机器学习特征工程和多组学数据处理时，我遇到了一个实际限制。 在某个时刻，问题不再是“有多少行”，而是“有多少列”。列数从几千到几万，有时甚至更多。 我在实践中观察到： - 标准SQL数据库通常限制在大约1000到1600列。 - 像Parquet这样的列式格式可以处理宽度，但通常需要Spark或Python管道。 - OLAP引擎速度很快，但通常假设相对较窄的模式。 - 特征存储通常通过将数据拆分为连接或多个表来解决这个问题。 在极宽的情况下，元数据处理、查询规划甚至SQL解析都会成为瓶颈。 我尝试了一种不同的方法： - 不使用连接 - 不使用事务 - 列分布而不是行 - 将SELECT作为主要操作 通过这种设计，可以在具有数十万到数百万列的表上运行原生SQL选择，并且在访问部分列时具有可预测的（亚秒级）延迟。 在一个小集群（2台服务器，AMD EPYC，每台128 GB内存）上，粗略的数据如下： - 创建一个100万列的表：约6分钟 - 插入一个包含100万值的单列：约2秒 - 在约5000行中选择约60列：约1秒 我很好奇这里的其他人是如何处理超宽数据集的。你们是否见过在这种宽度下能够顺利工作的架构，而不需要依赖繁重的ETL或复杂的连接？

我发现自己经常想在Claude Code中安排任务（包括一次性和定期任务），所以我开发了一个CC插件来帮助实现这一点。 安装方法： /plugin marketplace add jshchnz/claude-code-scheduler /plugin install scheduler@claude-code-scheduler 然后只需告诉Claude你想要做什么（以下是一些示例）： 每周三凌晨3点查找死代码：未使用的函数、不可达的分支、注释掉的代码和未使用的导入。按文件列出并附上行号。 在每个工作日的上午9点安排代码审查。审查过去24小时内的提交，检查漏洞、安全问题、错误处理缺口以及需要注释的代码。总结时附上文件:行号的引用。

我写下这些内容是为了描述一种执行模型，其中恢复是在本地强制执行，而不是从历史中推断出来的。与重试重放或协调不同，每个单元都接受或拒绝状态和输入对，并在约束被违反时立即重置。恢复成本是恒定的，故障之间没有相关性，尾延迟不会形成，因为没有恢复协商。这并不是关于可用性表演或更智能的重试，而是关于拒绝继续处于故障状态。