为什么用mongodb而不用mysql

　　为什么用mongodb而不用mysql

从数据库的界说来看，数据库便是一个数据管理体系，是用来存放数据文件的一个软件，它能够支撑用户的添加、修正、删去、查询等操作。因此从界说上讲，时序数据库和联系/非联系型数据库是相同的，都是用来存放数据的。但因为存储的数据特色不同，这两类数据库的运用场景也不尽相同：
联系型数据库：首要用来存储结构化数据，运用实物确保数据一致性，运用SQL言语来进行查询操作。这类数据库的典型代表首要包含MySQL、Oracle、SQLServer等。
非联系型数据库：首要用来存储非结构化数据，数据能够不通过验证进行存储，运用JSON数据对象进行查询操作。其典型代表首要有MongoDB、Redis等。
而时序数据库首要用于存储实时数据，最显着的特色便是每条数据都会带有时间戳属性，在电力、石化、冶金、智能轿车、监控等领域运用较为广泛。这类Database的典型代表首要包含TDengine、InfluxDB、TimescaleDB等。下面直切主题，咱们来讨论一下联系/非联系型数据库是否能替代时序数据库。
能否用联系/非联系型数据库替代时序数据库？
事实上，假如数据采集频率少，数据量不大的话，运用联系/非联系型数据库替代时序数据库是完全没有问题的。但假如从长远角度来看，这种做法却存在着很大的风险，详细原因还要从时序数据库的特色讲起。
时序数据具备采集频率高、数据量大、写操作为主读操作为辅、很少有更新或删去操作、却有核算聚合等实时核算操作等特色，联系/非联系型数据库很难满足这样高的功能需求。在大数据场景下，假如功能达不到要求，数据没有办法被有用存储的话，那么这样的数据库是无法替代时序数据库的。
举一个简单的比如，在相同的测验环境（16核64G内存）下，以传统的联系型数据库MySQL和时序数据库TDengine为例，做一下benchmark的比照测验：
别离运用MySQL自带的benchmark东西mysqlslap和TDengine自带的benchmark东西taosbenchmark，设置16个线程，写入单表10万条记载，表结构为1个timestamp类型，2个int类型，2个字符串类型，测验成果如下：
MySQL——
mysqlslap-uroot-p1234–concurrency=16–number-of-queries=100000–create-schema=tests–query=”INSERTINTOmeters(c0,c1,c2,c3)VALUES(RAND()*100,RAND()*100,uuid(),uuid())”
TDengine——
taosBenchmark-bint,int,binary\(128\),binary\(128\)-n100000-t1-T16
从以上比照测验成果能够看出在同样写入10万条记载的情况下，MySQL运用自带的mysqlslap东西需求75秒完成，而TDengine运用自带的taosBenchmark只需求不到1秒。在差距如此巨大的成果中，咱们能够得出一个定论——运用MySQL替代时序数据库处理时序数据是比较困难的。当然因为测验东西不同，这儿只是做一个示例，测验自身算不上谨慎。下面我会从一些详细的企业事例动身，再为大家做下剖析。

从详细的事例看大数据的存储问题
其实，想要答复这个问题，详细的企业事例实践才是最好、最实在的答案。业内人应该都知道，时序数据库是近几年跟着物联网等技术的开展才逐渐流行起来的，在此之前，各行各业的企业可选的数据库计划都非常有限，以车联网企业为例，职业中最遍及的挑选便是MongoDB、HBase一类的传统大数据处理计划。
但跟着事务的开展，数据量的不断攀升，这些企业或多或少都遭遇了数据架构危机，乃至阻止了事务的开展，不得不考虑进行数据架构的迭代和迁移。下面我从MySQL、MongoDB、HBase三个database维度罗列企业事例，进行说明。
MySQL
在柳工的工业车联网运用LiuGongiLink中，因为运用层不合理的杂乱查询和历史数据的高频写入，导致MySQL处理速度缓慢，乃至简单宕机，严重影响用户体会。在剖析原因后，他们得出了一个定论：联系型数据库并不适用于存储海量的时序数据，在海量数据聚合核算、抽稀等事务中功率很低。从这个定论动身，他们开始针对时序数据库进行选型。
因为其事务场景与TDengine的“一个设备采集点一张表”的理念非常吻合，且TDengine能够支撑对大数据进行聚合和降采样查询等操作，能够经有用改进MySQL的数据痛点问题，又经过谨慎的调研和测验，终究他们决定迁移至TDengine。
以一个实在场景看一下迁移效果：在替换TDengine之前，该项目每天都有一些事务报表需求展示，每一小时需核算一次下一个时区内所有设备的数据，这个流程在MySQL中常常需求耗时1小时以上，无法正常履行后续事务。而换到TDengine后，整个出表流程只需求10秒左右。
查询比照如下图所示：
参考资料：https://www.taosdata.com/blog/2022/05/17/8473.html
MongoDB&HBase
关于这两大数据库的运用坑点，零跑轿车能够说是相当有发言权了。作为一家典型的新能源车企，零跑轿车在数据存储挑选上一向都是MongoDB和HBase，跟着事务的加速扩张，呈现了写入速度太慢、支撑本钱过高等问题。
用MongoDB存储数据会将数据悉数存储在内存中，过高的存储本钱导致只能存储一段时间内的数据，且存储的数据格式需求经过事务组织处理，不仅事务变更不灵敏，能够做的事务也非常有限，而HBase自身便是一个很重的数据库，建立HBase需求整套HDFS做支撑，运用、运维、人力等本钱都很高。
在运用TDengine进行架构晋级后，紧缩功能直接提升了10到20倍，下降存储压力的一起处理了数据存储本钱高的问题，也处理了曾经HBase入库不及时的问题，能够用更少的服务器资源入库更多的数据，节约更多本钱。一起事务灵敏性也有了极大提升，不必再像MongoDB相同，在查询前还需求根据事务加工出需求数据，TDengine的列式存储，直接以SQL核算即可。
写在最终
从上面的诸多证明中咱们能够得出终究定论，假如你面对的也是时序大数据场景，时序数据库才是最正确、最合理的挑选，假如因为数据量尚小就挑选通用数据库，那后边各种扎手问题也会接二连三，包含开发功率慢、运行功率低、运维本钱高、运用推出慢、小数据量场景下私有化布置太重等诸多问题。在数据库的选型上，“对症下药”才是有利于事务开展的良策。