 |
NotLongNilV2EX 第 651854 号会员，加入于 2023-09-30 16:50:09 +08:00今日活跃度排名 5084 |
NotLongNil 最近回复了
4 天前 回复了 qianyeyixi 创建的主题 › 前端开发 › 关于前端的 DDD 领域驱动设计大佬们有啥实践么？ |
我专门读了《 Domain-Driven Design: Tackling Complexity in the Heart of Software 》这本书，然后被那些“没读过的人”说我理解错了。更神奇的是他们就根据网上一些文章整出了自己的一套理解，还不接受反驳。一旦到代码实现层面，就各种漏洞，得不断给自己的理论打补丁。最后把简单的代码变成屎一样难以理解。整了一大堆似是而非的概念，对软件工程根本没正增益。也不知道国内为什么这么热衷于这个。
22 天前 回复了 apollo007 创建的主题 › 生活 › 各位， 5 岁孩子，如何英语启蒙？ |
多领国
29 天前 回复了 Garalt 创建的主题 › 分享发现 › 谷歌翻译质量下降严重 |
确实，上个月有新闻说到谷歌把“沉浸翻译”的请求认为是攻击，它们现在应该对短时间内频繁的请求给污染了。只有用沉浸翻译才有这样的问题
32 天前 回复了 BuGoooo 创建的主题 › 程序员 › 我这个需求 适合用 clickhouse 吗 |
@silentsky #30 CH 的 MergeTree 索引结构，只能判断到数据在哪个段，然后将整个段加载到内存，在内存中进行遍历过滤。一个段默认大小有 8000 多行。在这个场景下，做好分表，设置好索引，B+ 树段查询速度反而会比 CH 更可观，还节省资源，并发更大。楼主这个搜索场景还需要考虑并发数，CH 的并发成本比 mysql 高了几个量级。物化视图只是 MergeTree 套了一层，底层没变
33 天前 回复了 BuGoooo 创建的主题 › 程序员 › 我这个需求 适合用 clickhouse 吗 |
@BuGoooo #26 clickhouse 不适合做这个。上面看到你试验后，发现查询慢。这是正常的，因为 CH 做了全表扫描。CH 的索引跟 mysql 多索引不一样。如果是固定前两位和固定后四位查询，你使用 mysql ，把这两个单独提出来，作为分表键，加索引，查询速度比 ch es 还快，还节省资源
33 天前 回复了 BuGoooo 创建的主题 › 程序员 › 我这个需求 适合用 clickhouse 吗 |
需要你再具体描述下你的搜索场景，是固定按后 3 位搜索？还是后 4 位？还是随机长度？
44 天前 回复了 geluofeng 创建的主题 › Apple › aldente 影响 Mac 睡眠问题 |
@lloyds 没有，我买的正版
44 天前 回复了 geluofeng 创建的主题 › Apple › aldente 影响 Mac 睡眠问题 |
抱歉，没看清楚，忽略我上一条回复。你试试升级到最新版本，重新安装下辅助程序
44 天前 回复了 geluofeng 创建的主题 › Apple › aldente 影响 Mac 睡眠问题 |
它设置有说明的，它限制了睡眠充电
Select Language