首页 > 编程知识 正文

qt与mysql数据库连接(jdbc mysql)

时间:2023-05-05 04:28:34 阅读:91000 作者:363

比较博客等文本数据的读写和搜索引擎连接的解决方案,这包括搜索引擎的数据同步、文章属性、文章内容、文章内图像属性的保存和检索,是MongoDB解决方案中MySQL的解决方案

一、从开发工序角度

MySQL文章的读写方法

方式一:文章标题、作者、标签、时间和内容保存关系表,图片保存OSS,地址保存关系表

上述方式与OSS和MySQL没有事务关系,因此在需要编辑文章的过程中保存图像和草稿是分别设计的。 后台写入是分开执行的,查询过程适合于前端异步检索图像。 另外,OSS需要附加的权限。

最重要的问题是OSS费用!

方式2 )文章标题、作者、标签、时间和内容保存关系表,图片本地保存,地址保存关系表,Nginx作为图片查询代理;

上图中的实线是写过程,虚线是查询过程。 由于写入本地文件的过程仍然无法保证事务处理,因此必须在后台分别运行。 查询流程Nginx的业务许可非常麻烦,需要部署Openresty与许可服务器的坞站。 此外,文件存储中的文件数量可能超过操作系统的最大限制,图像缺乏可靠的备份机制。

唯一的好处是图像存储的本地不需要额外付费。

让我们来看看MongoDB的文章读写方法

上面的照片方式1 :全部摄取。 MongoDB在文章的标题、作者、标签、时间和内容、照片存在于一个集合中时,照片以BSON形式,完整地收录。 文章照片完整的文件在16M以下的话,BSON比较合适。 如果文档的图太大,超过16M,请使用方法2,通过MongoDB提供的GridFS插件进行访问。

方式一:从开发工序开始最简单,但不适合太大的图像,整个文档会超过16M。

方式2 )相当于需要访问不同的MongoDB数据库,由于代码的复杂性,一致性控制并不比方式1好。

其他优点:这两种方式都可以通过MongoDB的统一访问控制进行保护。 无论使用哪种方法,图像都可以通过副本集进行可靠的备份。

但最重要的是,MySQL没有超出扭曲技术范围的体系结构考虑。 无论是通过OSS收费,还是使用Http代理的免费模式,我们都会容忍可靠性、复杂性和安全问题非常严重的情况。

二、从性能角度看

1、文章插入性能

根据目前MongoDB4的实测情况,一定期间内的数据写入量水平越大,MongoDB的完成时间就越短于MySQL的完成时间。 因此,博客网站和博客爬虫系统在写入的数据量特别大的情况下,MongoDB可以提供更好的负载能力。

2、伸缩性

虽然MongoDB和MySQL都可以进行数据库级的内存缓存,但是MongoDB可以尽可能将文档缓存到内存中,从而获得最佳性能。 如果内存不足导致磁盘溢出,性能会下降,但在这种情况下可以通过水平分区实现,从而提高内存性能。

MySQL的瓷砖需要通过引入自我钻研或第三方瓷砖APP来手动平铺。 也就是说,需要将一个数据表迁移到不同的MySQL库,并按数据记录生成表,以最终实现平铺APP对多个库的负载平衡。 这种方式的缺点是实现瓷砖化的过程非常复杂和麻烦。

MongoDB的瓷砖是其核心架构的

一,也是NoSQL天然所擅长的能力,因此MongoDB可以在用户不干预的情况下实现集合分片,这比MySQL的手动分片不知道要轻松多少。

上图中Mongos路由器作为接口,连接整个集群,将所有的读写请求指引到合适的分片上,配置服务器持久化分片集群的元数据,以及数据在分片之间进行迁移的历史信息,而且配置服务器本身也是高可靠的。

三、与Elasticsearch连接角度看

MySQL连接Elasticsearch

一种方式可以通过CDC(数据变更捕获)工具抓取binglog到Kafka,再由Kafka管道输出到Elasticsearch

另一种方式通过JDBC“轮询”数据库,再推送Elasticsearch

第一种方式在引入CDC抓取工具,例如debezium后,会让整个流程非常复杂,经历的环节过多,仍要控制好Kafka的按键分区和折叠模式,数据管道也要解决关系结构向文档结构的ETL过程。

当然方式一也可以不用Kafka,直接走Logstash管道的过滤通道,但是第三方CDC抓取工具就要再考虑一层与Logstash的对接过程。

第二种方式虽然简单,不过JDBC轮询对MySQL有不小的影响,而且业务表需要提供变化日志表,再有Logstash等清洗程序再做ETL合并同步,这个过程也不容易。

我们再看MongoDB连接Elasticsearch

通过mongo-connector可以轻松实现MongoDB到Elasticsearch的数据实时同步

mongo-connector通过监听oplog,非常类似MySQL CDC工具对binglog的监听,实时对数据进行采集并直接同步到Elasticsearch中,因为MongoDB和Elasticsearch都是无模式的文档型数据库,因此ETL过程可以由mongo-connector工具实现MongoDB集合向ES索引的无缝写入,会省去ETL过程很大的麻烦。

四、总结

从上面的架构描述上,其实已经强有力地论证了MongoDB无论作为存储文档型的博客文章也好,还是与其他专有搜索引擎同步也好,相对于MySQL,是更好的解决方案。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。