最新

archive.today 最近（我大约三天前注意到的）开始自动向某个人的博客的 CAPTCHA 页面发起请求。以下是我所说内容的截图：https://files.catbox.moe/20jsle.png 相关的 JavaScript 代码是： ```javascript setInterval(function() { fetch("https://gyrovague.com/?s=" + Math.round(new Date().getTime() % 10000000), { referrerPolicy: "no-referrer", mode: "no-cors" }); }, 300); ``` 查看这个博客，似乎只有一篇文章提到 archive.today——“archive.today：追踪互联网神秘游击档案员”（https://gyrovague.com/2023/08/05/archive-today-on-the-trail-of-the-mysterious-guerrilla-archivist-of-the-internet），在这篇文章中，博客的作者挖掘了一些关于 archive 拥有者的信息。 所以这或许是一种报复/拒绝服务攻击尝试/故意浪费他们带宽以回应这篇文章？也许是试图让他们沉默并迫使他们删除文章？但如果真是这样，我有很多疑问。比如，为什么 archive 的拥有者会在文章发布 <i>2.5 年</i> 后才这样做？或者他们为什么会这样做，他们难道不知道斯特赖桑效应吗？ 我很困惑。

请访问以下链接： [https://github.com/stepandel/chroma-explorer](https://github.com/stepandel/chroma-explorer)

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