近实时，有两层意思：
集群包含多个节点，每个节点属于哪个集群都是通过一个配置来决定的，
Node 是集群中的一个节点，节点也有一个名称，默认是随机分配的。默认节点会去加入一个名 称为 elasticsearch 的集群。如果直接启动一堆节点，那么它们会自动组成一个elasticsearch 集群，当然一个节点也可以组成 elasticsearch 集群。
文档是 es 中最小的数据单元，一个 document 可以是1条客户数据、1条商品分类数据、1条 订单数据，通常用json 数据结构来表示。每个 index 下的 type，都可以存储多条 document。
1个 document 里面有多个 field，每个 field 就是1个数据字段。
es 集群多个节点，会自动选举1个节点为 master 节点，这个 master 节点其实就是干一些管理 的工作的，比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了，那么会重新选举1个节点为 master 节点。 如果是非 master节点宕机了，那么会由 master 节点，让那个宕机节点上的 primary shard 的身 份转移到其他机器上的 replica shard。接着你要是修复了那个宕机机器，重启了之后，master 节点会控制将缺失的 replica shard 分配过去，同步后续修改的数据之类的，让集群恢复正常。 说得更简单1点，就是说如果某个非 master 节点宕机了，那么此节点上的 primary shard 不就 没了。那好，master 会让 primary shard 对应的 replica shard（在其他机器上）切换为 primary shard。如果宕机的机器修复了，修复后的节点也不再是 primary shard，而是 replica shard。
索引可以拆分成多个 shard ，每个 shard 存储部分数据。拆分多个 shard是有好处的，一是支持横向扩展，比如你数据量是 3T，3 个 shard，每个 shard 就 1T 的数据， 若现在数据量增加到 4T，怎么扩展，很简单，重新建1个有 4 个 shard 的索引，将数据导进 去；二是提高性能，数据分布在多个 shard，即多台服务器上，所有的操作，都会在多台机器 上并行分布式执行，提高了吞吐量和性能。 接着就是这个 shard 的数据实际是有多个备份，就是说每个 shard 都有1个 primary shard ，负责写入数据，但是还有多个 replica shard 。 primary shard 写入数据之后， 会将数据同步到其他几个 replica shard上去。
通过这个 replica 的方案，每个 shard 的数据都有多个备份，如果某个机器宕机了，没关系啊， 还有别的数据副本在别的机器上，这样子就高可用了。
总结：分布式就是两点，1.通过shard切片实现横向扩展；2.通过replica副本机制，实现高可用
基本概念
写数据过程：客户端通过hash选择一个node发送请求，这个node被称做coordinating node（协调节点），协调节点对docmount进行路由，将请求转发给到对应的primary shard，primary shard 处理请求，将数据同步到所有的replica shard，此时协调节点，发现primary shard 和所有的replica shard都处理完之后，就反馈给客户端。
客户端发送get请求到任意一个node节点，然后这个节点就称为协调节点，协调节点对document进行路由，将请求转发到对应的node，此时会使用随机轮询算法，在primary shard 和replica shard中随机选择一个，让读取请求负载均衡，接收请求的node返回document给协调节点，协调节点，返回document给到客户端
es最强大的是做全文检索，就是比如你有三条数据
1.java真好玩儿啊
2.java好难学啊
3.j2ee特别牛
你根据java关键词来搜索，将包含java的document给搜索出来。
更新/删除数据过程，首先还是write、merge操作，然后flush过程中：
1、write过程和上面的一致；
2、refresh过程有点区别
所谓的倒排索引，就是把你的数据内容先分词，每句话分成一个一个的关键词，然后记录好每一个关键词对应出现在了哪些 id 标识的数据。
然后你可以从其他地根据这个 id 找到对应的数据就可以了，这个就是倒排索引的数据格式 以及搜索的方式，这种利倒排索引查找数据的式，也被称之为全文检索。
Inverted Index就是我们常见的倒排索引, 主要包括两部分：
一个有序的数据字典 Dictionary（包括单词 Term 和它出现的频率）。
与单词 Term 对应的 Postings（即存在这个单词的文件）
当我们搜索的时候，首先将搜索的内容分解，然后在字典里找到对应 Term，从而查找到与搜索相关的文件内容。
本质上，Stored Fields 是一个简单的键值对 key-value。默认情况下，Stored Fields是为false的,ElasticSearch 会存储整个文件的 JSON source。
哪些情形下需要显式的指定store属性呢？大多数情况并不是必须的。从_source中获取值是快速而且高效的。如果你的文档长度很长，存储 _source或者从_source中获取field的代价很大，你可以显式的将某些field的store属性设置为yes。缺点如上边所说：假设你存 储了10个field，而如果想获取这10个field的值，则需要多次的io，如果从Stored Field 中获取则只需要一次，而且_source是被压缩过 的。
这个时候你可以指定一些字段store为true，这意味着这个field的数据将会被单独存储(实际上是存两份,source和 Stored Field都存了一份)。这时候，如果你要求返回field1（store：yes），es会分辨出field1已经被存储了，因此不会从_source中加载，而是从field1的存储块中加载。
Doc_values 本质上是一个序列化的 列式存储，这个结构非常适用于聚合（aggregations）、排序（Sorting）、脚本（scripts access to field）等操作。而且，这种存储方式也非常便于压缩，特别是数字类型。这样可以减少磁盘空间并且提高访问速度,ElasticSearch 可以将索引下某一个 Document Value 全部读取到内存中进行操作.
Doc_values是存在磁盘的
在es中text类型字段默认只会建立倒排索引，其它几种类型在建立倒排索引的时候还会建立正排索引，当然es是支持自定义的。在这里这个正排索引其实就是Doc Value。
即上文所描述的动态索引
往 es 写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 filesystem cache 中去。
es 的搜索引擎严重依赖于底层的 filesystem cache ，你如果给 filesystem cache 更多的 内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就 基本都是走内存的，性能会非常高。 性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能 绝对是秒级别的，1秒、5秒、10秒。但如果是走 filesystem cache ，是走纯内存的，那么一 般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。
那如何才能节约filesystem cache这部分的空间呢？
当写数据到ES时就要考虑到最小化数据，当一行数据有30几个字段，并不需要把所有的数据都写入到ES，只需要把关键的需要检索的几列写入。这样能够缓存的数据就会越多。 所以需要控制每台机器写入的数据最好小于等于或者略大于filesystem cache空间最好。 如果要搜索海量数据，可以考虑用ES+Hbase架构。用Hbase存储海量数据，然后ES搜索出doc id后，再去Hbase中根据doc id查询指定的行数据。
当每台机器写入的数据大于cache os太多时，导致太多的数据无法放入缓存，那么就可以把一部分热点数据刷入缓存中。
对于那些你觉得比较热的、经常会有人访问的数据，最好做个专门的缓存预热系统，就是 对热数据每隔一段时间，就提前访问一下，让数据进入 filesystem cache 里去。这样下 次别人访问的时候，性能肯定会好很多。
把热数据和冷数据分开，写入不同的索引里，然后确保把热索引数据刷到cache里。
在ES里最好不要用复杂的关联表的操作。当需要这样的场景时，可以在创建索引的时候，就把数据关联好。比如在mysql中需要根据关联ID查询两张表的关联数据：select A.name ,B.age from A join B where A.id = B.id，在写入ES时直接去把相关联数据放到一个document就好。
es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到1个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到 最终第 100 页的 10 条数据。
分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 shard，每个 shard 就查 2 条数据， 最后到协调节点合并成 10 条数据吧？你必须得从每个 shard 都查 1000 条数据过来，然后根据 你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。你翻页的时 候，翻的越深，每个 shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所 以用 es 做分页的时候，你会发现越翻到后面，就越是慢。
我们之前也是遇到过这个问题，用 es 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时 候，基本上就要 5~10 秒才能查出来一页数据了。
解决方案吗？
1）不允许深度分页：跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差；
2）在APP或者公众号里，通过下拉来实现分页，即下拉时获取到最新页，可以通过scroll api来实现；
scroll 会1次性给你生成所有数据的1个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动获取下一页，性能会比上面说的那种分页性能要高很多很 多，基本上都是毫秒级的。 但是，唯1的缺点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场 景。也就是说，你不能先进到第 10 页，然后去第 120 页，然后再回到第 58 页，不能随意乱跳 页。所以现在很多APP产品，都是不允许你随意翻页的，也有一些网站，做的就是你只能往 下拉，一页一页的翻。
初始化时必须指定 scroll 参数，告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。
除了用 scroll api ，也可以用 search_after 来做， search_after 的思想是使用前一页的结果来帮助检索下一页的数据，显然，这种方式也不允许你随意翻页，你只能一页一页往后 翻。初始化时，需要使用一个唯1值的字段作为 sort 字段。
云楼会议室云上3D会议室
云楼会议室2019年11月正式上线 ，移动微世界（北京）网络科技有限公司旗下“云上3D会议室”产品。提供远程云上虚拟现实3D会议室，云端协助语音视频会议、虚拟现实会议室、企业级直播等解决方案，服务于提供企业远程云上3D会议室、远程教育、远程医疗、会销、远程金融及远程政务等领域。[2]
打造“云端+服务+业务”的生态体系具有500人在线会议、全平台一键接入、256路语音通讯引擎、云楼会议室提供实时直播、共享屏幕、PPT文件上传、视频音乐播放、支持在线协作。[1]
基本信息
中文名
云楼会议室
外文名
Yunlou conference room
别名
云楼会议
所属国家
中华人民共和国
所属公司
北京云楼科技有限公司
展开
产品介绍
云楼会议室2019年正式上线，移动微世界公司旗下“云上3D会议室”产品，有PC客户端、iOS、Android。公司自主研发了“3D/VR引擎、 语音通讯引擎 、分布式服务器引擎”保证了系统的稳定性与安全性。
云上VR会议室，非视频群聊，真开会！云上360°真实场景会议室，区别于传统视频会议，于云上构建实景会议体验，让会议更有沉浸感、仪式感。
虚拟现实技术
开创性应用虚拟现实技术，于云上创建实景会议室，更加真实的会议体验，提升开会效率，提高企业运营能力。
云上会议室
操作简单，智能互动。
产品功能
（1）、提供3D场景会议室，满足25人—500人不同规格的会议需求；
（2）、清晰可见的组织架构，同公司的同事可以相互发送信息、语音呼叫、视频直播
（2）、在外办公人员可以外勤打卡，录入拜访客户信息；痕迹可见为公司留下的宝贵数据。 [3]
沉浸式体验
基于自主研发的三大技术引擎：3D/VR引擎、语音通讯引擎、分布式服务器引擎，在云上架构出360°真实场景会议室。
会议管理
一键进入会议室、便捷管理参会人员、完美匹配多种终端设备。
智能交互
三屏同步显示、实时智能语音、一对一、一对多、多对多交流，共享多种格式文件。
产品优势
强仪式感
云楼会议室创新性提出“云上会议室”概念，在云上架构虚拟现实的会议场景，通过沉浸式会议体验，增强代入感和会议仪式感。从根本上区分了视频聊天和视频会议。
使用简单
云楼会议室是一款操作方式极简、高品质低成本的超级产品，可迅速、便捷地实现商务沟通；一键进入云上会议室，链接全球团队、客户，让开会变得简单高效。
行业解决方案
行业现状
传统远程视频会议，缺少场景化体验；缺少极简式应用；传统的远程会议，通过视频“聊天”进行商务沟通，无角色感，会议专注度低、稳定性差、严肃性不够；在场景化体验、极简式应用方面，仍有待提升。
应用场景解决方案
（1）、在家云上会议：无特殊硬件要求，无高网络带宽要求；
（2）、途中云上会议：简单、方便，随时随地可以沟通；
（3）、多地同步云上会议：稳定、音视频流畅；
（4）、集团/分公司云上会议：安全、稳定、便捷。
销售团队解决方案
（1）、销售外勤打卡：在手机端定位出勤位置打卡、拍照、填写拜访记录，完成出勤数据；
（2）、销售团队“流动办公室”：手机随时登录会议室兼流动办公室，让销售人员不再孤单，随时和团队在一起，简单高效管理全国销售团队；
（3）、客户信息留存真实可靠：填写客户信息，保存数据，客户信息不流失；
（4）、后台统一管理：可统一导出客户信息、出勤报表，管理更便捷。
企业解决方案
云楼会议室采用云计算、3D/VR引擎、语音通信引擎、分布式服务器引擎、虚拟现实技术、人工智能技术，提供基于云上虚拟现实“3D会议室”服务，可覆盖企业业务全流程。云楼会议室即开即用，无需运维，按需扩容。同时，提供本地化部署解决方案，数据全部流转、存储于企业内网。针对企业业务场景，提供远程会议、协同办公、企业培训、远程招聘、视频客服、活动直播等多种场景应用。
教育解决方案
云楼会议室解决方案集教育中枢、教学管理与资源平台、互动教学终端于一体，支撑大规模云上3D虚拟现实互动教学场景、多学科在线互动教研、多业务融合统一管理，实现了互动、直播、录播、文件资源分享、文档PPT山上传、音视频播放、AI智能等多场景应用，同时具备扩展能力。
金融解决方案
云楼会议室提供稳定、高效的云上远程虚拟现实3D场景服务方案，适应金融用户业务场景和特点，内外部比较有仪式感、沉浸式体验沟通需求，助力金融机构的数字化转型发展战略。针对金融业务场景，提供晨夕大会、业务培训、协同办公、对公双录、视频客服、智慧网点、职场监管、活动直播等多场景应用。
远程医疗解决方案
云楼会议室提供多业务应用融合的3D虚拟现实场景能力，通过整合业务系统为远程医疗提供数据及流程支持，打造智慧远程医疗。
体验案例
教育机构21世纪中国电子商务网校
21世纪中国电子商务网校多次使用产品进行全国大学生的条码课程培训。云楼会议室适宜于教师主讲和学生讨论两种模式，可以实现老师视频直播授课和师生视频直播提问回答，以及举手发言、PPT播放等教学环节，参加直播听课的同学可通过手机、PC机等在线上课，直播现场秩序井然，授课老师与同学们实时视频互动，气氛热烈，许多同学表示一定积极参加下一次的直播课程。
论坛分享会一把犁现代农业网络座谈会+公益助农活动
2020年4月11日，由金惠国际集团、一带一路网、中外交流网、新视角智库主办，一把犁、一带一路网东北管理中心承办，陕西省公共关系协会绿色生态研究中心、黑龙江省绿色食品协会协办的“现代农业网络座谈会（黑龙江佳木斯站）”在云楼会议室的帮助下，成功召开。
产品端口
（1）、PC客户端；
（2）、iOS；
（3）、Android。[4]
发展历程
2019年11月，云楼会议室产品正式上线。[5]
核心技术
（1）、3D/VR引擎；
（2）、语音通信引擎；
（3）、分布式服务器引擎。[6]
会议室类型
（1）、25人；
共4张
云楼会议室25人场景图
（2）、50人；
共4张
云楼会议室50人场景图集
（3）、100人；
共4张
云楼会议室100人场景图集
（4）、200人；
共4张
云楼会议室200人场景图集
（5）、500人。[7]
共4张
云楼会议室500人场景图集
版本记录
云楼会议室1.2.8更新说明 [8]
（1）、外勤打卡增加可录入的内容；
（2）、50-200人规模会议室（分组模式会议室除外）增加后台提前安排座席功能；
（3）、 人物模型优化；
（4）、 视频上传转码功能优化，上传中可离开上传界面进行其它操作；
（5）、蓝牙语音通道问题调优；
（6）、 修复后台的在线时间统计的准确性问题；
（7）、其它已知问题的修复及优化。
云楼会议室1.2.7更新说明 [1]
（1）会议室权限功能优化：只需后台设置一个用户为会议室负责人，负责人即可在应用内对每个会议室进行会议室管理员设置，会议室管理员；并且随时方便更改；
（2）会议室选择界面增加管理员展示，可以看到当前会议室负责人是哪个用户；
（3）其他细节优化及已知问题修复。
云楼会议室1.2.6更新说明 [1]
（4） 服务器升级维护；
（5） 为了更好的用户体验进行数据库优化；
（6） 其他已知问题修复。
云楼会议室1.2.5更新说明 [1]
（1）、国际多语言版上线，增加英语支持。可以在设置中切换软件对应的语言；
（2）、关于增加云楼SOHO、云楼会议室管理后台地址。企业超管可以直接访问对应产品的管理后台；
（3）、其他已知问题修复；
（4）、新增会议室可删除背景音乐功能。
云楼会议室1.2.4更新说明 [1]
（1）、消息中表情更新调优；
（2）、新增无分组模式的200人会议室，规则与100人会议室完全一致；
（3）、其他已知问题修复。
云楼会议室1.2.3更新说明 [1]
（1）、登录模块优化；
（2）、UI界面优化；
（3）、修复若干bug。
云楼会议室1.2.2更新说明 [1]
（4）、UI界面优化；
（5） 、通讯录搜索框处增加联系人数显示；
（6）、修复了上传图片导致崩溃与其他已知问题。
云楼会议室1.2.1更新说明 [1]
（1）、会议室内左上角增加人数显示，可以查看当前会议室人员数量；
（2）、静音按钮更名为话筒；
（3）、UI界面优化；
（4）、权限功能优化；
（5）、更换APP主题色。
云楼会议室1.2.0更新说明[1]
（1）、新增200人规模会议室，200人会议室可使用传统主讲模式与新增分组讨论模式；
（2）、50人、100人、200人会议室增加鼓掌功能，可由会议室权限者在会议开始后开启允许鼓掌状态；
（3） 、直播管理更名为屏幕管理，并在界面增加屏幕共享、视频直播开关；
（4）、UI界面优化。
云楼会议室1.1.9更新说明 [1]
（1）、聊天表情优化；
（2）、3D场景优化。
云楼会议室1.1.8更新说明 [1]
（1）、修复语音bug；
（2）、优化细节体验。
云楼会议室1.1.7更新说明 [1]
（1）、企业管理员可通过[我的][关于]中，直接点击地址访问管理后台；
（2）、新增表情，可以在聊天时发送表情；
（3）、 新增100人规模会议室；
（4）、后台权限管理中新增会议室权限配置，分为小型会议室权限与中大型会议室权限；
（5）、优化了小型会议室权限，有权限时，可以操作锁定会议室、禁麦。
云楼会议室1.1.6更新说明 [1]
（1）、新增系统维护通知，可以收到紧急通知，或临近停服维护前倒计时通知；
（2）、 新增群聊功能，可以修改群名称可以在群内发送文件，图片，可以在群内查看历史记录；
（3）、 更改进入会议室的麦克风提示。可以手动关闭提示；’
（4）、优化了系统提示信息；
（5）、 图像优化。
云楼会议室1.1.5更新说明 [1]
（1）、会议室锁定功能调优：锁定、解锁，操作提示增加操作者名显示；已锁会议室新增【申请进入】功能。
（2）、新增会议室麦克风提示功能：默认为静音状态。用户可以自主选择【保持静音】或【打开麦克风】。当需要重新选择时，可通过系统设置内的“开启会议室麦克风提示”选项，重新打开提示、重新选择。
云楼会议室1.1.4更新说明 [1]
（1）、 新增会议室锁定功能，会议室内人员都可操作，可有效防止无关人员误入会议室；
（2）、消息中增加草稿功能；
（3）、50人会议室资源优化；
（4）、其他已知问题的修复及稳定性提升优化。
云楼会议室1.1.3更新说明 [1]
（1）、 新增50人会议室，当企业人数达到一定数量时自动开启；
（2）、3D会议室中增加通讯功能，可以收发信息及查看通讯录；
（3）、UI细节调优；
（4）、其他已知问题的修复及稳定性提升优化。
云楼会议室1.1.2更新说明 [1]
（1）、消息增加长按触发菜单功能，可以进行转发、删除、多选操作。并且支持多选消息后的批量转发与删除；
（2）、已知问题修复；
（3）、 细节体验优化。
运行环境
PC端
（1）、操作系统：Windows 10；
（2）、处理器：Intel Core i5 7代及以上；
（3）、运行内存：8GB及以上；
（5）、显卡：NVIDIA GeForce GTX1050或AMD Radeon RX Vega M GL同级别及以上；
（6）、硬盘空间：系统盘剩余空间大于4GB。
Android
（1）、Android（4.4）版本以上；
（2）、运行内存：2GB以上。
iOS
（1）、iOS系统9.3以上；
（2）、设备iPhone6S以上。[9]
参考资料
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）