Nosql入门知识（转）
1. NoSQL其实是关系型数据库相对应的，是no relational 即非关系型数据库；web2.0特别是一些用户访问量比较大的网站如：www.taobao.com weibo.com baidu.com
每秒的访问量可能是上万次(10K);传统的关系型数据库 mysql oracle 每秒进行10K次数据查询还可以勉强应付，但是如果是每秒10K次读写数据库，因为数据库的数据都是卸载磁盘中，所以磁盘IO也是支撑不住每秒10K的读写。
在web的架构中，数据库是最难进行横向扩展的(通过简单的添加机器和硬件，也就是添加一些服务节点来提高负载均衡能力)；对于7*24小时在线的网站来说，对关系型数据库进行升级和扩展(分布式扩展--分库分表)是非常痛苦的事情，往往要进行停机维护；但这种对www.taobao.com 来说是非常丑陋的事情。[--可不可以添加几台服务器然后把复制，然后进行负载均衡--]。
NoSQL 是采用key/value的结构来存储数据，而且大多数的NoSQL采用内存来存储数据，一段时间后把数据同步到磁盘中；由于使用内存保存数据很好地解决了高并发读写的问题；其次NoSQL提供了根据key值进行横向分表(比如：用户id，每2000w数据放到一台数据库服务器中的一张用户表中)；同时实现了主从数据库互备，这样可以让数据库的动态迁移变得简单，让数据库服务器的横向扩展变得容易了。
2. 分布式数据库的CAP理论
CAP理论是说Consistency（一致性）， Availability（可用性）， partition tolerance（分布）三部分系统；而且任何系统只会满足两个，不会有任何的系统会同时满足这三个条件；在传统的关系型数据库中是强调C 一致性，但是在满足高可用性(高并发时效率不高)，高扩展性(分布式数据库进行横向扩展)存在一定的缺陷。但是NoSQL在进行设计的时候就是针对并发海量数据存储的情况下进行设计的，在这种高并发海量数据下数据一致性并不像银行那样保持数据的强一致性，所以NoSQL·放弃强一致性的追求，从而达到更高的可用性和扩展性，通过“鸽巢原理”达到最终的一致性。
现在的数据库系统肯定是同一个时刻有多个进程对数据库进行读写操作，假设现在有3个进程(A、B、C)对数据库的某表进行操作，
- 强一致性：A写入的数据x，B、C可以读到数据x
- 弱一致性：A写入的数据x，B、C一段时间内读不到，最后会读到
- 最终一致性：是一种特殊的一致性，保证在一段时间内没有数据的更新，但所有的返回都是把最新的数据返回；---缓存的概念，一段时间后把数据更新到数据库，达到最终一致性。
- 首先，是把这个str，用相同的哈希算法进行编码---->映射到一个32位的int型数据 num
- 然后，把这个num % Size 获取此字符串在hash table里面的位置；
- 然后，判断hash table 此位置是否已经有数据占用，如果已经占用说明在array里面有一个字符串对应的32位整数与str的32位整数相同，在一个字符串对应唯一一个32位整数的前提条件下，就说明array里面存在字符串str。
- int GetHashTablePos(char *lpszString, SOMESTRUCTURE *lpTable, int nTableSize)
- { //lpszSring--要查询的字符串；lpTable 哈希表；nTableSize是哈希表的Size
- int nHash = HashString(lpszString), nHashPos = nHash % nTableSize;
- if (lpTable[nHashPos].bExists && !strcmp(lpTable[nHashPos].pString, lpszString)) //时间复杂度是O(1)
- return nHashPos;
- else
- return -1; //Error value
- }
- int GetHashTablePos(char *lpszString, MPQHASHTABLE *lpTable, int nTableSize)
- {
- const int HASH_OFFSET = 0, HASH_A = 1, HASH_B = 2;
- int nHash = HashString(lpszString, HASH_OFFSET);
- int nHashA = HashString(lpszString, HASH_A);
- int nHashB = HashString(lpszString, HASH_B);
- int nHashStart = nHash % nTableSize, nHashPos = nHashStart;
- while (lpTable[nHashPos].bExists)
- {
- if (lpTable[nHashPos].nHashA == nHashA && lpTable[nHashPos].nHashB == nHashB)
- return nHashPos;
- else
- nHashPos = (nHashPos + 1) % nTableSize;
- if (nHashPos == nHashStart)
- break;
- }
- return -1; //Error value
- }
这样就可以保证万无一失了！
- <begin transaction>
- ****
- ****
- ****
- </end transaction>
- Atomicity(原子性)：一个事务是一个不可分割的完整单元，一个transaction里面的所有操作要么都做完，要么都不做；当中间一个操作失败把所有已经做的操作都回滚！
- Consistency(一致性)：数据库在一个事务开始前是一致性的，在这个事务执行完毕后仍然是一致性的；只是从一个一致性状态到另一个一致性状态；但都是一致性的
- Isolation(隔离性)：一个事务的执行不能被其他事务所打扰，即一个事务内部操作及使用的数据对并发的事务是隔离的，并发执行的事务之间互相不干扰(不理解)!!
- Durablity(持久性)：也就永久性(Permanence)，即一个事务一旦执行完毕，则它对数据库的更新是持久性的，即不受其他操作的影响；也就是事务修改了数据库了
