springboot整合mongodb，并配置账户名和密码登录验证

springboot pom.xml加入依赖

1
2
3
    org.springframework.boot
    spring-boot-starter-data-mongodb
    2.1.6.RELEASE

application.yml加入连接信息 mapper编写

1
2
public interface BusinessLogRecordMapper extends MongoRepository<businesslogrecord,string> {
}

Application启动添加注解

1
@EnableMongoRepositories(basePackages = {"com.etc.mapper"})

application.yml配置，这里之前碰到一个坑，mongodb的配置没有写host和port属性，只写了database和uri，这种方式在无密码验证的情况下，可以连接mongodb。但是在mongodb设置了密码登录后，就无法连接，一直提示 Caused by: com.mongodb.MongoCommandException: Command failed with error 13: 'not authorized on wxsb_dev to execute command { insert 这里我们说下，application.yml关于mongodb的两种配置 第一种，yml方式，注意这里的host port username password database，每个属性都要配置。

1
2
3
4
5
6
7
8
spring:
  data:
    mongodb:
      host: 192.168.11.121
      port: 27017
      username: aroot
      password: 999999
      database: udb

  第二种，uri方式

1
2
3
4
spring:
  data:
    mongodb:
      uri: mongodb://aroot:999999@192.168.11.121:27017/udb

  之前就是配了如下的参数，导致一直出错，还以为是mongodb的用户权限配置出错导致，原来是配置文件出错，报错信息 Caused by: com.mongodb.MongoCommandException: Command failed with error 13: 'not authorized on wxsb_dev to execute command { insert

1
2
3
4
5
6
7
spring:
  data:
    mongodb:
      database: udb
      uri: mongodb://192.168.11.111:27017
      username: aroot
      password: 999999

  from:https://www.it610.com/article/1283088113266081792.htm

一篇文章，掌握所有开源数据库的现状

