精华内容
下载资源
问答
  • 下面是一种应用场景: 1:一行关系型数据库中的数据被打散了,各个field知道属于那一个id(显然这个id不能由es自动生成,而是规定好的) 2:一行数据也不是顺序过来的,字段也是无序过来的。 3:可以从一张...

    elasticsearch有各种core-type,另外还有各种复杂结构,比如nested,child-parent等。

    array是一种常用的类型。在es中array是默认支持的,并不存在单独的一个type=array。当你插入数据带有“[]”的时候,这个field就成为array。

    一般建立索引是采用bulk+prepareindex的方式完成的,检索出需要建立索引的数据,然后index。数组的话就带上方括号。很方面。

    但是现实项目中由于各种数据模型的限制并不能直接运用上面简易的方式进行。下面是一种应用场景:

    1:一行关系型数据库中的数据被打散了,各个field知道属于那一个id(显然这个id不能由es自动生成,而是规定好的)

    2:一行数据也不是顺序过来的,字段也是无序过来的。

    3:可以从一张单独的表中获取所有id。

    现在要把以前的一行记录完整的索引起来,es中的id就采用1中描述的id,各字段作为es的field。


    显然最简单的索引方法不适用与这个应用场景,但是采用bulk的方式是肯定的,要不然效率太低。

    首先想到的是es提供的partital-update的方法,用setDoc+upsert来实现,看起来没什么问题,但是如果是array类型,问题出现了:

    The update API also support passing a partial document, which will be merged into the existing document (simple recursive merge, inner merging of objects, replacing core "keys/values" and arrays).

    会覆盖之前的数组值。。。。。。

    剩下的只能采用groovy脚本的方式的,用脚本+upsert可行么?不可行。无法适应存在多个字段是array类型的情况。比如现在field1 和 field2都是array。

    upsert中根据首个值建立array。field1的多个值过来的,能很好的完成,当时field2的多个值过来的时候,失败了。

    upsert是首次出现该id的时候执行的语句,因此 "upsert" : { "field1" = ["valu1"]}

    "script" : " if(ctx.source.field1.add(value1))".

    “params” : "value1" : "v1"

    第一个field是ok的,但是第二个field是不行的,因为直接走了script,没有走upsert(id已经存在了,无法走upsert)。

    可能想改进一下脚本:

    "script" : " if (ctx._source.containsKey(field1) {ctx._source.field1.add(value1)} else {ctx.source.field1=[value]})"

    只有第一个field走一次upsert,其余field都不走,在脚本中判断,像上边一样,如何?看上去挺好但是。。。。这样代码怎么写呢,囧,你如何控制第一个field走upsert?

    难道要先检索再判断!!!!!!还能不能愉快的一起玩耍了!!


    不过那个改进后的脚本倒是给了启示!何不直接放弃upsert!!完全用update的方式。yeah!这样逻辑就很通畅了,一个脚本就搞定!

    问题是:update要知道id才行?怎么办?我们可以先把id放到索引中啊,我们的应用场景允许我们这样做。

    怎么放?只需要在mapping中设置一个index=no的字段,给这个字段赋值用prepareindex的方式赋值即可。这样所有id都存在了,然后批量update吧!


    该应用场景下是否还有更好的解决方法呢?


    展开全文
  • LevelDB(适用于多读少场景

    万次阅读 2018-03-21 20:13:57
    LevelDB 一、LevelDB入门LevelDB是Google开源的持久化...LevelDB应用了LSM (Log Structured Merge) 策略,lsm_tree对索引变更进行延迟及批量处理,并通过一种类似于归并排序的方式高效地将更新迁移到磁盘,降低索...

    LevelDB

     

    一、LevelDB入门

    LevelDB是Google开源的持久化KV单机数据库,具有很高的随机写,顺序读/写性能,但是随机读的性能很一般,也就是说,LevelDB很适合应用在查询较少,而写很多的场景。LevelDB应用了LSM (Log Structured Merge) 策略,lsm_tree对索引变更进行延迟及批量处理,并通过一种类似于归并排序的方式高效地将更新迁移到磁盘,降低索引插入开销,关于LSM,本文在后面也会简单提及。

     

    根据Leveldb官方网站的描述,LevelDB的特点和限制如下:

    特点:
    1、key和value都是任意长度的字节数组;
    2、entry(即一条K-V记录)默认是按照key的字典顺序存储的,当然开发者也可以重载这个排序函数;
    3、提供的基本操作接口:Put()、Delete()、Get()、Batch();
    4、支持批量操作以原子操作进行;
    5、可以创建数据全景的snapshot(快照),并允许在快照中查找数据;
    6、可以通过前向(或后向)迭代器遍历数据(迭代器会隐含的创建一个snapshot);
    7、自动使用Snappy压缩数据;
    8、可移植性;

    限制:
    1、非关系型数据模型(NoSQL),不支持sql语句,也不支持索引;
    2、一次只允许一个进程访问一个特定的数据库;
    3、没有内置的C/S架构,但开发者可以使用LevelDB库自己封装一个server;

     

     python 版示例

    安装依赖

    pip install  leveldb

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    python 2.7 示例<br>>>> import leveldb
    >>> db = leveldb.LevelDB( './db' )
    >>> db.Put( 'hello' 'world' )
    >>> print db.Get( 'hello' )
    world
    >>> db.Delete( 'hello' )
    >>> db.Get( 'hello' )
    Traceback (most recent call last):
       File  "<stdin>" , line 1,  in  <module>
    KeyError
    >>>  for  in  xrange(10):
    ...   db.Put(str(i),  'string_%s'  % i)
    ...
    >>> print list(db.RangeIter(key_from =  '2' , key_to =  '5' ))
    [( '2' 'string_2' ), ( '3' 'string_3' ), ( '4' 'string_4' ), ( '5' 'string_5' )]
    >>> batch = leveldb.WriteBatch()
    >>>  for  in  xrange(1000):
    ...   db.Put(str(i),  'string_%s'  % i)
    ...
    >>> db.Write(batch, sync = True)<br><br>python 3.5 将 字符串进行编码 如  'key' .encode() , '' .decode() <br><br>用于python3 sock通信<br>

    插入数据示例

    ?
    1
    2
    3
    4
    5
    6
    7
    import leveldb
    db = leveldb.LevelDB( './db' )
    batch = leveldb.WriteBatch()
    for  in  xrange(1000000):
    ...     db.Put(str(i), 'string_%s'  % i)
    ...
    db.Write(batch,sync=True)

     

    下面生成一个目录db,里面包含若干文件:

     

     

    然后简要说下各个文件的含义:

    1、CURRENT

    2、LOG

    3、LOCK

    4、MANIFEST

     

    下图是LevelDB运行一段时间后的存储模型快照:内存中的MemTable和Immutable MemTable以及磁盘上的几种主要文件:Current文件,Manifest文件,log文件以及SSTable文件。当然,LevelDb除了这六个主要部分还有一些辅助的文件,但是以上六个文件和数据结构是LevelDb的主体构成元素。

     

    log文件、MemTable、SSTable文件都是用来存储k-v记录的,下面再说说manifest和Current文件的作用。

    SSTable中的某个文件属于特定层级,而且其存储的记录是key有序的,那么必然有文件中的最小key和最大key,这是非常重要的信息,Manifest 就记载了SSTable各个文件的管理信息,比如属于哪个Level,文件名称叫啥,最小key和最大key各自是多少。下图是Manifest所存储内容的示意:

     

    另外,在LevleDb的运行过程中,随着Compaction的进行,SSTable文件会发生变化,会有新的文件产生,老的文件被废弃,Manifest也会跟着反映这种变化,此时往往会新生成Manifest文件来记载这种变化,而Current则用来指出哪个Manifest文件才是我们关心的那个Manifest文件。

     


     

    二、读写数据

     

     

    写操作流程:

    1、顺序写入磁盘log文件;
    2、写入内存memtable(采用skiplist结构实现);
    3、写入磁盘SST文件(sorted string table files),这步是数据归档的过程(永久化存储);

     

    注意:

    • log文件的作用是是用于系统崩溃恢复而不丢失数据,假如没有Log文件,因为写入的记录刚开始是保存在内存中的,此时如果系统崩溃,内存中的数据还没有来得及Dump到磁盘,所以会丢失数据;
    • 在写memtable时,如果其达到check point(满员)的话,会将其改成immutable memtable(只读),然后等待dump到磁盘SST文件中,此时也会生成新的memtable供写入新数据;
    • memtable和sst文件中的key都是有序的,log文件的key是无序的;
    • LevelDB删除操作也是插入,只是标记Key为删除状态,真正的删除要到Compaction的时候才去做真正的操作;
    • LevelDB没有更新接口,如果需要更新某个Key的值,只需要插入一条新纪录即可;或者先删除旧记录,再插入也可;

     

     

    读操作流程:
    1、在内存中依次查找memtable、immutable memtable;
    2、如果配置了cache,查找cache;
    3、根据mainfest索引文件,在磁盘中查找SST文件;

     

     

    举个例子:我们先往levelDb里面插入一条数据 {key="www.samecity.com"  value="我们"},过了几天,samecity网站改名为:69同城,此时我们插入数据{key="www.samecity.com"  value="69同城"},同样的key,不同的value;逻辑上理解好像levelDb中只有一个存储记录,即第二个记录,但是在levelDb中很可能存在两条记录,即上面的两个记录都在levelDb中存储了,此时如果用户查询key="www.samecity.com",我们当然希望找到最新的更新记录,也就是第二个记录返回,因此,查找的顺序应该依照数据更新的新鲜度来,对于SSTable文件来说,如果同时在level L和Level L+1找到同一个key,level L的信息一定比level L+1的要新。

     

     

     


     

    三、SSTable文件

    SST文件并不是平坦的结构,而是分层组织的,这也是LevelDB名称的来源。

    SST文件的一些实现细节:

    1、每个SST文件大小上限为2MB,所以,LevelDB通常存储了大量的SST文件;
    2、SST文件由若干个4K大小的blocks组成,block也是读/写操作的最小单元;
    3、SST文件的最后一个block是一个index,指向每个data block的起始位置,以及每个block第一个entry的key值(block内的key有序存储);
    4、使用Bloom filter加速查找,只要扫描index,就可以快速找出所有可能包含指定entry的block。
    5、同一个block内的key可以共享前缀(只存储一次),这样每个key只要存储自己唯一的后缀就行了。如果block中只有部分key需要共享前缀,在这部分key与其它key之间插入"reset"标识。

     

    由log直接读取的entry会写到Level 0的SST中(最多4个文件);

    当Level 0的4个文件都存储满了,会选择其中一个文件Compact到Level 1的SST中;

    注意:Level 0的SSTable文件和其它Level的文件相比有特殊性:这个层级内的.sst文件,两个文件可能存在key重叠,比如有两个level 0的sst文件,文件A和文件B,文件A的key范围是:{bar, car},文件B的Key范围是{blue,samecity},那么很可能两个文件都存在key=”blood”的记录。对于其它Level的SSTable文件来说,则不会出现同一层级内.sst文件的key重叠现象,就是说Level L中任意两个.sst文件,那么可以保证它们的key值是不会重叠的。

     

    Log:最大4MB (可配置), 会写入Level 0;
    Level 0:最多4个SST文件,;
    Level 1:总大小不超过10MB;
    Level 2:总大小不超过100MB;
    Level 3+:总大小不超过上一个Level ×10的大小。

    比如:0 ↠ 4 SST, 1 ↠ 10M, 2 ↠ 100M, 3 ↠ 1G, 4 ↠ 10G, 5 ↠ 100G, 6 ↠ 1T, 7 ↠ 10T

     

    在读操作中,要查找一条entry,先查找log,如果没有找到,然后在Level 0中查找,如果还是没有找到,再依次往更底层的Level顺序查找;如果查找了一条不存在的entry,则要遍历一遍所有的Level才能返回"Not Found"的结果。

    在写操作中,新数据总是先插入开头的几个Level中,开头的这几个Level存储量也比较小,因此,对某条entry的修改或删除操作带来的性能影响就比较可控。

    可见,SST采取分层结构是为了最大限度减小插入新entry时的开销;

     

     

    Compaction操作

    对于LevelDb来说,写入记录操作很简单,删除记录仅仅写入一个删除标记就算完事,但是读取记录比较复杂,需要在内存以及各个层级文件中依照新鲜程度依次查找,代价很高。为了加快读取速度,levelDb采取了compaction的方式来对已有的记录进行整理压缩,通过这种方式,来删除掉一些不再有效的KV数据,减小数据规模,减少文件数量等。

    LevelDb的compaction机制和过程与Bigtable所讲述的是基本一致的,Bigtable中讲到三种类型的compaction: minor ,major和full:

    • minor Compaction,就是把memtable中的数据导出到SSTable文件中;
    • major compaction就是合并不同层级的SSTable文件;
    • full compaction就是将所有SSTable进行合并;

    LevelDb包含其中两种,minor和major。

    Minor compaction 的目的是当内存中的memtable大小到了一定值时,将内容保存到磁盘文件中,如下图:

     

    immutable memtable其实是一个SkipList,其中的记录是根据key有序排列的,遍历key并依次写入一个level 0 的新建SSTable文件中,写完后建立文件的index 数据,这样就完成了一次minor compaction。从图中也可以看出,对于被删除的记录,在minor compaction过程中并不真正删除这个记录,原因也很简单,这里只知道要删掉key记录,但是这个KV数据在哪里?那需要复杂的查找,所以在minor compaction的时候并不做删除,只是将这个key作为一个记录写入文件中,至于真正的删除操作,在以后更高层级的compaction中会去做。

    当某个level下的SSTable文件数目超过一定设置值后,levelDb会从这个level的SSTable中选择一个文件(level>0),将其和高一层级的level+1的SSTable文件合并,这就是major compaction。

    我们知道在大于0的层级中,每个SSTable文件内的Key都是由小到大有序存储的,而且不同文件之间的key范围(文件内最小key和最大key之间)不会有任何重叠。Level 0的SSTable文件有些特殊,尽管每个文件也是根据Key由小到大排列,但是因为level 0的文件是通过minor compaction直接生成的,所以任意两个level 0下的两个sstable文件可能再key范围上有重叠。所以在做major compaction的时候,对于大于level 0的层级,选择其中一个文件就行,但是对于level 0来说,指定某个文件后,本level中很可能有其他SSTable文件的key范围和这个文件有重叠,这种情况下,要找出所有有重叠的文件和level 1的文件进行合并,即level 0在进行文件选择的时候,可能会有多个文件参与major compaction。

    LevelDb在选定某个level进行compaction后,还要选择是具体哪个文件要进行compaction,比如这次是文件A进行compaction,那么下次就是在key range上紧挨着文件A的文件B进行compaction,这样每个文件都会有机会轮流和高层的level 文件进行合并。

    如果选好了level L的文件A和level L+1层的文件进行合并,那么问题又来了,应该选择level L+1哪些文件进行合并?levelDb选择L+1层中和文件A在key range上有重叠的所有文件来和文件A进行合并。也就是说,选定了level L的文件A,之后在level L+1中找到了所有需要合并的文件B,C,D…..等等。剩下的问题就是具体是如何进行major 合并的?就是说给定了一系列文件,每个文件内部是key有序的,如何对这些文件进行合并,使得新生成的文件仍然Key有序,同时抛掉哪些不再有价值的KV 数据。

     

    Major compaction的过程如下:对多个文件采用多路归并排序的方式,依次找出其中最小的Key记录,也就是对多个文件中的所有记录重新进行排序。之后采取一定的标准判断这个Key是否还需要保存,如果判断没有保存价值,那么直接抛掉,如果觉得还需要继续保存,那么就将其写入level L+1层中新生成的一个SSTable文件中。就这样对KV数据一一处理,形成了一系列新的L+1层数据文件,之前的L层文件和L+1层参与compaction 的文件数据此时已经没有意义了,所以全部删除。这样就完成了L层和L+1层文件记录的合并过程。

    那么在major compaction过程中,判断一个KV记录是否抛弃的标准是什么呢?其中一个标准是:对于某个key来说,如果在小于L层中存在这个Key,那么这个KV在major compaction过程中可以抛掉。因为我们前面分析过,对于层级低于L的文件中如果存在同一Key的记录,那么说明对于Key来说,有更新鲜的Value存在,那么过去的Value就等于没有意义了,所以可以删除。

     

     

     


     

    四、Cache

    前面讲过对于levelDb来说,读取操作如果没有在内存的memtable中找到记录,要多次进行磁盘访问操作。假设最优情况,即第一次就在level 0中最新的文件中找到了这个key,那么也需要读取2次磁盘,一次是将SSTable的文件中的index部分读入内存,这样根据这个index可以确定key是在哪个block中存储;第二次是读入这个block的内容,然后在内存中查找key对应的value。

    LevelDb中引入了两个不同的Cache:Table Cache和Block Cache。其中Block Cache是配置可选的,即在配置文件中指定是否打开这个功能。

     

    如上图,在Table Cache中,key值是SSTable的文件名称,Value部分包含两部分,一个是指向磁盘打开的SSTable文件的文件指针,这是为了方便读取内容;另外一个是指向内存中这个SSTable文件对应的Table结构指针,table结构在内存中,保存了SSTable的index内容以及用来指示block cache用的cache_id ,当然除此外还有其它一些内容。

    比如在get(key)读取操作中,如果levelDb确定了key在某个level下某个文件A的key range范围内,那么需要判断是不是文件A真的包含这个KV。此时,levelDb会首先查找Table Cache,看这个文件是否在缓存里,如果找到了,那么根据index部分就可以查找是哪个block包含这个key。如果没有在缓存中找到文件,那么打开SSTable文件,将其index部分读入内存,然后插入Cache里面,去index里面定位哪个block包含这个Key 。如果确定了文件哪个block包含这个key,那么需要读入block内容,这是第二次读取。

     

     

    Block Cache是为了加快这个过程的,其中的key是文件的cache_id加上这个block在文件中的起始位置block_offset。而value则是这个Block的内容。

    如果levelDb发现这个block在block cache中,那么可以避免读取数据,直接在cache里的block内容里面查找key的value就行,如果没找到呢?那么读入block内容并把它插入block cache中。levelDb就是这样通过两个cache来加快读取速度的。从这里可以看出,如果读取的数据局部性比较好,也就是说要读的数据大部分在cache里面都能读到,那么读取效率应该还是很高的,而如果是对key进行顺序读取效率也应该不错,因为一次读入后可以多次被复用。但是如果是随机读取,您可以推断下其效率如何。

     

     


     

    五、版本控制

    在Leveldb中,Version就代表了一个版本,它包括当前磁盘及内存中的所有文件信息。在所有的version中,只有一个是CURRENT(当前版本),其它都是历史版本。

    当执行一次compaction 或者 创建一个Iterator后,Leveldb将在当前版本基础上创建一个新版本,当前版本就变成了历史版本。

     

    VersionSet 是所有Version的集合,管理着所有存活的Version。

    VersionEdit 表示Version之间的变化,相当于delta 增量,表示有增加了多少文件,删除了文件:

    Version0 + VersionEdit --> Version1 
     
    Version0->Version1->Version2->Version3

     

    VersionEdit会保存到MANIFEST文件中,当做数据恢复时就会从MANIFEST文件中读出来重建数据。

    Leveldb的这种版本的控制,让我想到了双buffer切换,双buffer切换来自于图形学中,用于解决屏幕绘制时的闪屏问题,在服务器编程中也有用处。

    比如我们的服务器上有一个字典库,每天我们需要更新这个字典库,我们可以新开一个buffer,将新的字典库加载到这个新buffer中,等到加载完毕,将字典的指针指向新的字典库。

    Leveldb的version管理和双buffer切换类似,但是如果原version被某个iterator引用,那么这个version会一直保持,直到没有被任何一个iterator引用,此时就可以删除这个version。

     

    学习参看

    http://blog.csdn.net/qq112928/article/details/21172841

    http://www.cnblogs.com/chenny7/p/4026447.html

    http://www.cnblogs.com/haippy/archive/2011/12/04/2276064.html

    展开全文
  • 虽然是17年才发表,但这篇论文其实是很早之前的,所以用的案例比较老。 ____________________________________ 作者:胡伟峰;王玉梅;汤进;李世国 (江南大学,无锡, 214122) 摘 要:目的 研究产品交互...

    注:论文发表于《包装工程》杂志2017年第6期“工业设计”栏目。虽然是17年才发表,但这篇论文其实是很早之前写的,所以用的案例比较老。

     

    ____________________________________

    作者:胡伟峰;王玉梅;汤进;李世国

    (江南大学,无锡, 214122)

    摘 要:目的 研究产品交互设计中场景理论。方法 通过阐述交互设计各阶段中客观场景、目标场景、实际场景的含义及其应用。结论 指出了场景理论对交互设计的价值与意义,并提出了动态思维:场景设计是一个循环设计流程;主次思维:抓主要场景,统筹次要场景;拆解思维:复杂的大场景由众多小场景组成三大基于场景理论的交互设计思维。

    关键词:用户场景;交互设计;

    中图分类号:TB472 文献标识码:A

    “场景(scenarios) ”一词常见应用于戏剧领域中,指在一定的时间、空间内发生的一定的任务行动或生活画面。【1】在交互设计领域,基于场景设计(scenario-based design) 的思想最早由Carroll提出,强调将设计工作的焦点从定义系统的操作转变到描述什么人将使用该系统去完成其任务。【2】交互设计改变了设计中以物为对象的传统,直接把人类的行为作为设计对【3】人使用产品必须有一定的行为,这种行为是在一定场景下进行的, 行为的完成需要一定技术的支持,因而人、行为、场景和技术4个要素构成了所谓的交互系统。【4】场景是交互系统中极其重要的要素,研究在一定场景下的用户行为,对用户行为逻辑针对相应的场景进行规划和设计,是交互设计的重要目标。

     

    1 交互设计各阶段中场景的种类及其应用

    场景描述了关于操作者、操作者及其环境的背景信息、操作者的目的或目标、一系列活动和事件等内容,【5】这里的操作者即指的是产品的使用用户。基于场景理论的交互设计,是指在交互设计整个过程中使用场景描述的方法来具体地描述用户对产品的使用情况。如图1,交互设计各阶段可分为不同的用户场景,包括早期用户需求分析阶段的客观场景,产品交互设计阶段的目标场景以及场景验证和评估阶段的实际应用场景。


    图1 用户场景种类及其设计流程

    Fig1 User scene type and its design process

     

    1.1 客观场景

    设计师在交互设计的开始阶段,需要对用户现状及其需求进行分析。客观场景便是通过对用户现状的调查研究,从中获取有效信息进行总结和归纳出来的。客观场景的构建,最常见的调研方法是:用户现场观察法。在观察的同时,设计师可以对观察中遇到的问题进行总结和分析,通过观察后结合用户访谈等方式来补充分析用户的需求。

    比如在“快的打车”等打车类APP未投入市场之前,用户的典型客观场景可以描述为:公司职员王先生晚上6:00下班(操作者及其背景信息),需要打车回家(操作者的目标),在公司门口招揽出租车,可是一直招揽不到出租车,最终走了两公里路到附近的商场才打到了车,而且发现商场附近待揽客的出租车非常多,王先生觉得非常郁闷,为什么资源不匹配呢(操作者的一些列活动、感受等)。

     


     

    上述对用户“打车”这一客观场景的描述,是建立在对一定量“打车”用户调研的基础之上描述出的典型场景。客观场景是为了描述目标用户和客观状况而总结的,强调的不仅仅是问题点,还包括产品的目标用户描述、用户客观行为流程、用户情感表现、问题点等。设计师可以通过客观场景中分析出用户的需求,包括行为流程上的体验问题及其对应的设计机会点等。

    1.2 目标场景

    在产品交互设计阶段,需要设计师构建目标场景。目标场景,是建立在客观场景之上,设计师所期望达成的能解决用户客观场景中相关需求的用户场景。在客观场景的基础之上,设计师可以结合相关交互理论和设计准则,以及通过可用性和场景实验等方法,对客观场景进行分析和研究,进而设计和规范出能够满足用户需求的目标场景。目标场景从表达形式上可以细分为行为场景和交互场景。

    行为场景,是指在客观场景研究的基础之上,对用户的行为流程进行分析和描述的场景,常用场景故事版等表现工具进行描述;如图2,设计师勾勒出的“快的打车”投入市场后的目标行为场景故事版。结合场景故事版,用户的典型目标场景可以被描述为:公司职员王先生晚上6:00下班,需要打车回家。王先生在5:50时,打开“快的打车”APP可以看到公司附近有很多出租车,王先生输入出发地和目的地确认打车。30秒后出租车司机李师傅接单,王先生可以在手机上清晰的看到李师傅的车辆位置,10分钟后王先生成功上车。到达目的地后,王先生用手机在线支付了打车费,开心的回到家陪女儿吃晚饭。

    图 2 “快的打车”目标场景故事版

    Fig2 Story version of “Quick taxi ”target scene

    交互场景则是指产品在被用户使用过程中的场景,常用信息流程图、低保真页面流程图、使用流程故事版等工具进行描述。【6】以“快的打车”为例,用户在移动场景下不方便打字,所以设计了语音输入和快速搜索来确定家和公司的位置;移动场景下容易出错,所以设计了信息确认机制;在等待应答的过程中,可视化告知用户APP通知的车辆数和距离,并且在打车成功后告知车辆距离和时间,消除用户等待的焦虑,将信息可视化。

     

     

    图 3 “快的打车”交互场景

     

    Fig3 Interaction scene of “Quick taxi ”

    所设计的目标场景需要针对用户在客观场景中反应的需求提出针对性的解决方案。通过目标场景设计,设计师可以勾画出未来用户和产品之间理想的行为交互模型。

    1.3 实际场景

    在实际产品交互设计阶段,目标场景会有很多,不同设计师设计出的目标场景也不同。如何验证和评估目标场景的优劣,就需要引入实际场景。实际场景是指在设计师不干预的情况下,提供目标场景中设计好的相关产品或模型给用户,由用户在实际的参与式体验过程中测试目标场景,进行产品的测试及适用性评价【7】。通过这个评价过程,设计师可以进一步观察用户和产品之间存在的其他关系,并为产品最终设计方案提供场景参考。【8】

    2 用户场景对交互设计的价值与意义

    在产品交互设计中,设计师设计的对象是用户的行为。用户行为是动态的,建立在一定场景上的用户行为才有意义。因此在对用户行为进行设计时,需要设计师意识到研究和应用基于场景设计的价值和意义。

    2.1 更准确地把握产品和用户之间的关系及其用户需求

    以用户为中心的产品设计,【9】强调需求来源于用户,需求转化出的设计方案最终服务于用户。设计师可以通过观察用户和产品的互动行为,通过客观场景描述,直观的展现出用户和产品之间的互动关系及其问题。这些关系和问题是用户需求的直观体现,客观场景描述了目标用户、用户客观行为流程、用户情感表现、问题点等信息,而且场景具有故事性,是通过一段段的故事片段描述构成的,因此场景描述相对于其他用户研究总结出来的客观数据、需求文档等更生动和直观。直观而且形象的客观场景描述,便于设计师和其他产品设计人员更准确和细致的把握客观用户需求。

     

    2.2 提升交互设计方向的合理性和产品满意度

    在产品交互设计阶段,通过对目标场景的设计和描绘,设计师可以基于场景进行交互设计,通过场景故事版、用户体验旅程图、信息流程图、低保真页面流程图等工具细化用户在客观场景中所反映出来的需求并给出解决方案。因此基于场景的交互设计,一方面更加全面的分析和解决用户的需求,避免单一分析用户行为或者产品功能造成的对用户需求的遗漏。同时,通过实际场景中对目标用户场景的验证和评估,提升了产品交互设计方向的合理性;另一方面,设计师设计的目标场景将用户的情感表现等需求直观化和故事化,使得设计师所设计的产品设计点更容易被用户感受,提升产品的满意度。

    3 基于用户场景的产品交互设计的设计思维

    3.1 动态思维:场景设计是一个循环设计流程

     

    图4 交互设计中场景设计的动态思维

     

    Fig4Dynamic thinking of scene design in interactive design

    用户场景不是固定不变的。【10】如图4,在交互设计各阶段中,客观场景是目标场景的设计基础,实际场景对目标场景进行验证和评估。同时,被验证的实际场景又是下一次交互设计的设计对象,上一次的实际场景会转化为下一次的客观场景。因为在实际场景验证和评估中,总会遇到不符合用户预期,目标场景中没有考虑到的用户需求的问题。需要指出的是,掌握交互设计中场景设计的动态思维,并不是指这个设计流程是无限循环的,场景设计是一个持续优化和快速迭代的过程,设计师及其相关产品负责人需要讨论出每个迭代阶段具有共识性的目标场景和实际场景的评估标准。面对既定的迭代阶段目标,在整个设计循环流程中,一旦满足相关目标场景及其实际场景评估标准,现有迭代阶段的交互设计便可终止。

     

    3.2 主次思维:抓主要场景,统筹次要场景

    在客观场景分析和目标场景设计过程中。分析场景时,需要区分主要场景和次要场景。在交互设计各阶段不同场景中,必有而且只有一种场景居于支配的地位,起着规定或影响其他场景的作用,这种场景就是主要场景,其他场景则是次要场景。在分析和解决、处理用户需求时,既要看到主要场景的重要性,善于抓住重点,又要看到次要场景的客观影响,学会全面地看待用户需求,做到抓主要场景,统筹次要场景的统一。主次思维,把握主要场景,同时兼顾次要场景,可以有效地保证基于场景分析的交互设计的产品设计的准确性。

    3.3 拆解思维:复杂的大场景由众多小场景组成

    用户场景有大有小,用户的客观大场景总是由众多可以层级细分的小场景组成。在客观场景分析过程中,大场景相对宏观,可以总览用户的宏观需求。而小场景更加聚焦,可以分析出用户更加具体需求,同时,小场景更加具象,能够落实到用户的具体行为流程和对产品的细节体验,便于设计师有针对性且具象的针对客观小场景进行目标场景设计。比如用户用“快的打车”叫出租车的场景就是大场景,这个大场景中包含用户叫车场景,司机接单场景,用户付款场景等等小场景。用户叫车场景还可以细分为用户当前位置定位场景、用户输入目的地地址场景、用户立即叫车或预约叫车场景等。越细分的客观场景,越有利于设计师针对性的设计出有效的目标场景,同时也更有利于在实际场景中进行交互模型评估和场景验证。所以,在交互设计各阶段应用场景理论进行设计时,需要具备拆解思维,将复杂的大场景拆分为众多可设计的小场景,再由众多的目标小场景,组成最终的目标大场景,进行实际场景验证,输出最终的交互设计成果。

    4 结语

    现在产品和用户体验日趋复杂,传统的物理逻辑层面的设计已经不能满足用户的需要,要关注“事”,【11】场景作为交互系统中极其重要的要素,研究交互设计中的场景理论,从产品交互设计各阶段入手,将场景理论深入到交互设计的各个阶段,是对现有的交互设计实践的一次深化。同时,掌握交互设计中运用场景理论时的循环思维、主次思维和拆解思维,可以有效地把握产品和用户之间的关系及其用户需求,提升交互设计方向的合理性和用户对产品的满意度。研究交互设计中的场景理论,具有非常重要的价值和意义。

     

    参考文献

     

    [1] 沈贻炜. 影视剧创作[M].浙江:浙江大学出版社, 2012.

    SHEN Yiwei. Film and television drama creation[M]. Zhejiang: Zhejiang University press,2012

    [2]Carroll J M. Five reasons for scenario-based design[J]. Interacting with Computers, 2000(13):43–60.

    [3]辛向阳. 交互设计:从物理逻辑到行为逻辑[J]. 装饰, 2015(01):58-62.

    XIN Xiangyang.Interaction Design: From Logic of Things to Logic of Behaviors [J].2015.1:58-62.

    [4]李世国, 费钎. 和谐视野中的产品交互设计[J]. 包装工程, 2009(01):137-140.

    LI Shiguo, FEI Qian. Product Interaction Design in the Perspetive of Harmony [J].Packaging Engineering, 2009(01):137-140

    [5]Go K. , Carroll J. M. , Imamiya A. . Surveying scenario based approaches in sys tem design[J] . IPSJSIG Notes, HI878, 2000:43-48.

    [6]赵婉茹. 浅谈场景故事在用户体验设计中的应用[J]. 设计, 2014(09):174-175.

    ZHAO Wanru.The Application of Scenario Stories in User Experience Design [J].Design, 2014(09):174-175.

    [7] 诺曼·唐纳德 A.设计心理学[M].北京:中信出版社,2010.

    NORMAN D A.The Design of Everyday Things[M].Beijing:China CITIC Press,2010.

    [8]DDF·UXPA中国. 用户体验百家谈[M] .北京:电子工业出版社, 2014.

    DDF·UXPA China. User experience a hundred talk[M] .Beijing:Electronics Industry Press,2014

    [9]罗仕鉴, 胡一. 服务设计驱动下的模式创新[J]. 包装工程, 2015(12).1-4.

    LUO Shijian,HU Yi.Model Innovation Driven by Service Design[J]. Packaging Engineering, 2015(12).1-4.

    [10]COOPER A.软件观念革命——交互设计精髓[M].北京:电子工业出版社,2012.

    COOPER A. Software Concept Revolution: the Essence of Interaction Design[M]. Beijing: Publishing House of Electronics Industry,2012.

    [11] 安娃. 交互设计思维在服务体验中的应用[J]. 包装工程, 2015, 02期(02):5-8.

    AN Wa. Collaborative Design of Product Interaction Design System[J].Packaging Engineering,2015,02(02):5-8.

    转载于:https://www.cnblogs.com/xjmnet/p/9377274.html

    展开全文
  • 、使用场景和业务需求描述

    千次阅读 2019-09-24 05:04:42
    提问:这个获取码流类型的(主码流、子码流、第三) 是可以 管理 关闭 这三中,某个码 ,还是操作不了的。 回答:操作不了,只能取。 转载于:https://www.cnblogs.com/fger/p/11492172.html

    作为小白,业务需求我也不知道,

    我就提问:

      请问下 ,你们的产品很全,根据我们的业务 会使用到你们那个软件产品

    给我的回答:

      主要要用到的就是资源服务,用于获取设备资源,还有视频应用,获取预览url。

      历史版本里的1.2.0

      http使用的是36100,https443

     

    是因为,我们服务器搭建的海康威视的服务应用

    1、(运行管理中心)

     

     2、(综合安防平台)

     

     这两个作用,以及用那个暂时不知道

     ----  隔半天,

     

    然后 以下提问和遐想

    1、执法记录仪的设备绑定、查看和配置在哪里可以查看的

    给我的回答:这个不是对接相关的,是海康平台添加设备

    具体步骤是执法记录仪开启ehome向平台注册,平台根据设备注册编号识别设备

    2、就是 在哪里可以看到 我的执法记录仪

    192.168.xx.xx ,用户名admin,密码hik12345+,登陆后右上角有个三道杠的图标,鼠标移动上去点系统管理,新的页面左边视频设备管理

    3、进入后我看到都是在根节点下面的,我就疑问,不可以编辑改变根节点么?提问:这个设备 都是挂在根节点下的吗? 因为当时 有个概念 是  获取区域信息,然后根据区域可以获取监控点

    给我的回答:区域可以自己划分的,在安保区域管理里

     

     然后此图我未启用按照行政区划定义区域节点编码即(GB28181协议编码:符合中国国家标准(GB/T28181《安全防范视频监控联网系统信息传输、交换、控制技术要求》)协议的编码)。

    后面你就根据接口获取功能吧(比如获取区域信息、在根据区域获取监控点)以下是接口文档(当时未有C#SDK 他们从新给的一份,然后根据他们接口的加密方式调用获取区域信息)

    https://open.hikvision.com/docs/72f1ab73e00449efbcd63194bfa7e5a9#d0c1cc14可以从这里获取区域信息,然后根据区域可以获取监控点

    一、实践

    1、根据接口文档获取区域列表信息

    2、根据接口文档根据区域编号获取监控点信息列表

    3、根获取监控点预览取流URL

     

     

     

     

     播放的时候

    然后排查问题:

     

     说明接口获取正常。

    靠经验判断吧ps 封装 播放工具不支持,用rtp码流转封装包格式。具体:

     

     

    感觉是不是vlc解不了ps封装,应该是ps封装问题,把streamform=rtp去掉估计就又不行了我估计

    然后更改入参

           static string ReqParam3 = "{\"cameraIndexCode\":\"6c2983c65f3d43b28ee082ae8012ff4e\",\"streamType\":0,\"protocol\":\"rtsp\",\"transmode\":1,\"expand\":\"streamform=rtp&transcode=1&videotype=h264\"}";

    完美解决。

     

     

    其他的咨询:

     

     回答:从前往后清晰度依次下降,带宽也依次下降,不过执法记录仪的话可能没这么多码流可以选择,至少第三码流肯定没有。

    提问:这个获取码流类型的(主码流、子码流、第三) 是可以 管理 关闭 这三种中,某一个码 ,还是操作不了的。

    回答:操作不了,只能取。

    转载于:https://www.cnblogs.com/fger/p/11492172.html

    展开全文
  • 消息队列使用的四种场景介绍

    万次阅读 多人点赞 2017-04-18 10:55:09
    消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步...二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理,应用解耦,流量削锋和消息通讯四个场景 2.1异步处理 场景说明:用
  • spark streaming三应用场景

    千次阅读 2016-09-08 00:12:01
    下面分别描述下本人对这三运用场景的理解。 1、无状态操作  只关注当前新生成的小批次数据,所有计算都只是基于这个批次的数据进行处理。  个批次的数据,我们将这个批次的时间假设得长一些,比如说天。...
  • RabbitMQ 6应用场景

    千次阅读 2018-01-23 14:00:06
    RabbitMQ是实现AMQP(高级消息队列协议)的消息中间件的一种,服务器端用Erlang语言编写,支持多种客户端,如:Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等,支持AJAX。用于在分布式系统中...
  • Spark Streaming的三运用场景

    千次阅读 2014-12-25 22:54:21
    下面分别描述下本人对这三运用场景的理解。 1、无状态操作  只关注当前新生成的小批次数据,所有计算都只是基于这个批次的数据进行处理。  个批次的数据,我们将这个批次的时间假设得长一些,比如说天。这样...
  • 存储过程五使用场景比较

    千次阅读 2018-01-19 01:40:56
    存储过程五使用场景比较 1. 使用 JDBC API 直接调用存储过程 Java Database Connectivity (JDBC) API 是 J2EE 的部分,是 Java 语言访问关系数据库的基于标准的首要机制,提供了对数据库访问和缓存管理的直接...
  • 模式描述 个类有且仅有个实例,并且自行实例化并向整个系统提供。 2.模式作用 保证某个类在系统中只有个实例对象,对于特殊需求来说非常必要。 限制了实例个数有利于GC的回收。
  • 模式描述 提供个用于创建对象的接口(工厂接口),让其实现类(工厂实现类)决定实例化哪个类(产品类),并且由该实现类创建对应类的实例。 2.模式作用 可以一定程度上解耦,消费者和产品实现类隔离开,只依赖产品...
  • RabbitMQ的几应用场景

    万次阅读 2014-12-15 19:14:56
    之前的几篇文章介绍了一下RabbitMQ的概念以及环境的搭建和配置,有了RabbitMQ环境就可以基于其实现一些特殊的任务场景了。RabbitMQ官方有个很好的Tutorials基本覆盖了RabbitMQ的各中常见应用场景,先以代码加注释的...
  • 模式描述 用原型实例指定创建对象的种类,并且通过拷贝来创建新的对象。 2.模式作用 可以一定程度上解耦,消费者和对象的构造过程隔离开,对象如何构造与消费者完全无关。 可以一定程度提升效率,复杂对象的构造...
  • 个容易出现死锁的场景

    千次阅读 2014-08-15 16:52:09
    前不久在工作中遇到一个死锁的问题,特记录下。... 那么就存在这样一种情况。假如线程T1调用接口,刚上完A锁,还没有上B锁。底层回调线程T2刚上完B锁,还没有上A锁。这个时候,线程T1要申请上B锁,但是B锁已经被线程
  • 应用之星已经让做个免费场景不难,但做个好看的,这就需要用户自己修炼了!希望下文能对大家有帮助。  你需先了解以下内容: 1.浏览器 请使用chrome浏览器,更新到最新版。...名称和描述就是场景的广
  • 消息队列常见的几使用场景介绍

    千次阅读 2019-06-27 17:41:03
    、简介 消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ...
  • 场景理解--场景分类

    千次阅读 2019-03-09 13:04:43
    场景分类是遥感图像处理的一个重要环节,也是遥感研究领域的热点。随着卫星遥感图像和航空...而场景分类就是解决该类问题的一种重要途径。场景分类指的就是从多幅图像中区分出具有相似场景特征的图像,并正确的对...
  • 消息队列使用的四种场景

    万次阅读 2017-05-26 13:31:01
    消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题 实现高性能,高可用,可伸缩和最终一致性架构 使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,...场景说明:用
  • Activity四启动模式及应用场景

    千次阅读 2019-03-29 10:47:18
    面试的时候科大讯飞的个面试官问我...、Activity四启动模式: ()、基本描述 standard:标准模式:如果在mainfest中不设置就默认standard;standard就是新建个Activity就在栈中新建个activity实例; si...
  • 消息队列常见的几使用场景介绍!

    万次阅读 多人点赞 2018-06-29 19:58:00
    、简介消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。使用较多的消息队列有ActiveM...
  • redis 五数据类型的使用场景

    万次阅读 多人点赞 2014-11-12 12:26:38
    String 1、String 常用命令: 除了get、set、incr、decr mget等操作外,Redis还提供了下面一些操作: ...String是最常用的一种数据类型,普通的key/value存储都可以归为此类,value其实不仅是String
  • 作为个系统介绍Unity3D中Shader编写的系列文章的开篇,本文的第部分系列文章的前言,然后第二部分介绍了这个系列文章中我们会使用的游戏场景创建方式,最后部分讲解了如何在Unity中创建和使用Shader,为后面...
  • 设计模式(二) 三适配器模式 总结和使用场景

    万次阅读 多人点赞 2016-10-18 16:34:41
    http://blog.csdn.net/zxt0601/article/details/52703280本文出自:【张旭童的博客】 概述定义:适配器模式将某个类的接口转换成客户端期望的另个接口表示,主的目的是兼容性,让原本因接口不匹配不能一起工作的...
  • 虽然我知道你也是脸懵逼的进来,脸懵逼的出去,但是等你深入了解后,你会收益匪浅的,小白可以先收藏起来 其实如果按照名称来说,锁大概有以下名词: 自旋锁 ,自旋锁的其他种类,阻塞锁,可重入锁 ,读写锁 ...
  • 常见的六设计模式以及应用场景

    万次阅读 多人点赞 2018-01-21 20:55:26
    单例模式是一种常用的软件设计模式。 在它的核心结构中只包含一个被称为单例类的特殊类。通过单例模式可以保证系统中一个类只有一个实例而且该实例易于外界访问,从而方便对实例个数的控制并节约系统资源。
  • Redis的六特性及使用场景

    万次阅读 2017-05-17 11:42:55
    Redis的六特性 l Strings l Hashs l Lists l Sets l Sorted Sets l Pub/Sub Redis各特性的应用场景 Strings Strings 数据结构是简单的key-value类型,value其实不仅是String,也...
  • 用例的泛化关系及场景描述

    千次阅读 2012-06-21 00:18:16
    比如“预定房间”或者“预定早餐”还可以有套相同的其它服务的时候,可以使用泛化描述。  在“预定服务”用例中有个抽象子事件流,所以“预定房间”是个抽象用例,而“选择服务”的事件实现在“预

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 439,899
精华内容 175,959
关键字:

写一种活动的场景的描述