Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
还要看运维动作。备份、删除、迁移、索引重建,按租户还是全局?
安全上别只看向量库。对象存储、缓存、日志、评估样本都要带 tenant。
每个租户 collection 会不会太多?
会。collection 数量不是无限免费的,监控和配置也会爆。
一个 collection 的风险是 filter 漏传就灾难。所以 SDK 层要强制 tenant,不允许裸 search。
可以把 tenant_id 封在 repository 里,业务层拿不到不带 tenant 的方法。
还有大租户影响小租户的问题。一个超大客户更新索引,会不会拖慢其他人?
资源隔离如果是硬要求,就不要全混一起。
我们早期租户几十个,单租户数据几千到几万 chunk。
那先一个 collection + 强制 tenant filter 可以,保留迁移到分 collection 的能力。
doc_id 设计带租户前缀,后面迁移会轻松。
权限测试要写成自动化。故意不传 tenant,应该直接失败,不是返回空。
多租户最大坑不是方案选错,是代码某处绕过方案。
你好!看起来您对这段对话很感兴趣,但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。
有了你的建议,这篇帖子会更精彩哦 💗