数据库作为业务的核心，在整个基础软件栈中是非常重要的一环。近几年社区也是新的方案和思想层出不穷，接下来我将总结一下近几年一些主流的开源数据库方案，其背后的设计思想以及适用场景。本人才疏学浅如有遗漏或者错误请见谅。本次分享聚焦于数据库既结构化数据存储 OLTP 及 NoSQL 领域，不会涉及 OLAP、对象存储、分布式文件系统。 1 开源RDBMS与互联网的崛起 很长时间以来，关系型数据库一直是大公司的专利，市场被 Oracle / DB2 等企业数据库牢牢把持。但是随着互联网的崛起、开源社区的发展，上世纪九十年代 MySQL 1.0 的发布，标志着关系型数据库的领域社区终于有可选择的方案。 MySQL 第一个介绍的单机RDBMS就是MySQL。相信大多数朋友都已经对 MySQL 非常熟悉，基本上 MySQL 的成长史就是互联网的成长史。我接触的第一个 MySQL 版本是 MySQL 4.0，到后来的 MySQL 5.5 更是经典——基本所有的互联网公司都在使用。 MySQL 也普及了「可插拔」引擎这一概念，针对不同的业务场景选用不同的存储引擎是 MySQL tuning 的一个重要的方式。比如对于有事务需求的场景使用 InnoDB;对于并发读取的场景 MyISAM 可能比较合适;但是现在我推荐绝大多数情况还是使用 InnoDB，毕竟 5.6 后已经成为了官方的默认引擎。大多数朋友都基本知道什么场景适用 MySQL(几乎所有需要持久化结构化数据的场景)，我就不赘述了。 另外值得一提的是 MySQL 5.6中引入了多线程复制和 GTID，使得故障恢复和主从的运维变得比较方便。另外，5.7(目前处于 GA 版本) 是 MySQL 的一个重大更新，主要是读写性能和复制性能上有了长足的进步(在5.6版本中实现了SCHEMA级别的并行复制，不过意义不大，倒是MariaDB的多线程并行复制大放异彩，有不少人因为这个特性选择MariaDB。MySQL 5.7 MTS支持两种模式，一种是和5.6一样，另一种则是基于binlog group commit实现的多线程复制，也就是MASTER上同时提交的binlog在SLAVE端也可以同时被apply，实现并行复制)。 如果有单机数据库技术选型的朋友，基本上只需要考虑 5.7 或者 MariaDB 就好了，而且 5.6、5.7 由 Oracle 接手后，性能和稳定性上都有了明显的提升。 PostgreSQL PostgreSQL的历史也非常悠久，其前身是UCB的Ingres，主持这个项目的 Michael Stronebraker 于 2015 年获得图灵奖。后来项目更名为 Post-Ingres，项目基于 BSD license 下开源。 1995 年几个 UCB 的学生为 Post-Ingres 开发了 SQL 的接口，正式发布了 PostgreSQL95，随后一步步在开源社区中成长起来。 和 MySQL 一样，PostgreSQL 也是一个单机的关系型数据库，但是与 MySQL 方便用户过度扩展的 SQL 文法不一样的是，PostgreSQL 的 SQL 支持非常强大，不管是内置类型、JSON 支持、GIS 类型以及对于复杂查询的支持，PL/SQL 等都比 MySQL 强大得多。而且从代码质量上来看，PostgreSQL 的代码质量是优于 MySQL 的，另外 PostgreSQL 的 SQL 优化器比 MySQL 强大很多，几乎所有稍微复杂的查询(当然，我没有对比 MySQL 5.7，也可能这个信息 outdated 了)PostgreSQL 的表现都优于 MySQL。 从近几年的趋势上来看，PostgreSQL 的势头也很强劲，我认为 PostgreSQL 的不足之处在于没有 MySQL 这样强大的社区和群众基础。MySQL 经过那么多年的发展，积累了很多的运维工具和最佳实践，但是 PostgreSQL 作为后起之秀，拥有更优秀的设计和更丰富的功能。PostgreSQL 9 以后的版本也足够稳定，在做新项目技术选型的时候，是一个很好的选择。另外也有很多新的数据库项目是基于 PostgreSQL 源码的基础上进行二次开发，比如Greenplum等。 我认为，单机数据库的时代很快就会过去。榨取摩尔定律带来的硬件红利总是有上限的，现代业务的数据规模、流量以及现代的数据科学对于数据库的要求单机已经很难满足。网卡磁盘 IO 和 CPU 总有瓶颈，线上敏感的业务系统可能还得承担 SPOF(单点故障) 的风险，主从复制模型在主挂掉时到底切还是不切?切了以后数据如何恢复?如果只是出现主从机器网络分区问题呢?甚至是监控环境出现网络分区问题呢?这些都是问题。 所以我的观点是，无论单机性能多棒(很多令人乍舌的评测数据都是针对特定场景的优化，另外甚至有些都是本机不走网络，而大多数情况数据库出现的第一个瓶颈其实是网卡和并发连接……)，随着互联网的蓬勃发展，移动互联网的出现使得数据库系统迎来了第一次分布式的洗礼。 2 分布式时代：NoSQL的复兴和模型简化的力量 在介绍 NoSQL 之前，我想提两个公司，一个是Google，另一个是Amazon。 Google Google 应该是第一个将分布式存储技术应用到大规模生产环境的公司，同时也是在分布式系统上积累最深的公司，可以说目前工业界的分布式系统的工程实践及思想大都来源于 Google。比如 2003 年的 GFS 开创了分布式文件系统，2006 年的 Bigtable 论文开创了分布式键值系统，直接催生的就是 Hadoop 的生态;至于 2012 年发表论文的Spanner和F1更是一个指明未来关系型数据库发展方向的里程碑式的项目，这个我们后续会说。 Amazon 另一个公司是 Amazon。2007 年发表的Dynamo的论文尝试引入了最终一致性的概念， WRN 的模型及向量时钟的应用，同时将一致性 HASH、merkle tree 等当时一些很新潮的技术整合起来，正式标志着 NoSQL 的诞生——对后来业界的影响也是很大，包括后来的 Cassandra、RiakDB、Voldemort 等数据库都是基于 Dynamo 的设计发展起来的。 新思潮 另外这个时期(2006 年前后持续至今)一个比较重要的思潮就是数据库(持久化)和缓存开始有明确的分离——我觉得这个趋势是从 memcached 开始的。随着业务的并发越来越高，对于低延迟的要求也越来越高;另外一个原因是随着内存越来越便宜，基于内存的存储方案渐渐开始普及。当然内存缓存方案也经历了一个从单机到分布式的过程，但是这个过程相比关系型数据库的进化要快得多。 这是因为 NoSQL 的另外一个重要的标志——数据模型的变化——大多 NoSQL 都抛弃了关系模型，选择更简单的键值或者文档类型进行存储。数据结构和查询接口都相对简单，没有了SQL 的包袱，实现的难度会降低很多。 另外 NoSQL 的设计几乎都选择牺牲掉复杂 SQL 的支持及 ACID 事务换取弹性扩展能力，也是从当时互联网的实际情况出发：业务模型简单、爆发性增长带来的海量并发及数据总量爆炸、历史包袱小、工程师强悍，等。其中最重要的还是业务模型相对简单。 嵌入式存储引擎 在开始介绍具体的开源的完整方案前，我想介绍一下嵌入式存储引擎们。 随着 NoSQL 的发展，不仅仅缓存和持久化存储开始细分，再往后的存储引擎也开始分化并走上前台。之前很难想象一个存储引擎独立于数据库直接对外提供服务，就像你不会直接拿着 InnoDB 或者 MyISAM甚至一个 B-tree 出来用一样(当然，bdb 这样鼎鼎大名的除外)。人们基于这些开源的存储引擎进行进一步的封装，比如加上网络协议层、加上复制机制等等，一步步构建出完整的风格各异的 NoSQL 产品。 这里我挑选几个比较著名存储引擎介绍一下。 TC 我最早接触的是Tokyo Cabinet(TC)。TC 相信很多人也都听说过，TC 是由日本最大的社交网站 Mixi 开发并开源的一个混合 Key-Value 存储引擎，其中包括 HASH Table 和 B+ Tree 的实现。但是这个引擎的一个缺陷是随着数据量的膨胀，性能的下降会非常明显，而且现在也基本不怎么维护了，所以入坑请慎重。于 TC 配合使用的Tokyo Tyrant(TT)是一个网络库，为 TC 提供网络的接口使其变成一个数据库服务，TT + TC 应该是比较早的 NoSQL 的一个尝试。 LevelDB 在 2011 年，Google 开源了 Bigtable 的底层存储擎：LevelDB。LevelDB 是一个使用 C++ 开发的嵌入式的 Key-Value 存储引擎，数据结构采用了 LSM-Tree，具体 LSM-Tree 的算法分析可以很容易在网上搜索到，我就不赘述了。其特点是，对于写入极其友好，LSM 的设计避免了大量的随机写入;对于特定的读也能达到不错的性能(热数据在内存中);另外 LSM-Tree 和 B-tree 一样是支持有序 Scan 的;而且 LevelDB 是出自 Jeff Dean 之手，他的事迹做分布式系统的朋友一定都知道，不知道的可以去 Google 搜一下。 LevelDB 拥有极好的写性能，线程安全，BaTCh Write 和 Snapshot 等特性，使其很容易的在上层构建 MVCC 系统或者事务模型，对于数据库来说非常重要。 另外值得一说的是，Facebook 维护了一个活跃的 LevelDB 的分支，名为 RocksDB。RocksDB 在 LevelDB 上做了很多的改进，比如多线程 Compactor、分层自定义压缩、多 MemTable 等。另外 RocksDB 对外暴露了很多 Configration ，可以根据不同业务的形态进行调优;同时 Facebook 在内部正在用 RocksDB 来实现一个全新的 MySQL 存储引擎：MyRocks，值得关注。RocksDB 的社区响应速度很快也很友好，实际上 PingCAP 也是 RocksDB 的社区贡献者。我建议新的项目如果在 LevelDB 和 RocksDB 之间纠结的话，请果断选择 RocksDB。 B-tree 家族 当然，除了 LSM-Tree 外，B-tree的家族也还是有很多不错的引擎。首先大多数传统的单机数据库的存储引擎都选择了B+Tree，B+Tree 对磁盘的读比较友好，第三方存储引擎比较著名的纯 B+Tree 实现是LMDB。首先 LMDB 选择在内存映像文件 (mmap) 实现 B+Tree，同时使用了 Copy-On-Write 实现了 MVCC 实现并发事务无锁读的能力，对于高并发读的场景比较友好;同时因为使用的是 mmap 所以拥有跨进程读取的能力。因为我并没有在生产环境中使用过 LMDB ，所以并不能给出 LMDB 的一些缺陷，见谅。 混合引擎 还有一部分的存储引擎选择了多种引擎混合，比如最著名的应该是WiredTiger，大概是去年被 MongoDB 收购，现在成为了 MongoDB 的默认存储引擎。WiredTiger 内部有 LSM-Tree 和 B-tree 两种实现提供一套接口，根据业务的情况可自由选择。另外一些特殊数据结构的存储引擎在某些特殊场合下非常抢眼，比如极高压缩比TokuDB，采用了名为分形树的数据结构，在维持一个可接受的读写压力的情况下，能拥有 10 倍以上的压缩率。 NoSQL 说完了几个比较著名的存储引擎，我们来讲讲比较著名的 NoSQL。在我的定义中，NoSQL 是Not Only SQL 的缩写，所以可能包含的范围有内存数据库，持久化数据库等。总之就是和单机的关系型数据库不一样的结构化数据存储系统。 我们先从缓存开始。 memcached 前面提到了 memcached 应该是第一个大规模在业界使用的缓存数据库，memcached 的实现极其简单，相当于将内存用作大的 HASH Table，只能在上面 get/set/ 计数器等操作，在此之上用 libevent 封装了一层网络层和文本协议(也有简单的二进制协议)，虽然支持一些 CAS 的操作，但是总体上来看，还是非常简单的。 但是 memcached 的内存利用率并不太高，这个因为 memcached 为了避免频繁申请内存导致的内存碎片的问题，采用了自己实现的slab allocator 的方式。即内存的分配都是一块一块的，最终存储在固定长度的chunk 上，内存最小的分配单元是chunk，另外 libevent 的性能也并没有优化到极致，但是不妨碍 memcached 成为当时的开源缓存事实标准(另外，八卦一下，memcached 的作者Brad Fitzpatrick，现在在 Google，大家如果用 Golang 的话，Go 的官方 HTTP 包就是这哥们写的，是个很高产的工程师)。 Redis 如果我没记错的话，在 2009 年前后，一位意大利的工程师Antirez，开源了Redis。从此彻底颠覆了缓存的市场，到现在大多数缓存的业务都已用上Redis，memcached 基本退出了历史舞台。Redis 最大的特点是拥有丰富的数据结构支持，不仅仅是简单的 Key-Value，包括队列、集合、Sorted Set 等等，提供了非常丰富的表达力，而且 Redis 还提供 sub/pub 等超出数据库范畴的便捷功能，使得几乎一夜之间大家纷纷投入 Redis 的怀抱。 Twemproxy 但是随着 Redis 渐渐的普及，而且越用越狠，另外内存也越来越便宜，人们开始寻求扩展单机Redis的方案，最早的尝试是twitter 开源的twemproxy，twemproxy 是一个 Redis 中间件，基本只有最简单的数据路由功能，并没有动态的伸缩能力，但是还是受到了很多公司的追捧，因为确实没方案。随后的 Redis Cluster 也是难产了好久，时隔好几年，中间出了 7 个RC 版本，最后才发布; 2014 年底，我们开源了Codis，解决了 Redis 中间件的数据弹性伸缩问题，目前广泛应用于国内各大互联网公司中，这个在网上也有很多文章介绍，我也就不展开了。所以在缓存上面，开源社区现在倒是非常统一，就是 Redis 极其周边的扩展方案。 MongoDB 在 NoSQL 的大家庭中，MongoDB其实是一个异类，大多 NoSQL 舍弃掉 SQL 是为了追求更极致的性能和可扩展能力，而 MongoDB 主动选择了文档作为对外的接口，非常像 JSON 的格式。Schema-less 的特性对于很多轻量级业务和快速变更了互联网业务意义很大，而且 MongoDB 的易用性很好，基本做到了开箱即用，开发者不需要费心研究数据的表结构，只需要往里存就好了，这确实笼络了一大批开发者。 尽管 MongoDB 早期的版本各种不稳定，性能也不太好(早期的 Mongo 并没有存储引擎，直接使用了 mmap 文件)，集群模式还全是问题(比如至今还未解决的 Cluster 同步带宽占用过多的问题)，但是因为确实太方便了，在早期的项目快速迭代中，Mongo 是一个不错的选择。 但是这也正是它的问题，我不止一次听到当项目变得庞大或者「严肃」的时候，团队最后还是回归了关系型数据库。Anyway，在 2014 年底 MongoDB 收购了 WiredTiger 后，在 2.8 版本中正式亮相，同时 3.0 版本后更是作为默认存储引擎提供，性能和稳定性有了非常大的提升。 但是，从另一方面讲，Schema-less 到底对软件工程是好事还是坏事这个问题还是有待商榷。我个人是站在 Schema 这边的，不过在一些小项目或者需要快速开发的项目中使用 Mongo 确实能提升很多的开发效率，这是毋庸置疑的。 HBase 说到 NoSQL 不得不提的是HBase，HBase 作为Hadoop 旗下的重要产品，Google Bigtable的正统开源实现，是不是有一种钦定的感觉:)。提到 HBase 就不得不提一下Bigtable，Bigtable是Google内部广泛使用的分布式数据库，接口也不是简单的Key-Value，按照论文的说法叫：multi-dimensional sorted map，也就是 Value 是按照列划分的。Bigtable 构建在 GFS 之上，弥补了分布式文件系统对于海量、小的、结构化数据的插入、更新、随机读请求的缺陷。 HBase 就是这么一个系统的实现，底层依赖 HDFS。HBase 本身并不实际存储数据，持久化的日志和 SST file (HBase 也是 LSM-Tree 的结构) 直接存储在 HDFS 上，Region Server (RS) 维护了 MemTable 以提供快速的查询，写入都是写日志，后台进行 Compact，避免了直接随机读写 HDFS。 数据通过 Region 在逻辑上进行分割，负载均衡通过调节各个 Region Server 负责的 Region 区间实现。当某 Region 太大时，这个 Region 会分裂，后续可能由不同的 RS 负责，但是前面提到了，HBase 本身并不存储数据，这里的 […]

