最新 | 最热门 | 最高评价

+5  Oracle如何监控表的DML次数

Tag: 数据库 | 监控 | DML | oracle
NinGoo 发于 2010年04月27日 12:13 | 点击: 2611 | 展开摘要
Author:NinGoo posted on NinGoo.net
在数据库技术大会上,做了《构建高可用数据库监控系统》的分享以后,很多朋友对北斗如何实现表的DML次数监控有兴趣,会上因为时间的原因,我只是说有系统视图可以查到这个信息,因此有了本文,可以稍微详细一点来说明是如何实现的。

我说的系统视图,具体指的是dba_tab_modifications/all_tab_modifications/user_tab_modifications,这几个视图收集了表自从上一

查看全文: http://www.udpwork.com/item/1683.html

+1  数据库事务ACID和锁

Tag: 分布式 | 数据库
ideawu 发于 2021年05月02日 13:30 | 点击: 206 | 展开摘要
数据库事务功能非常重要, 任何应用只要操作的多个对象之间有依赖(约束)关系, 都会不约而同地想到使用事务, 例如银行转账功能, 社交 App 中的粉丝关注功能, 购物网站下订单功能. 任何一个数据库系统, 如果不提供事务功能, 就不能减少用户(应用开发者)的某些麻烦, 因为用户不得不自己在应用层去实现类似事务的代码逻辑.

从用户的角度看, 如果数据库不提供事务, 他就要多写代码, 这让他很不爽. 所以, 即使是 KV 数据库, 也应该提供事务功能. 但是, 不仅事务功能的实

查看全文: http://www.udpwork.com/item/17453.html

+1  千万别用MongoDB?真的吗?!

Tag: 数据库 | 轶事趣闻 | 10gen | Database | MongoDB
陈皓 发于 2011年11月10日 08:28 | 点击: 3791 | 展开摘要
某人发了一篇Don’t use MongoDB的血泪控诉,我把原文翻译如下,你可以看看。不过,我想我们还要去看看10gen CTO的对此事的回复,我们还要去在Reddit上看看大家的说法,10gen CTO的对此事的回复后面也有一堆人在讨论这个事,还有一些程序员开始去读MongoDB的源码了,呵呵。看样子,说MongoDB的这些事并不是真的。

10gen CTO 对此事的并不完全知道,其在回复,对些文中的每一条都做了回复。我把其回复的大体意思也放在原文中。不过,

查看全文: http://www.udpwork.com/item/6256.html

+0  并发编程的核心技术 – 多版本(Multi Version)

Tag: C/C++语言编程 | Computer System | 分布式 | 数据库 | 算法
ideawu 发于 2021年04月17日 18:20 | 点击: 103 | 展开摘要
在单机编程时代, 每一项数据只有唯一的一份, 对数据的修改也是 in-place 的. 但是, 在并发编程领域, 包括分布式系统, 数据多版本(Multi Version, Versioning)是核心.

我们先从单机编程的内存操作出发. 对于内存的操作, 都是原地(in-place)更新的. 对象和内存空间强绑定, 当更新对象时, 是将对象的内存空间擦除然后用新数据写覆盖. 到了多线程编程时代, 就引入了锁机制, 因为擦除和写操作过程不是原子性的, 可能擦除到一半时, 就

查看全文: http://www.udpwork.com/item/17461.html

+0  数据库的并发操作与一致性

Tag: 分布式 | 数据库
ideawu 发于 2021年04月24日 10:08 | 点击: 106 | 展开摘要
作为分布式强一致数据库的开发者, 被多次问到:

如果我在新加坡和欧洲同时修改一条记录, 如在新加坡 set a=1, 在欧洲 set a=2, 结果 a 是多少?

我的回答是:

可能是 a=1, 也可能是 a=2.

然后提问者会非常困惑和不满:

你不是说数据库是强一致的吗? 为什么结果不确定呢?

我非常理解他的困惑, 但是, 他所提到的"并发操作"和"一致性"并没有必然的联系.

并发

Martin Kleppmann 提到并发(Concurrency)的定义:

查看全文: http://www.udpwork.com/item/17458.html

+0  数据库事务的原子性与隔离级别

Tag: 数据库
ideawu 发于 2021年04月24日 10:25 | 点击: 135 | 展开摘要
数据库事务的原子性并不仅仅是指写操作, 还包括读操作. 对于写操作, 众所周知, 原子性是指操作序列中的所有操作要么全部成功, 要么全部失败. 但多次读操作未必是指要么全部读到要么全部读不到. 如果不是 Snapshot Isolation, 那么两次读操作, 可能有其中一次读到旧值, 另一次读到新值. 但是, 读操作的原子性要求必须满足因果性. 当读到新值之后, 就说明事务中的所有写操作都已完成, 显然, 后续的读操作必须读到新值, 不能读到旧值.

