Robo 3T(原名Robomongo)是一款跨平台的MongoDB图形化客户端数据库管理软件, 基于Shell。支持操作系统包括:Windows, Linux, 和Mac OS。可以管理数据库内容以及编辑数据库代码,内置一个代码编辑区域,可以将数据库文件放到软件上修改,结合图形化的处理方式,支持将MongoDB数据库中的文件转换为分布式的存储方式,提高数据文件编辑和保存效率,方便查找数据库对象、利用其中的数据生成器,可以将Excel文件的数据导入数据库中保存,方便制作数据文件。 https://robomongo.org/ 1. Robo 3T Robo 3T (formerly Robomongo) is the free lightweight GUI for MongoDB enthusiasts. MongoDB GUI with embedded shell 2. Studio 3T Are you serious about MongoDB? Choose Studio 3T – our fully featured IDE for MongoDB professionals. Fully featured IDE with… Continue Reading MongoDB数据库管理开源工具Robo 3

原文:数据库事务、隔离级别和锁ACID的真实含义隔离级别和并发控制MySQL和PostgreSQL对比如何写代码 作者:大宽宽 转自:https://cloud.tencent.com/developer/article/1121737 数据库事务、隔离级别和锁ACID的真实含义隔离级别和并发控制MySQL和PostgreSQL对比如何写代码 这是个令大多数后端同学头疼的问题。部分是因为不同的文章、文档充斥着不相容的概念。高层抽象和底层实现混到一起令人傻傻的分不清楚。此外还有一部分是SQL标准和实现压根就不一致。本文期望在众多文献中找到一条容易理解知识线,帮助大家在实际工作中更加容易明白到底怎么使用数据库的事务、隔离级别和锁。 ACID的真实含义 一般都会用ACID来表达事务的特性。A、C、I、D分别代表“原子性”,“一致性”,“隔离性”和“持久性“。这是1983年(恰好是我出生的年份)ACM的一篇期刊文章Principles of Transaction-Oriented Database Recovery给出的。这四条特性指导了30多年来数据库的模型、设计和开发。ACID很重要,基本上每篇关于数据库的事务的书、文章都要把他们拿出来重新解释一遍。但是,似乎很多人看了很多遍这种文章还是不明白(包括我在内)。因为简单列举,解释这4个概念和现实中数据库的实现不那么容易接起来。 我是这样理解这几个概念的: Atomicity,原子性。很令人郁闷的是,这个词表达意思与常规语境下不太一样。对于一门支持并发的编程语言(比如Java,C++),原子性是指一组指令被执行时,不受其他指令的干扰。比如我们可以说“CAS是原子的;给一个整型变量赋值是原子的”等等。但是在ACID语境下,“不受干扰”这层意思其实是后边“隔离性“说的事情。在ACID语境下,原子性是指一组对数据库的改变,要么最终成功执行完成,要不就全部回滚。这就要求数据库系统要实现某种回滚的机制,比如redo/undo log)。所以,也许这里用术语”revertability“可能更适合。与事务性数据库相比,一些NoSQL的数据库也声称支持原子性,但是意义不同。比如Redis事务的原子性的意思可能更接近于“一组指令被执行时,不受其他指令的干扰”,而不是“可以回滚”。 Consistency, 一致性。这个术语的用词也颇为怪异。一般来讲,我们习惯用“一致性”来描述数据在某些条件下可以变成一样的。例如,在描述CPU工作方式时可以说需要主内存在CPU Core1里的缓存和CPU Core2里的缓存是“一致的“;或者,一个分布式数据系统中,A节点从B节点复制数据,A的数据要和B的数据”严格一致”或者“最终一致”。而ACID下的一致性指的是,在事务完成前后,数据都是要在业务意义上是”正确的“,所以也许术语”correctness“更适合这里的意思。但如果这样定义的话,数据库的位置就很尴尬了,因为保证业务是否正确是要业务代码来最终保证的,数据库能做的非常有限。目前数据库里实现的约束检查,比如唯一约束、外键约束、一些enum测检查、一些数据类型/长度/有效数字的检查等等,对于简单的场景还可以使用。对于复杂的业务约束检查,很难或者不可能实现。有一类数据正确性问题正是由于下面隔离性的使用不当而带来的。 真实复杂业务的数据正确性维护一般用正确的业务代码 + 合法性job来定时执行 + 数据库自身的简单合法性防护一起实现。 Isolation,隔离性。是指一组对数据库的并发修改互相不影响。这个概念表面上看来并不是能说得通,因为如果并发修改的是互不相干的数据,那么自然隔离性可以得到满足;如果并发修改的是相关联的,或者就是同一份数据,就必然会相互影响。那么,此时可以做的就是区分哪个修改优先级更加高。而高优先级的修改应该覆盖掉低优先级的修改。但是,现实往往更复杂,因为并发的修改并不一定能够讲明白先来后到的(要不怎么叫并发呢),此时谁应该生效无法很好的定义。另外一种情况是“先读取,再基于读取结果对数据进行修改”这样业务逻辑。比如,先找到可用的库存,有则扣减,没有则提示缺货;再比如先读取当前的计数值,再往上加1。这时保证隔离性的主要问题不在于隔离本身,而在于如果将读取作为对数据修改的前提条件,之后在对数据进行修改的一刹那,读取时的前提条件还是否满足。毕竟读取和写入是两个分开的指令,而在这两个指令中间可能夹杂其他事务对数据的修改。保持隔离性的一个简单做法是保证对关联数据的修改串行化,对应事务性数据库的“Serializable”隔离级别。保证串行化的一种方案是锁,通过锁定可以彻底避免竞争条件。但是大家都能明白加锁对数据库并发的性能负面影响很大,所以就衍生出了几种弱一些的隔离性保证——READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ。此外MVCC能够解决一部分锁带来的问题。这些内容在下文中会详细的讲解。 Duration,持久性。是指对数据的修改,一旦完成,该结果就应当永远不丢失。这是这4个术语中我唯一觉得表面上和实际上意思差不多的一条。在现实当中,一般通过持久性存储设备(比如磁盘/SSD)写入并刷新来保证数据的持久性。如果觉得一个节点不靠谱,可以增加多个副本(replica)一起来保证持久;如果觉得这样还不够靠谱,可以在不同的地理位置的另一个数据中心做备份。实际上绝对的持久性是不存在的,因为整个存储层面有很多不确定因素,比如文件系统本身fsync指令实现有bug,磁盘的固件有bug,供电出现问题造成数据错乱,异步的数据复制没有生效等等。所以在现实当中的数据库,只能在当前成本和技术限制的约束下,尽量维持一定程度的持久性。 所以这么整理起来。实际上事务性数据库实现的是 支持未完成的数据修改回滚的机制,对应“原子性” 力所能及的数据合法性检查,对应“一致性” 保证数据并发的修改的规则,对应“隔离性” 使用基于持久化存储(磁盘、SSD)的方式对数据进行存储,对应“持久性” 这四条中一、二、四不是本文要讨论的内容,不再赘述。后面主要来谈一下第三条——隔离性规则,即隔离级别的实现。 隔离级别和并发控制 SQL92标准定义了四种隔离级别——Read Uncommitted,Read Committed,Repeatable Read和Serializable。定义这4种隔离级别时,制定者主要围绕着基于锁的并发控制来说的。但是后来出现了MVCC,之后主流数据库都开始支持MVCC。有的数据库采用比较纯粹的MVCC实现,比如PostgreSQL;有的则是混杂的,比如MySQL InnoDB。这就会造成数据库的实现和标准的描述有很多出入。 其实我们并不在意标准怎么说。标准只是一个参考,引导我们理解我们能够接触的实际数据库系统的工作原理。我们先从最简单情况谈起。 最不严格的隔离级别 理论上,最不严格的隔离级别应该是不隔离。 不隔离很容易理解,不同的事务可以对同一数据并发的随便改:A事务改了一半的结果B能看到;B改了一半的结果A也能看到;如果A和B反复修改同一个数据,那么彼此的修改可以覆盖。数据系统在没有做隔离防护时,就一定会是这个样子。这样也就无所谓事务了。 这里数据访问冲突可以分为两种: Dirty Read,脏读。即一个事务的没提交之前的修改被另外一个事务可以看到。 Dirty… Continue Reading 【转载】数据库事务、隔离级别和锁ACID的真实含义隔离级别和并发控制MySQL和PostgreSQL对比如何写代码