六个藉藉无名但迅速崛起的Apache大数据项目

如今全球各地的无数企业组织在处理数据集，这些数据集是如此地庞大而复杂，以至于传统的数据处理应用软件再也无法支持经过优化的数据分析和洞察力获取。这是新一批大数据应用软件旨在解决的问题，而Apache软件基金会（ASF）最近将一批值得关注的开源大数据项目升级为Apache顶级项目。这意味着，这些项目将获得积极的开发和强有力的社区支持。 （图片来源：Creative Commons Zero） 大多数人已听说过Apache Spark，这种大数据处理框架拥有内置模块，可用于数据流、SQL、机器学习和图形处理。IBM及其他公司正在往Spark项目投入数十亿美元的开发资金，美国宇航局和SETI研究所在开展合作，利用Spark的机器学习能力，分析数TB的复杂的外太空无线信号，搜寻可能表明存在智能外星生命的模式。 然而，另外几个最近被提升为顶级项目的Apache大数据项目同样值得关注。实际上，其中一些打造的生态系统在活动和开发上可与Spark的生态系统相媲美。本文介绍了你应该知道的几个Apache大数据项目。 下面是六个迅速崛起的项目： Kylin Apache最近宣布，Kylin项目这个脱胎于eBay的开源大数据项目已被提升为顶级项目。Kylin是一个开源分布式分析引擎，旨在提供一种基于Apache Hadoop的SQL接口和多维分析（OLAP），支持极其庞大的数据集。它仍广泛用于eBay和另外几家组织。 Apache Kylin副总裁Luke Han说：“Apache Kylin的孵化之旅已证明了开源治理在Apache软件基金会（ASF）具有的价值，并证明了围绕该项目打造一个开源社区和生态系统的力量。我们的社区在与世界上最庞大的本地开发者社区积极互动，完全依照Apache之道。” 作为一种基于Hadoop的OLAP解决方案，Apache Kylin旨在填补大数据探索与人类使用之间的空白，“让分析员、最终用户、开发人员和数据爱好者能够对庞大数据集执行交互式分析，延迟低于1秒，”据开发人员声称。他们补充道：“Apache Kylin将商业智能（BI）带回給Apache Hadoop，发掘大数据的价值。” Lens Apache最近还宣布，Apache Lens这个开源大数据和分析工具由Apache孵化器提升为顶级项目（TLP）。据宣布声称：“Apache Lens是一种统一分析平台。它为统一视图的分析查询提供了一种最佳执行环境。Apache Lens旨在通过针对多个分层数据存储系统，提供单一的数据视图，从而消除数据分析孤岛。” “通过在数据基础上提供一种联机分析处理（OLAP）模型，Lens将Apach Hadoop和传统数据仓库无缝集成起来，好比是一个整体。它还为在系统中运行的查询提供了查询历史记录和分析统计功能，另外提供了查询生命周期管理。” Apache Lens的副总裁Amareshwari Sriramadasu 说：“在ASF孵化Apache Lens是个神奇的经历。Apache Lens着眼于最终用户，解决了大数据分析领域的一个非常关键的问题。它让业务用户、分析员、数据科学家、开发人员及其他用户能够轻松处理复杂的分析，不需要了解底层的数据布局。” Ignite Apache软件基金会还宣布Apache Ingite成为了一个顶级项目。这个开源项目旨在构建一种内存中数据架构（in-memory data fabric）。 据Apache社区的成员声称：“Apache Ignite是一种高性能、集成、分布式的内存中数据架构，针对大规模数据集可实现实时计算和处理，速度比基于磁盘或闪存的传统技术要快几个数量级。它旨在可以轻松支持成本合理、基于行业标准的硬件上的分布式大规模并行架构中的新旧应用程序。” Brooklyn Apache软件基金会宣布，Apache Brooklyn现在是个顶级项目（TLP），“这标志着该项目的社区和产品已在该基金会的精英管理流程和原则下得到了妥善治理。”Brooklyn是一种应用程序蓝图和管理平台，用于跨多个数据中心集成服务，并集成云端的众多软件。 据Brooklyn宣布声称：“由于现代应用程序由许多组件构成，微服务架构日前受到关注，部署应用程序和已部署应用程序的日常改进成了一个越来越难的问题。Apache Brooklyn的蓝图提供了一种清晰简洁的方式，可以在部署到公共云或私有基础设施之前，明确应用程序、组件、配置以及组件之间的关系。基于策略的管理建立在自主计算理论这个基础上，不断评估运行中的应用程序，并对它进行改动，让应用程序保持顺畅运行，并且针对成本和响应能力等度量指标进行优化。” Brooklyn现用于一些知名企业组织。云服务提供商Canopy和Virtustream已开发了基于Brooklyn的产品。IBM也广泛使用Apache Brooklyn，以便将大量的工作负载从AWS迁移到IBM Softlayer。 Apex 今年4月份，Apache软件基金会将Apex项目提升为顶级项目。它号称是“面向Apache Hadoop生态系统的一种大规模、高吞吐量、低延时、容错、统一的大数据数据流和批量处理平台。”Apex可与Apache Hadoop YARN协同运行，后者是一种适用于Hadoop集群的资源管理平台。 Tajo 最后，Apache Tajo是需要了解的另一个新的大数据项目，这是Apache Hadoop中一个先进的开源数据仓库系统。Apache声称，Tajo为Hadoop部署系统、第三方数据库和商用商业智能工具提供了快速获取更多信息的功能。 很显然，虽然Apache Spark吸引了大量眼球，但它不是Apache提供的唯一引人注目的大数据工具。今年，Apache可能会将更引人注目的大数据项目提升为顶级项目，这些项目将得益于经过优化的开发资源及更多优势。 原文标题：On the Rise: Six Unsung Apache Big Data Projects   from:http://developer.51cto.com/art/201606/513276.htm

关于redis、memcached、mongoDB 的对比

从以下几个维度，对redis、memcached、mongoDB 做了对比，欢迎拍砖 1、性能 都比较高，性能对我们来说应该都不是瓶颈 总体来讲，TPS方面redis和memcached差不多，要大于mongodb 2、操作的便利性       memcached数据结构单一       redis丰富一些，数据操作方面，redis更好一些，较少的网络IO次数        mongodb支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富 3、内存空间的大小和数据量的大小        redis在2.0版本后增加了自己的VM特性，突破物理内存的限制；可以对key value设置过期时间（类似memcache）        memcached可以修改最大可用内存,采用LRU算法        mongoDB适合大数据量的存储，依赖操作系统VM做内存管理，吃内存也比较厉害，服务不要和别的服务在一起 4、可用性（单点问题） 对于单点问题，              redis，依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制，因性能和效率问题， 所以单点问题比较复杂；不支持自动sharding,需要依赖程序设定一致hash 机制。 一种替代方案是，不用redis本身的复制机制，采用自己做主动复制（多份存储），或者改成增量复制的方式（需要自己实现），一致性问题和性能的权衡              Memcached本身没有数据冗余机制，也没必要；对于故障预防，采用依赖成熟的hash或者环状的算法，解决单点故障引起的抖动问题。              mongoDB支持master-slave,replicaset（内部采用paxos选举算法，自动故障恢复）,auto sharding机制，对客户端屏蔽了故障转移和切分机制。 5、可靠性（持久化） 对于数据持久化和数据恢复，          redis支持（快照、AOF）：依赖快照进行持久化，aof增强了可靠性的同时，对性能有所影响           memcached不支持，通常用在做缓存,提升性能；           MongoDB从1.8版本开始采用binlog方式支持持久化的可靠性 6、数据一致性（事务支持）          Memcached 在并发场景下，用cas保证一致性         redis事务支持比较弱，只能保证事务中的每个操作连续执行         mongoDB不支持事务 7、数据分析          mongoDB内置了数据分析的功能(mapreduce),其他不支持 8、应用场景         redis：数据量较小的高性能操作和运算上         memcached：用于在动态系统中减少数据库负载，提升性能;做缓存，提高性能（适合读多写少，对于数据量比较大，可以采用sharding）         MongoDB:主要解决海量数据的访问效率问题 from:http://blog.csdn.net/yangbutao/article/details/7437290