Snapshot Is

查看全文: http://www.udpwork.com/item/17456.html

-1  分布式数据库的过期机制(TTL)实现原理

Tag: 分布式 | 数据库
ideawu 发于 2021年04月30日 00:41 | 点击: 162 | 展开摘要
像 MySQL 这样的传统关系数据库, 没有提供数据过期自动删除功能(TTL), 因为从常规理解, MySQL 是一个持久化数据库, 不是缓存系统, 数据应该由用户主动地通过 DELETE 指令显式地删除. 不过, 从实践经验上看, 由数据库系统提供基于过期时间自动删除数据(TTL)的功能, 可以减少用户(应用开发者)的工作量. 所以, Redis, SSDB, MongoDB 这些新开的 NoSQL 数据库都提供了 TTL 功能.

TTL 功能非常有用, 能节省用户的工作

查看全文: http://www.udpwork.com/item/17455.html

+0  Raft日志复制状态机模型的Apply进度问题

Tag: 分布式 | 数据库 | Raft
ideawu 发于 2021年04月30日 22:25 | 点击: 173 | 展开摘要
日志复制状态机模型是 Raft 协议里的一个基础概念, 用于保障多副本一致性. 这个概念并非 Raft 独创, 而是由 Raft 具体总结和推广的, 在 Raft 之前, 像 MySQL 的 binlog 等等, 都是广义的日志复制状态机模型.

采用日志复制状态机模型的系统, 把多副本一致性问题分解成两个部分(模块), 第一部分是日志本身的一致性, 第二部分是状态机(例如数据库引擎)的数据一致性. 这两个系统模式是独立运行的, 它们之间的通信(Apply)也是异步的. 由此

查看全文: http://www.udpwork.com/item/17454.html

+0  Redis 6.0 客户端缓存特性及实践

Tag: 数据库
鸟窝 发于 2020年11月11日 22:22 | 点击: 76 | 展开摘要
Redis 6.0 发布了。

Redis 6.0的新特性也是在一步步的讨论和优化中确定的。

很多的特性已经在之前的RC等版本中介绍过了。

但是正式GA版中也有一些新的变化:

SSL

ACL: 更好,命令支持

RESP3

Client side caching:重新设计

Threaded I/O

Diskless replication on replicas

Cluster support in Redis-benchmark and improved r

查看全文: http://www.udpwork.com/item/17420.html

+0  解析一个简单的分布式事务Case

Tag: 数据库
Felix021 发于 2018年06月08日 21:41 | 点击: 1165 | 展开摘要
注:这篇是3月初在公司内部平台上发布的,搬一份到 blog 存档。
===

我注意到过去几个月有些同学还在踩一个简单的分布式事务Case的坑,而这个坑我们在两年以前就已经有同学踩过了,这里简单解析一下这个case和合适的处理方案,供各位参考。

# 1. 踩过的坑

这个case有很多变种,先说说我们在 X 业务踩过的坑开始,大约是16年9月,核心业务需求是很简单的:在用户发起支付请求的时候,从用户的银行卡扣一笔钱。负责这个需求的同学是这么写的代码(去除其他业务逻辑的简化版

查看全文: http://www.udpwork.com/item/16890.html

+0  浅析嵌套数据库事务

Tag: 数据库
Felix021 发于 2018年03月29日 22:00 | 点击: 1239 | 展开摘要
大家都知道,数据库事务提供的强一致性,让我们只需要在业务开始之前执行begin、结束后执行commit,并在异常的情况下执行rollback,就能够保证业务数据的强一致性。

## 1. 转一笔账

以一个转账操作为例,从from账户往to账户转一笔钱,涉及到两个账户的操作,我们用事务来保证数据的一致性:
function actionTransfer(Account $from, Account $to, int $amount)
{
   

查看全文: http://www.udpwork.com/item/16757.html

+0  2017升的最快的几个数据库无责任点评

Tag: 数据库 | MariaDB
Yu Feng 发于 2018年01月05日 14:57 | 点击: 1456 | 展开摘要
原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: 2017升的最快的几个数据库无责任点评

ItPub写的文章“2017 年度 DB-Engines 数据库冠军得主:PostgreSQL 封王!”, 点击 这里 进一步阅读

升的最快的几个数据库,我简单的无责任点评:

PG数据库是很老的数据库,不过这几年冉冉升起,因为是学院派的,有很好的学术和智力的支持,一直以来在数据库的体系结构,代码的质量,创新的方向上都做的不错,借云计算的东风,特别是比如AWS对pg

查看全文: http://www.udpwork.com/item/16592.html
|<<<123456>>>| 一共6页, 70条记录