大家好，感谢邀请，今天来为大家分享一下为什么不适合直接采用关系型数据库对空间数据进行管理的问题，以及和为什么不建议用nosql的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！
本文目录
什么情况下必须用Redis，而不能使用其他数据库
首先，你一定知道redis是单线程的NoSQL落地产品。既然是NOSQL肯定是可以做一些数据库的事情，但在这个之外，它可以有高效进行内存缓存。明白点就是将数据存放于内存中而不是每次都从数据库的存储文件上面捣腾。这样速度就可以很快。
既然是基于内存进行缓存，那必然有一点不能放太大太多的数据，所以第一点，我们一定放一些实用性较高，命中率较高的数据。这样不至于占着茅坑不拉屎。所以，结合起来就是，需要查询的存储数据比较多，而每次几乎只查这么多数据中的其中一小部分经常使用的数据时，就用他了！
第二点，既然是单线程！那么你怕啥？你想到啥？高并发环境呀！对！针对一些高并发的数据排队，任务执行时候，可以通过Redis进行分布式锁的控制。
第三点，还有啥？太多了！可以做订阅发布，服务注册……
但是！我们公司和支付宝等大企业很多架构师明确提出，中间件的就应该做自己该做的事情！Redis其实开发的初衷就是缓存储缓存！其他功能都是对它的扩展和包装！不建议使用！就把它当成一个分布式缓存中间件来用吧！其他扩展功能都有对应的其他中间件。
不越俎代庖，不推诿避任！它就是一个缓存中间件。
感谢指导，相互指正学习！
Java后端学什么NoSQL数据库比较好
推荐内存数据库redis，应用场景比较多。
1.作为缓存
可以取代memcached，同时可以方便的对缓存进行可视化管理
2.持久化session存储
解决分布式session一致性问题
3.实时排序
实时排序，如直播房间内的榜单排序
4.分布式锁
高并发下的分布式锁，如抽奖、秒杀场景
5.异步消息，也叫pub/sub
作为消息发布订阅的管道，处理异步消息，支持多订阅者并发处理
6.内存数据库
如直播房间要支持百万用户在线，单机连接数无法支撑时，可把实时数据放在redis中，redis有很多的数据结构，可方便对数据进行管理。
为什么不适合直接采用关系型数据库对空间数据进行管理
什么是NoSQL?
NoSQL，指的是非关系型的数据库。NoSQL有时也称作NotOnlySQL的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称。
NoSQL用于超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。
为什么使用NoSQL?
今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了,NoSQL数据库的发展也却能很好的处理这些大的数据。
百度都用哪些nosql
NoSQL，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。NoSQL(NoSQL=NotOnlySQL)，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。NoSQL数据库的四大分类：键值(Key-Value)存储数据库这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value模型对于IT系统来说的优势在于简单、易部署。但是如果DBA只对部分值进行查询或更新的时候，Key/value就显得效率低下了。举例如：TokyoCabinet/Tyrant,Redis,Voldemort,OracleBDB.列存储数据库。这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra,HBase,Riak.文档型数据库文档型数据库的灵感是来自于LotusNotes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB,MongoDb.国内也有文档型数据库SequoiaDB，已经开源。图形(Graph)数据库图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。许多NoSQL数据库都有REST式的数据接口或者查询API。如：Neo4J,InfoGrid,InfiniteGraph.因此，我们总结NoSQL数据库在以下的这几种情况下比较适用：1、数据模型比较简单；2、需要灵活性更强的IT系统；3、对数据库性能要求较高；4、不需要高度的数据一致性；5、对于给定key，比较容易映射复杂值的环境。NoSQL数据库的四大分类表格分析分类Examples举例典型应用场景数据模型优点缺点键值（key-value）TokyoCabinet/Tyrant,Redis,Voldemort,OracleBDB内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。Key指向Value的键值对，通常用hashtable来实现查找速度快数据无结构化，通常只被当作字符串或者二进制数据列存储数据库Cassandra,HBase,Riak分布式的文件系统以列簇式存储，将同一列数据存在一起查找速度快，可扩展性强，更容易进行分布式扩展功能相对局限文档型数据库CouchDB,MongoDbWeb应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）Key-Value对应的键值对，Value为结构化数据数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义表结构查询性能不高，而且缺乏统一的查询语法。图形(Graph)数据库Neo4J,InfoGrid,InfiniteGraph社交网络，推荐系统等。专注于构建关系图谱图结构利用图结构相关算法。比如最短路径寻址，N度关系查找等很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。
关于为什么不适合直接采用关系型数据库对空间数据进行管理和为什么不建议用nosql的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。