通C#访问MongoDB数据

开始： 先下载个C#的驱动。MongoDB提供各种主流与非主流预言的开发驱动。 C# Driver 下载地址：猛击这里 CSharp Driver Tutorial：猛击这里 下载文件安装或者解压缩包 如果您是安装，请到安装位置寻找，如果是ZIP压缩包，解压缩包得到如下两个文件： MongoDB.Bson.dll              ：序列化、Json相关 MongoDB.Driver.dll             ：我们的驱动 没了，只有这两个文件是我们的最爱。   继续： 新建一个C#的项目，不管你是vs2008，还是vs2010，也许您手中有vs2012？也发给我一份吧。感谢共享：） 添加引用，将上面两个DLL引入到项目里面   您启动Mongod.exe了吗？启动服务。   代码里面添加命名空间： using MongoDB.Bson; using MongoDB.Driver; 跟着[CSharp Driver Tutorial：猛击这里]继续做。如果您没有打开[CSharp Driver Tutorial]就不要开了，看完全文再看，以免分散精力。 //  MongoDB连接串，以[mongodb: // ]开头。这里，我们连接的是本机的服务 string  connectionString  =   " mongodb://localhost " ; //  连接到一个MongoServer上 MongoServer server  =  MongoServer.Create(connectionString); MongoDb的连接串 在连接串中，我们可以指定其他机器上的服务和连接端口格式如下： mongodb://[username:password@]hostname[:port][/[database][?options]] 简单示例：mongodb://server1,server2:27017,server2:27018 更进一步详细的信息请查看[CSharp Driver Tutorial：猛击这里] MongoServer 有几种不同的重载了的创建方式： MongoServer Create()   如果只是连接本机，并且本机只启动了一个服务，直接调用这个方法，完全不需要连接串 MongoServer Create(MongoConnectionStringBuilder builder) MongoServer Create(MongoUrl url) MongoServer Create(string connectionString) MongoServer Create(Uri uri) 更进一步详细的信息请查看[CSharp Driver Tutorial：猛击这里] 继续： 再增加几行代码： //  MongoDB连接串，以[mongodb: // ]开头。这里，我们连接的是本机的服务 string  connectionString  =   " mongodb://localhost " ; //  连接到一个MongoServer上 MongoServer server  =  MongoServer.Create(connectionString); //  ————————————————————————- //  打开数据库testdb MongoDatabase db  =  server.GetDatabase( " testdb " ); //  获取集合employees MongoCollection collection  =  db.GetCollection( " employees " ); server.GetDatabase("testdb") 打开数据库：testdb 我没有testdb库啊？？不要担心，不要疑惑，不要在这个问题上浪费时间，如果没有这个库存在，MongoDB会自动替你创建它的 db.GetCollection("employees") 获取集合：employees 好吧有了前一个教训，管他呢，爱存在不存在，MongoDB的开发人员都会替我们创建吧？ 继续： //  MongoDB连接串，以[mongodb: // ]开头。这里，我们连接的是本机的服务 string  connectionString  =   " mongodb://localhost " ; //  连接到一个MongoServer上 MongoServer server  =  MongoServer.Create(connectionString); //  ————————————————————————- //  打开数据库testdb MongoDatabase db  =  server.GetDatabase( " testdb " ); //  获取集合employees MongoCollection collection  =  db.GetCollection( " employees " ); //  ————————————————————————- //  创建一个employee BsonDocument employee  =   new  BsonDocument { {  " name " ,  " Ernest Hemingway "  }, {  " title " ,  " For Whom the Bell Tolls "  } }; //  把它写到上面那个集合里面去 collection.Insert(employee); 如果您的程序没有抛出任何异常，那么数据已经进去了。不知到BsonDocument是个啥东西？ 看个简单的例子吧： BsonDocument document = new BsonDocument { { "name", name }, { "city", city }, // not added if city is null         { "dob", dob, dobAvailable } // not added if dobAvailable is false     }; 它以键值对的方式、JSON的格式，保存数据。MongoDB通过BsonDocument套BsonDocument的方式，使您可以存储复杂格式的数据。 有一些重要的概念，看完文章以后，你一定要去过一遍：BsonType、BsonValue、BsonElement、BsonDocument、MongoServer、MongoDatabase、MongoCollection 在这里： [CSharp Driver Tutorial：猛击这里] 继续： 最后几行小代码： //  ————————————————————————- //  查询上面那个刚刚插进去的数据，就这格式了，看看QueryDocument的文档吧 var query  =   new  QueryDocument( " name " ,  " Ernest Hemingway " ); //  遍历结果 foreach  (BsonDocument emp  in  collection.Find(query)) { //  BsonValue有两种取值方式，下面两个都用了一个是AsXXX,一个是ToXXX Console.WriteLine( " name:{0}\ttitle:{1} " , emp[ " name " ].AsString, emp[ " title " ].ToString()); } QueryDocument MongoCollection books; var query = Query.And( Query.EQ( "author",  "Kurt Vonnegut"), Query.EQ( "title",  "Cats Craddle") ); 不解释了，查询的各种细节用法看各种文档吧（因为我还没看呢，解释不了，呵呵）。作为第一步，这里知道有这个东西，量和细节的积累在不断的实践中获得。[CSharp Driver Tutorial：猛击这里] BsonValue 的取值 emp["name"].AsString 这是第一种取值方式。相关的有AsInt32,AsBoolean等等 emp["title"].ToString() 这是第二种取值方式。相关的有ToInt32,ToBoolean等等 请注意细节： AsXXX取值方式，如果类型不一致，可以抛出异常InvalidCastException ToXXX取值方式，不会抛出异常，会返回默认值。[CSharp Driver Tutorial：猛击这里] 至此，已经完成第一次C#程序访问MongoDB的全过程。 PS:重要概念： BsonType、BsonValue、BsonElement、BsonDocument、MongoServer、MongoDatabase、MongoCollection 一定要看。[CSharp Driver Tutorial：猛击这里]   from:http://www.open-open.com/lib/view/open1326521480843.html

关于Mongodb启动服务时1067错误的解决方法

如图：按照官网Install MongoDB on Windows（参考文尾备注）章节介绍安装完服务之后，无论是命令行net start mongodb，还是在系统服务中启动MongoDB服务，都会提示1067的错误。 网上有些说删除Mongodb数据库目录下的mongod.lock文件之后可以正常重启服务，但是笔者试了之后还是不行，也觉得删除这类文件是治标不治本或者不安全的。 仔细看了下上面链接中的文档，因为我并未按照默认的C:\路径安装Mongodb，以及在C:\下面md data文件存放数据库，而是放在了D:\MongoDB（程序目录），以及D:\DB_MongoDB（数据库目录），初步觉得问题就出在这个问题之上。         如图，在mongod.cfg文件中指定了dbpath，再启动服务，就正常了。 （不止dbpath，其它必要的配置不正确或者不完全也可能导致1067服务启动失败的情况。） 备注： 官方安装Mongodb的Windows服务说明可能在更新，一般可按照以下方法直接安装Windows服务： ? 1 D:\Program Files\MongoDB 2.6 Standard\bin>mongod --install --serviceName MongoDB --serviceDisplayName MongoDB --logpath D:\Program Files\MongoDB 2.6 Standard\log\MongoDB.Log --dbpath D:\Program Files\MongoDB 2.6 Standard\db --directoryperdb 需要注意的是，log与db目录都要事先创建。   from:http://my.oschina.net/iuranus/blog/176258

Mongodb 安装 以及 问题解决

