nosqlapi下载,nosql软件

什么是NoSQL数据库？

2. 什么是NoSQL？

网站的建设创新互联专注网站定制,经验丰富,不做模板,主营网站定制开发.小程序定制开发,H5页面制作!给你焕然一新的设计体验!已为成都石牌坊等企业提供专业服务。

2.1 NoSQL 概述

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，

泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。

（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。

2.2 NoSQL代表

MongDB、 Redis、Memcache

3. 关系型数据库与NoSQL的区别？

3.1 RDBMS

高度组织化结构化数据

结构化查询语言（SQL）

数据和关系都存储在单独的表中。

数据操纵语言，数据定义语言

严格的一致性

基础事务

ACID

关系型数据库遵循ACID规则

事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：

A (Atomicity) 原子性

原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。

C (Consistency) 一致性

一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。

I (Isolation) 独立性

所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的

D (Durability) 持久性

持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

3.2 NoSQL

代表着不仅仅是SQL

没有声明性查询语言

没有预定义的模式

键 - 值对存储，列存储，文档存储，图形数据库

最终一致性，而非ACID属性

非结构化和不可预知的数据

CAP定理

高性能，高可用性和可伸缩性

分布式数据库中的CAP原理(了解)

CAP定理：

Consistency(一致性), 数据一致更新，所有数据变动都是同步的

Availability(可用性), 好的响应性能

Partition tolerance(分区容错性) 可靠性

P: 系统中任意信息的丢失或失败不会影响系统的继续运作。

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。

AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。

而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。

所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

说明：C：强一致性 A：高可用性 P：分布式容忍性

举例：

CA：传统Oracle数据库

AP：大多数网站架构的选择

CP：Redis、Mongodb

注意：分布式架构的时候必须做出取舍。

一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。

因此牺牲C换取P，这是目前分布式数据库产品的方向。

4. 当下NoSQL的经典应用

当下的应用是 SQL 与 NoSQL 一起使用的。

代表项目：阿里巴巴商品信息的存放。

去 IOE 化。

ps：I 是指 IBM 的小型机，很贵的，好像好几万一台；O 是指 Oracle 数据库，也很贵的，好几万呢；M 是指 EMC 的存储设备，也很贵的。

难点：

数据类型多样性。

数据源多样性和变化重构。

数据源改造而服务平台不需要大面积重构。

谁有InterSystem Caché数据库安装包,或者哪里可以下载啊，谢谢

互联网公司常用的基本集中在以下几种，每种只举一个比较常见或者应用比较成功的例子吧。

1. In-Memory KV Store : Redis

in memory key-value store，同时提供了更加丰富的数据结构和运算的能力，成功用法是替代memcached，通过checkpoint和commit log提供了快速的宕机恢复，同时支持replication提供读可扩展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盘的key-value storage, 模型单一简单，数据量不受限于内存大小，数据落盘高可靠，Google的几位大神出品的精品，LSM模型天然写优化，顺序写盘的方式对于新硬件ssd再适合不过了，不足是仅提供了一个库，需要自己封装server端。

3. Document Store: Mongodb

分布式nosql，具备了区别mysql的最大亮点：可扩展性。mongodb 最新引人的莫过于提供了sql接口，是目前nosql里最像mysql的，只是没有ACID的特性，发展很快，支持了索引等特性，上手容易，对于数据量远超内存限制的场景来说，还需要慎重。

4. Column Table Store: HBase

这个富二代似乎不用赘述了，最大的优势是开源，对于普通的scan和基于行的get等基本查询，性能完全不是问题，只是只提供裸的api,易用性上是短板，可扩展性方面是最强的，其次坐上了Hadoop的快车，社区发展很快，各种基于其上的开源产品不少，来解决诸如join、聚集运算等复杂查询。

怎样用python爬新浪微博大V所有数据

先上结论，通过公开的api如果想爬到某大v的所有数据，需要满足以下两个条件：

1、在你的爬虫开始运行时，该大v的所有微博发布量没有超过回溯查询的上限，新浪是2000，twitter是3200。

2、爬虫程序必须不间断运行。

新浪微博的api基本完全照搬twitter，其中接口的参数特性与底层的NoSQL密不可分，建议先看点Nosql数据库的设计理念有助于更好的理解api设计。

一般来说，如果决定爬某个大v，第一步先试获取该用户的基本信息，中间会包含一条最新的status，记下其中的id号作为基准，命名为baseId。

接口中最重要的两个参数：

since_id：返回ID比since_id大的微博（即比since_id时间晚的微博），默认为0。

max_id：返回ID小于或等于max_id的微博，默认为0。

出于各种原因，获取statuses的接口，固定为按id降序排列（scan_index_forward=false），即最新的statuses返回在前。假设该微博第一天上线，就一个用户，发了一百条，id是1到100。而你在该用户发了第50条的时候开始运行的爬虫，即baseId=50。

假设按每次获取10条历史数据递归，先将max_id设为baseId，获取该用户id为41－50的微博，再将max_id设为41重复循环，直到返回微博数量为1或0。这步没有问题。

获取用户最新的statuses就有些蛋疼了，since_id＝50，同样获取10条数据，返回的并不是id值为51－60的数据，而是100-91的数据。简单说就是你没法从since_id逐步更新到用户当前status，而是得一口气从用户当前status更新到上次爬虫运行时得到的最后一条status。假设你的爬虫一个月才运行一次，该用户在这期间发了2300条微博，根据限制你只能更新2000条，这其中最老的300条在你的系统内就会出现“断档”。

