nosql第一章测试,nosql数据库入门与实践第二章

如何成为一名数据科学家

"Data Science = statistics who uses python and lives in San Francisco"

创新互联公司是一家专业从事做网站、网站制作的网络公司。作为专业网络公司,创新互联公司依托的技术实力、以及多年的网站运营经验,为您提供专业的成都网站建设、成都营销网站建设及网站设计开发服务！

恰好我马上启程到Twitter的data science team，而且恰巧懂一点点统计和住在旧金山，所以冲动地没有邀请就厚脸回答了:D

我认为有几个大方面

1）学好python。

现在几乎所以公司的数据都可以api给你，而python的数据处理能力强大且方便。加之在machine learning的很多算法上，python也独俏一方。另外，它的简明方便迅速迭代开发，15分钟写完个算法就可以看效果了。

除此之外，py还有点酷酷的感觉。任何程序拿matlab和c++都是可以写的，不过我真没认识过哪个d愿意自己把自己扔那个不酷的框框里:D

对不规则输入的处理也给python一个巨大的优势。通常来说，在我现在日常的工作里，所有的数据都是以纯文本但是非格式的形式存储的（raw text, unstructured data)。问题在于，这些文本不可以直接当作各种算法的输入，你需要

分词，分句

提取特征

整理缺失数据

除掉异类（outlier）

在这些时候，python可谓是神器。这里做的1-4都可以直接在scikit-learn里面找到对应的工具，而且，即使是要自己写一个定制的算法处理某些特殊需求，也就是一百行代码的事情。

简而言之，对于数据科学面临的挑战，python可以让你短平快地解决手中的问题，而不是担心太多实现细节。

2）学好统计学习

略拗口。统计学习的概念就是“统计机器学习方法”。

统计和计算机科学前几十年互相平行着，互相造出了对方造出的一系列工具，算法。但是直到最近人们开始注意到，计算机科学家所谓的机器学习其实就是统计里面的prediction而已。因此这两个学科又开始重新融合。

为什么统计学习很重要？

因为，纯粹的机器学习讲究算法预测能力和实现，但是统计一直就强调“可解释性”。比如说，针对今天微博股票发行就上升20%，你把你的两个预测股票上涨还是下跌的model套在新浪的例子上，然后给你的上司看。

Model-1有99%的预测能力，也就是99%的情况下它预测对，但是Model-2有95%，不过它有例外的一个附加属性——可以告诉你为什么这个股票上涨或者下跌。

试问，你的上司会先哪个？问问你自己会选哪个？

显然是后者。因为前者虽然有很强的预测力（机器学习），但是没有解释能力（统计解释）。

而作为一个数据科学家，80%的时间你是需要跟客户，团队或者上司解释为什么A可行B不可行。如果你告诉他们，“我现在的神经网络就是能有那么好的预测力可是我根本就没法解释上来”，那么，没有人会愿意相信你。

具体一些，怎么样学习统计学习？

先学好基本的概率学。如果大学里的还给老师了（跟我一样），那么可以从MIT的概率论教材【1】入手。从第1章到第9章看完并做完所有的习题。（p.s.面试Twitter的时候被问到一个拿球后验概率的问题，从这本书上抓来的）。

了解基本的统计检验及它们的假设，什么时候可以用到它们。

快速了解统计学习有哪些术语，用来做什么目的，读这本【5】。

学习基本的统计思想。有frequentist的统计，也有bayesian的统计。前者的代表作有【2】，后者看【3】。前者是统计学习的圣书，偏frequentist，后者是pattern recognition的圣书，几乎从纯bayesian的角度来讲。注意，【2】有免费版，作者把它全放在了网上。而且有一个简易版，如果感觉力不从心直接看【2】，那么可以先从它的简易版开始看。简易版【4】是作者在coursera上开课用的大众教材，简单不少（不过仍然有很多闪光点，通俗易懂）。对于【3】，一开始很难直接啃下来，但是啃下来会受益匪浅。

注意，以上的书搜一下几乎全可以在网上搜到别人传的pdf。有条件的同学可以买一下纸制版来读，体验更好并且可以支持一下作者。所有的书我都买了纸制版，但是我知道在国内要买本书有多不方便（以及原版书多贵）。

读完以上的书是个长期过程。但是大概读了一遍之后，我个人觉得是非常值得的。如果你只是知道怎么用一些软件包，那么你一定成不了一个合格的data scientist。因为只要问题稍加变化，你就不知道怎么解决了。

如果你感觉自己是一个二吊子数据科学家（我也是）那么问一下下面几个问题，如果有2个答不上来，那么你就跟我一样，真的还是二吊子而已，继续学习吧。