一，下载 1.官网为：http://www.mongodb.org/ ；下载安装程序的地址为：http://www.mongodb.org/downloads ,选择选择的是Windows 32-bit 2.4.0版本。 2.下载MongoDB For .net 驱动开发包，官方的c#driver位于driver菜单下，地址为：https://github.com/mongodb/mongo-csharp-driver/downloads。这里还了解到有samus驱动下载地址：https://github.com/samus/mongodb-csharp 二，安装 1.将mongodb-win32-i386-2.4.0.zip解压到目录E:\mongodb-2.4.0，也就是把Bin目录放在该文件夹下。 2.在E:\mongodb-2.4.0创建Data文件夹，然后在该目录下分别创建db,log两个文件夹，至此E:\mongodb-2.4.0文件目录下有三个文件夹（bin,data,log）. 3.在log文件夹下创建一个日志文件log.log,即完全目录为：E:\mongodb-2.4.0\log\log.log. 4. 程序启动方式 进入bin目录，在目录上输入cmd ，回车 弹出CMD窗口 mongod -dbpath "E:\mongodb-2.4.0\data\db" 执行此命令即将mongodb的数据库文件创建到C:\Program Files\mongodb\data\db 目录。 接着将Mongodb安装成windows服务 mongod --logpath "E:\mongodb-2.4.0\log\log.log"  --logappend --dbpath "E:\mongodb-2.4.0\data\db" --directoryperdb --install 测试数据库操作 在bin目录打开 mongo.exe   >help (查看相关信息） >db.foo.insert({test:100}) （往foo表插入test,100字段值,foo表为默认表) >db.foo.find() (查看foo表数据） 结果如下： 可以看到插入了2条记录分别人set,test 其它命令可查阅help命令或官网说明。               遇到的问题解决 ——————————————-- 1. 首先，当然是下载 MongoDB MongoDB的官方网站是：http://www.mongodb.org/， 最新版本下载在：http://www.mongodb.org/downloads 。请注意下载适合自己系统的安装包，我选择的是：Windows 64-bit 2008 R2+。 下载后的文件名称是：mongodb-win32-x86_64-2008plus-ssl-3.0.1-signed.msi ，点击安装。   根据官方文档：http://docs.mongodb.org/manual/tutorial/install-mongodb-on-windows/ Starting in version 2.2, MongoDB does not support Windows XP. Please use a more recent version of Windows to use more recent releases of MongoDB. 大意是：从版本2.2开始，MongoDB不支持Windows XP。请用较新版本的Windows来使用MongoDB的最新版本。     2. 创建数据库文件的存放位置 在你安装MongoDB的bin 目录下打开cmd, 输入：mongod 回车启动服务。会看到： Hotfix KB2731284 or later update is not installed.  以及 C:\data\db not found 的字样。 这就涉及到了两个问题了。先说第2个。 MongoDB默认数据库文件夹路径为C:/data/db（注：虽然是默认，但是需要你自己创建）。但也可以自己设置默认路径，比如d:/test/data/db。启动mongodb服务之前必须创建数据库文件的存放文件夹，否则不能启动成功。使用系统默认文件夹路径时，启动服务无需加 --dbpath 参数说明。如果不是默认路径，则启动服务格式有如下两种： （1）mongod --dbpath 存放的路径。如：mongod --dbpath d:\test\data 【注：路径不能包含空格，否则使用第2种】 （2）mongod --dbpath "存放的路径" 。如 mongod --dbpath "d:\my text\data"   此处设置为默认数据库文件夹路径 [以下创建的文件与第5步骤相关]： (1)创建：C:\data\db 文件夹，以及创建 C:\data\log\mongod.log 文件。 (2)创建：C:\mongodb\mongod.cfg 文件，在该文件中输入以下文本： logpath= C:\data\log\mongod.log dbpath=C:\data\db   3.在浏览器中输入网址：http://localhost:27017/ 。如果服务启动成功会看到以下一段话：  

1
It looks like you are trying to access MongoDB over HTTP on the native driver port.

    4.回到 Hotfix KB2731284 or later update is not installed这个问题，从官方文档的另一段话： If you are running any edition of Windows Server 2008 R2 or Windows 7, please installa hotfix to resolve an issue with memory mapped files on Windows. 大意是：如果您运行的是任何版本的Windows Server 2008 R2或Windows 7，请安装修复程序来解决一个内存映射文件在Windows的问题。 你需要从：https://support.microsoft.com/zh-cn/hotfix/kbhotfix?kbnum=2731284&kbln=zh-cn 下载 Fix405791 补丁，填写 邮箱，微软会发一个补丁下载路径的邮件给你，邮件下载地址是：http://hotfixv4.microsoft.com/Windows%207/Windows%20Server2008%20R2%20SP1/sp2/Fix405791/7600/free/451413_intl_x64_zip.exe。下载完成后点击解压成 Windows6.1-KB2731284-v3-x64.msu 文件，点击该文件，会安装补丁，该过程需要重启。   5.由于每次都要打开mongodb服务，要输入那么一段cmd文字。其实可以将其添加为 服务 来启动。做法如下： 打开cmd, 输入以下文字【注意：路径需和自己的一致，参看第2步骤】：  

1
sc.exe create MongoDB binPath= "\"C:\mongodb\bin\mongod.exe\" --service --config=\"C:\mongodb\mongod.cfg\"" DisplayName= "MongoDB" start= "auto"

如无意外，会看到：CreateService 成功。打开cmd,输入 services.msc，查找 MongoDB 服务，如果能启动成功，则证明路径正确。如果不能启动，则表示 路径错误，需要删除该服务（命令为：sc delete MongoDB），然后重新添加。     官方文档为：http://docs.mongodb.org/manual/tutorial/install-mongodb-on-windows/   from:http://www.cnblogs.com/haoliansheng/p/4389911.html

MongoDB 管理

