yhjj0108

1. select count(*) from A,统计所有数据包括null数据,这里会使用到聚合索引,如果判断聚合suoyou

阅读Postgresql

postgresql创建外键后会在表pg_constraint

Hbase region上在做修改操作时有两个关键的lock: updatesLock,rowlock.updatesLock保证memstore的刷新和其上的修改不能同时发生,memstore刷新时加写锁,其它情况加读锁.rowlock顾名思义就是操作那一行的lock.操作时先updatesLock上的写锁,然后是rowlock如append操作代码如下(下面的代码来自于hbase0

以前一直以为数据库在做子查询时会重新做全部的查询，后来发现postgresql在做子查询时如果来自父查询的参数未发生改变,那么其是可以直接计算结果而不用再次执行子查询的,那么mysql是怎么处理的呢,再次翻出mysql(5.6.10)的源码简单调试了下发现以下结论:1. 在执行子查询无关的exists not exists时如:select  * from a where exists

通过前面源码的分析感觉mongodb的分片加上replset就是全部了,啥问题都应该解决了,后来看到了foursquare发生mongodb宕机事件,看了一下宕机事件的分析,当时阅读代码还并未阅读到分片部分,但是准备阅读分片时就决定一定要仔细将分片机制研究清楚,然后可以分析下foursquare宕机原因.后来阅读完分片代码后明白了其分片策略,当时怎么也想不通为什么会产生shard不平衡的状况呢,一

这里的writeback也许可以翻译成回写,是指发生如下情况,来自mongos对mongod的数据请求,但是请求时发现版本不对了(发生了chunk的迁移)那么这里的请求将得不到响应,这里的请求需要以某种方式回到mongos,然后再次发往正确的mongod,这就是所谓的writeback.下面直接来看代码.先来看一份简化了的插入操作代码.void receivedInsert(Message&

本文将分析mongodb中数据平衡的策略.先来看看流程.mongodb开启一线程banlance专门负责数据的平衡工作,其查看系统中所有的shard,发现有不平衡的情况就选择将其中shard服务器的chunk迁移到其它服务器让整个系统达到平衡.来看看平衡策略.1. shard数据大小超过了shard配置的数据大小,从中选取chunk迁移到别处.2. 找到shard中有违法tag规则的chu

本文我们分析一个chunk的迁移，下文中将分析mongodb的shard平衡策略,之所以分开成两篇文章分析是因为chunk的偏移设计命令太多，太长.下面首先来看看chunk的迁移流程.1.  将要迁移chunk端A首先记录chunk迁移数据的位置.2. 通知远端B,让其执行_recvChunkStart开始chunk的迁移.3. B端首先从A端system.indexes读取索引,并将

本文我们分析mongodb chunk的拆分,chunk的分拆分两种情况.1. chunk范围[min,max]这表明这个chunk还没拆分,第一次拆分考虑到后面插入更多的数据,所以拆分时chunk将从实际的最大值max1处拆分,拆分后的chunk范围如下:[min,max1),[max1,max].对于这种[value,max]的拆分拆分点选择这个chunk的最小值min1,得到[value

本来简单讲讲mongos对于查询 添加 的流程,修改和删除的处理流程简单其也与添加差不多不再分析,对于添加 修改和删除,mongos都只是将其发往正确的mongod服务器让其处理,对于查询稍微麻烦点,因为查询多个mongod服务器的结果回来时汇总需要mongos自身完成其排序.下面来看具体代码吧,在mongos的初始化部分我们已经知道向mongos发送的请求,其处理函数是Request::proc

本文描述分片设置命令的流程.在分析分片设置命令流程前先来看看configserver服务器config数据库中各个collection的作用.version:   保存当前configserver的版本信息,这个是随mongodb升级而变动的.settings: 保存分片系统设置信息如chunksize大小,balancer配置信息.shards:   保存shard中的配置信息包括每

转载一篇mongodb架构的文章,原文地址MongoDb Architecture需要翻墙.NOSQL has become a very heated topic for large web-scale deployment where scalability and semi-structured data driven the DB requirement towards

mongos是mongodb提供的自动分片组件,在提供分片功能的mongodb系统中,几乎所有的请求都将通过mongos转发到mongod中,然后mongos再汇总,最后返回给客户端.本来就来分析分析mongos的初始化,为后面通过mongos的查询,删除,修改,增加记录 mapreduce aggregate以及mongos的自动分片与负载均衡做准备.下面来看代码,其入口为mongo\s\ser

本无意写这篇文章,但是之前在分析replset时有一个线程一直没弄明白其作用,后来偶然间在阅读tags时搞明白了notifierthread的作用,tags的实现过程很隐晦.不仔细阅读,很难弄明白,所以这里专门写一篇文章来分析replset tags的实现.首先来看看一份带tags的replset config.这里的dc可以理解为datacenter或者任何自己觉得好理解的词,dc后

本文接上面两篇分析replset模式的文章,来看看replset的状态转换图.看不到全图的请看这里:replication replset状态转换图        本图中某些部分并未画到.1. 服务器进入RS_SHUNNING状态后如果配置更改后其会再次进入RS_SECONDARY等状态.2. 心跳协议无法连接时是自己端将远端服务器标识为RS_DOWN,远端服务器处于什么状

上一篇文章分析了replset的初始化,下面我们继续分析replset的同步部分,这里涉及到2个线程,一个函数.producerThread: 对于非primary的服务器,选取一个目标服务器并从其读出操作日志.startsyncthread:  从producerthread处读取操作日志然后replay.msgCheckNewState函数: 负责各个服务器状态的切换,seco

相对于主从模式,replset模式复杂得多,其中的主从对应于这里的primary,secondary概念,primary和secondary之间可以切换,primary掉线后能够自动的选取一个secondary成为新的primary,当然这里也是有限制的,本文将会分析到.首先来看replset模式用到的几个集合.local.oplog.rs: 记录replset模式下的操作日志,mas

mongodb提供数据的复制机制,老的master/slave和新的replset模式,本文分析老的master/slave机制,replset在下一篇文中分析.master/slave机制是一台主服务器,其它的从服务器,从服务器从主服务器中读出操作记录,然后在自己这端重现操作,达到和主服务器一致的目的.主从服务器是启动时设定的,之间无法动态的切换,其提供数据的备份机制,默认情况下从服

先来看看持久化的流程.默认情况下持久化是开启的,需要关闭启动时--nodur或者--nojournal.在开启journal时mongodb保留了多数据库的两份映射,每一个文件有两个映射的初始地址_view_write和_view_private,_view_private是为了持久化而生的.这就是为什么用mongostat查看系统信息时会看到vsize是mapped的2倍多了,因为一