为什么在神经网络里面feature需要standardize而不是直接扔进去

对Random Forest需要做Cross-Validatation来避免overfitting吗？

用naive-bayesian来做bagging，是不是一个不好的选择？为什么？

在用ensembe方法的时候，特别是Gradient Boosting Tree的时候，我需要把树的结构变得更复杂（high variance, low bias)还是更简单（low variance, high bias)呢？为什么？

如果你刚开始入门，没有关系，回答不出来这些问题很正常。如果你是一个二吊子，体会一下，为什么你跟一流的data scientist还有些差距——因为你不了解每个算法是怎么工作，当你想要把你的问题用那个算法解决的时候，面对无数的细节，你就无从下手了。

说个题外话，我很欣赏一个叫Jiro的寿司店，它的店长在（东京？）一个最不起眼的地铁站开了一家全世界最贵的餐馆，预订要提前3个月。怎么做到的？70年如一日练习如何做寿司。70年！除了丧娶之外的假期，店长每天必到，8个小时工作以外继续练习寿司做法。

其实学数据科学也一样，沉下心来，练习匠艺。

3）学习数据处理

这一步不必独立于2）来进行。显然，你在读这些书的时候会开始碰到各种算法，而且这里的书里也会提到各种数据。但是这个年代最不值钱的就是数据了（拜托，为什么还要用80年代的“加州房价数据”？），值钱的是数据分析过后提供给决策的价值。那么与其纠结在这么悲剧的80年代数据集上，为什么不自己搜集一些呢？

开始写一个小程序，用API爬下Twitter上随机的tweets（或者weibo吧。。。）

对这些tweets的text进行分词，处理噪音（比如广告）

用一些现成的label作为label，比如tweet里会有这条tweet被转发了几次

尝试写一个算法，来预测tweet会被转发几次

在未见的数据集上进行测试

如上的过程不是一日之功，尤其刚刚开始入门的时候。慢慢来，耐心大于进度。

4）变成全能工程师（full stack engineer）

在公司环境下，作为一个新入职的新手，你不可能有优待让你在需要写一个数据可视化的时候，找到一个同事来给你做。需要写把数据存到数据库的时候，找另一个同事来给你做。

况且即使你有这个条件，这样频繁切换上下文会浪费更多时间。比如你让同事早上给你塞一下数据到数据库，但是下午他才给你做好。或者你需要很长时间给他解释，逻辑是什么，存的方式是什么。

最好的变法，是把你自己武装成一个全能工作师。你不需要成为各方面的专家，但是你一定需要各方面都了解一点，查一下文档可以上手就用。

会使用NoSQL。尤其是MongoDB

学会基本的visualization，会用基础的html和javascript，知道d3【6】这个可视化库，以及highchart【7】

学习基本的算法和算法分析，知道如何分析算法复杂度。平均复杂度，最坏复杂度。每次写完一个程序，自己预计需要的时间（用算法分析来预测）。推荐普林斯顿的算法课【8】（注意，可以从算法1开始，它有两个版本）

写一个基础的服务器，用flask【9】的基本模板写一个可以让你做可视化分析的backbone。

学习使用一个顺手的IDE，VIM， pycharm都可以。

leveldb高性能nosql数据库在node.js环境下如何使用及实例介绍

看了CNode社区的一篇文章，非常好，果断转，a href=""想看点我/a

nosql是什么

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

虽然NoSQL流行语火起来才短短一年的时间，但是不可否认，现在已经开始了第二代运动。尽管早期的堆栈代码只能算是一种实验，然而现在的系统已经更加的成熟、稳定。不过现在也面临着一个严酷的事实：技术越来越成熟——以至于原来很好的NoSQL数据存储不得不进行重写，也有少数人认为这就是所谓的2.0版本。这里列出一些比较知名的工具，可以为大数据建立快速、可扩展的存储库。

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

对于NoSQL并没有一个明确的范围和定义，但是他们都普遍存在下面一些共同特征：

不需要预定义模式：不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式。当插入数据时，并不需要预先定义它们的模式。

无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能。

弹性可扩展：可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可以自动迁移。

分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题。

异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。

BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。BASE是最终一致性和软事务。

NoSQL数据库并没有一个统一的架构，两种NoSQL数据库之间的不同，甚至远远超过两种关系型数据库的不同。可以说，NoSQL各有所长，成功的NoSQL必然特别适用于某些场合或者某些应用，在这些场合中会远远胜过关系型数据库和其他的NoSQL。

nosql数据库是什么 具有代表性以key-value的形式存储的

