结构固定直接走代码生成不就行了

@hkhk366 按照官方说明索引 100 万文件要花 1 分钟： https://www.voidtools.com/en-us/faq/#how_long_will_it_take_to_index_my_files. 考虑到要建索引和分词 1 秒 100 万不太可能。倒排索引我觉得 1gram 和 2gram 就行。文件名 1 个索引，文件大小 1 个索引。文件名索引存[]string ，其他索引直接存[]bytes 方便 bitwise 操作。比如搜"abcd", 那就 ("ab"索引 AND "bc"索引 AND "cd"索引) 。然后再 AND 文件大小索引。最后反查一遍文件名数组把 bitwise 结果为 1 的找出来。对于 regex 的情况如果包含常固定字符可以先用 ngram 过滤一遍，剩余结果再真用 regex 匹配

没明白 abc.txt 难分词的原因，搜索 a 那所有包含 a 的文件都应该显示。另外"倒排 100 万文件大约需要 1 个 GB 的空间"感觉也不对，你是用 sqlite 的全文检索测试的吗

看上去 google cloud function 可以无限扩展 https://cloud.google.com/functions/docs/configuring/max-instances?hl=zh-cn

缓存策略相关的论文很多，包括各种改进版的 lru 策略也很多

@Nazz Hierarchical Timing Wheels, 我是照着 caffeine 的 java 代码翻译的，也可以 google 。LFU 就复杂些了, 建议去看 W-TinyLFU 的论文。简单来说 frequency 数据是存在 Count-Min Sketch 这种概率类数据结构里的，所以占用空间很小

@Nazz 知识盲区，也许这个能参考一下: https://github.com/golang/go/issues/54766

我以前在的时候得物有工时排行榜的，而且还是公开的。你早下班会拉低整个组的平均工时

@Nazz 好家伙，这个展开出乎我意料。可能这是 V2EX 为数不多的外国朋友

这个看上去可能行 https://civitai.com/models/125264/golang-gopher

@neochen13 你是如何找到我这个 29 天前的主题的。看 issue Insomnia 8.3 应该已经恢复离线了

我测了测纯 GET 确实很快，因为用的是 xsync map( https://github.com/puzpuzpuz/xsync). 不过按照 xsync 作者的说法 GC 压力会更高( https://github.com/puzpuzpuz/xsync/issues/94)，这点从 benchmark 的 allocs 上倒是不太能看出来

无意中看到了另一个快 5 倍的 https://github.com/maypok86/otter (看 bench 写入比我的 Theine 也快 5 倍), 可以研究一下

直连数据库执行 sql 也要 10s 吗？最好把 query plan 也发出来

看到你的对比图我立刻想到了以前看到的鹅厂 tcache: https://zhuanlan.zhihu.com/p/624248354

我觉得最优雅的办法就是 fork 。fork 完 release 个新版本，等 ssh 真的支持你想要的，再发布个新版本换回原来的

affine 的 database 居然没有 formula 类型, 光这一点就感觉技术上不太行

W3 Techs 的报告: https://w3techs.com/technologies/history_overview/programming_language/ms/y. 相关讨论： https://news.ycombinator.com/item?id=28510520

假设踢人是低频操作。 有数据库，签发 token 可控的情况下感觉可以这样: 把用户分为 n 组, 每组存个 version 到数据库里，签发 jwt 的时候把用户组的 version 也带上。踢用户时用户组对应的 version+1 。服务器每分钟同步整个用户组/version 表到内存(或者用 mq 实时性更高)，解析 jwt 时对比内存里的 version 和 token 里的 version ，不匹配就走数据库查询用户有没有被踢。比如 1000 万用户分 1000 组，最坏情况就是这一组的 10000 个用户同时请求