建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块

云享专家

发帖: 23粉丝: 6

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-22 00:04:53 4148 15 楼主 显示全部楼层
【云享专家·微话题】Jaison与您探讨NoSQL技术,赢《失控》书籍

J.jpg


本期【云享专家·微话题】由云享专家 Jaison 与大家一起探讨“NoSQL技术”,希望大家能够畅所欲言。如果大家有其他任何与 NoSQL 相关的问题,也可以在本帖回复直接咨询云享专家 Jaison 

 

=======【云享专家·微话题】NoSQL技术探讨 =======

NoSQL主要泛指一些分布式的非关系型数据存储技术,这其实是一个非常广泛的定义,可以说涉及到分布式系统技术的方方面面,典型的NoSQL技术包括Apache HBase, MongoDB, Cassandra, Bigtable, DynamoDB, OpenTSDB, GeoMesa, CosmosDB, ScyllaDB, JanusGraph等等。随着人工智能、物联网、大数据、云计算以及区块链技术的不断普及,相信NoSQL技术将会发挥越来越大的价值。


今天我们希望与大家一起探讨一下NoSQL技术,下面的几个问题,希望看到大家精彩的评论:

1. NoSQL技术有哪些典型的技术特征?

2. 以某NoSQL技术为例介绍一下它在实际应用中所遇到的痛点?

3. NoSQL技术是否应该引入全文索引技术来支持更灵活的数据检索能力?

4. NoSQL技术是否需要支持SQL接口?


微话题活动:参与本次微话题讨论,有机会获得优质评论奖

活动时间:2018年7月23日-8月5日

参与方式:直接在本帖回复你关于以上4个问题的理解或评论

获奖方式:活动结束后,将由云享专家 Jaison 选取出3名优质评论奖,各送出《失控》书籍1本。

image.png


回复 举报
分享

分享文章到朋友圈

分享文章到微博

云享专家

发帖: 23粉丝: 6

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-8-14 09:09:46 来自 16# 显示全部楼层

感谢参与云享专家 Jaison 的微话题。恭喜以下3位小伙伴获得本次微话题的“优质评论奖”:

image.png

恭喜各位小伙伴,请获奖的各位小伙伴尽快把联系方式+收货地址 私信 我~~~

点赞 回复 举报

RamboZhong

发帖: 1粉丝: 0

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2018-7-23 10:00:24 沙发 显示全部楼层

1. NoSQL技术有哪些典型的技术特征?

海量数据、高并发、简单查询语句、事务性要求不高


2. 以某NoSQL技术为例介绍一下它在实际应用中所遇到的痛点?

以HBase为例,由于CAP不能同时满足,为了一致性,它牺牲了一些可用性,所以在MTTR上一直不尽如人意;

HBase依赖于Hadoop,导致其依赖的服务比较多(ZK、HDFS),所以在可靠性上更容易出问题;

HBase本身不支持SQL,专有接口需要对HBase比较深入的了解,使用成本高;

HBase本身不支持索引数据的功能(RowKey除外),在很多场景下都需要应用去构建,使用成本比较高;


3. NoSQL技术是否应该引入全文索引技术来支持更灵活的数据检索能力?

应该。HBase的使用场景应该会扩大几倍。


4. NoSQL技术是否需要支持SQL接口?

应该,可以大大减低使用成本。


点赞 回复 举报

pippo

发帖: 0粉丝: 0

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2018-7-23 10:17:47 板凳 显示全部楼层

1. NoSQL技术有哪些典型的技术特征?

海量数据、高并发、高吞吐、业务查询方式比较简单


2. 以某NoSQL技术为例介绍一下它在实际应用中所遇到的痛点?

以HBase为例

1)故障切换时间比较长

2)Meta表和用户表部署在同一节点,资源无法保障,容易导致meta访问失败

3)HMaster不支持类似HDFS Federation能力,无法提供高扩展

4)业务开发比较复杂,对于复杂查询需要进行相关schema设计来确保性能



