喜闻乐见。

我也打算加个这样的功能

就是 tradeoff 用 es 有 es 的问题 数据同步 数据插入时间 如果你的数据量上几十亿 每次同步一次 es 可能需要几天 更不要说 es 额外需要更多的机器成本了

同义词发现 这种需求就是推荐系统协同过滤之类算法来解决的了 相关书籍不少

我目前只实现了简单的基于文本相似的发现 fuzzywuzzy https://ruby-china.org/topics/38133

1. 如果你学历不错，然后进大厂拿高薪是你的职业规划，那么无论做前端还是后端，刷题就对了。
2. 不要想着什么分布式这些 buzz word，认真搬砖就可以了
3. 如果你有做自由职业/独立开发/创业的规划，那么 Rails 最好还是不要丢掉

信息结构的组织和是否 web 没有关系哇 网页只是一个 ui 层面的东西 信息组织是内容性网站的核心 应该所有内容性网站/app 都离不开类目、搜索、标签、推荐、导航、信息管理这些基本需求 但大部分产品经理其实并不懂信息架构…

https://book.douban.com/subject/3169342/

https://github.com/hackershare/hackershare/blob/master/app/views/common/_ga_tracking.html.erb

这个会触发 GA 的请求吗 刚看到一堆 GA 请求，不知道是不是 prefetch 触发的

应该可以，不过最近没时间啊

可以的

欢迎加入魔法师

感谢

中间表还是有用的，一个很有用的原则就是先满足范式再冗余。如果直接去掉业务有新需求的时候弄不好还得加回去，比如：

• 验证 bookmark 和 tag 组合唯一性
• 记录标记人
• 记录标记时间
• 自定义标记顺序
• 修改标签名

还有一个好处可能就是有了中间表，两边做 counter cache 方便一些

好的，期待

有试 https://ruby-china.org/topics/40472 这个帖子用的 并行 copy 吗

你是物理机还是云服务 有 ssd 没

主要是你的 mysql 在划水吧，CPU 应该只用了一个

cool

ku

一般都是在小数据上测，然后乘以系数，比如你可以测 100w 的，如果你真实数据是 1 亿，就乘以 100

最实际的办法还是 如果你有闲置服务器，模拟一下数据量，实际跑一遍

查询网上好多基于 tpc-x 数据集的对比了 差别不大 会有差别的是 join 和聚合查询 这种 pg 一些场景是可以开并行的 多核机器上有优势

graphviz

我那个插入快还有一个原因应该是 varchar 那里由于是假数据 我直接给了默认值

mysql load infile 就是最快的了，再优化就是调参了 之前记录过 http://shopperplus.github.io/blog/2014/11/08/fastest-way-to-load-data-in-mysql.html

感觉快照是刚需呀 最近看一个快照（只是图片快照），贵的离谱：https://www.stillio.com/pricing

不是吧……上面链接有写啊 int4 对不齐

ruby 3 + pg 13 双喜临门