1.启动和停止MongoDB 执行mongod,启动MongoDB服务器。mongod有很多选项，在命令中执行 mongod --help 主要选项如下： --dbpath 指定数据目录，默认值是C:\data\db。每个mongod进程都需要独立的数据目录。如果要是有3个mongod 实例，那么必须有3个独立的数据目录。当mongod启动时，会在数据库目录中创建mongod.lock文件 这个文件用于防止其他的mongod纯净使用该数据目录。 --port 指定服务器监听的端口号，默认端口27017.要运行多个mongod进程，则要给每个指定不同的端口号。 --logpath 指定日志的输出路径。如果对文件夹有读写权限，系统会在文件不存在时创建它。它会将已有文件覆盖掉， 清除所有原来的日志记录。如果想要保留原来的日志，需使用--logappend选项。 --config 指定配置文件，加载命令行未指定的各种选项。   2.从配置文件启动 MongoDB支持从文件获取配置信息.当需要配置非常多或者要自动化MongoDB的启动时会用到. 指定配置文件可以用-f或--config选项. 如: mongod --config refactorConfig.txt refactorConfig.txt内容如下: #start MongoDB port = 10000 dbpath = "f:\mongo\db" logpath = "f:\mongo\log\MongoDB.txt" rest = true 配置文件和命令行的功能一样 mongod --dbpath "f:\mongo\db" --logpath "f:\mongo\log\MongoDB.txt" --rest --port 10000 配置文件的特点: a.以#开头的行是注释 b.指定选项的语法是这种"选项=值"的形式.选项是区分大小写的. c.命令行如--rest的开关选项,值要设为true   3.停止MongoDB 可以使用shutdown命令{"shutdown":1},这个命令要在admin数据库下使用.shell还提供了辅助函数: use admin db.shutdownServer()   4. 监控 使用管理接口,默认情况下,启动mongod会启动基本的http服务器,该服务的默认端口是28017.可以在浏览器中输入 localhost:28017.有些链接需要在mongod启动时,用--rest选项开启rest支持 才能进去.当开启rest支持后,可以 在mongod启动时使用--nohttpinterface来关闭管理接口.   5.serverStatus 要获取运行中的MongoDB服务器统计信息,最基本的工具是serverStatus命令 db.runCommand({"serverStatus":1}) serverStatus返回的键解释: "globalLock"的值表示全局写入锁占用了服务器多少时间(单位微秒) "mem"包含服务器内存映射了多少数据,服务器进程的虚拟内存和常驻内存的占用情况(单位MB) "indexCounters"表示B树在磁盘检索("misses")和内存检索("hits")的次数.如果这个比值开始上升,就要考虑加内存了. "backgroundFlushing"表示后台做了多少次fsync以及用了多少时间 "opcounters"文档包含了每种主要操作的次数 "asserts"统计了断言的次数   6.mongostat serverStatus虽然强大,但对服务器的监控来说不怎么容易.MongoDB提供了mongostat mongostat输出一些serverStatus提供的重要信息,它会每秒输出新的一行,比之前看到的静态数据实时性要好. 它输出多个列,分别是 inserts/s commands/s vsize 和 %locked,与serverStatus的数据相对应. 还可以使用第三方插件进行数据库的监控.   7.安全和认证 认证的基础知识 每个MongoDB实例中的数据库都可以有很多用户,如果开启了安全性检查,这只有数据库认证用户才能执行读或写操作. 在认证的上下文中,MongoDB会将普通的数据作为admin数据库处理.admin数据库中的用户被称为超级用户(管理员). 在认证后,管理员可以读写所有数据库,执行特定的管理命令,如listDatabases和shutdown. 在开启安全检查前,至少要有个管理员帐号,在shell连接的是没有开启安全检查的服务器   上面添加了管理员refactor_root,在test数据库添加了两个普通账号,其中一个有只读权限.在shell中创建只读用户只要 在addUser的第三个参数设为true.调用addUser必须有响应数据库的写权限.这里可以对所有数据库调用addUser, 因为还没有开启安全检查.   重启数据库,重启时加入 --auth 命令行选项,开启安全检查 第一次连接时,不能test数据库执行任何操作,作为只读用户认证后,能查找,不能插入数据.能读写用户认证后,能查找和插入 数据,但不能使用show dbs 来列举所有数据库.超级用户认证后,可以为所欲为了.   8.认证的工作原理 数据库的用户帐号以文档的形式存储在system.users集合里.文档的结构是 { "_id" : ObjectId("5006a037dff37e149322fd83"), "user" : "refactor_read_write", "readOnly" : false, "pwd" : "5a84584ac51d3f702461fce4c46b0d6b"//是根据用户名和密码生成的散列 } 知道了用户信息是如何存储的以及存储位置后,就可以进行日常的管理工作了. 如删除帐户: > db.system.users.remove({"user":"refactor_read"}) > db.auth("refactor_read","refactor") 0 用户认证时,服务器将认证和连接绑定来跟踪认证,也就是说如果驱动程序或是工具使用了连接池或是因故障切换到 另一个节点,所有认证用户必须对每个新连接重新认证.   MongoDB的传输协议是不加密的,如需加密,可以用ssh隧道或者类似的技术做客户端和服务器间的加密. 建议将MongoDB服务器放在防火墙或放在只有应用服务器能访问的网络中.如果MongoDB必须能被外面访问到的话, 建议使用--bindip选项,可以指定mongod绑定到的本地ip地址.如:只能从本机应用服务器访问,可以使用 mongod --bindip localhost 默认情况下MongoDB会开启一个简单的http服务器,便于查看运行,锁,复制等方面的信息,要是不想公开这些信息,可以用 --nohttpinterface来关闭管理接口. 可以用--noscripting完全禁止服务端javascript执行   9.备份和修复 MongoDB将所有数据都存放在 数据目录 下,默认目录是C:\data\db\.启动MongoDB的时候可以用--dbpath指定数据目录. 不论数据目录在哪里,它都存放着MongoDB的所有数据.要想备份MongoDB,只要简单的复制数据目录中的所有文件即可. 除非服务器做了完整的fsync,还不允许写入,否则在运行MongoDB时创建数据目录的副本并不安全,这样的备份可能已经 破损了,需要修复. 在运行MongoDB时创建数据目录的副本并不安全,所以就得先把服务器关了,再复制数据目录.但是关闭数据库就要停止业务.   10.mongodump和mongorestore mongodump是一种能在运行时备份的方法.mongodump对运行的MongoDB做查询,然后将所有查到的文档写入磁盘. 因为mongodump是一般的客户端,所以可供运行的MongoDB使用,即便是正在处理其他请求或是执行写入也没有问题. mongodump使用普通的查询机制,所以产生的备份不一定是服务器数据的实时快照.服务器在备份过程中处理写入时,非常明显. mongodump备份时的查询会对其他客户端的性能产生影响. mongodump --help 获得帮助 mongorestore是从备份中恢复数据的工具. mongorestore获取mongodump 的输出结果,并将备份的数据插入运行的MongoDB实例中. 如:将数据库test备份到backup目录 mongodump -d test -o backup 使用mongorestore 恢复到testNew 数据库 mongorestore -d testNew --drop backup/test/ -d指定要恢复的数据库.--drop指在恢复前删除集合(若存在),否则数据就会与现有集合数据合并,可能会覆盖一些文档. 可以使用mongorestore --help获得帮助信息   11.fsync和锁 虽然使用mongodump和mongorestore能不停机备份,但是却失去了获取实时数据视图的能力.MongoDB的fsync命令 能在MongoDB运行时复制数据目录还不会损坏数据. fsync命令会强制服务器将所有缓冲区写入磁盘.还可以选择上锁住址对数据库的进一步写入,知道释放锁为止.写入锁是让 fsync在备份时发挥作用的关键. 在shell中,强制执行fsync并获得写入锁: db.runCommand({"fsync":1,"lock":1}) 这时,数据目录的数据就是一致的,且为数据的实时快照.因为上了锁,可以安全的将数据目录副本作为备份.要是数据库运行在 有快照功能的文件系统上时,比如LVM,EBS,这个很有用,因为拍个数据库目录的快照很快. 备份好了,解锁: db.$cmd.sys.unlock.findOne() db.currentOp() 运行db.currentOp()是为了确保已经解锁了(初次请求解锁会花点时间) 有了fsync命令,就能非常灵活的备份,不用停掉服务器,也不用牺牲备份的实时性能.要付出的代价就是一些写入操作被 暂时阻塞了.唯一不耽误读写还能保证实时快照的备份方式就是通过从服务器备份.   12.从属备份 虽然上面的备份方式很灵活,但都没有从服务器上备份好.当复制的方式运行MongoDB,前面的提到的备份技术就不仅能用在 主服务器上,也可用在从服务器上.从服务器的数据几乎与主服务器同步.因为不太在乎从属服务器的性能或者是能不能读写, 于是就能随意选择上面的3种备份方式:关停,转存或恢复工具或fsync命令.从服务器上备份是MongoDB推荐的备份方式.   13.修复 MongoDB的存储方式不能保证磁盘上的数据还能用,因为可能有损毁.MongoDB内置的修复功能会试着恢复损坏的数据文件. 未正常停止MongoDB后应该修复数据库.修复数据库的方式很简单就是 mongod --repair 来启动服务器. 修复数据库的实际过程很简单:将所有的文档导出后马上导入,忽略无效的文档.完成后,会重建索引.数据量大的话,会花很多时间, 因为所有数据都要验证,所有索引都要重建(从MongoDB 1.8 以后版本引入了日志系统,使修复时间打打的缩短). 修复后可能会比修复前少些文档,因为损坏的文档被删除了. 修复数据库还能起到压缩数据的作用.闲置控件(如删除体积较大集合,或删除大量文档后腾出的空间)在修复后会被重新利用. 修复运行中的服务器上的数据库,要在shell用repairDatabases. use test db.repairDatabase() from:http://www.cnblogs.com/refactor/archive/2012/08/10/2597775.html

NoSQL架构实践（三） 以NoSQL为缓存