3. NoSQL技术是否应该引入全文索引技术来支持更灵活的数据检索能力?

现在一个典型场景是HBase+Solr或者HBase+ES,从而提供更好、更灵活的查询。

如果能在HBase侧直接实现SOlr、ES相关能力,那么将会减少管理和部署成本,同时减少二次开发难度。



4. NoSQL技术是否需要支持SQL接口?

需要,从而减少NoSQL技术的门槛。


点赞 回复 举报

Arvin

发帖: 3粉丝: 0

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2018-7-23 15:39:39 地板 显示全部楼层

NoSQL技术有哪些典型的技术特征?

NoSQL作为对不同于传统的关系数据库的数据库管理系统的统称,其概念在不同时期也发生过变化。

  • 最早出现于1998年,是Carlo Strozzi开发的一个轻量、开源、不提供SQL功能的关系数据库

  • 2009年在ast.fm的Johan Oskarsson发起了一次关于分布式开源数据库的讨论,Rackspace的Eric Evans提出了NoSQL的概念为非关系型、分布式、不提供ACID的数据库设计模式

  • 2009年在亚特兰大举行的"no:sql(east)"讨论会上,NoSQL最普遍的解释是“非关联型的”,强调Key-Value Stores和文档数据库的优点,而不是单纯的反对RDBMS

而发展到现在NoSQL 概念更多是强调为 NOT Only SQL,其主要的目的就是解决传统关系型数据库无法横向扩展的问题。

NoSQL  表现出来的典型的技术特征为:

  • 分布式计算& 分布式存储  

  • 高可扩展性& 高并发

  • Scheme-less or scheme-free

  • 架构灵活, 可定义的一致性

  • 简单语义

    其在云上的发展,技术特征变得更加丰富

  • 多租户

  • 跨AZ&Region

  • 可预期性能

  • 多模式

  • SQL的支持

  • 丰富索引  

  • 计算与存储分离

以某NoSQL技术为例介绍一下它在实际应用中所遇到的痛点?

技术都存在两面性,一种技术不能解决所有的问题,都存在痛点。

HBASE:

  • 入门门槛较高(安装和易用)

  • 时延不稳定,GC卡顿

  • 故障切换时间比较长

Mongodb:

  • 故障后,rebalance 时间太长(搬迁数据)

  • 连接数受限

  • 无法大规模横向扩展

NoSQL技术是否应该引入全文索引技术来支持更灵活的数据检索能力?

   二级索引支持需要在设计之初就需要认真考虑的问题,带来的问题在于:索引数据一致问题

如果要保证二级索引的强一致,那么写入 和 数据&计算rebalance 的时候,索引sharding or resharding 带来的技术难点。

同样的引入全文索引,从客户使用角度看,灵活的数据检索能力,能够有效地查询已经存在的数据。但是用户写入的数据需要全文索引的场景是否需要NoSQL? 或者说使用需要这种解决方法?

换一种思路,当用户需要全文索引 和Nosql,我们有两种方式实现:

  • Nosql 内置全文索引

  • 外置全文倒排索引能力,全文倒排索数据存储到Nosql,外部在封装NoSql接口

两者对外展现的能力是一样的,但是技术难度是不一样的。

个人倾向外置全文倒排索引能力,内置倒排索引能力而不是全文倒排索引能力。

NoSQL技术是否需要支持SQL接口?

这个毫无疑问 ,需要支持。

自从有了Spanner各种NewSQL 茁长成长。SQL 带来的好处,就是生态好,企业级客户多,易用 ,再加上Nosql 带来的分布式能力,SQL 就是插上了翅膀




点赞1 回复 举报

建赟

发帖: 129粉丝: 9

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-23 17:40:16 5# 显示全部楼层