什么是NoSQL

大家有没有听说过“NoSQL”呢?近年，这个词极受关注。看到“NoSQL”这个词，大家可能会误以为是“No!SQL”的缩写，并深感愤怒：“SQL怎么会没有必要了呢?”但实际上，它是“Not Only SQL”的缩写。它的意义是：适用关系型数据库的时候就使用关系型数据库，不适用的时候也没有必要非使用关系型数据库不可，可以考虑使用更加合适的数据存储。

为弥补关系型数据库的不足，各种各样的NoSQL数据库应运而生。

为了更好地了解本书所介绍的NoSQL数据库，对关系型数据库的理解是必不可少的。那么，就让我们先来看一看关系型数据库的历史、分类和特征吧。

关系型数据库简史

1969年，埃德加?6?1弗兰克?6?1科德(Edgar Frank Codd)发表了划时代的论文，首次提出了关系数据模型的概念。但可惜的是，刊登论文的《IBM Research Report》只是IBM公司的内部刊物，因此论文反响平平。1970年，他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文，终于引起了大家的关注。

科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升，加之使用简单、性能优越等优点，关系型数据库得到了广泛的应用。

通用性及高性能

虽然本书是讲解NoSQL数据库的，但有一个重要的大前提，请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低，它具有非常好的通用性和非常高的性能”。毫无疑问，对于绝大多数的应用来说它都是最有效的解决方案。

突出的优势

关系型数据库作为应用广泛的通用型数据库，它的突出优势主要有以下几点:

保持数据的一致性(事务处理)

由于以标准化为前提，数据更新的开销很小(相同的字段基本上都只有一处)

可以进行JOIN等复杂查询

存在很多实际成果和专业技术信息(成熟的技术)

这其中，能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性和处理完整性的情况下，用关系型数据库是肯定没有错的。但是有些情况不需要JOIN，对上述关系型数据库的优点也没有什么特别需要，这时似乎也就没有必要拘泥于关系型数据库了。

关系型数据库的不足

不擅长的处理

就像之前提到的那样，关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库，并不能完全适应所有的用途。具体来说它并不擅长以下处理：

大量数据的写入处理

为有数据更新的表做索引或表结构(schema)变更

字段不固定时应用

对简单查询需要快速返回结果的处理

。。。。。。

NoSQL数据库

为了弥补关系型数据库的不足(特别是最近几年)，NoSQL数据库出现了。关系型数据库应用广泛，能进行事务处理和JOIN等复杂处理。相对地，NoSQL数据库只应用在特定领域，基本上不进行复杂的处理，但它恰恰弥补了之前所列举的关系型数据库的不足之处。

易于数据的分散

如前所述，关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的，就是说，各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理，关系型数据库不得不把数据存储在同一个服务器内，这不利于数据的分散。相反，NoSQL数据库原本就不支持JOIN处理，各个数据都是独立设计的，很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上，减少了每个服务器上的数据量，即使要进行大量数据的写入操作，处理起来也更加容易。同理，数据的读入操作当然也同样容易。

提升性能和增大规模

下面说一点题外话，如果想要使服务器能够轻松地处理更大量的数据，那么只有两个选择：一是提升性能，二是增大规模。下面我们来整理一下这两者的不同。

首先，提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法，程序方面也不需要进行变更，但需要一些费用。若要购买性能翻倍的服务器，需要花费的资金往往不只是原来的2倍，可能需要多达5到10倍。这种方法虽然简单，但是成本较高。

另一方面，增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更，但由于使用廉价的服务器，可以控制成本。另外，以后只要依葫芦画瓢增加廉价服务器的数量就可以了。

不对大量数据进行处理的话就没有使用的必要吗？

NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话，NoSQL数据库的应用就没有意义吗?

答案是否定的。的确，它在处理大量数据方面很有优势。但实际上NoSQL数据库还有各种各样的特点，如果能够恰当地利用这些特点将会是非常有帮助。具体的例子将会在第2章和第3章进行介绍，这些用途将会让你感受到利用NoSQL的好处。

希望顺畅地对数据进行缓存(Cache)处理

希望对数组类型的数据进行高速处理

希望进行全部保存

多样的NoSQL数据库

NoSQL数据库存在着“key-value存储”、“文档型数据库”、“列存储数据库”等各种各样的种类，每种数据库又包含各自的特点。下一节让我们一起来了解一下NoSQL数据库的种类和特点。

NoSQL数据库是什么

