189 8069 5689
nosql是not only sql的意思。是近今年新发展起来的存储系统。当前使用最多的是key-value模型，用于处理超大规模的数据。
创新互联建站长期为超过千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为奇台企业提供专业的做网站、成都网站设计，奇台网站改版等技术服务。拥有十余年丰富建站经验和众多成功案例,为您定制开发。
以下是摘自百度百科中的一部分
NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处：Hadoop、Voldemort、Dynomite，还有其它很多。
NoSQL与关系型数据库设计理念比较
关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。
Apache Hive社区项目的提交者包括Cloudera，Hortonworks，Facebook，Intel，LinkedIn，Databricks等。Hadoop发行版支持Hive。与Hbase NoSQL数据库一样，它通常作为Hadoop分布式数据处理应用程序的一部分实现。Hive可从Apache Foundation下载，也可从Hadoop分发商Cloudera，MapR和Hortonworks下载，也可作为AWS Elastic MapReduce的一部分下载。后一种实现方式支持在Simple Storage Service对象存储中的数据集分析。
Apache Hive是首次将SQL查询功能引入Hadoop生态系统的软件之一。在众多其他SQL-on-Hadoop产品中出现的是BigSQL，Drill，Hadapt，Impala和Presto。此外，Apache Pig已经成为面向Hadoop数据库的HiveQL的替代语言。
项目上需要找一个硬盘型的NoSQL，用于将 Redis 中的冷数据落入硬盘。初步选型了几款 key-value 类型的NoSQL，分别有 levelDB、 rocksDB、 TiDB、 SSDB、swapDB、 Kvrocks、Tikv 。均为基于 levelDB 开发的几款NoSQL。其中因为 levelDB、rocksDB 无网络接口，不方便做分布式和高可用。， TiDB 过重，还有 swapDB 社区不够活跃且相关client API不完备。暂时选型 SSDB 。
项目需要存储的其实是一个略长的二进制字符串，初步认为，使用 对象存储 方案其实也可以替代NoSQL，所以压测对象添加当前非常火的云原生对象存储 MinIO
硬件名|配置 系统| Ubuntu(基于win10 wsl版的docker启动) 内存| 16GB(实际可用6.08G) CPU| Intel i5-8400
测试项目： 1. 写50M数据100次 2. 随机读取任意key 100次（对LRU机制不友好）
写
数据导入成功！
数据序列化成功！
a 数据大小:50.99295234680176 MB
第1次写入总用时: 797 ms
第2次写入总用时: 848 ms
第3次写入总用时: 3621 ms
第4次写入总用时: 813 ms
第5次写入总用时: 1862 ms
第6次写入总用时: 838 ms
第7次写入总用时: 2235 ms
第8次写入总用时: 836 ms
第9次写入总用时: 900 ms
第10次写入总用时: 1027 ms
第11次写入总用时: 1101 ms
第12次写入总用时: 880 ms
第13次写入总用时: 1956 ms
第14次写入总用时: 866 ms
第15次写入总用时: 2422 ms
第16次写入总用时: 852 ms
第17次写入总用时: 4511 ms
第18次写入总用时: 875 ms
第19次写入总用时: 2736 ms
第20次写入总用时: 814 ms
第21次写入总用时: 7172 ms
第22次写入总用时: 891 ms
第23次写入总用时: 7820 ms
第24次写入总用时: 836 ms
第25次写入总用时: 22103 ms
第26次写入总用时: 877 ms
第27次写入总用时: 2712 ms
第28次写入总用时: 841 ms
第29次写入总用时: 1928 ms
第30次写入总用时: 916 ms
第31次写入总用时: 839 ms
第32次写入总用时: 826 ms
第33次写入总用时: 7759 ms
第34次写入总用时: 843 ms
第35次写入总用时: 10670 ms
第36次写入总用时: 843 ms
第37次写入总用时: 9361 ms
第38次写入总用时: 821 ms
第39次写入总用时: 810 ms
第40次写入总用时: 794 ms
第41次写入总用时: 13281 ms
第42次写入总用时: 833 ms
第43次写入总用时: 811 ms
第44次写入总用时: 798 ms
第45次写入总用时: 18843 ms
第46次写入总用时: 911 ms
第47次写入总用时: 9428 ms
第48次写入总用时: 898 ms
第49次写入总用时: 17582 ms
第50次写入总用时: 903 ms
第51次写入总用时: 831 ms
第52次写入总用时: 800 ms
第53次写入总用时: 14602 ms
第54次写入总用时: 827 ms
第55次写入总用时: 5898 ms
第56次写入总用时: 856 ms
第57次写入总用时: 5693 ms
第58次写入总用时: 1050 ms
第59次写入总用时: 882 ms
第60次写入总用时: 1020 ms
第61次写入总用时: 15060 ms
第62次写入总用时: 902 ms
第63次写入总用时: 1062 ms
第64次写入总用时: 915 ms
第65次写入总用时: 7572 ms
第66次写入总用时: 823 ms
第67次写入总用时: 9649 ms
第68次写入总用时: 832 ms
第69次写入总用时: 10403 ms
第70次写入总用时: 907 ms
第71次写入总用时: 978 ms
第72次写入总用时: 789 ms
第73次写入总用时: 2111 ms
第74次写入总用时: 947 ms
第75次写入总用时: 4675 ms
第76次写入总用时: 944 ms
第77次写入总用时: 8592 ms
第78次写入总用时: 832 ms
第79次写入总用时: 2940 ms
第80次写入总用时: 842 ms
第81次写入总用时: 19835 ms
第82次写入总用时: 862 ms
第83次写入总用时: 7646 ms
第84次写入总用时: 873 ms
第85次写入总用时: 1002 ms
第86次写入总用时: 842 ms
第87次写入总用时: 9057 ms
第88次写入总用时: 801 ms
第89次写入总用时: 5117 ms
第90次写入总用时: 918 ms
第91次写入总用时: 798 ms
第92次写入总用时: 853 ms
第93次写入总用时: 7728 ms
第94次写入总用时: 810 ms
第95次写入总用时: 3969 ms
第96次写入总用时: 814 ms
第97次写入总用时: 2050 ms
第98次写入总用时: 819 ms
第99次写入总用时: 9566 ms
第100次写入总用时: 833 ms/pre
随机读
第1次读取 15总用时: 2251 ms
第2次读取 73总用时: 2045 ms
第3次读取 98总用时: 1548 ms
第4次读取 20总用时: 2683 ms
第5次读取 46总用时: 1156 ms
第6次读取 69总用时: 1160 ms
第7次读取 46总用时: 1520 ms
第8次读取 51总用时: 1381 ms
第9次读取 48总用时: 1000 ms
第10次读取 69总用时: 1400 ms
第11次读取 82总用时: 1236 ms
第12次读取 22总用时: 1140 ms
第13次读取 36总用时: 864 ms
第14次读取 66总用时: 843 ms
第15次读取 47总用时: 922 ms
第16次读取 17总用时: 885 ms
第17次读取 14总用时: 864 ms
第18次读取 64总用时: 888 ms
第19次读取 74总用时: 815 ms
第20次读取 33总用时: 866 ms
第21次读取 36总用时: 822 ms
第22次读取 78总用时: 975 ms
第23次读取 40总用时: 1186 ms
第24次读取 54总用时: 857 ms
第25次读取 92总用时: 963 ms
第26次读取 43总用时: 955 ms
第27次读取 38总用时: 853 ms
第28次读取 47总用时: 926 ms
第29次读取 62总用时: 877 ms
第30次读取 70总用时: 890 ms
第31次读取 88总用时: 895 ms
第32次读取 15总用时: 937 ms
第33次读取 3总用时: 993 ms
第34次读取 99总用时: 892 ms
第35次读取 76总用时: 818 ms
第36次读取 30总用时: 1020 ms
第37次读取 89总用时: 863 ms
第38次读取 99总用时: 819 ms
第39次读取 62总用时: 818 ms
第40次读取 1总用时: 871 ms
第41次读取 66总用时: 809 ms
第42次读取 68总用时: 847 ms
第43次读取 72总用时: 910 ms
第44次读取 50总用时: 1128 ms
第45次读取 47总用时: 898 ms
第46次读取 26总用时: 909 ms
第47次读取 35总用时: 872 ms
第48次读取 30总用时: 826 ms
第49次读取 79总用时: 904 ms
第50次读取 66总用时: 863 ms
第51次读取 2总用时: 885 ms
第52次读取 65总用时: 900 ms
第53次读取 67总用时: 1023 ms
第54次读取 16总用时: 934 ms
第55次读取 63总用时: 892 ms
第56次读取 9总用时: 894 ms
第57次读取 71总用时: 896 ms
第58次读取 20总用时: 947 ms
第59次读取 89总用时: 865 ms
第60次读取 57总用时: 872 ms
第61次读取 62总用时: 856 ms
第62次读取 14总用时: 881 ms
第63次读取 19总用时: 950 ms
第64次读取 14总用时: 876 ms
第65次读取 86总用时: 968 ms
第66次读取 12总用时: 911 ms
第67次读取 93总用时: 877 ms
第68次读取 59总用时: 886 ms
第69次读取 79总用时: 878 ms
第70次读取 49总用时: 869 ms
第71次读取 91总用时: 964 ms
第72次读取 38总用时: 838 ms
第73次读取 73总用时: 915 ms
第74次读取 8总用时: 875 ms
第75次读取 96总用时: 827 ms
第76次读取 98总用时: 826 ms
第77次读取 95总用时: 892 ms
第78次读取 36总用时: 843 ms
第79次读取 44总用时: 872 ms
第80次读取 89总用时: 863 ms
第81次读取 24总用时: 883 ms
第82次读取 89总用时: 804 ms
第83次读取 49总用时: 876 ms
第84次读取 81总用时: 873 ms
第85次读取 72总用时: 914 ms
第86次读取 68总用时: 861 ms
第87次读取 73总用时: 893 ms
第88次读取 4总用时: 880 ms
第89次读取 3总用时: 987 ms
第90次读取 76总用时: 896 ms
第91次读取 16总用时: 1010 ms
第92次读取 73总用时: 903 ms
第93次读取 83总用时: 933 ms
第94次读取 52总用时: 945 ms
第95次读取 48总用时: 901 ms
第96次读取 26总用时: 942 ms
第97次读取 37总用时: 883 ms
第98次读取 44总用时: 866 ms
第99次读取 89总用时: 921 ms
第100次读取 61总用时: 896 ms/pre
写
数据导入成功！
第1次写入总用时: 956 ms
第2次写入总用时: 912 ms
第3次写入总用时: 1241 ms
第4次写入总用时: 1564 ms
第5次写入总用时: 942 ms
第6次写入总用时: 3666 ms
第7次写入总用时: 1629 ms
第8次写入总用时: 1712 ms
第9次写入总用时: 977 ms
第10次写入总用时: 1515 ms
第11次写入总用时: 911 ms
第12次写入总用时: 1009 ms
第13次写入总用时: 1024 ms
第14次写入总用时: 1206 ms
第15次写入总用时: 984 ms
第16次写入总用时: 943 ms
第17次写入总用时: 954 ms
第18次写入总用时: 1033 ms
第19次写入总用时: 1008 ms
第20次写入总用时: 1121 ms
第21次写入总用时: 963 ms
第22次写入总用时: 949 ms
第23次写入总用时: 889 ms
第24次写入总用时: 1066 ms
第25次写入总用时: 1289 ms
第26次写入总用时: 1125 ms
第27次写入总用时: 1111 ms
第28次写入总用时: 953 ms
第29次写入总用时: 964 ms
第30次写入总用时: 1125 ms
第31次写入总用时: 998 ms
第32次写入总用时: 1993 ms
第33次写入总用时: 926 ms
第34次写入总用时: 920 ms
第35次写入总用时: 926 ms
第36次写入总用时: 1169 ms
第37次写入总用时: 1325 ms
第38次写入总用时: 1170 ms
第39次写入总用时: 1074 ms
第40次写入总用时: 1011 ms
第41次写入总用时: 931 ms
第42次写入总用时: 984 ms
第43次写入总用时: 1563 ms
第44次写入总用时: 905 ms
第45次写入总用时: 944 ms
第46次写入总用时: 1147 ms
第47次写入总用时: 1429 ms
第48次写入总用时: 934 ms
第49次写入总用时: 1133 ms
第50次写入总用时: 912 ms
第51次写入总用时: 953 ms
第52次写入总用时: 1127 ms
第53次写入总用时: 1065 ms
第54次写入总用时: 1323 ms
第55次写入总用时: 1003 ms
第56次写入总用时: 1489 ms
第57次写入总用时: 1377 ms
第58次写入总用时: 940 ms
第59次写入总用时: 1317 ms
第60次写入总用时: 912 ms
第61次写入总用时: 898 ms
第62次写入总用时: 934 ms
第63次写入总用时: 1005 ms
第64次写入总用时: 1729 ms
第65次写入总用时: 983 ms
第66次写入总用时: 1684 ms
第67次写入总用时: 908 ms
第68次写入总用时: 895 ms
第69次写入总用时: 1171 ms
第70次写入总用时: 1372 ms
第71次写入总用时: 1261 ms
第72次写入总用时: 1024 ms
第73次写入总用时: 1048 ms
第74次写入总用时: 904 ms
第75次写入总用时: 941 ms
第76次写入总用时: 928 ms
第77次写入总用时: 1806 ms
第78次写入总用时: 1052 ms
第79次写入总用时: 1030 ms
第80次写入总用时: 1092 ms
第81次写入总用时: 1117 ms
第82次写入总用时: 950 ms
第83次写入总用时: 933 ms
第84次写入总用时: 928 ms
第85次写入总用时: 935 ms
第86次写入总用时: 1908 ms
第87次写入总用时: 994 ms
第88次写入总用时: 1097 ms
第89次写入总用时: 930 ms
第90次写入总用时: 1052 ms
第91次写入总用时: 1119 ms
第92次写入总用时: 958 ms
第93次写入总用时: 987 ms
第94次写入总用时: 973 ms
第95次写入总用时: 2036 ms
第96次写入总用时: 891 ms
第97次写入总用时: 954 ms
第98次写入总用时: 951 ms
第99次写入总用时: 1044 ms
第100次写入总用时: 1366 ms/pre
随机读
第1次读取 46总用时: 40 ms
第2次读取 8总用时: 36 ms
第3次读取 28总用时: 26 ms
第4次读取 80总用时: 10 ms
第5次读取 77总用时: 13 ms
第6次读取 27总用时: 49 ms
第7次读取 86总用时: 20 ms
第8次读取 0总用时: 45 ms
第9次读取 54总用时: 34 ms
第10次读取 24总用时: 153 ms
第11次读取 78总用时: 29 ms
第12次读取 0总用时: 17 ms
第13次读取 91总用时: 56 ms
第14次读取 5总用时: 99 ms
第15次读取 23总用时: 138 ms
第16次读取 37总用时: 120 ms
第17次读取 40总用时: 156 ms
第18次读取 88总用时: 41 ms
第19次读取 76总用时: 32 ms
第20次读取 49总用时: 102 ms
第21次读取 20总用时: 179 ms
第22次读取 40总用时: 68 ms
第23次读取 6总用时: 215 ms
第24次读取 36总用时: 197 ms
第25次读取 37总用时: 30 ms
第26次读取 68总用时: 154 ms
第27次读取 14总用时: 314 ms
第28次读取 27总用时: 91 ms
第29次读取 51总用时: 255 ms
第30次读取 66总用时: 166 ms
第31次读取 86总用时: 140 ms
第32次读取 29总用时: 374 ms
第33次读取 96总用时: 235 ms
第34次读取 68总用时: 72 ms
第35次读取 74总用时: 264 ms
第36次读取 11总用时: 334 ms
第37次读取 55总用时: 316 ms
第38次读取 31总用时: 287 ms
第39次读取 93总用时: 233 ms
第40次读取 44总用时: 499 ms
第41次读取 26总用时: 312 ms
第42次读取 76总用时: 33 ms
第43次读取 11总用时: 31 ms
第44次读取 86总用时: 191 ms
第45次读取 96总用时: 217 ms
第46次读取 20总用时: 145 ms
第47次读取 1总用时: 772 ms
第48次读取 69总用时: 477 ms
第49次读取 9总用时: 320 ms
第50次读取 46总用时: 42 ms
第51次读取 34总用时: 823 ms
第52次读取 76总用时: 115 ms
第53次读取 62总用时: 635 ms
第54次读取 99总用时: 596 ms
第55次读取 64总用时: 657 ms
第56次读取 66总用时: 97 ms
第57次读取 18总用时: 461 ms
第58次读取 91总用时: 247 ms
第59次读取 46总用时: 147 ms
第60次读取 12总用时: 702 ms
第61次读取 79总用时: 545 ms
第62次读取 47总用时: 956 ms
第63次读取 17总用时: 853 ms
第64次读取 97总用时: 771 ms
第65次读取 74总用时: 368 ms
第66次读取 84总用时: 790 ms
第67次读取 72总用时: 866 ms
第68次读取 82总用时: 742 ms
第69次读取 93总用时: 313 ms
第70次读取 57总用时: 917 ms
第71次读取 61总用时: 1185 ms
第72次读取 66总用时: 162 ms
第73次读取 5总用时: 168 ms
第74次读取 68总用时: 275 ms
第75次读取 43总用时: 1108 ms
第76次读取 74总用时: 281 ms
第77次读取 65总用时: 955 ms
第78次读取 22总用时: 1169 ms
第79次读取 88总用时: 501 ms
第80次读取 80总用时: 1685 ms
第81次读取 92总用时: 1286 ms
第82次读取 89总用时: 1680 ms
第83次读取 30总用时: 1537 ms
第84次读取 41总用时: 1576 ms
第85次读取 2总用时: 2193 ms
第86次读取 52总用时: 1817 ms
第87次读取 8总用时: 323 ms
第88次读取 81总用时: 1409 ms
第89次读取 40总用时: 577 ms
第90次读取 88总用时: 598 ms
第91次读取 19总用时: 2324 ms
第92次读取 75总用时: 2275 ms
第93次读取 29总用时: 668 ms
第94次读取 77总用时: 2773 ms
第95次读取 62总用时: 484 ms
第96次读取 84总用时: 883 ms
第97次读取 32总用时: 2945 ms
第98次读取 44总用时: 884 ms
第99次读取 66总用时: 631 ms
第100次读取 38总用时: 2739 ms/pre
非常奇怪的是 MinIO 整体性能略优于 SSDB 但是理论上不太应该， SSDB 怎么说也是半内存半硬盘的NoSQL不应该比纯硬盘的 MinIO 性能要差，有可能是 SSDB 写到一定数据量后把本机内存写爆了，导致读写非常慢。但这变相验证了 SSDB 在极端情况下的不稳定。
1、使用冗余，每个人的好友信息都在数据库中有存储，就是你说的记录一对一关系
2、数据缓存到内存，数据访问很快
3、状态信息修改异步，比如一个人登陆了，他的好友不是马上就知道，中间间隔几秒也没有关系
4、数据可能不放在关系数据库中，可能使用nosql数据库，比如mongodb,bigtable,cassandra等
我们使用Elasticsearch存储的文档数量接近50亿（算上1份复制，接近100亿文档），总共10个数据节点和2个元数据节点（48GB内存，8核心CPU，ES使用内存达到70%），每天的文档增量大概是3000W条（速度持续增加中）。目前来看，单个文档的查询效率基本处于实时状态；对于1到2周的数据的聚合统计操作也可以在10秒之内返回结果。
但是，还有提升的空间：
1. 对于查询单条数据的应用场景来说，我们可以使用ES的路由机制，将同一索引内的具有相同特征（比如具有相同的userid）的文档全部存储于一个节点上，这样我们之后的查询都可以直接定位到这个节点上，而不用将查询广播道所有的节点上；
2. 随着数据节点的增加，适当增加分片数量，提升系统的分布水平，也可以通过分而治之的方式优化查询性能；
个人以为Elasticsearch作为内部存储来说还是不错的，效率也基本能够满足，在某些方面替代传统DB也是可以的，前提是你的业务不对操作的事性务有特殊要求；而权限管理也不用那么细，因为ES的权限这块还不完善。由于我们对ES的应用场景仅仅是在于对某段时间内的数据聚合操作，没有大量的单文档请求（比如通过userid来找到一个用户的文档，类似于NoSQL的应用场景），所以能否替代NoSQL还需要各位自己的测试。如果让我选择的话，我会尝试使用ES来替代传统的NoSQL，因为它的横向扩展机制太方便了。
在我的工作过程中，我深切体会到：经验固然是一个很重要的东西，因为它能够帮助我们少走很多弯路，但同时也应该看到经验的另一面——它会变成一个笼子，将我们闭塞其中，使我们错过一些可能更好的解决方案，关键是我们要学会尝试，接触新的世界。
什么是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不是万能的，但在大型项目中，你往往需要它！