在《NoSQL架构实践》系列的前面两篇文章中，介绍了《以NoSQL为主》和《以NoSQL为辅》的架构。由于NoSQL数据库天生具有高性能、易扩展的特点，所以我们常常结合关系数据库，存储一些高性能的、海量的数据。从另外一个角度看，根据NoSQL的高性能特点，它同样适合用于缓存数据。用NoSQL缓存数据可以分为内存模式和磁盘持久化模式。 内存模式 说起内存模式缓存，我们自然就会想起大名鼎鼎的Memcached。在互联网发展过程中，Memcached曾经解救了数据库的大部分压力，做出了巨大的贡献，直到今天，它依然是缓存服务器的首选。Memcached的常见使用方式类似下面的代码： Memcached提供了相当高的读写性能，一般情况下，都足够应付应用的性能要求。但是基于内存的Memcached缓存的总数据大小受限于内存的大小。 当前如日中天、讨论得异常火热的NoSQL数据库Redis又为我们提供了功能更加强大的内存存储功能。跟Memcached比，Redis的一个key的可以存储多种数据结构Strings、Hashes、Lists、Sets、Sorted sets。Redis不但功能强大，而且它的性能完全超越大名鼎鼎的Memcached。Redis支持List、hashes等多种数据结构的功能，提供了更加易于使用的api和操作性能，比如对缓存的list数据的修改。 同样，其他一些NoSQL数据库也提供了内存存储的功能，所以也适合用来做内存缓存。比如Tokyo Tyrant就提供了内存hash数据库、内存tree数据库功能，内存tree数据可根据key的顺序进行遍历。你可以通过使用其提供的兼容Memcached协议或自定义的协议来使用。 持久化模式 虽然基于内存的缓存服务器具有高性能，低延迟的特点，但是内存成本高、内存数据易失却不容忽视。几十GB内存的服务器，在很多公司看来，还比较奢侈。所以，我们应该根据应用的特点，尽量的提高内存的利用率，降低成本。 大部分互联网应用的特点都是数据访问有热点，也就是说，只有一部分数据是被频繁访问的。如果全部都cache到内存中，无疑是对内存的浪费。 这时，我们可以利用NoSQL来做数据的缓存。其实NoSQL数据库内部也是通过内存缓存来提高性能的，通过一些比较好的算法，把热点数据进行内存cache，非热点数据存储到磁盘以节省内存占用。由于其数据库结构的简单，从磁盘获取一次数 据也比从数据库一次耗时的查询划算很多。用NoSQL数据库做缓存服务器不但具有不错的性能。而且还能够Cache比内存大的数据。 使用NoSQL来做缓存，由于其不受内存大小的限制，我们可以把一些不常访问、不怎么更新的数据也缓存起来。比如论坛、新闻的老数据、数据列表的靠后的页面，虽然用户访问不多，但是搜索引擎爬虫会访问，也可能导致系统负载上升。 如果NoSQL持久化缓存也使用类似基于内存的memcached设置过期时间的方式，那么持久化缓存就失去了意义。所以用NoSQL做缓存的过期策略最好不使用时间过期，而是数据是否被更新过，如果数据没有更新，那么就永久不过期。下面我们用代码(php)演示一种实现这种策略的方法： 场景：新闻站点的评论系统。用户对新闻页面的url进行评论，然后根据url进行查询展示。 我把上面代码演示的缓存使用方式称为基于版本的缓存。这种方式同样适用于基于内存的Memcached。它能实现缓存数据的实时性，让用户感觉不到延迟。只要用户一发表评论，该新闻的评论缓存就会失效。用户很少去评论一些过时的新闻，那么缓存就一直存在于NoSQL中，避免了爬虫访问过时新闻的评论数据而冲击数据库。 总结 目前国内的新浪微博已经在大量的使用Redis缓存数据，赶集网也在大量的使用Redis。Redis作为一些List，Hashes等数据结构的缓存，非常适合。 把NoSQL当持久化Cache使用的模式，在很多大数据量、有热点、查询非热点数据比较消耗资源的场景下比较有用。 NoSQL架构实践总结 到这里，关于NoSQL架构实践的三篇文章就结束了。NoSQL架构并不局限于我介绍的三种模式，他们之间也可以进行组合，应该根据你具体的应用场景灵活使用。不管是什么模式，都是为了解决我们的问题而出现的，所以在系统架构的时候，要问下自己，我为什么要用NoSQL；在对NoSQL架构模式选型的时候，要问下自己，我为什么要这么用NoSQL。 原文链接：http://www.cnblogs.com/sunli/archive/2011/03/31/nosql-architecture-practice_3.html 转自：http://database.51cto.com/art/201103/252469.htm

NoSQL架构实践（二）以NoSQL为主

前面一篇《NoSQL架构实践（一）以NoSQL为辅》主要介绍了以NoSQL为辅助的架构，这种架构实施起来比较简单，易于理解，由于其中也使用了传统的关系数据库，让开发者更容易控制NoSQL带来的风险。接下来我们继续深入下去，换另外一个角度，“以NoSQL为主”来架构系统。 （三）纯NoSQL架构 只使用NoSQL作为数据存储。 图 4-纯NoSQL架构 在一些数据结构、查询关系非常简单的系统中，我们可以只使用NoSQL即可以解决存储问题。这样不但可以提高性能，还非常易于扩展。手机凤凰网的前端展示系统就使用了这种方案。 在一些数据库结构经常变化，数据结构不定的系统中，就非常适合使用NoSQL来存储。比如监控系统中的监控信息的存储，可能每种类型的监控信息都不太一样。这样可以避免经常对MySQL进行表结构调整，增加字段带来的性能问题。 这种架构的缺点就是数据直接存储在NoSQL中，不能做关系数据库的复杂查询，如果由于需求变更，需要进行某些查询，可能无法满足，所以采用这种架构的时候需要确认未来是否会进行复杂关系查询以及如何应对。 非常幸运的是，有些NoSQL数据库已经具有部分关系数据库的关系查询特性，他们的功能介于key-value和关系数据库之间，却具有key-value数据库的性能，基本能满足绝大部分web 2.0网站的查询需求。比如： MongoDB就带有关系查询的功能，能解决常用的关系查询，所以也是一种非常不错的选择。下面是一些MongoDB的资料： ◆《视觉中国的NoSQL之路：从MySQL到MongoDB》◆《Choosing a non-relational database; why we migrated from MySQL to MongoDB》◆最近的一次Mongo Beijing 开发者聚会也有一部分资料。 虽然Foursquare使用MongoDB的宕机事件的出现使人对MongoDB的自动Shard提出了质疑，但是毫无疑问，MongoDB在NoSQL中，是一个优秀的数据库，其单机性能和功能确实是非常吸引人的。由于上面的例子有详细的介绍，本文就不做MongoDB的使用介绍。 Tokyo Tyrant数据库带有一个名为table的存储类型，可以对存储的数据进行关系查询和检索。一个table库类似于MySQL中的一个表。下面我们看一个小演示： 我们要存储一批用户信息，用户信息包含用户名(name),年龄(age)，email，最后访问时间(lastvisit)，地区(area)。下面为写入的演示代码：     $tt = new TokyoTyrantTable ( "127.0.0.1", 1978 );     $tt->vanish ();//清空     $id = $tt->genUid ();//获取一个自增id     //put方法提供数据写入。 put ( string $key , array $columns )；     $tt->put ( $id, array ("id" => $id, "name" => "zhangsan", "age" => 27, "email" => "zhangsan@gmail.com", "lastvisit" =>strtotime ( "2011-3-5 12:30:00" ), "area" => "北京" ) );     $id = $tt->genUid ();     $tt->put ( $id, array ("id" => $id, "name" => "lisi", "age" => 25, "email" => "lisi@126.com", "lastvisit" => strtotime( "2011-3-3 14:40:44" ), "area" => "北京" ) );     $id = $tt->genUid ();     $tt->put ( $id, array ("id" => $id, "name" => "laowang", "age" => 37, "email" => "laowang@yahoo.com", "lastvisit" =>strtotime ( "2011-3-5 08:30:12" ), "area" => "成都" ) );     $id = $tt->genUid ();     $tt->put ( $id, array ("id" => $id, "name" => "tom", "age" => 21, "email" => "tom@hotmail.com", "lastvisit" =>strtotime ( "2010-12-10 13:12:13" ), "area" => "天津" ) );     $id = $tt->genUid ();     $tt->put ( $id, array ("id" => $id, "name" => "jack", "age" => 21, "email" => "jack@gmail.com", "lastvisit" =>strtotime ( "2011-02-24 20:12:55" ), "area" => "天津" ) );     //循环打印数据库的所有数据库     $it = $tt->getIterator ();     foreach ( $it as $k => $v ) {     print_r ( $v );     }     ?>   比如我们需要查询年龄为21岁的所有用户：         $tt = new TokyoTyrantTable ( "127.0.0.1", 1978 );     $query = $tt->getQuery ();     //查询年龄为21岁的用户     $query->addCond ( “age”, TokyoTyrant::RDBQC_NUMEQ, “21” );     print_r ( $query->search () );     ?>   查询所有在2011年3月5日之后登陆的用户：         $tt = new TokyoTyrantTable ( "127.0.0.1", 1978 );     $query = $tt->getQuery ();     $query->addCond ( “lastvisit”, TokyoTyrant::RDBQC_NUMGE, strtotime ( "2011-3-5 00:00:00" ) );     print_r ( $query->search () );     ?> 从上面的示例代码可以看出，使用起来是非常简单的，甚至比SQL语句还要简单。Tokyo Tyrant的表类型存储还提供了给字段建立普通索引和倒排全文索引，大大增强了其检索功能和检索的性能。 所以，完全用NoSQL来构建部分系统，是完全可能的。配合部分带有关系查询功能的NoSQL，在开发上比MySQL数据库更加快速和高效。 （四）以NoSQL为数据源的架构 数据直接写入NoSQL，再通过NoSQL同步协议复制到其他存储。根据应用的逻辑来决定去相应的存储获取数据。 图 5 -以NoSQL为数据源 纯NoSQL的架构虽然结构简单，易于开发，但是在应付需求的变更、稳定性和可靠性上，总是给开发人员一种风险难于控制的感觉。为了降低风险，系统的功能不局限在NoSQL的简单功能上，我们可以使用以NoSQL为数据源的架构。 在这种架构中，应用程序只负责把数据直接写入到NoSQL数据库就OK，然后通过NoSQL的复制协议，把NoSQL数据的每次写入，更新，删除操作都复制到MySQL数据库中。同 时，也可以通过复制协议把数据同步复制到全文检索实现强大的检索功能。在海量数据下面，我们也可以根据不同的规则，把数据同步复制到设计好的分表分库的 MySQL中。这种架构：◆非常灵活。可以非常方便的在线上系统运行过程中进行数据的调整，比如调整分库分表的规则、要添加一种新的存储类型等等。◆操作简单。只需要写入NoSQL数据库源，应用程序就不用管了。需要增加存储类型或者调整存储规则的时候，只需要增加同步的数据存储，调整同步规则即可，无需更改应用程序的代码。◆性能高。数据的写入和更新直接操作NoSQL，实现了写的高性能。而通过同步协议，把数据复制到各种适合查询类型的存储中（按照业务逻辑区分不同的存储），能实现查询的高性能，不像以前MySQL一种数据库就全包了。或者就一个表负责跟这个表相关的所有的查询，现在可以把一个表的数据复制到各种存储，让各种存储用自己的长处来对外服务。◆易扩展。开发人员只需要关心写入NoSQL数据库。数据的扩展可以方便的在后端由复制协议根据规则来完成。 这种架构需要考虑数据复制的延迟问题，这跟使用MySQL的master-salve模式的延迟问题是一样的，解决方法也一样。 在这种以NoSQL为数据源的架构中，最核心的就是NoSQL数据库的复制功能的实现。而当前的几乎所有的NoSQL都没有提供比较易于使用的复制接口来完成这种架构，对NoSQL进行复制协议的二次开发，需要更高的技术水平，所以这种架构看起来很好，但是却不是非常容易实现的。我的开源项目PHPBuffer中有个实现TokyoTyrant复制的例子，虽然是PHP版本的，但是很容易就可以翻译成其他语言。通过这个例子的代码，可以实现从Tokyo Tyrant实时的复制数据到其他系统中。 总结 以NoSQL为主的架构应该算是对NoSQL的一种深度应用，整个系统的架构以及代码都不是很复杂，但是却需要一定的NoSQL使用经验才行。 转自：http://database.51cto.com/art/201103/248952.htm

