PingCAP 招聘季： TiDB Architecture Team 招人啦

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 外包信息请发到 /go/outsourcing 节点。

• 不要把相同的信息发到不同的节点

这是一个创建于 1760 天前的主题，其中的信息可能已经有所发展或是发生改变。

接受上次的教训，文章是从微信公众号转来的，供有需要的小伙伴了解

主要是 TiDB Architecture Team 的相关介绍，团队在做什么以及需要什么样的人，感兴趣的小伙伴可以关注下投个简历看看

———————————————————————— 礼貌分割————————————————————————————————————————————————————

数据库系统需要提供事务保证，而且要高效地处理并发事务。更大的挑战在于，如何在基于不可靠硬件的分布式环境下，实现可靠而高效的分布式事务，提供更强高效的 OLTP 处理能力。

TiDB Architecture Team 在做什么？

TiDB 从一开始就定位于分布式的关系数据库，TiDB 架构组一直致力于 TiDB 事务引擎的架构设计和研发工作，不断解决分布式事务的各种挑战和难题，提升 TiDB 稳定性和 OLTP 处理能力，其中包括但不限于：

实现完整的基于 Percolator 论文的分布式事务引擎，确保分布式语境下事务原子性和一致性。将 TiDB、PD、TiKV 等分布式组件有效整合，实现基本的分布式事务原语，即两阶段提交的各个基本组成部分，对上层提供完整的事务语义接口；
并发事务的协调和处理，确保快照读取（ Snapshot Isolation ）的事务隔离级别。支持数据多版本（ MVCC ），实现数据历史版本的控制和清理；
协调事务处理资源使用，提升系统吞吐量和资源利用率，支持量级更大的事务处理能力（ GB 级别）和并发控制，提供更佳的资源调度策略；
提供不同的加锁模型适配不同的业务场景，同时支持乐观锁和悲观锁的加锁模型，实现高效的优先级评估，等待唤醒，分布式死锁检测等机制；
尝试不同的提交策略，获取更好的事务处理性能，实现组提交、并行提交、一阶段提交等优化策略，提升系统响应能力和吞吐量，降低延迟；
处理分布式环境的各种异常（操作系统，磁盘，网络等），保障事务引擎的正确性和性能，实现分布式的容灾测试和异常测试，覆盖分布式环境下所有可能的异常分支，确保在各种异常情况下，分布式事务的正确推进和执行。

除此之外，架构组致力于探索新的事务和存储技术，包括但不限于：

更强大的日志模块，在实现分布式一致性协议，提供持久化保证的基础上，实现更好的性能和吞吐能力；
更强大 TiDB OLTP 处理能力，更好的复用执行计划，支持编译、向量化等执行方式，更友好的 cache 使用和更佳的指令执行效率等；
更前沿的存储技术，新的 lsm 存储引擎，新的索引结构、缓存策略和算法、新的冻结和合并处理机制等，提供更好的读写性能，以及更优的内存，磁盘空间利用率。

需要什么样的人呢？

如果你对下面描述的任何一项，心有戚戚焉——

对分布式技术充满热情，对于 CAP 理论、一致性协议有独到的理解，热衷于解决相关的挑战和难题；
对于事务处理有较深的认识，对于传统数据库的事务、存储引擎实现有深入探究，对于事务异常，并发控制，隔离级别等有独到的理解；
有存储引擎工作的相关经验，对于索引结构，缓存策略，文件系统等有实践经历；
对于分布式执行，有创新的想法，深谙 OLTP 性能调优之道；
对于操作系统，数据库有浓厚的兴趣，期待加入 NewSQL 的浪潮。

那么，欢迎加入 TiDB Architecture Team ！和我们一起挑战在不可靠的硬件环境下实现可靠的数据库服务的终极难题，打造新一代的海量数据存储系统，实现更低成本更高性能的分布式关系数据库服务。这里是一个数据库技术和分布式技术的爱好者聚集地，高效快乐的工作的同时，你可以收获满满的个人成长，在基础核心技术领域遨游，尽情放飞想象力。

除此之外，我们也需要数据库安全方面的专家，如果你熟悉 informix 的或者有数据库安全相关的经验，非常欢迎你的加入

如果有数据库方向的应届生或者毕业时间不长的小伙伴感兴趣我们也十分欢迎，期望在你良好的理论基础上，能对诸如 TPC-C 规范、事务行为的解释等给出一些理论上的建议；

简历投递通道： [email protected]

分布式

事务

tidb

数据库

8 条回复 • 2020-02-27 22:43:56 +08:00