1. NoSQL技术有哪些典型的技术特征?

     NoSQL它主要是用来解决半结构化数据和非机构化数据的存储问题。其典型的技术特征主要分为几个特征:a、索引支持;NOSQL系统在系统层面提供对索引的支持,同时NoSQL系统的单机存储引擎是纯粹的,只需要支持基于主键的随机读取和范围查询。而关系型数据库由于需要在单机存储引擎层面支持索引,大大降低了系统的可扩展性,使得单机存储引擎的设计变得很复杂。b、并发事务处理;NOSQL系统简化了系统的设计,减少了很多操作的overhead,提高了性能。c、数据结构;关系型数据库存储引擎的数据结构是通用的动态更新的B+树。而在NoSQL系统中,比如Bigtable中采用SSTable + MemTable的数据结构,数据先写入到内存的MemTable,达到一定大小或者超过一定时间才会dump到磁盘生成SSTable文件,SSTable是只读的。如果说关系型数据库存储引擎的数据结构是一颗动态的B+树,那么SSTable就是一个排好序的有序数组。很明显,实现一个有序数据比实现一个动态B+树且包含复杂的并发控制机制要简单高效地多。d、Join操作;关系型数据库需要在存储引擎层面支持Join,而NoSQL系统一般根据应用来决定Join实现的方式。

    

2. 以某NoSQL技术为例介绍一下它在实际应用中所遇到的痛点?

     在某公安厅接触NOSQL产品以来,所发现其不足总结为:a、不提供对SQL的支持:如果不支持SQL这样的工业标准,将会对用户产生一定的学习和应用迁移成本; b、支持的特性不够丰富:现有产品所提供的功能都比较有限,大多数NoSQL数据库都不支持事务,也不像MS SQL Server和Oracle那样能提供各种附加功能,比如BI和报表等; c、现有产品的不够成熟:大多数产品都还处于初创期,和关系型数据库几十年的完善不可同日而语。

     

3. NoSQL技术是否应该引入全文索引技术来支持更灵活的数据检索能力?
     

    分布式NoSQL系统旨在提供大规模数据的高可用性,但缺乏内在的支持复杂查询的应用程序。传统的基于单一词汇倒排表的解决方案未达到良好的效果。因此,NoSQL技术可以引入全文索引技术来支持更灵活的数据检索能力。就文档型数据库在处理动态文档集时不支持多键作为主索引的缺点来说,是否可以利用一种改进的组合索引方法。通过存储组合条件的倒列表,查询驱动机制可以从最近的查询记录中自适应地存储比较受欢迎的条件组合。该方法可以降低整体的带宽消耗,只需占用较少的存储资源等额外开销,明显改善了NoSQL系统的容量和响应时间。

 

4. NoSQL技术是否需要支持SQL接口?

          

   使用NoSQL的基础架构实现SQL数据库是一个很好的解决方案。一个SQL数据库是可扩展、易管理,云就绪、高度可用的,完全建立在NoSQL的基础结构(分布式)上,但仍然提供SQL数据库的所有优势,如互操作性,定义良好的语义以及更多。这种混合结构也许不如纯粹的NoSQL的服务,但足以满足需要更稳定系统、可扩展性和云服务的80%的市场需求。这种解决办法还允许很容易地迁移现有的应用到云环境,从而保护相关组织在这些应用上所付出的巨大的投资。在我看来,构建于NoSQL基础之上的SQL数据库,可以为那些在其成长期间期望灵活、高效的客户提供最高的价值。



   


点赞1 回复 举报

aprioy

发帖: 76粉丝: 25

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-23 17:58:59 6# 显示全部楼层

顶一下下。

点赞 回复 举报

技术火炬手

发帖: 19粉丝: 1

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-23 18:22:09 7# 显示全部楼层

顶一下

点赞 回复 举报

ecstatic

发帖: 9粉丝: 4

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2018-7-24 00:15:27 8# 显示全部楼层

1. NoSQL技术有哪些典型的技术特征?

1.不需要预定义模式:不需要事先定义数据模式,预定义表结构。数据中的每条记录都可能有不同的属性和格式。当**数据时,并不需要预先定义它们的模式。

2.无共享架构:相对于将所有数据存储的存储区域网络中的全共享架构。NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能,从而提高了系统的性能。

