这个看上去可能行 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 个用户同时请求

@crackidz 确实 Postman 也在整活 https://news.ycombinator.com/item?id=37792690

@zhuzhibin 看了一眼 es 的文档，wildcard 类型已经是通过 trigram 来优化了。如果用 wildcard 类型 cpu 还高可能就要考虑一下别的方法 https://www.elastic.co/cn/blog/find-strings-within-strings-faster-with-the-new-elasticsearch-wildcard-field

@zhuzhibin 刚才没注意到是 wildcard, 可以顺便看看这个: https://tech.justgiving.com/posts/how-i-discovered-the-power-of-trigrams-for-text-search-in-sql-server

@zhuzhibin N-gram 空间换时间，一般来说 2gram 或 3gram 效果都很不错, 你也可以两个加一起。比如 google code search 就是 trigram: https://github.com/google/zoekt

如果只是 RESTful API 到文件的映射我觉得不能称为数据库。你可以称它是某种无代码工具，但和开发者传统认知中的数据库差别很大。从数据库直接生成 API 也有挺多现成方案

不是代码的问题，是人的问题。大部分程序员英文水平有限，像 Hacker News 那样放个链接自己看已经筛选掉大部分人了，而且很多链接还要翻墙。剩下的水平足够很可能直接看 Hacker News 了，毕竟和全世界交流肯定强点

@mightybruce cache 这么底层的东西很难火，除非是 Redis 这样独立成服务的。ristretto 能有这么多 stars 是 dgraph 本身的流量加持，caffeine 则是因为完全原创了 tinyLFU 缓存策略。其实能多些用户使用我就很开心了，用户多了要是有什么 bug 也能及时发现