最后一条，以上只针对公开的api，stackoverflow上twitter

API可以申请权限突破数量限制和更改排序机制，微博也应该有类似机制。

什么是nosql非结构化数据库

基本含义NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。NoSQLNoSQL数据库的四大分类键值(Key-Value)存储数据库这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。[3] 举例如：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.列存储数据库。这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra, HBase, Riak.文档型数据库文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可 以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb. 国内也有文档型数据库SequoiaDB，已经开源。图形(Graph)数据库图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。[2] 如：Neo4J, InfoGrid, Infinite Graph.因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。

nosql与rdbms直接有什么区别

NoSQL与RDBMS的九点区别联系 

1 理解ACID与BASE的区别（ACID是关系型数据库强一致性的四个要求，而BASE是NoSQL数据库通常对可用性及一致性的弱要求原则，它们的意思分别是，ACID：atomicity, consistency, isolation, durability;BASE：Basically Available, Soft-state, Eventually Consistent。同时有意思的是ACID在英语里意为酸，BASE意思为碱）

2 理解持久化与非持久化的区别。这么说是因为有的NoSQL系统是纯内存存储的。

3 你必须意识到传统有关系型数据库与NoSQL系统在数据结构上的本质区别。传统关系型数据库通常是基于行的表格型存储，而NoSQL系统包括了列式存储（Cassandra）、key/value存储（Memcached）、文档型存储（CouchDB）以及图结构存储（Neo4j）

4与传统关系数据库有统一的SQL语言操作接口不同，NoSQL系统通常有自己特有的API接口。

5 在架构上，你必须搞清楚，NoSQL系统是被设计用于成百上千台机器的集群中的，而非共享型数据库系统的架构。

6在NoSQL系统中，可能你得习惯一下不知道你的数据具体存在何处的情况。

7 在NoSQL系统中，你最好习惯它的弱一致性。”eventually consistent”(最终一致性)正是BASE原则中的重要一项。比如在Twitter，你在Followers列表中经常会感受到数据的延迟。

8 在NoSQL系统中，你要理解，很多时候数据并不总是可用的。

9 你得理解，有的方案是拥有分区容忍性的，有的方案不一定有。

为什么不用NoSQL

当为大家描述我们的整体服务架构时，最常见的两个问题是：

为什么采用结构化方式将数据存储在SQL数据库中，而不使用NoSQL平台？

为什么自己维护数据中心，而不将Evernote托管到云服务提供商？

这两个问题都很有趣，我们先来探讨第一个。

对特定的应用而言，相比一个单一的SQL实例，一个现代的键值存储引擎具备显著的性能优势和可扩展性。

CREATE TABLE notebooks ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, name varchar(100) COLLATE utf8_bin NOT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE notes ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, notebook_id int UNSIGNED NOT NULL, title varchar(255) NOT NULL, ... FOREIGN KEY (notebook_id) REFERENCES notebooks(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

如果你在Windows客户端上创建了一个名为“Cooking”的记事本，并立即在其中粘贴了一个名为“Quick Tomato Sauce”的食谱，客户端会立刻进行如下同步：

调用NoteStore.createNotebook() 请求服务器创建记事本，并返回以创建记事本的GUID。

通过指定记事本的GUID，调用NoteStore.createNote()在记事本中创建笔记。

每次API调用都通过SQL事物予以实现，可以让客户端完全信任服务器的任何提示。ACID兼容的数据库可以做到这些：

原子性（Atomicity）：如果API调用成功，那么所有的改动都会保存；如果API调用失败，所有的改动都不会提交。

一致性（Consistency）： 在API调用完成后，所有的账户都可用，并能保证内部状态的一致性。每篇笔记都与记事本相关联，以避免出现孤立项。数据库不允许删除关联有记事的记事本，这得感谢FOREIGN KEY约束。

持久性（Durability）：当服务器发送记事本已创建完毕的回执后，客户端会认为它的存在具有持久性，以便进行后续的操作。变更的持久性，可以让客户端知道在任何时刻对服务状态的影响都能保持一致性。

对我们的同步协议而言，持久性最为重要。如果客户端不能确定服务器端的变更具有持久性，那么协议将会变得复杂而低效。

“大数据”问题

得益于事务处理的数据库的ACID属性，同样使得数据集非常难以扩展，以超出单台服务器的范围。数据库集群和多主复制技术并不理想，键值存储为实现可扩展性提供了一条捷径。

所幸，Evernote暂时不需要考虑这个问题。即便是我们有近10亿的笔记，和近20亿的资源文件，这也并不能称得上是一个大数据集。通过按用户分区，它被划分成了2千万个独立的数据集。

我们尚未遇到所谓“大数据”引发的问题，倒是遇到了许多“中数据”的存储问题，这就是通过规整分区形成的分片存储架构。

也许以后……

我们对新的存储系统非常感兴趣，非常乐意应用在哪些对ACID要求不强，但确实需要横向扩展的新项目中。例如，我们的报告分析系统已经逐渐超出了MySQL平台的承受力，需要被更快、更先进的系统所取代。

我们现在对以Evernote用户元数据为基础的MySQL分片存储颇为满意，尽管这不会引起那些IT弄潮儿的兴趣。