原文:http://mysql.taobao.org/monthly/2015/12/07/ PgSQL · 答疑解惑 · 表膨胀 背景 最近处理了几起线上实例表膨胀的问题。表膨胀是指表的数据和索引所占文件系统的空间,在有效数据量并未发生大的变化的情况下,不断增大。PG使用过程中需要特别关注这方面,我们来给大家解析一下表膨胀的原因。 表膨胀的直接触发因素是表上的大量更新,如全表的update操作、大量的insert+delete操作等。而我们知道,PG在更新数据时,是不直接删除老数据的。一个update操作执行后,被更改的数据的旧版本也被保留下来,直到对表做vacuum操作的时候,才考虑回收旧版本。做数据更新时,这些旧版本不及时回收就会造成表膨胀。 线上实例都配置了autovacuum,有了autovacuum,PG会定期自动启动autovacuum worker进程,执行vacuum回收旧版本,防止表膨胀。但在我们看到的几起表膨胀问题里面,autovacuum几乎每分钟运行一次,仍然没有避免表膨胀,这是为什么呢? 表膨胀问题的重现 从问题实例的pg_stat_activity视图里面,可以发现它们有一个特点,就是有长时间未提交或终止的事务。 我们用下面的例子简单模拟一下。先创建一张表,插入一条数据。再建立两个连接,其中一个开启一个事务,执行插入和查询,但不提交;另一个不断执行update操作。 控制台A: postgres=# begin; BEGIN postgres=# insert into test_bloat values(1); INSERT 0 1 postgres=# select * from test_bloat; a — 1 1 (2 rows) postgres=# 控制台B: postgres=# update test_bloat set a = 1; UPDATE 1 postgres=# \watch… Continue Reading 【转载】PgSQL · 答疑解惑 · 表膨胀