NoSQL架构实践（一）以NoSQL为辅

经常有朋友遇到困惑，看到NoSQL的介绍，觉得很好，但是却不知道如何正式用到自己的项目中。很大的原因就是思维固定在MySQL中了，他们问得最多的问题就是用了NoSQL，我如何做关系查询。那么接下来，我们看下怎么样在我们的系统中使用NoSQL。 怎么样把NoSQL引入到我们的系统架构设计中，需要根据我们系统的业务场景来分析，什么样类型的数据适合存储在NoSQL数据库中，什么样类型的数据必须使用关系数据库存储。明确引入的NoSQL数据库带给系统的作用，它能解决什么问题，以及可能带来的新的问题。下面我们分析几种常见的NoSQL架构。 （一）NoSQL作为镜像 不改变原有的以MySQL作为存储的架构，使用NoSQL作为辅助镜像存储，用NoSQL的优势辅助提升性能。 图 1 -NoSQL为镜像（代码完成模式 ） //写入数据的示例伪代码   //data为我们要存储的数据对象   data.title=”title”;   data.name=”name”;   data.time=”2009-12-01 10:10:01”;   data.from=”1”;   id=DB.Insert(data);   //写入MySQL数据库   NoSQL.Add(id,data);   //以写入MySQL产生的自增id为主键写入NoSQL数据库 如果有数据一致性要求，可以像如下的方式使用 //写入数据的示例伪代码   //data为我们要存储的数据对象   bool status=false; DB.startTransaction();   //开始事务   id=DB.Insert(data);   //写入MySQL数据库   if(id>0){       status=NoSQL.Add(id,data);   //以写入MySQL产生的自增id为主键写入NoSQL数据库   }   if(id>0 && status==true){       DB.commit();   //提交事务   }else{       DB.rollback();   //不成功，进行回滚   } 上面的代码看起来可能觉得有点麻烦，但是只需要在DB类或者ORM层做一个统一的封装，就能实现重用了，其他代码都不用做任何的修改。 这种架构在原有基于MySQL数据库的架构上增加了一层辅助的NoSQL存储，代码量不大，技术难度小，却在可扩展性和性能上起到了非常大的作用。只需要程序在写入MySQL数据库后，同时写入到NoSQL数据库，让MySQL和NoSQL拥有相同的镜像数据，在某些可以根据主键查询的地方，使用高效的NoSQL数据库查询，这样就节省了MySQL的查询，用NoSQL的高性能来抵挡这些查询。 图 2 -NoSQL为镜像（同步模式） 这种不通过程序代码，而是通过MySQL把数据同步到NoSQL中，这种模式是上面一种的变体，是一种对写入透明但是具有更高技术难度一种模式。这种模式适用于现有的比较复杂的老系统，通过修改代码不易实现，可能引起新的问题。同时也适用于需要把数据同步到多种类型的存储中。 MySQL到NoSQL同步的实现可以使用MySQL UDF函数，MySQL binlog的解析来实现。可以利用现有的开源项目来实现，比如： ◆MySQL memcached UDFs：从通过UDF操作Memcached协议。◆国内张宴开源的mysql-udf-http：通过UDF操作http协议。 有了这两个MySQL UDF函数库，我们就能通过MySQL透明的处理Memcached或者Http协议，这样只要有兼容Memcached或者Http协议的NoSQL数据库，那么我们就能通过MySQL去操作以进行同步数据。再结合lib_mysqludf_json，通过UDF和MySQL触发器功能的结合，就可以实现数据的自动同步。 （二）MySQL和NoSQL组合 MySQL中只存储需要查询的小字段，NoSQL存储所有数据。 图 3 -MySQL和NoSQL组合 //写入数据的示例伪代码   //data为我们要存储的数据对象   data.title=”title”;   data.name=”name”;   data.time=”2009-12-01 10:10:01”;   data.from=”1”;   bool status=false; DB.startTransaction();   //开始事务   id=DB.Insert(“INSERT INTO table (from) VALUES(data.from)”);   //写入MySQL数据库,只写from需要where查询的字段   if(id>0){       status=NoSQL.Add(id,data);   //以写入MySQL产生的自增id为主键写入NoSQL数据库   }   if(id>0 && status==true){       DB.commit();   //提交事务   }else{       DB.rollback();   //不成功，进行回滚   } 把需要查询的字段，一般都是数字，时间等类型的小字段存储于MySQL中，根据查询建立相应的索引，其他不需要的字段，包括大文本字段都存储在NoSQL中。在查询的时候，我们先从MySQL中查询出数据的主键，然后从NoSQL中直接取出对应的数据即可。 这种架构模式把MySQL和NoSQL的作用进行了融合，各司其职，让MySQL专门负责处理擅长的关系存储，NoSQL作为数据的存储。它有以下优点： ◆节省MySQL的IO开销。由于MySQL只存储需要查询的小字段，不再负责存储大文本字段，这样就可以节省MySQL存储的空间开销，从而节省MySQL的磁盘IO。我们曾经通过这种优化，把MySQL一个40G的表缩减到几百M。◆提高MySQl Query Cache缓存命中率。我们知道query cache缓存失效是表级的，在MySQL表一旦被更新就会失效，经过这种字段的分离，更新的字段如果不是存储在MySQL中，那么对query cache就没有任何影响。而NoSQL的Cache往往都是行级别的，只对更新的记录的缓存失效。◆提升MySQL主从同步效率。由于MySQL存储空间的减小，同步的数据记录也减小了，而部分数据的更新落在NoSQL而不是MySQL，这样也减少了MySQL数据需要同步的次数。◆提高MySQL数据备份和恢复的速度。由于MySQL数据库存储的数据的减小，很容易看到数据备份和恢复的速度也将极大的提高。◆比以前更容易扩展。NoSQL天生就容易扩展。经过这种优化，MySQL性能也得到提高。 总结 以NoSQL为辅的架构还是以MySQL架构的思想为中心，只是在以前的架构上辅助增加了NoSQL来提高其性能和可扩展性。这种架构实现起来比较容易，却能取得不错的效果。如果正想在项目中引入NoSQL，或者你的以MySQL架构的系统目前正出现相关的瓶颈，希望本文可以为你带来帮助。 转自：http://database.51cto.com/art/201103/248938.htm

NoSQL

NoSQL，指的是非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。 NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。 计算机体系结构在数据存储方面要求具备庞大的水平扩展性①，而NoSQL致力于改变这一现状。Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。 NoSQL项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：它们可以处理超大量的数据。 这场革命仍然需要等待。的确，NoSQL对大型企业来说还不是主流，但是，一两年之后很可能就会变个样子。在NoSQL运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。分享他们如何推翻缓慢而昂贵的关系数据库的暴政的经验，怎样使用更有效和更便宜的方法来管理数据。 “关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足RDBMS （relational database management system，关系型数据库管理系统）的需要，”在NoSQL拥护者们看来，基于NoSQL的替代方案“只是给你所需要的”。 水平扩展性(horizontal scalability)指能够连接多个软硬件的特性,这样可以将多个服务器从逻辑上看成一个实体。