我刚加入一家新公司，发现他们在生产环境中同时使用 SQL （关系型）数据库和 NoSQL 数据库。大约 90%的数据（尤其是核心内容）存储在 SQL 数据库中，而用户相关数据（例如个人资料、访问权限等）存储在 NoSQL 数据库中。然而，这些数据源之间的所有连接操作都是在应用层用代码处理的，这使得即使是简单的查询（统计具有特定属性的用户数量）也变得比实际需要的更复杂。据我所知，这个公司的业务模型是高度关系型的，将所有内容保留在 postgreSQL 中可以显著简化架构，并使后端更易于长期维护。在这种情况下，我很难看出在新项目中同时使用 SQL 和 NoSQL 有什么实际好处。采用这种方法真的有什么好处吗？好像前端在 NoSQL 方面更有经验，所以他们选择了 NoSQL ，然后转向 SQL 来处理应用程序内容。我注意到的问题是，由于架构原因，原本需要 2 周的新功能后端开发却需要 2 个月
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 404 days ago, the information mentioned may be changed or developed.
 |
1
Martin123123 May 6, 2025
实际上业务系统没必要关联这么多用户具体信息把，只需要一个用户唯一 id ，不太理解你们为什么会从 2 周 -> 2 月
这种场景可能是计划把 user 相关的东西抽出来做 sso |
 |
2
duzhuo May 6, 2025
听起来像是历史遗留的屎山
|
 |
3
niubiman May 6, 2025
这个问题的最好答案还是得问项目的架构负责人，单从你的描述看不出来这么设计的缘由，或许有一些历史遗留原因，也或许是有一些未来业务的考量，都不好说
|
|
4
niubiman May 6, 2025
@Martin123123 我们目前就是把用户抽离出来做了 sso ， 但是这种做法也不一定非要采用 nosql
|
 |
5
qxdo1234 May 6, 2025
要看数据量有多大了，是否值得用上 noSQL 了。应该不至于用个 noSQL 就足以把需求时间从 2 周拉长到 2 个月吧？
|
 |
6
coderzhangsan May 6, 2025
我以为是用 nosql 做数据缓存，没想到是 nosql 和 sql 各自存储和维护相关数据，确实有点坑啊。
"好像前端在 NoSQL 方面更有经验，所以他们选择了 NoSQL 。"，这话的意思让我像想到了另外一句话："前端娱乐圈"。 |
 |
7
xiaomushen May 6, 2025
nosql 在业务系统中，只适合做数据缓存
|
 |
8
fffq May 6, 2025
后端是不是以前前端兼着干的？
|
 |
9
iugo May 6, 2025
如果用 pg, 可以全部数据都在 SQL 上, 部分频繁的读操作或者简单且临时的业务配合 NoSQL 使用.
NoSQL 在性能上是有优势的, 尤其是可以比较容易做到分布式, 从而提高并发读写性能. |
|
10
Martin123123 May 6, 2025
@niubiman
描述的只是一种可能性，楼主说的场景就算用户表不是 nosql 也会存在的，真正的原因只有架构负责人才知道，一开始就是全部用的 mongo 踩坑了才陆续把需要优化的地方挪到 pg 这种情况也正常 @coderzhangsan 具体得看业务是怎么实现的，云函数之类的用起来也方便 但是我不认为两个库会导致开发周期相差这么长 |
 |
11
iamzcr May 7, 2025
1 、可能是历史问题。
2 、nosql(mongodb)的场景常用于第三方 api 接口返回的不确定性数据格式，如果某些第三方数据返回的数据格式更新比较频繁，而这些接口的数据又不是那么重要，mongodb 是一个很好的存储方式。 |
Select Language