腾讯面试三月后复盘
本身这场面试时间极短,也完全没有八股
但由于是笔者第一次面试(刚开始进入暑假实习投递,腾子太快了QAQ
现在回顾起来,腾讯此时这场面试更加考验笔者的自我学习能力以及是否会自己深挖
前情回顾
1.自我介绍起手,然后丢两个算法题
(1) O(n)计算最长连续子序列长度
(2)检验二叉树是否成环(快慢指针+先序) md第一个我记得力扣原题做过的,忘记了,后面用的快排+dp,面试官同意nlogn了,二叉树这个就是有点卡壳(悲)
2.我看你简历项目都是用了ElasticSearch,那你说说他跟MySQL的使用体验(提了MySQL模糊查询,es的倒排索引,lsm树之类的)
3.为什么不能用es替代MySQL(场景+资源消耗)
4.目前学了哪些计算机专业课程
5.我看你在杭州是吧,然后是3-6月的实习时间阿巴阿巴。
6.除了简历上做过的项目,还做过哪些?
复盘
1.算法题
O(n)计算最长连续子序列长度
经典LeetCode题,当时虽然没有刷到过,但是On肯定了就是哈希表,但是当时由于想用数组做哈希,导致卡壳后换成DP
正常哈希
class Solution { |
中心扩散
class Solution { |
- 检验二叉树是否成环
?? 当时紧张麻了吧? 二叉树成环了,还能叫树吗?但是居然没有质疑
1.快慢指针(当时的方法 |
2. ElasticSearch
我看你简历项目都是用了ElasticSearch,那你说说他跟MySQL的使用体验
现在想来,很明显是想问你,学习以及使用过后,他们的应用场景、优势劣势
现在复盘的话
首先他们定位就完全不一样,MySQL作为关系型数据库ElasticSearch则是天然支持分布式的一个搜索引擎
但其实说是搜索引擎,但是如果只是用它的分词搜索功能,便直接引入这个组件,是非常浪费的
MySQL重要需要思考的是,为什么很简单的web开发,貌似都会使用MySQL或者其他关系型数据库?
(这点其实可以先从文件存储管理先去思考),以及强大的事务、一致性
而ES如同官网所列举出来的一样。
(1)数据存储: 由于ES天然支持分布式,也就是架构设计时,通过多种结点去存储数据
- 协调结点(Coordinating Node 负责接收请求、拆分请求、分发到各个结点,最后聚合结果
- 存储结点(Data Node 负责存储数据、处理读写请求
- 主结点(master Node 复杂管理Cluster状态(建索引、删除、分片分片等)
- 预处理结点(Ingest Node 做预处理
每个结点可以有多个身份。也就是说,通过协调结点,将读写请求分配到对应的存储结点上,ES有DocID以及_id,通过 _id(唯一)定位数据存储在哪一个分片(主分片会有一个Data Node去管理它)
也就是说,作为存储引擎的话,ES显然是不错的,无需像MySQL那样自己去哈希路由,并且我们可以使用SSD去存储热数据结点,用HHD/HDD去存储冷数据结点
(2)向量数据库(如果系统本身已经引入ES,又考虑落地 AI应用的话,很推荐)
但是7.x版本速度极慢,不支持HNSW、不支持ANN搜索,内存占用大(dense_vertor无压缩
8.x引入Knn_vector,
(3)分析引擎(是ELK,我们有救了)
ES的索引底层是? 倒排索引(好了,回去等通知吧)
ES关键存储有倒排索引(FST+Posting list)、正排索引(_source–>文档)、docValue(列式存储)
纯数据聚合分析时,docValue速度极快,而加入条件时,通过倒排索引去筛选
将分析请求通过协调结点发布到各个分片上,并发聚合分析然后将结果跟协调结点进行合并
(4)搜索引擎
对于复杂条件支持上,ES的must、should、must_not显然更加优秀
且ES是多结点并发查询,每个should都会先查询出一个文档集合然后去和其他的should求交集
且倒排索引(FST) 支持模糊查询,查询 apple 时支持可以查询到apply
(5)地理空间引擎
这里可以想到经典的外卖场景或者打车
geo_shape
:支持复杂的几何图形,比如:Polygon(多边形)、MultiPolygon(多个多边形)、Line、Envelope 等等。通过图形求交集
也可以通过 存储 id形成一种网络栏栅
3. 为什么不能用ES去代替MySQL
当时回答简直闹麻了,完全就脱离了核心,当时说的是,ES资源占用极大,应用场景(但是这里答得贼不好)
最基本的点:
对于萌新来说,使用成本更高(学习上,以及构建Mapping时,mapping无法修改删除字段,只能添加字段)
ES 近实时搜索(由于二阶段提交的缘故,写入的数据无法实时搜索到)
ES 容错性更低,一致性弱,不支持多表事务(这在很多场景是大忌啊)
ES的数据模型松散,复杂关系建模很痛苦(比如订单拆分、子表操作),且没有主键/外键/约束
高频的小事务处理尤为不划算(ES 是为“读优化”设计的,虽然Lucene和LSM树很相似,但是目的大不相同
456
这里就基本没什么了,害,前面回答太拉跨了,估计人家也觉得没必要了