数据库真的已死吗?

上一段时间 看了一篇文章《数据库已死》读后大为感叹!!!

 

        的确,现在的企业级的项目, 数据库成为了大多数企业应用的主要瓶颈,也成为了运行环境中最不具伸缩性的层,刚毕业的时候开过这样的一个项目的源码  ,所有的业务逻辑用数据库的存储过程写的  java 负责调用 存储过程和触发器    当时那个程序读起来 很是费劲   很明显  没有完全的脱了数据库,没有充分的发挥 java面向对象的优势,同时它的业务逻辑相当的混乱,以至于当时我用UML费了好长的时间才把 业务逻辑区分开来  这样的项目 那结果是必然的  维护人员 经常的发现数据库的服务器的CPU 100% 导致程序经常的dang机,这样的设计 我认为 那是明显的背着面向对象的口号  写出面向数据库、 面向过程的软件.......

 

      现在,很多人已经理解,分析设计要用OO,但是数据库是运行阶段缺少不了的,确实,这是正确观点,我们夺取数据库的王位,不是将它打倒,只是理性和平移交权力重心而已,数据库退出主角地位,让位于Java中间件,也预示着过去数据库为王的时代的结束, 但是数据库会和操作系统一样,成为我们现代软件系统一个不可缺少重要的基础环节.

 

       过去,我们是将业务逻辑写成SQL送往数据库执行,导致数据库成为业务逻辑主要运行瓶颈,那么,如果我们将 业务逻辑用对象概念表达,而不是SQL,那么我们的业务逻辑就围绕内存中的对象反复计算,这样,负载不是集中在 对象运行的中间件服务器上(也就是应用服务器Weblogic/websphere/JBoss/Tomcat)?而对象/中间件都是用Java 语言表达的,无疑,这样的架构,Java才成为主角。   

        现在一些,也许好多。。不是很大的不是很专业的IT公司(我以前进去的有几个公司) 使用的还是以上的流程 ,这的确不让人担心,所有的东西都让数据库来处理?这明显的脱离了中间件的使用优势。

        让我们真正的去了解面向对象   了解OOP、OOD吧!!!

### PostgreSQL 数据库元组的清理与预防 #### 元组产生的原因 在事务处理过程中,当记录被修改或删除时,旧的数据并不会立即从磁盘上消失。相反,这些旧数据被称为“元组”,直到后续的 `VACUUM` 或者 `autovacuum` 进程将其清除。然而,某些情况下,如存在未提交的预定义语句,则会阻碍这一过程的发生[^1]。 对于这种情况,可以使用以下 SQL 查询来查找并解决这些问题: ```sql SELECT gid, prepared, owner, database, transaction FROM pg_prepared_xacts ORDER BY age(transaction) DESC; ``` 通过上述命令获取到的信息可以帮助管理员识别哪些分布式事务处于挂起状态,并采取相应措施(即执行 `COMMIT PREPARED` 或 `ROLLBACK PREPARED`),从而允许后续正常的垃圾收集工作继续进行。 另外,如果表和索引正受到其他并发操作的影响,也可能妨碍 VACUUM 的正常运作。此时可以通过下面这条指令找出可能干扰的因素: ```sql select * from pg_stat_activity where query like '%表名%' AND pid !=pg_backend_pid(); ``` 这有助于定位那些长时间运行且占用资源较多的操作,进而考虑调整应用逻辑以减少冲突的可能性[^2]。 #### 自动化解决方案——Autovacuum 为了简化维护流程,PostgreSQL 提供了一个名为 Autovacuum 的特性,默认状态下它是启用的。这意味着系统能够根据配置参数自动触发必要的清理动作而无需人工干预。要确认此功能是否已激活以及查看其当前设置情况,可利用如下两条简单的 SQL 命令完成: ```sql SHOW autovacuum; SET autovacuum = on; ``` 值得注意的是,尽管 Autovacuum 能够显著减轻管理负担,但在高负载环境下仍需密切关注性能表现,必要时适当调优相关参数以便更好地平衡效率与响应速度之间的关系[^4]。 #### 手工介入方式——Manual Vacuum 除了依赖于内置机制外,还可以主动发起一次完整的扫描及整理活动。这对于特定场景下的即时需求尤为有用,比如刚刚经历了一轮大规模写入之后想要尽快释放空间的情形下。不过需要注意的是,频繁的手动干预并非总是最佳实践,因为过度活跃反而可能导致不必要的开销甚至引发新的问题。 针对这一点,建议仅在确实有必要的情况下才采用这种方式来进行针对性强的小范围修正而非作为常规手段长期运用。 #### 动态剪枝技术的应用 最后值得一提的技术是所谓的 “Hot Update”。它指的是在一个更新操作发生的同时尽可能多地保留原有物理存储位置上的有效信息,而不是简单粗暴地创建全新的副本再废弃掉前者。这种方法不仅有利于节省I/O成本,同时也间接促进了后续清理工作的顺利开展。具体来说,在每次更新 tuple 时,PostgreSQL 将老版本标记为 heap_hot_update 并给新版本打上 heap_only_tuple 标记[^5]。 这种做法使得即使是在非常忙碌的时间段内也能维持较高的吞吐率而不至于让过多无用的历史残留物堆积起来影响整体性能。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值