NoSQL数据库有很多种，实现方式差别很大。有接近SQL查询方式的，也有纯粹的键值对查询。
创新互联建站专注于企业全网营销推广、网站重做改版、望都网站定制设计、自适应品牌网站建设、H5响应式网站、商城网站建设、集团公司官网建设、外贸网站制作、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为望都等各大城市提供网站开发制作服务。
对于K-V型数据库，比较典型的是Redis，系统提供了get、set之类的命令用于增删改查。关键是键值对的键和值怎么设计。
首先，来谈一下对数据库市场的看法，关系型数据库会一直占有主导地位。第一个原因是它的历史最久，有庞大的用户基础，根深。第二，SQL 的 query 在场景上依然是占主体的，尤其在数据分析上。 NoSQL的产生的是SQL对某些非关系为场景（KV点读)上的scalability 不好导致的。那个时候，主要问题是无法横向 scale，也就是没有分布式的支持，所以NoSQL 诞生了。而且KV， document 使用 normalized 数据结构也不利于理解和编程，所以可以看做是NoSQL 从SQL中抢了一些自己更适合的场景，所以它是在特定的时间和环境出现的一个产品。随着Distributed SQL 的出现， NoSQL 和 Distributed SQL 变得越来越像。未来几年有可能和 Distributed SQL 合并作为了一个产品类型。 NoSQL 在市场份额上不会超过或取代SQL， 在一些场景上会继续成长，尤其是用关系型数据集不好表达的，比如图。
今天 NewSQL 和 Distributed SQL 这2个名词在业界有一定的混淆。NewSQL 出现的早，可以被认为是Distributed SQL 的子集。以后还是以 Distributed SQL 为定义好。 所以你的问题其实是在 传统SQL，Distributed SQL 和 noSQL 之间如何选择。
答案是，最重要的指标是看用户的数据access的场景，和对应的数据结构。满足以下条件，更多考虑NoSQL：
数据之间没有关系，或者关系不强烈；每个row独立，row 之间不存在大规模的一对多，多对多的关系。
数据本身适合KV， 或者自我包含的hierachy关系。 比如个人profile, 完全自我contain, 人很人之间不需要query。
Access 数据的方式主要以 ID (primary key) 为主的点读，和顺序access (按顺序iterate）。
需要支持大规模的读写，低延时。
如果需要事务特性，范围限于一个或几个row, 没有关系型的事务。
使用 SQL 主要是因为 row 和 row 之间有关系； 存在一对多、多对多的关系。同时在关系的前提下，支持事务。支持table join的语法。对一致性要求高（强一致)。 Distributed SQL 提供了跨节点的分布式事务，query 等。但它是建立在牺牲性能的前提下的，延时大大价高。所以 NoSQL 是分布式+无关系，传统SQL 是 有关系+无分布式， Distributed SQL 是 分布式 + 有关系 + 性能取舍。
NewSQL 现在已经消退了，目前在国外退化为Distributed SQL原因如下：
卡耐基梅隆大学数据库教授Andy Pavlo，在文中系统地分析了NewSQL兴起到消亡的过程，给出了他认为NewSQL消亡的一些原因，比如：
1）没有开源。
2）没有拥抱公有云，在成本与技术上难与跟公有云厂商抗衡。
3）已有的关系型数据库MySQL,PostgreSQL做的不错，而且在不断改进，大部分客户数据并不多，单节点存储就能装下。
4）销售困难：客户担心切换风险，而且面临NoSQL在易用性方面的夹击。
另外，在谈到数据库发展趋势时，也提到NoSQL开始普遍支持SQL,joins和事务功能。到2021年后NewSQL概念除了中国的数据库创业公司，国外较少提了，更多地转向Distributed SQL。
NoSQL 和 关系型数据库，OLAP和OLTP的边界目前和未来会进一步模糊。市场的主要NoSQL产品开始普遍支持SQL,joins和事务功能，就我个人观点而言，NoSQL未来应该还是坚守初心——高并发，低延时，高伸缩性，对于关系型数据库擅长的 跨表Join, 跨机事务，AP等能力扩展应该谨慎些。产品选型时，最好也从这些方面多考虑些。
AWS推出了与SQL兼容的查询语言PartiQL，只要数据库查询引擎提供PartiQL支持，使用者就能以PartiQL单一查询关联式数据库的结构化资料，以及开放资料格式中的巢状资料或是半结构化资料，甚至还能用来查询NoSQL或是文件数据库中无固定结构（Schema-less）的资料。除了AWS自家的数据库服务，NoSQL数据库Couchbase Server也承诺将会支持PartiQL。
企业资料分散在关联式数据库、非关联式数据库以及资料湖泊中。高度结构化的资料，储存在SQL数据库或是资料仓储；无固定结构的资料则由键值储存、图形数据库（Graph Database）、分类帐数据库或是时间序列数据库等NoSQL数据库处理；而在资料湖泊中的资料，可能也有部分缺乏结构，或是可能为巢状或是多值结构。不同的资料类型适用于不同的使用案例，而每种类型的资料，可能都有自己的查询语言。
不同的资料储存对应不同的查询语言，当企业更换资料格式或是数据库引擎时，可能还需要跟着改变应用程式和查询语法，AWS提到，这对于资料的应用，特别是使用资料湖泊的灵活性与效率，有着很大的阻碍。为了统一不同类型数据库存取方法，AWS发布了查询语言PartiQL，这是个与SQL兼容的查询语言，可以用来查询以各种格式储存在各地的资料。
用户可以使用PartiQL来查询关联式数据库，像是在Redshift实作交易或是资料分析等应用，或对于Amazon S3资料湖泊的开放资料格式，同样能使用PartiQL对巢状资料与半结构化资料例如Amazon Ion格式进行查询，另外，PartiQL也可用于文件数据库等NoSQL数据库，查询无固定结构的资料。
AWS表示，PartiQL的出现，是为了满足自家查询和转换大量资料的需求，其提供严格的SQL兼容性，可与标准SQL混合使用，执行连接（Join）、过滤（Filtering）与聚合（Aggregation）操作，并以最小扩充支持巢状和半结构化资料，让开发者以简单且一致的方法，不需要更改查询语言，就能查询各种格式和服务的资料。
PartiQL具格式独立性与储存独立性，PartiQL语法和语义不依赖任何资料格式，无论使用者是要查询JSON、Parquet、ORC、CSV还是Ion等格式，查询语句的写法都相同，PartiQL的查询在综合逻辑类型系统上运作，才对应到不同底层的格式。而PartiQL也不相依于特定资料储存，因此适用于不同的底层资料储存。
虽然过去针对跨不同类型数据库查询的问题，已有不少解决方案，AWS指出，像是Postgres JSON同样也兼容于SQL，但是却无法良好地处理JSON巢状资料；而半结构化查询语言，虽然能良好处理巢状资料，但却无法与SQL语言兼容。AWS提到，PartiQL是第一个能够完全解决这些问题的查询语言。
目前AWS已在自家多项服务支持PartiQL，包括Amazon S3 Select、Amazon Glacier Select、Amazon Redshift Spectrum、Amazon QLDB，接下来几个月将会有更多的AWS服务支持PartiQL，Couchbase也公布将加入支持PartiQL的行列。现在PartiQL以Apache2.0授权许可开源，公开教学、规范以及参考实作，所有社群都能使用并参与贡献。
每种nosql都有自己的语法。跟t-sql类数据库的方式类似。但。不是用sql语句。而是他自身定义的读取语句
一、查看是否开启操作日志：
nosql ： db.getProfilingStatus()
返回：
{
"was": NumberInt("0"),
"slowms": NumberInt("100")
}
注：was：0表示未开启。1表示记录慢命令（默认：执行时常超过100ms）2表示记录所有命令。
二、修改was：
nosql： db.setProfilingLevel(2)
三、查看操作日志
nosql：db.system.profile.find()
