这是一个创建于 1681 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前业务数据库用的是结构化的 SQL, 但考虑到业务需求, schema 可能不太稳定, 随着时间变化, 会有新字段的增加, 和老字段的删除, 感觉比较适合用 NoSQL, 或者 SQL + NoSQL 的组合.
研究了下发现, 貌似 PG 的 JSON, JSONB, HStore 数据类型对 NoSQL 支持比较好, 有没有用过的朋友给点意见? 比如函数啊, 性能啊.
另外, 表里也要存 GIS 数据, 正常 SQL 的话, 就存 geometry, geography 数据类型了, 那么如果改用 JSON/JSONB/ HStore 字段的话, 那么 GIS 数据怎么在这几种 NoSQL 的字段里面存? 会不会导致不能用 PostGIS 的一些函数? Django 对这几种数据类型的支持咋样? 因为要用 DRF 做后端...
或者用混合式的? SQL + NoSQL? 比较稳定的字段用 SQL, 除此之外的不确定稳不稳定的字段用 NoSQL 存储?
还有比较纠结的一点是, 业务上的其他很多小工具应该还是用 SQL 写的查询逻辑, 如果这些字段用 NoSQL 的话, 这些个工具的 Refactoring 的成本高不高呢? 主要指语法不同造成的语句重写...
谢谢各位大佬!!!
 | 1 ElmerZhang 2021 年 9 月 16 日 一般只把不作为业务中查询条件的数据放在 JSON 、JSONB 、HStore 这类字段中。 比如我设计表时经常保留一个字段叫做 extra_info 或者 extend 之类，存一些未来有可能扩展的属性。 如果后加的字段需要作为业务查询条件，可以考虑加个扩展表来存，表中字段为 id, item_id, key, value 。其中 item_id 加索引，(key, value, item_id) 做联合索引。 GIS 数据存在 NoSQL 字段里之后，我印象中是可以用 PostGIS 函数的，已经多年不用，不是很确定，楼主还是自己验证一下。 |
 | 2 dzdh 2021 年 9 月 16 日 无需过度担心性能问题。GIN 索引还是很强的。 HStore 解析可能是个问题。 |
 | 3 wwebrtsed OP @ElmerZhang 谢谢兄台解答! 但我们的业务中, 随时间变化, 可能新增或减少的字段也是会进入查询条件的.... 非常不幸. 所以这种情况下, 有没有好的解决办法呢? 还是说只能用 SQL 这一套, 到时候手工进入数据库增删字段... |
 | 4 Huelse 2021 年 9 月 16 日 推荐 jsonb，如果是 kotlin 开发就更爽了 |
 | 5 bthulu 2021 年 9 月 16 日 上 mongodb 啊 |
 | 6 hanssx 2021 年 9 月 16 日 python postgreSQL sqlalchemy jsonb 用得也舒服 |
 | 8 2i2Re2PLMaDnghL 2021 年 9 月 16 日 具体选型的问题还考虑到你的前瞻性。 你说的 schema 不稳定，但其实如果不是记录间有差异（比如每个人有不同的职业，各种职业具有不同的参数，导致要么字段重载，要么大量空字段），否则 SQL 没有问题，都不过是用着爽不爽的问题。 记录间有差异其实也可以用辅表。 如果又要不确定的字段又要进行查询，是典型的需要 ES 的情况。但得问你是不是真的需要压这点性能。我记得说 PG 的 JSON 是可以作为查询条件的（只是效率问题）。 题外话， 我认为完全可以存在大一统的数据库，采用图论数据库的基本模型并且根据实际需求写优化查询的方案。 但是现在似乎普遍不希望数据库负担运算任务，即使实际业务的执行树已经复杂到数据库传输成本过高，也是每个前台添加 Redis 或者添加更多只读从库解决。 |
Select Language