3.弹性可扩展:可以在系统运行的时候,动态增加或者删除结点。不需要停机维护,数据可以自动迁移。

4.分区:相对于将数据存放于同一个节点,NoSQL数据库需要将数据进行分区,将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能,又能保证没有单点失效的问题。

5.异步复制:和RAID存储系统不同的是,NoSQL中的复制,往往是基于日志的异步复制。这样,数据就可以尽快地写入一个节点,而不会被网络传输引起迟延。缺点是并不总是能保证一致性,这样的方式在出现故障的时候,可能会丢失少量的数据。

6.BASE:相对于事务严格的ACID特性,NoSQL数据库保证的是BASE特性。BASE是最终一致性和软事务。

NoSQL数据库并没有一个统一的架构,两种NoSQL数据库之间的不同,甚至远远超过两种关系型数据库的不同。可以说,NoSQL各有所长,成功的NoSQL必然特别适用于某些场合或者某些应用,在这些场合中会远远胜过关系型数据库和其他的NoSQL。

2. 以某NoSQL技术为例介绍一下它在实际应用中所遇到的痛点?

Redis 是Key/Value 类数据库,追求的是速度,优点就是快。缺点是...除了快其他基本上都是短处。
Mongo 是文档类数据库,追求的是通用,优点是万金油,各种支持也比较好,缺点是,大部分性能指标在NoSQL中比较差。
还有宽表类的Cassandra也比较主流,比较适合超大规模的数据的场景。

HBase就和Hadoop结合紧密,支持HDFS储存,性能也不错,缺点就是比较复杂,不管是维护还是开发都比较困难,很多操作都需要手工鞋MapReduce。如果没有超大数据规模,使用HBase的代价就太高了。
3. NoSQL技术是否应该引入全文索引技术来支持更灵活的数据检索能力?

应该。

MySQL,虽然已经建立了索引,但是由于使用的是%a%模式匹配,很不给力,在大量并发下,数据库会挂掉

使用lucene或者其他可以提供全文索引的nosql数据库,比如tt server或MongoDB

把需要模糊查询的字段的字符串数据进行”全分词“,即把所有可能分词都枚举出来,比如abc,可以分成a,ab,abc,b,bc,c

把这些分好的term建立索引,如果使用lucene则需要建立一个分词器,能把传入的字符串分解成第2步描述的分词后建立索引,如果使用的是mongodb,则把分好的词存入一个字段并且建立索引,如果使用的tt server,那就简单了,直接建立qgram类型的索引即可,不需要自己去分词,我们最终就是使用tt server解决的问题

最终采用tt server的qgram方式实现,50多万条数据的模糊查询时间不超过15毫秒,有缓存的情况可能是0ms。

4. NoSQL技术是否需要支持SQL接口?

一般会把NoSQL和关系数据库进行结合使用,各取所长,需要使用关系特性的时候我们使用关系数据库,需要使用NoSQL特性的时候我们使用NoSQL数据库,各得其所。如果能添加sql接口,那么学习nosql成本会下降很多,也能增加很多实用的功能。


点赞1 回复 举报

带你站在云...

发帖: 0粉丝: 0

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2018-7-24 10:17:35 9# 显示全部楼层

1. NoSQL技术有哪些典型的技术特征?

1:减少操作,提供更高性能。

2:索引支持,整体更加方便化,

3:数据结构机制更加简单

4:Join操作 由之前的引擎支持更改为应用实现。

2. 以某NoSQL技术为例介绍一下它在实际应用中所遇到的痛点?

接口不丰富,成型的对接产品不多。

3. NoSQL技术是否应该引入全文索引技术来支持更灵活的数据检索能力?

应该引入,虽然现在有索引,但是说实话真的很不给力。

4. NoSQL技术是否需要支持SQL接口?

个人期望增加,这样所需要的人工、技术成本会降低很多。



点赞 回复 举报

176一路发

发帖: 0粉丝: 0

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2018-7-24 10:46:00 10# 显示全部楼层