NoSQL说起来简单，但实际上到底有多少种呢?我在提笔的时候，到NoSQL的官方网站上确认了一下，竟然已经有122种了。另外官方网站上也介绍了本书没有涉及到的图形数据库和对象数据库等各个类别。不知不觉间，原来已经出现了这么多的NoSQL数据库啊。

本节将为大家介绍具有代表性的NoSQL数据库。

key-value存储

这是最常见的NoSQL数据库，它的数据是以key-value的形式存储的。虽然它的处理速度非常快，但是基本上只能通过key的完全一致查询获取数据。根据数据的保存方式可以分为临时性、永久性和两者兼具三种。

临时性

memcached属于这种类型。所谓临时性就是 “数据有可能丢失”的意思。memcached把所有数据都保存在内存中，这样保存和读取的速度非常快，但是当memcached停止的时候，数据就不存在了。由于数据保存在内存中，所以无法操作超出内存容量的数据(旧数据会丢失)。

在内存中保存数据

可以进行非常快速的保存和读取处理

数据有可能丢失

永久性

Tokyo Tyrant、Flare、ROMA等属于这种类型。和临时性相反，所谓永久性就是“数据不会丢失”的意思。这里的key-value存储不像memcached那样在内存中保存数据，而是把数据保存在硬盘上。与memcached在内存中处理数据比起来，由于必然要发生对硬盘的IO操作，所以性能上还是有差距的。但数据不会丢失是它最大的优势。

在硬盘上保存数据

可以进行非常快速的保存和读取处理(但无法与memcached相比)

数据不会丢失

两者兼具

Redis属于这种类型。Redis有些特殊，临时性和永久性兼具，且集合了临时性key-value存储和永久性key-value存储的优点。Redis首先把数据保存到内存中，在满足特定条件(默认是15分钟一次以上，5分钟内10个以上，1分钟内10000个以上的key发生变更)的时候将数据写入到硬盘中。这样既确保了内存中数据的处理速度，又可以通过写入硬盘来保证数据的永久性。这种类型的数据库特别适合于处理数组类型的数据。

同时在内存和硬盘上保存数据

可以进行非常快速的保存和读取处理

保存在硬盘上的数据不会消失(可以恢复)

适合于处理数组类型的数据

面向文档的数据库

MongoDB、CouchDB属于这种类型。它们属于NoSQL数据库，但与key-value存储相异。

不定义表结构

面向文档的数据库具有以下特征：即使不定义表结构，也可以像定义了表结构一样使用。关系型数据库在变更表结构时比较费事，而且为了保持一致性还需修改程序。然而NoSQL数据库则可省去这些麻烦(通常程序都是正确的)，确实是方便快捷。

可以使用复杂的查询条件

跟key-value存储不同的是，面向文档的数据库可以通过复杂的查询条件来获取数据。虽然不具备事务处理和JOIN这些关系型数据库所具有的处理能力，但除此以外的其他处理基本上都能实现。这是非常容易使用的NoSQL数据库。

不需要定义表结构

可以利用复杂的查询条件

面向列的数据库

Cassandra、Hbase、HyperTable属于这种类型。由于近年来数据量出现爆发性增长，这种类型的NoSQL数据库尤其引人注目。

面向行的数据库和面向列的数据库

普通的关系型数据库都是以行为单位来存储数据的，擅长进行以行为单位的读入处理，比如特定条件数据的获取。因此，关系型数据库也被称为面向行的数据库。相反，面向列的数据库是以列为单位来存储数据的，擅长以列为单位读入数据。

高扩展性

面向列的数据库具有高扩展性，即使数据增加也不会降低相应的处理速度(特别是写入速度)，所以它主要应用于需要处理大量数据的情况。另外，利用面向列的数据库的优势，把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同，应用起来十分困难。

高扩展性(特别是写入处理)

应用十分困难

最近，像Twitter和Facebook这样需要对大量数据进行更新和查询的网络服务不断增加，面向列的数据库的优势对其中一些服务是非常有用的，但是由于这与本书所要介绍的内容关系不大，就不进行详细介绍了。

总结：

NoSQL并不是No-SQL，而是指Not Only SQL。

NoSQL的出现是为了弥补SQL数据库因为事务等机制带来的对海量数据、高并发请求的处理的性能上的欠缺。

NoSQL不是为了替代SQL而出现的，它是一种替补方案，而不是解决方案的首选。

绝大多数的NoSQL产品都是基于大内存和高性能随机读写的（比如具有更高性能的固态硬盘阵列），一般的小型企业在选择NoSQL时一定要慎重！不要为了NoSQL而NoSQL，可能会导致花了冤枉钱又耽搁了项目进程。

NoSQL不是万能的，但在大型项目中，你往往需要它！