感觉 js/ts 和 mongodb 整合还是蛮舒服的,可以直接把一个 js 对象存进数据库里,不需要其他的设置,听有些人说速度比关系型快,不知道靠不靠谱
1
lithiumii 2021-09-03 14:36:04 +08:00 via Android
特别花哨,需求还老变的统计报表,数据提前算好了写进去
|
2
lucays 2021-09-03 14:41:38 +08:00 via Android
就是适合存 json 格式的数据而已吧
|
3
AA5DE3F034ACCB9E 2021-09-03 14:44:27 +08:00
mongodb 各人挺喜欢用的,api 友好型
|
4
youngce 2021-09-03 14:50:31 +08:00
爬虫数据用的比较多,不用担心分库分表什么的,数据库本身就是分布式设计,数据的分片也比较友好,大数据量下的查询、写入性能都还不错
|
5
est 2021-09-03 14:53:17 +08:00
LZ 说得挺对的。mongo 就是把一堆乱七八糟 json 存起来的东西
你要担心各种一致性问题之类的还是不要选 mongo 了 |
6
boywang004 2021-09-03 15:00:56 +08:00
把程序员伺候舒服了,他们就会(选)用……至于适合不适合,那是架构师的事儿(手动狗头
|
7
k9982874 2021-09-03 15:02:08 +08:00
前期用的爽,后面因为要处理关系恨不得火葬场
|
8
InDom 2021-09-03 15:03:33 +08:00
日志存文件,查起来不方便.
|
9
Huelse 2021-09-03 15:07:45 +08:00
如果一开始就按着规范来做那问题也不大
|
10
dcoder 2021-09-03 15:11:34 +08:00
MangoDB 适合 db schema 一层层包含特别多那种
|
11
YJi 2021-09-03 15:16:11 +08:00
{
"条件 1": 1, "日期": 20210903, "条件 3": 3, "条件 n": "n", "data": [{ "gender": 1, "value": 1 }, { "gender": 2, "value": 10 } ] } 我们是存了这种结构的一堆结果数据(简单举个例子),需要做聚合 or 查询。 |
12
RRRoger 2021-09-03 15:43:31 +08:00
如果计划用 MangoDB 了 为什么不选择 ES
|
13
vopsoft 2021-09-03 16:07:46 +08:00
mysql 查询速度不够
我们是 mysql 同步到 mongodb 用 mongodb 做查询库 |
14
darkengine 2021-09-03 16:08:35 +08:00
原有屎山就是用 mongoDB 的,冇得选
|
15
MarioLuo 2021-09-03 16:25:52 +08:00
整个系统都是用的 mongodb, 事务对我们来说不重要,程序写起还是很爽
|
16
cxytz01 2021-09-03 17:41:02 +08:00
@MarioLuo mongo 已经支持事务了吧?虽然对你们不重要,但我还是提醒下的,已经支持事务了。
另外,你们的系统是什么类型的系统,为什么选择 mongodb,能分享下吗? |
17
windyboy 2021-09-03 17:57:59 +08:00
其实大部分国内引用的场景都不存在事务的场景,而数据结构一直在改,挺适合文档型的数据库
|
18
Rache1 2021-09-03 18:11:13 +08:00
用来临时看日志还是挺香的
|
19
cloverzrg2 2021-09-03 18:18:05 +08:00
个人爬虫
|
20
libook 2021-09-03 18:24:42 +08:00 4
不同模型的数据,用不同的数据库。
当需要存储一个层级很多的树状结构的时候,关系型数据库需要给每一层都创建一张表,然后表之间建立联系,查询的时候也要在所有表中进行查询。 用文档型数据库只需要一个集合,查询也只需要一条原子语句查这个集合。 当需要存储一个 N 对 N 关系的结构的时候,实体之间是纯关系模型,此时用文档型数据库就必须为每种实体建立一个集合,然后集合之间互相引用,查询也只能递归查询。 用关系型数据库就方便很多。 另外 ES 不是数据库,ES 是不保证一致性的,本身有刷新周期,在两个刷新周期之间做的任何写操作,都不能读出最新结果,必须等到下一次刷新后,才可以。 设想一个查询表单有二十个查询参数,每次查询都会在这二十个查询参数中随机选取随机数量的参数组合作为查询条件;这种需求用传统业务数据库难以做到高性能查询,受限于索引的机制,理论上要达到稳定的高速读性能要将这二十个参数的全组合都创建为索引,但对于传统业务数据库来说,索引越多就意味着写性能越差。ES 就是专门应付这种场景的,所以为了兼顾一致性和查询性能,很多系统会用业务数据库+ES 将数据冗余两份,业务数据库负责写操作和一致性读操作,ES 负责非一致性读操作,两边做好同步。 MongoDB 从 4.0 就支持事务了,现在很多人对 MongoDB 有偏见是来源于很多年前对与 MongoDB 的了解。 没有任何一种技术能满足所有需求的,所以我们才会需要各种数据库、中间件来配合实现需求。 |
21
hongweiliuruige 2021-09-03 18:50:17 +08:00
性能好易扩展,自带分片集群支持无限数据,两个字:省心
|
22
lllby1102 2021-09-03 19:52:23 +08:00
mysql 数据量一大就不行了,不过现在 tidb 发展挺好的
|
23
yangzhezjgs 2021-09-03 20:53:50 +08:00
推荐本书《数据密集型应用设计》
|
24
opengps 2021-09-03 21:02:40 +08:00
我同行,gps 这种数据采集类业务,换成 nosql 可以直接有效的提高 iops 单机上限
|
25
Philippa 2021-09-03 21:07:00 +08:00 via iPhone
有些业务无法预测表结构需要动态创建。
|
26
kingfalse 2021-09-03 22:02:36 +08:00 via Android
爬虫在用,为什么就不用解释了吧
|
27
TangMonk 2021-09-03 22:05:22 +08:00
很久以前用过,做一些 JOIN 操作似乎很麻烦
|
28
huntcool001 2021-09-04 01:26:30 +08:00
Mongodb 可以做的, PostgreSQL 都可以.. 实在没必要用前者了
|
29
neoblackcap 2021-09-04 02:36:56 +08:00
Mongodb 我不知道,但是 Cassandra 我倒是可以说说。因为传统的关系型数据库在面对海量的写入的时候会有问题。所以人们为了获取更高的写入吞吐量,就开始分库分表,然后就产生了像 Cassandra 这样的分布式数据库。对一致性的牺牲,获取可用性以及更高地写入性能。
Mongodb 大抵也是类似的情况,虽然最开始是说它自身的无表特性。不过它的集群功能也的确比传统的关系型数据库要来得好一些。水平拓展更加容易。 |