通讯录

手机通讯录误删了怎么恢复？通讯录是我们手机上的一项重要数据，虽然现在使用到通讯录的次数会越来越少，所以有时候也不会在意手机里面的通讯录，通讯录里面肯定会有很多重要的联系人在里面，万一里面的通讯录数据被删除了怎么办？手机通讯录误删了怎么恢复？ 一：手机云备份 在手机中都会有手机云备份这样的一个功能，可以开启自动备份手机里面的数据，当我们手机中有数据被删除就可以从云备份中找到需要恢复的数据并且恢复。从手机中找到云备份在里面找到删除的数据之后恢复到手机中。 二：同步助手备份 或者是借助同步助手备份的，有些小伙伴的手机云备份没有足够的储存空间所以才会用同步助手来对手机中的重要数据进行备份。当你发现手机通讯录被删除的时候就可以从同步助手中找到备份的数据进行恢复。 三：电脑软件恢复 找到电脑软件来对手机里面的通讯录恢复，在电脑中找到【互盾安卓恢复大师】借助这个软件恢复通讯录，手机连接电脑之后使用软件的“一键恢复”功能的快速扫描对手机里面的数据扫描。 待软件扫描操作完成之后就可以在软件的界面上看到已经扫描出来的数据了，从这些数据中可以看到“联系人”一栏，点击后可以看到扫描出来的联系人，选择需要恢复的联系人使用“恢复选中文件”将联系人恢复。 手机通讯录误删了怎么恢复？根据以上的几个简单方法就可以轻松将手机的联系人恢复回来了，要知道手机上的很多重要数据一定要做好备份。

苹果手机通讯录删除怎么恢复？现在使用通讯录的越来越少了，基本上都在使用微信，我们储存在手机里面的联系人已经没什么用了，很多人会去将手机中不需要的联系人删除，如果重要的联系人被删除了，但是却不知道该怎么将通讯录进行恢复。苹果手机通讯录删除怎么恢复？ 一：iCloud同步 苹果手机通过iCloud同步手机通讯录，在手机上删除了手机通讯录同步了iCloud之后可以从iCloud中将通讯录的内容找出并且进行恢复。打开手机的设置--上方iD-iCloud--通讯录选项重新开关即可，通讯录就可以被恢复了。 二：导入SIM卡 苹果手机中可以将通讯来的号码进行导入，通过导入SIM卡恢复手机通讯录的号码，打开手机设置-通讯录-导入SIM卡通讯录，操作步骤完成之后就会将里面的通讯录进行导出到手机中。 三：电脑软件恢复 借助电脑也是能恢复通讯录，在电脑的浏览器中找到【互盾苹果恢复精灵】使用这个软件找出通讯录内容，手机连接电脑后使用“从iPhone设备扫描恢复”功能扫描手机数据。 待软件扫描出数据之后可以看到扫描的恢复内容，找到联系人一栏之后点击查看里面的内容，选择需要的联系人勾选中，使用“导出选中记录”恢复通讯录。 苹果手机通讯录删除怎么恢复？以上的简单方法就可以恢复通讯录的内容了，建议还是将手机中的重要数据备份，避免引起不必要的麻烦。

前言前段时间与同事一起为产品接入了 Elasticsearch 框架技术。从参与方案会议到搭建开发上线过程中有很多讨论点，故产生本文，希望藉此总结和分享一些经验。 1. 业务模型接触已有的业务时，数据模型是最早需要知道的信息。我和同事负责接入 Elasticsearch 的产品是一个业务繁多的通讯录，简化下来就是 3 个关键的模型，如下： 部门（Department）人员（User）标签（Tag）它们的用途和联系，就跟它们的词义一样。由此产生的业务如下： 通过 标签 查询 部门、人员通过 部门 查询 人员 基于以上模型和业务，在典型的关系型数据库下，为了实现关联关系，自然会有额外的关联表： 部门人员关联表：每条记录包含1个部门，1个人员标签对象关联表：每条记录包含1个标签，1个部门或人员2. 需求Elasticsearch 的特点有全文检索、分布式、海量数据下近实时查询。当时为通讯录业务引入 Elasticsearch 的需求和目标如下： 多字段的匹配或模糊查询。这些部门、人员、标签数据原本存储在 MySQL 中，如果要做匹配多个字段的模糊查询就比较吃力了，考虑一个常用功能 “输入姓名/手机号/拼音/首字母来查询人员”。而快速查询此类业务是 Elasticsearch 可以提供的。基础模块能力。其他业务模块也提出了类似全文检索的需求，因此在通讯录业务首次应用 es 时，要定义和提供好 es 的访问和工具方法，供其他模块在未来接入时，能复用一些实现，能保持一致的接口和命名风格等。3. 索引设计从原 MySQL 数据库表，到 Elasticsearch 的索引，数据模型的变化称为异构。Elasticsearch 适合解决在 MySQL 中多条件或连表这样比较慢的查询业务，因此除了原有的信息字段，我们会再附加 3 个模型的关联关系到 es 索引中。 索引 字段原有关联关系部门部门名<br/>完整部门路径名（无）人员姓名<br/>拼音<br/>首字母<br/>手机号父部门Id<br/>所有父级部门Id<br/>标签Id标签标签名部门Id<br/>人员Id（上表略去了一些无关本篇内容的字段，如 SaaS 平台的租户Id、每个对象的信息详情字段） 是否需要添加关联关系的字段，是由业务需求决定的。拿人员索引的 “所有父级部门Id” 举例子，因为有查询部门下所有人员（包括直属、子部门下的）的业务需求，所以会设计这么一个字段。可以使用 Elasticsearch 的分词功能来记录关联关系的字段中。为该字段定义一个分隔模式为竖线 “|” 的分词器，把若干个关联Id存成一个拼接的字符串。4. 版本选择同事是个版本控，在选择版本时了解和考虑了非常多的信息。不过版本选择确实是为平台接入新技术时的一个重要考虑点。我们提出这个方案的当时（2018年4月），对比了主要使用的云服务提供商的几个版本，考虑项可以按优先级概括为： 稳定的案例资料多的时新程度，包括 Elasticsearch版本 和 Lucene版本我们已经使用了某家云服务提供商，会偏向再用其提供的服务几个版本对比我们当时选择了 Elasticsearch 6.2.2 版本。 v5.6.4是 Spring 整合的各个框架中，支持数最多的版本市面使用人数较多，资料较多其依赖的 Lucene 大版本是v6，较旧v6.2.2是当时稳定的版本中最新的，性能比 v5 好v6.2.4是当时最新的版本，修复了许多 bug性能更好，是官方推荐的版本官方的技术文档部分还没更新，得看旧文档市面上找不到相应的人的使用资料版本发展（于2019年4月）在写本篇文章时，我再去了解了和 Elasticsearch版本 相关的变更： ...