对象存储替代nosql,对象存储替代hdfs实战

什么是nosql

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与关系型数据库设计理念比较

关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。而非关系型数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。

Hive有哪些支持者和替代品？

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的替代语言。

ssdb、minio性能测试c

项目上需要找一个硬盘型的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 在极端情况下的不稳定。

NoSQL 数据库和对象云存储的区别

1、使用冗余，每个人的好友信息都在数据库中有存储，就是你说的记录一对一关系

2、数据缓存到内存，数据访问很快

3、状态信息修改异步，比如一个人登陆了，他的好友不是马上就知道，中间间隔几秒也没有关系

4、数据可能不放在关系数据库中，可能使用nosql数据库，比如mongodb,bigtable,cassandra等

elasticsearch可以代替NoSQL吗

我们使用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数据库是什么 具有代表性以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不是万能的，但在大型项目中，你往往需要它！