1. NoSQL技术有哪些典型的技术特征?
    它们可以处理超大量的数据。
    它们运行在便宜的PC服务器集群上。
    PC集群扩充起来非常方便并且成本很低,避免了“sharding”操作的复杂性和成本。
    它们击碎了性能瓶颈。NoSQL的支持者称,通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间,执行速度变得更快。
易扩展
  NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。
大数据量,高性能
  NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用 Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的 Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了。
灵活的数据模型
  NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
高可用
  NoSQL在不太影响性能的情况,就可以方便的实现高可用的架构。比如Cassandra,HBase模型,通过复制模型也能实现高可用。
2. 以某NoSQL技术为例介绍一下它在实际应用中所遇到的痛点?
高并发问题,尤其是秒杀等场景。redis解决高并发问题,如商品秒杀。
导致Redis并发原因解释
正所谓只有知其然才能知其所以然,只有弄明白问题出现的原因所在,才能对症下药,寻找解决问题的良方。众所周知,Redis程序采用单线程模式进行运行(关于Redis的基础原理本文不细说,有兴趣可查阅我前期作品),作为单线程程序,Redis客户端的命令是逐条执行,也叫做One by One执行。既然是逐条命令执行,从表面上来看Redis似乎不存在高并发的问题,这一观点论也有道理,原子性的Redis命令本身也确实不存在高并发问题,这与多线程下的程序勃然不同。但是我们项目工作搭建Redis环境之后,通常都会是一组命令集合执行程序,一个请求中就包含了N个Redis执行命令,再加上多个客户端请求,命令就更多了,导致连接超时、数据混乱或错误、请求阻塞等多种问题。即总结为,产生Redis并发诱因是程序中的业务复杂度导致。
解决方式一:将Redis连接池化
    首先,Redis也归属于数据库范凑,即便它是NoSQL类型,依然为C/S结构模式。客户端每次请求都需要建立数据库连接,在多客户端请求模式下服务端与客户端连接频繁将导致系列阻塞、超时等等系列问题。学过关系型数据库的朋友也知道,关系型数据库解决方式是采用连接池方式解决多请求连接问题。同样,Redis数据库也同理,建立友好的连接数量让客户端与服务端保持一定数额的连接量,当客户端需要连接时,能直接从连接池中获取连接,然后直接访问Redis服务端。
解决方式二:执行关键读写时添加内部锁
    软件开发工程师可以在关键读写业务地方添加内部锁方式解决Redis高并发问题。常用并发锁的地方有:
    set方式;
    setnx方式;
    setnx+getset方式;
    具体的执行方式需要结合自身项目业务来实现Redis并发加锁、解锁代码,但这里提醒大家,需要对线程内容有一定熟悉了解才将该方式写的代码投入到生产环境去 ,因为锁的不合理使用会导致更大问题出现,比如死锁问题。
3. NoSQL技术是否应该引入全文索引技术来支持更灵活的数据检索能力?
我觉得还是有必要的,目前也有一部分相关的专家在研究这个问题。
随着互联网的发展,数据的增加越来越快,从海量的信息中快速地提取出用户需求的信息成为新的挑战。传统的方式已经不能完全满足现在的需求,而NoSQL却能够有效地解决这一问题。Lucene的特点以及不足可以利用NoSQL来构建全文检索系统。单纯使用 Lucene 的全文检索系统性能会随着数据的增加下降得十分明显,用 NoSQL 的全文检索系统的稳定性以及性能得到很大的提高,而不足之处在于创建索引文件的速度随着文档数量的增加也会有一定的下降,因此索引文件的创建应该避开业务高峰期。
4. NoSQL技术是否需要支持SQL接口?
在不麻烦不复杂不额外增加很多工作量的情况下,当然是有更好了,有肯定是比没有强的。毕竟相关的系统不可能只是使用nosql,肯定也会使用关系型数据库。目前来看,大多数情况下,nosql和关系型数据库可以比较好的结合在一起使用。即使没有支持sql接口也无所谓。

点赞1 回复 举报

游客

您需要登录后才可以回帖 登录 | 立即注册