尊敬的华为云客户：       华为云计划于2019/12/06 00:00（北京时间）将云数据库GeminiDB正式转商用。服务正式商用后，将于2019/12/06 00:00（北京时间）正式开始收费，计费模式为按需计费。华为云在此提醒您，如果您不再需要使用该服务，请及时删除资源，以免产生费用。更多关于云数据库GeminiDB的产品介绍，请您点击了解。如您有任何问题，可随时通过工单或者服务热线（4000-955-988或950808）与我们联系。       感谢您对华为云的支持！

随着云端数据库的蓬勃发展，市面上涌现出越来越多的数据库，如何满足日益增长的客户需求，是每个云厂商必须考虑的问题。华为云数据库聚焦企业，致力于打造企业级数据库，为企业客户提供稳定可靠、安全可信、可持续创新的云服务，华为云数据库GeminiDB在此情境下应运而生。华为云数据库GeminiDB华为云数据库GeminiDB是一款基于华为新一代DFV计算存储分离架构打造的Active-Active全分布式架构多模NoSQL数据库服务，相比社区版具有分钟级计算扩容、秒级存储扩容、数据强一致、超低时延、高速备份恢复性能的优势。目前已兼容Cassandra、MongoDB两款NoSQL接口，日前新增Redis和InfluxDB两个兼容接口，正在火热邀测中。GeminiDB for RedisRedis是一个键值型内存数据库，提供了丰富的数据模型，广受业界欢迎。但是，社区版Redis也存在一些饱受开发者诟病的问题，如数据全内存存储成本过高，无法满足海量存储需求; 进程重启时服务恢复慢，耗时长，影响可用性；热备可靠性不足，业界现有集群方案弹性不够，扩容操作复杂、耗时长等。针对这些痛点，华为云数据库打造了GeminiDB for Redis，这是一款基于华为黑科技DFV Pool打造的数据库产品，是业界首款基于共享存储架构的Redis产品，面向海量数据实时持久化存储场景，与业界现有Redis方案相比，具有五大核心优势。极具竞争力的五大优势高兼容度 兼容社区版所有数据结构的全部命令，优于社区版Redis Cluster对单机版Redis的兼容度。高性价比 GeminiDB for Redis存储容量不受内存限制，海量数据存储无压力，同时拥有优异的性能。根据不同使用场景，使用同等内存规格的资源，可提供数倍于社区版的性价比。高可靠性 底层存储使用多副本强一致高可用协议，上层数据实时下沉到存储池，数据安全可靠。高可用性 计算节点无状态，故障节点数据被自动接管，无需主备倒换，无需数据迁移，数据强一致。高伸缩性 秒级弹性扩容，增删节点、分裂节点均无需搬迁数据。应用场景GeminiDB for Redis可广泛适用于游戏、电商、社交等场景，绝大多数场景下可替换Redis使用，例如：游戏场景中的角色信息、经验道具信息、好友排名电商场景中的海量商品展示信息、购物评论信息社交场景中的好友信息、关系链信息、评论列表等等对于数据存储量巨大，有极大的成本压力，并且对性能、可靠性、伸缩性均有高要求的场景，GeminiDB for Redis是极佳选择。GeminiDB for InfluxDBInfluxDB是一个时间序列数据库，用于处理海量写入与查询，具有完善的功能和优异的性能，在业界被誉为时序数据库一哥。华为云数据库团队在InfluxDB基础上精心自研出GeminiDB for InfluxDB，用于存储大规模的时序数据并进行实时分析，具有以下明显优势：与开源相比，GeminiDB for InfluxDB基于计算存储分离架构，可完全解绑存储与计算资源，用户可按需申请。在内存资源消耗方面，华为云数据库利用动态GC解决内存消耗问题。GeminiDB for InfluxDB采用分布式集群设计，在开源单机基础上拓展分布式能力，副本卸载到存储，计算层无需关注复杂的一致性协议，可专注于计算。应用场景云边一体的端到端时序解决方案，助力工业物联网时序数据轻松上云在工业物联网领域，需要采集时序数据的设备（传感器）一般分布在各个工厂。客户机房稳定性不受控制，可能会出现掉电、网络异常、磁盘损坏等问题，导致数据丢失。GeminiDB for InfluxDB在分布式云端服务的基础上，拓展边缘时序数据库应用，通过云边协同方式同步数据，在客户机房部署边缘时序数据库应用，客户数据写入边缘，边缘上传数据到云端，边缘节点异常情况可从云端恢复数据，确保数据无遗漏。运维监控GeminiDB for InfluxDB亿级时间线支持，完美解决大量运维监控数据采集、分析问题。加速行业落地，华为云数据库不止步。GeminiDB for Redis和GeminiDB for InfluxDB的推出，极大程度上满足了客户对新型数据库的多样化管理需求，帮助企业聚焦自身业务场景，实现新一轮发展。未来，华为云数据库还会持续构筑领先的技术资源，持续为客户提供更优的服务。

双十一马上来啦，小云吐血整理7项#华为云# #数据库# 最全最省钱的购买攻略！用超实惠的价格，买管家式的华为云数据库，超省心省力，保证物超所值~爆款云数据库MySQL 2折起！更多云数据库全规格明星产品包年4.5折起，还有消费满额送Mate30pro，多项好礼等你来拿，限时优惠不容错过，快来体验吧！攻略详情请戳：https://activity.huaweicloud.com/2019nov_promotion/index.html?utm_source=weibo&utm_medium=sm-hwysm-bu&utm_campaign=-&utm_content=WBH-HWY-WBTS&utm_term=20191106-03#invite

华为云数据库年度超低价来袭，最优惠的购买指南拿走，不谢~活动时间：预热期：2019.10.21-2019.10.31，正式期：2019.11.01-2019.11.20活动对象：华为云官网已完成注册并实名认证的用户。首先，购买之前先领取优惠券啦，进入双11活动主场双11预热期主场代金券可叠加优惠券商务是9折使用范围：官网产品页下单使用与特价套餐使用，（比如买了活动页上的MySQL下单时领取该了优惠券还可以再打9折哦），规则详情移步活动页面查看不可叠加优惠券新购券的商务是7折，续订券商务是85折使用范围：官网产品页下单使用，特价套餐不能使用，规则详情移步活动页面查看 1、预热期点我直达购买指导：页面展示出来的只有MSQL，规格是2C4G，4C8G单机/主备，6个月/1年；折扣是6个月8折，1年是55折（12个月的55折）； 3年是打45折（36个月的45折）；其余没有展示出来的产品规格同享该折扣，联系您的客户经理（客服电话950808 转1）申请优惠的邮件主送lubianbian，邮件参考格式如下折扣券类型折扣券限制优惠折扣用户名购买产品订购类型购买周期新购折扣券一年原价55折折扣前原价7920折扣后4356优惠2239MYSQL    5.6  单机版新购包1年 正式期最优购买指导：1、先领取数据库代金券云数据库双11正式期新购优惠券，大约是6折优惠（预热期新购代金券7折优惠）代金券商务：满500可用200元；满1200可用500元；满5000可用2000元；  领取渠道：1、如有需要客户经理发邮件申请新购券，邮件内容自拟即可；2、在双11正式期的活动页购买所有ECS规格，系统自动赠送该新购代金券，数量有限先到先得；使用范围：代金券使用仅支持在官网产品页下单，包年包月可用2、不限新老客户，购买商务如下：MySQLSQL ServerDDSPostgreSQL活动页没有展示，走邮件申请商务6个月（仅限新购）8折8折8折7折1年（仅限新购）5.5折无6.5折5折3年（仅限新购）4.5折4.5折4.5折4.5折注：1年的折扣是指12个月的基础上再打对应的折扣，3年是36个月的价格基础上再打4.5折；活动页上没有展示出来的规格，可发邮件申请同等的折扣3、小规格秒杀福利，只限新用户领取：MySQL与DDS副本集2折起购正式期秒杀抢购1年MySQL（活动页抢购）2C4G/40G超高IO/单机2折2C4G/40G超高IO/主备3折DDS副本集（暗促申请）2C4G/40G超高IO2折4、购买MySQL之后，使用华为云数据复制服务DRS完成业务数据迁移，截图反馈迁移完成的结果，还可申请MySQL续订/变更 4折优惠正式期迁移专区福利，购买1年的MySQL规格（不限以下规格），申请续费/变更 1年4折的优惠1年MySQL（活动页抢购）2C4G/100G超高IO/主备5.5折使用华为云DRS服务，迁移数据后提供迁移完成的截图给客户经理，申请续费或变更代金券1年4折的优惠，（官网价直接购2年7折优惠，现等同于购2年4.7折，折扣史上最低）；其他规格的续订优惠申请发送邮件给lubianbian4C8G/100G超高IO/主备4C16G/100G超高IO/主备5、以上消费满额符合以下条件时，即可把大礼抱回家~申请优惠邮件格式参考：折扣券类型折扣券限制优惠折扣用户名购买产品订购类型购买周期新购折扣券一年原价55折折扣前原价7920折扣后4356优惠2239MYSQL    5.6  单机版新购包1年

目前，华为云数据库双11大促火热启动，血拼风暴，高性能云数据库MySQL4.5折起，为运维”无忧放假“，即开即用，全托管式部署升级运维，更有1亿红包等你来领取，详情猛戳：https://activity.huaweicloud.com/2019nov_promotion/index.html?utm_source=weibo&utm_medium=sm&utm_campaign=s11_1023&utm_content=sjk_s11#gift

10月10日，2019锦江都城酒店管理有限公司（以下简称“锦江都城”）全国总经理年会在上海举行，作为华为云重要客户，华为云数据库服务总经理苏光牛被特邀参会并作主题演讲。演讲中，苏光牛分享了华为企业文化和核心价值观，并介绍了华为云助力锦江都城数字转型升级的的系列实践，进一步推动了华为云与锦江都城的深度合作。牢记以客户为中心理念，以奋斗者为本“以客户为中心、以奋斗者为本、坚持自我批判、长期艰苦奋斗”，这24字箴言是华为人秉承于心的核心价值观，苏光牛结合锦江都城PMS上华为云的过程，在会上分享了这一理念。合作开始，华为云团队第一时间就和锦江之星信息部总监凌晨沟通解决方案，凌总告诉我们：“我的客户就是各个门店的经理和使用这些系统的人，不能让我的每个门店在业务暴增时系统出现问题….”。为客户服务是华为存在的唯一理由，华为时刻以客户为中心，因为我们深刻明白，理解客户需求是基础，为客户服务是手段，为客户创造长期价值是目的，并始终如一地践行着。但其实不仅是华为，锦江都城的管理者也是一样的，他们心中也时刻装着客户。苏光牛提到，在PMS系统迁移的关键时刻，锦江都城的唐雅文等员工时刻和华为在一起，凌总也亲自参与几个门店的验证过程。整个迁移过程处处透露着奋斗的普世价值观，不仅华为人在奋斗，客户也和我们一起奋斗，双方在共同的奋斗中产生了信赖、友谊和尊重。这些核心价值观扎根于华为人内心深处，而此次助力锦江都城数据库上云也是一次践行华为核心价值观的重要典范。未来客户还会有更多的系统上华为云，我们还需要不断进步，不断提升，才能更好地满足客户的需求。华为云DRS仅用1小时助力锦江都城数据库轻松上云锦江都城PMS核心业务系统涉及到的变更多达几百项，有各种渠道、银行支付接口的变更，酒店硬件设备和公安等各种接口的变更，尽管我们做了回滚的方案，但迁移一旦开始，回滚将更加复杂，因而这对连锁酒店而言是业内难度最高的迁移之一。而华为人从不惧任何困难，难度越大，越是迎难而上。在实际迁移过程中，锦江都城依托华为云DRS（Data Replication Service），仅用1小时就完成了原定5小时的迁移。华为云数据库产品DAS（Data Admin Service），可以帮助客户对数据库做一次全面的体检，数据库内核优化的线程池技术、双非1技术、并行复制等技术，配合专家服务优化，数据库整体负载压力下降1+倍，关键业务流程效率提升36倍，成功助力锦江都城酒店数字化升级。相对于通过简单增加硬件的叠加来获取有限性能提升的方案，华为云数据库更注重在有限的硬件投入下如何提升数据库运行效率，为客户着想，永远站在客户角度思考问题，持续为客户创造长期价值，这是华为人矢志不渝的坚守和追求。未来，华为云希望可以携手更多像锦江都城这样寻求数字化升级的企业，为其提供专业优质的云服务，助力加快智能升级进程。更多详情了解请前往华为云官网：https://www.huaweicloud.com/product/drs.html?utm_source=wechat&utm_medium=officialaccount&utm_campaign=drs_1015&utm_content=sjk_drs

众所周知，谁在市场中真正懂得客户，谁将站在市场高地。华为云数据库长年奋斗在一线，与客户进行了深度接触和交融，真正了解客户最关心的诉求，并精心整理好了十个2019年度最热门问题，所有你想到的想不到的，全部都在这里，赶紧一睹为快吧！Question12019华为全联接大会推出了哪些云上数据库“黑科技”呢？ 华为云数据库发布3款分布式数据库新品TaurusDB、GeminiDB、GaussDB及两大解决方案——MySQL云灾备、RDS for MCS，聚焦金融、互联网、车企、物联网、游戏、ISV等行业，提供覆盖六大行业典型场景的完整数据库解决方案。Question2云上数据库和自建数据库有什么区别，云上数据库最大的优势在哪？自建开源数据库依赖专业DBA和数据库技术人员等手工下载版本、补丁、分析Bug情况，然后人工安装部署，面临各种运维难题。而云数据库能够让您几分钟内申请到一个基本能解决上述所有问题的数据库实例。云端完全托管各类管理任务（如硬件扩容、数据库设置、补丁升级和备份恢复），同时华为云有强大的技术团队保障修改数据库社区还未来得及修改的Bug的能力，从而保证可用率高达99.95%，让您专注于应用程序开发，远离数据库运维的烦恼。Question3OLTP VS OLAP的区别按数据应用场景分类：分为OLTP和OLAP数据库。OLTP是传统关系型数据库的主要应用，主要是基本的、日常的事务处理场景，例如人们到银行去取1000块所发生的背后交易所用到的数据库场景。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，如银行给个人授予100万的贷款额度(授信)，需要进行大数据分析的数据库场景。Question4关系型数据库 VS NoSQL数据库的区别 按数据结构分类：关系型数据库是基于关系模型来组织数据的数据库，具有数据存储结构化、数据强一致性等特点，（TaurusDB、MySQL、PostgreSQL、SQL Server等)，NoSQL数据库用于存储一些非结构化数据，如图片、文档、地理位置信息等（DDS、多模NoSQL服务、Redis等）。Question5TaurusDB VS 开源MySQL 开源MySQL主要满足中小型业务系统的需求（QPS<12万），基本无法满足大型业务负载；而TaurusDB依托华为云最新一代硬件专为大型业务系统设计和打造，在完全兼容MySQL基础上性能提升高达7倍，百万级QPS，扩展性较非云源生数据库提升5倍，支持1写15读；容量支持最大128T；在数据0丢失的前提下，故障秒级恢复。Question6多模NoSQL服务GeminiDB中的多模是什么意思？GeminiDB有哪些黑科技优势？ 多模是多种数据模型的意思。当前GeminiDB已支持Cassandra接口、MongoDB接口，后续还会支持更多主流NoSQL接口。GeminiDB基于华为云最新一代DFV计算存储分离架构，实现分钟级扩展；相比于社区版和其它友商的基于开源的服务化版本，大幅优化长尾时延，集群更稳定，备份恢复性能提升5+倍，被2019中国数据库技术大会（DTCC）评选为年度最佳创新产品。Question7数据库迁移时，怎么保证对业务没有影响？DRS迁移时如何确保数据不丢失？DRS迁移时，对源数据仅仅是做最轻量的查询，没有任何锁等额外动作，同时对数据进行切片抓取，最小粒度的进行迁移，避免对源库产生大的性能消耗，同时业内独有的流控技术，限制流量的开销，避免对业务产生影响；DRS不但能检查迁移的一致性，而且很多贴心的设计确保迁移时数据不丢失。Question8DRS数据库迁移这方面有哪些客户案例吗？华为云DRS已成功支撑包括金融、互联网、车企、物联网、游戏、ISV 六大行业上千家企业云上迁移。锦江都城依托华为云DRS，仅用1小时就完成了原定约5小时的迁移，整体负载压力由80%降至20%，关键业务流程效率提升36倍，成为酒店管理行业云上迁移解决方案的典范。Question9华为云数据库的去O方案是什么？ 目前全球没有一家厂商能够提供百分百完全兼容Oracle的替代产品，但华为云数据库PG增强版，Oracle语法兼容性90%以上，仅需做部分边缘业务改造就可以完成去O目标，目前华为云已成功帮用友、金蝶、赛云等多个企业领先行业完成Oracle改造上云。Question10GaussDB和TaurusDB、GeminiDB三者的关系？TaurusDB和GeminiDB都是华为云基于主流开源版研发的分布式数据库，性能、可靠性、容量、扩展性等远远优于开源版。TaurusDB是关系型数据库MySQL的优化版，适用于传统OLTP场景。GeminiDB的定位是NoSQL领域，兼容MongoDB、Cassandra等多个主流NoSQL接口，产品已上线。、而GaussDB是国产数据库代表产品，自主可控，是基于鲲鹏架构的OLTP数据库，适用于政企、银行、保险等（国家要求只能用国产数据库的行业，场景），并且GaussDB能高度兼容Oracle常用语法，预计将在2019年12月份正式公测。  这十个问题涵盖了分布式数据库TaurusDB、GeminiDB、DRS迁移、GaussDB等相关数据库问题，聚焦客户痛点，为六大行业提供了新颖独特的解决方案。未来，华为云将持续构建业内顶尖的技术资源，为客户提供更高价值的数据库解决方案、产品和服务。

2019年的夏天，华为云数据库携TaurusDB性能挑战赛与来自30+重点高校、20多个行业等近千名数据库爱好者进行了一场技术上的碰撞与思想上的交流，在为期近三个月的比赛中，收获了很多故事与满满的感动。近500支队伍在层层赛制激烈的角逐中，终于诞生出了决赛10强，而前六强席位颁奖则于9月18日在华为全联接大会举行。0xCC单枪匹马的王者0xCC是一支单人团队，也是本次大赛的冠军，选手口中的CC大神，拥有丰富的数据库、中间件比赛经历，并多次斩获大奖，知名度较高。CC毕业于南京理工大学，入职刚满一年，高中时期就很喜欢计算机编程并自行研究，本科生时期积极参加了很多大大小小的比赛，研究生时期也参加了许多国内比赛，凭着自己一腔热爱与对技术的执着勇敢走到了今天。华为云主要在大赛中起到一个基础平台的作用，参赛作品依托华为云弹性服务器、NVME和高性能网卡，实现了超高吞吐量的数据读写。只有借由这个平台，才能发挥作品的全部性能。关于大赛CC如是说道，并指出技术是以人为本的，希望通过技术让人们的生活更加美好。Watermelon三人组名校高材生这是一支集结了上海交通大学、浙江大学两所名校研究生的三人团队，三人目前均是研二在读。他们三人曾组队参加过两次比赛并闯入决赛，这是他们参加的第三个比赛，也是毕业前最后一个比赛，能够获奖他们感到十分幸运。源于对数据库的浓厚兴趣和狂热喜爱，他们一边实习一边利用空闲时间来提交比赛作品，凭借过硬的技术实力，在众多学生队伍中脱颖而出。华为云技术在两个方面给予了我们很大帮助。一方面，从评测环境的角度，华为云提供了高性能的服务器与磁盘，可以使我们在作品中的一些优化点充分的体现出来；另一方面，华为云在这次比赛中提供的一些技术资料，也对我们在作品中计算存储分离的设计，起到了很大的帮助。三人均认为华为云TaurusDB 的计算存储分离架构对于数据的存储、磁盘性能的提升还是很厉害的，对华为云技术予以肯定与支持。这是一支由资深码农和技术网红组成的两人组团队——这位“码农”是一个经验丰富的大神，有好几年的工作经验，技术很强，但为人低调。而他的搭档是一位喜欢分享技术和大赛心得的网络写手，同时也是技术大牛，比赛期间经常在选手交流群分享做题中遇到的一些坑，以此提醒其他选手，是一个暖心的95后技术网红。对于华为云最新一代高扩展海量存储分布式数据库TaurusDB，他们提到：在大数据存储的场景下，分布式数据库的优势越发凸显，可以解决传统数据库所面临的容量问题。华为云TaurusDB单实例扩容数据可达128T，容量十分强大。ADSL三队渴望成就自我的高校研究生这是一支两人组学生团队，两人均就读于中国科学技术大学，目前研一在读。他们表示此次参加华为云TaurusDB性能挑战赛是一个很不错的契机，可以借此检验自己的学习成果，因此对这次比赛格外用心。但由于时间问题，在作品呈现中有一些优化点没有完全实现，对此感到十分遗憾。虽有缺憾，但两人在比赛中依旧成绩斐然，摘下了季军宝冠。华为云给我们比赛提供了评测环境，并给了我们机会接触到一些领先的硬件设备，使我们能够在这上面实现自己的一些优化想法。他们十分感激华为云提供了这么一个技术交流平台，在比赛中见识了各类牛人大咖的风采，希望自己能够沿着这条路继续走下去，成就自我。Pilipala首次参赛的资深程序员Pilipala是一支三人组团队，其主创人员是一家公司的分布式存储团队负责人，工作多年，拥有丰富的数据库产品经验，一得知华为云TaurusDB比赛，立马组队积极参加，想与更多技术大咖进行技术碰撞及交流。由于是第一次参赛，且因为公司项目比较紧急，参赛精力有限，最终呈现的作品只是他们原先设想的一个子集，一些优化没有完全展现出来，因此希望明年华为云数据库还能举办这样的比赛，自己会全身心投入。这场比赛是基于华为云最新一代高扩展海量存储分布式数据库产品TaurusDB举办的。华为云TaurusDB采用计算与存储分离、日志即数据的架构设计，支持1写15读，完全兼容MySQL8.0，性能达到原生MySQL的7倍。此次大赛的一等奖得主是0xCC，二等奖得主为Watermelon和Rollbacked，三等奖得主共3名，分别是Kirito的技术分享、ADSL三队、Pilipala。这6支队伍在大赛中表现卓越，引人注目，近三个月的辛苦付出终换得如今的奖冠加身，荣耀时刻，光辉万里长。目前，华为云数据库正在积极开展开发者生态发展计划，华为云TaurusDB性能挑战赛只是其计划的一部分，希望通过这次大赛能携手更多数据库领域开发者共建一个开放、合作、共赢的数据库产业生态，共同创造智能未来。 

1、前言华为云TaurusDB结束有一段时间了，这几天抽时间写一下参赛总结，我是从阿里第三届中间件比赛开始参加类似比赛的，TaurusDB这次是第三次，虽然有过两次参赛经验，但是数据库比赛还是第一次，报名也是无意中看到朋友在朋友圈的分享，正好想要学习一下数据库相关知识，于是报名参加了比赛，熬了无数个夜晚，很幸运最终以第10名的成绩擦边入围，主要还是cpp大佬和其他选手承让^_^。2、赛题回顾比赛分成了初赛和复赛两个部分，初赛要求实现一个简化、高效的本地 kv（为简化开发，K固定大小8B，V固定大小4KB）存储引擎，其中每个KVStore为一个实例，每个线程操作独立的KV实例，线程间互不影响，复赛在初赛的基础上增加了计算存储分离的架构，计算节点需要通过网络传输将数据递交给存储节点存储。程序主要提供三个接口：评测程序分为2个阶段正确性评测此阶段评测程序会并发写入随机数据（key 8B、value 4KB），写入数据过程中进行任意次进程意外退出测试，引擎需要保证异常中止不影响已经写入的数据正确性。异常中止后，重启引擎，验证已经写入数据正确性和完整性，并继续写入数据，重复此过程直至数据写入完毕。只有通过此阶段测试才会进入下一阶段测试。性能评测随机写入：16个线程并发随机写入，每个线程使用Set各写400万次随机数据（key 8B、value 4KB）。顺序读取：16个线程并发按照写入顺序逐一读取，每个线程各使用Get读取400万次随机数据。热点读取：16个线程并发读取，每个线程按照写入顺序热点分区，随机读取400万次数据，读取范围覆盖全部写入数据。热点的逻辑为：按照数据的写入顺序按10MB数据粒度分区，分区逆序推进，在每个10MB数据分区内随机读取，随机读取次数会增加约10%。评测环境计算节点：内存占用不得超过4G(CPP), 5G(JAVA)，不得写入和读取磁盘空间。存储节点：内存占用不得超过2G(C++),3G(JAVA)，磁盘占用不得超过320G。注：后台将CPU统一限制为16核。语言限定CPP & Java，一起排名3、赛题分析拿到赛题后首先我们对赛题已知条件做下分析：数据总量为4M*16(64M)条数据Key数据总量为64M*8(B)，索引可以完全加载到内存定长Key(8B)和Value(4KB)极大简化索引构建和写入缓存设计读取分为顺序和逆序遍历(10M内随机)可以考虑使用LRU作为缓存策略kill -9保证数据不丢需使用mmap保证数据最终落盘因为我们比系统更了解程序的缓存策略读写考虑使用DirectIO+自管理缓存计算存储分离可以把存储节点当作一块磁盘对外提供read, write接口，把索引构建及索引查找放到计算节点因为DB是分布式的应考虑使用大块网络传输来减少rtt带来的性能损耗可以看出此次大赛的核心考察点是计算存储分离，因为计算量不大，存储介质性能又非常强悍，程序的瓶颈可能是在网络层面，如何高效利用网络是本次比赛重点思考内容。4、程序设计4.1 功能设计首先要考虑的是功能评测，即保证kill -9数据不丢，因为一个程序只有功能正确才能谈性能，保证kill -9数据不丢有两种方式，第一种是来一条数据写一次盘，每条数据都即时落盘，这个方式虽然可以保证数据不丢，但是性能堪忧，好在操作系统给我们提供了另一种方式mmap（memory mapping），通过mmap可以将文件直接映射到user内存区，user可以直接操作这块内存，程序可以通过主动（force）或者被动（程序结束或崩溃）方式将内存中的数据持久到磁盘，这个过程不经过kernel内存区，省去一次内存拷贝，同时也保证了数据安全。保证了存储节点数据不丢后下面要考虑在有网络传输的情况下数据不丢，如果允许数据丢失则可以使用异步io方式传输数据，但是要保证数据不丢则计算机点需要一直阻塞直到存储节点数据落盘并返回ack后计算节点set方法才能返回，这样网络模型为PING/PONG模型。4.2 文件分布设计因为程序是多实例数据库，实例之间互不干扰，这里没有对数据进行分片操作，其实换一个角度看我们可以把每个实例看作一个数据库分片，因为分片的目的是为了让分片之间互不干扰，提高程序并行能力，每个实例(分片)内的写操作都比较简单，采用追加写的方式。每个实例包含3个文件： MergeIO(mmap)：merge io索引文件(mmap)：Key实际存储文件数据文件：Value实际存储文件写入Value时先写入MergeIO文件，Merge满后批量写入数据文件，即使程序被kill，也可以从MergeIO文件恢复Value数据。这里感谢一下徐靖峰(岛风)同学开源的kdio(java操作DirectIO的库)4.3 索引设计数组二分查找：构建索引时需要排序，单点查询对cpu分支预测不友好，但是方便进行范围LongIntMap(开放寻址法)：可以动态构建索引，单点查询可快速定位（key冲突量不大时），难以范围查询因为这里考虑只有单点get没有范围查询，所以用了LongIntMap 4.4 读取设计读取采用LRU算法对数据进行缓存读取，每个LRU Item包含4M Value数据(1K个Value，参数可调)每个实例包含14个LRU Item，包含4M(总消息数)/1K个空Item，比如说通过Key找到Index为1，对1取模得到缓存位置0，因为缓存已存在则直接使用item.get(),如果Index为1024，因为缓存不存在，则根据缓存最后访问时间找到需要失效的缓存，通过read方法从存储节点读取该缓存的内容，然后get出结果。4.5 网络传输设计存储节点：存储节点采用Epoll EventLoop模式，节点启动16条线程，计算节点与存储节点tcp连接均匀分布在16条线程上，后面数据交互均在固定线程完成，充分利用多核优势。计算节点：计算节点采用bio方式与存储节点建立连接，计算节点与存储节点交互均采用req/res阻塞模式交互。计算节点从存储节点read数据时，存储节点dio读取的数据直接使用ByteBuf.wrap，没有内存拷贝(程序层面)，直接发送给计算节点。连接建立后开启tcp_nodelay以减少网络延迟。在比赛结束最后一天之前计算节点一直用的nio开发，写入耗时始终在719秒往上，因为一直觉得虽然nio在发送接收时与set/get线程有cpu切换，但是这些切换耗时与网络rtt相比应该不算什么，可事实总是在啪啪啪打脸，最后一天（其实也就写好两三天的样子，java环境最后几天才好，(/ □ \)）把nio改写成bio传输，写入时间从725降到560左右（不确定是否是因为cpu切换导致），总结一下就是不能搞经验主义，一定要benchmark everything。5、可探索的改进一般情况下我们使用nio都是将其fd绑定到某个event loop上，该event loop监听该fd的事件，这里其实我们可以改变nio使用方式，在set/get当前线程监听fd事件来读写数据，有set/get线程充当event loop，可能会有一个不错的提升。6、一些感想第一次参加数据库相关的比赛，收获颇多，对数据库相关知识有了初步的了解，也学到了其他选手不错的分享，同时也非常感谢举办方举办这次比赛，给选手提供一个展示和学习的平台，预祝比赛越办越好。源码地址：https://github.com/wangkaish/hw_race2019_r2_kvstore 

大家好，我们是watermelon团队，今天我们的答辩展示主要分为四个部分来介绍。首先是我们的团队和成员的简介然后是我们对这次题目重点的理解接下来，我会介绍一下我们最基础的架构，包括网络、磁盘、缓存等最后，重点介绍我们每一个性能优化点团队名叫watermelon，我们三个人都是在读的研究生，分别来自浙江大学和上海交通大学，都是明年毕业。初赛和复赛的成绩都是第四名，历史成绩非常的稳定。我们总结了几个题目重点：首先，KV 都是定长的：这样简化了⽂件和内存的操作和管理。第二点，value远大于key：把 KV 分离存储，解除索引和数据之间的耦合性。第三点，线程数固定：测评程序固定使用 16 个线程访问数据库。第四点，只需要保证进程意外退出时的持久性：所以可以利用操作系统的缓存对写入方式进行一些优化。第五点，分阶段测评：随机写、随机读、顺序读三个阶段互相没有重叠。第六点，计算节点无状态：我们知道，在这种基于共享存储的计算存储分离架构下，所有持久化数据只能存于存储节点，计算节点只进行逻辑操作。第七点，数据读取的线程和数据写入线程之间没有绑定关系：就是说，每个线程不是只读取自己写入的数据。  //与初赛不一样，读取线程id不一读的是相同id写入的数据最后一点，随机读的随机性在每个时刻只局限在一个 10M 热点分区内：并且热点分区按写入的顺序逆序推进。 下面是我们方案的核心架构:    我们计算节点和存储节点的线程采用一对一的tcp连接，因为测评程序是16线程，所以连接数就是16。在存储节点，我们有数据持久化产生的文件，以及读写文件的缓存。在计算节点，我们维护了读数据的缓存，但是没有写数据的缓存，因为要保证计算节点被 kill 的数据持久性。并且我们的索引也是只在计算节点上维护的，在数据库启动阶段从存储节点把索引数据拉到计算节点。接下来，具体介绍一下我们的文件组织形式:首先，按写入线程进行数据的分区，就是说，每个写入线程只顺序写自己的分区文件，这样就避免了多线程写同一个文件冲突的问题。然后，在每个分区内，将 key 和 value 分离存储为两个文件，一个是key log，一个是value log。可以解除索引和数据之间的耦合性。并且我们为了提高写入value 的速度，对 value 进行了缓存，缓存中凑齐若干个value后，再一起进行刷盘。为了保证缓存不丢失，缓存也使用了mmap的形式，因此对应有一个缓存文件。我们的索引也是按分区进行构建的，每个分区是一个hash，里面存的是该分区所有数据的索引项，索引项就是一个 key 和 一个value offset复赛的优化历程，我们从最开始跑通的 2300 分，到最后的 780 分，中间经过了好几次架构和方法的改变。首先我们的第一个优化是，我们在启动阶段把 key 从存储节点批量的传到计算节点，这样相比每个 key 都请求一次，批量的方法相当于减少了一半的网络请求，使得时间提升了 300 秒。接下来，由于我们无法搞定网络传输大数据包的问题，因此我们选择先在存储节点实现顺序读和随机读的缓存，这样减少了存储节点的 io 次数，时间提升了 500s再后来，我们解决了网络传输的问题，所以先在计算计算节点进行了顺序读的缓存，成绩提升到 1100s这样紧接着，我们按存储节点缓存一样的思路，把随机读缓存也拿到了计算节点，这样做之后我们的成绩就已经突破了 800s在最后阶段，我们又优化了一些细节问题，最终成绩是 781s围绕读写文件，缓存策略，和网络传输这三个方面，来讲解我们是如何把这个系统的性能压榨到极致的。对于 key 这种小数据量的读写模式，采用 mmap 可以利用 page cache 将小数据读写转换为整个内存页的读写，减少了系统调用的时间消耗。value 的大小为固定 4KB，我们知道，写入数据大小要对齐 ssd 的内部 page 时，可以达到最优写入性能。我们经过线上测试，按 1M 大小顺序写入数据可以达到最大吞吐量。所以，为每一个分区分配一个容量为 1M 的写缓冲区，写满 256 个 value 再将缓存数据一起刷盘，刷盘方式采用 direct io。并且，用 mmap 做缓存，可以保证数据持久性。第二点，我们来看，如何做随机读的缓存，使得缓存命中率最高。现在背景是，随机读在每个时刻只局限在一个 10M 热点分区内，并且热点分区按写入的顺序逆序推进。看图，上面是我们实际存储的文件，按10M分为了若干个block，就是说，我们的缓存只能按 block 对齐进行加载数据。然后，下面是测评的热点分区示意图，我们发现一共 400w 数据，热点分区的边界跟实际数据 10M 边界很可能是不对齐的，并且边界值未知。所以，如果我们只用单个 10M 的缓存，会出现下面这样的问题。假设当前阶段，测评程序要随机访问 hot1 这个热点分区。第一个位置，我们缓存加载了block3，然后，访问第二个位置，发现缓存失效，加载了block2，继续访问第三个位置，缓存又失效了，重现加载回了block3所以，这样就产生了一个缓存来回震荡的问题，极端情况是，我要访问400万数据，一共要加载400万次大块的缓存，肯定超时，还不如不做缓存。我们的方案是，采用两个 10M 的buffer，一前一后，一起往前推进，这样非常完美了避免了缓存来回震荡的问题。并且这个 buffer 不一定是10M，只要大于10M都可以解决这个问题。第三点，我们来看，如何使得网络的传输效率最高。我们发现，写入阶段的网络传输时间主要瓶颈是在周转时间上，也就是说，不是网络有多么拥塞导致网络传输变慢，而是说，value发过去再回来，本身就需要这么长的时间。所以我们的优化只能是让存储节点尽可能快的返回ack信号，我们的做法是在数据写入存储节点的mmap之后，就返回ack，而不用等待page cache 刷盘。对于持久性，recover 阶段会把 cachebuffer 里面的数据都重新写进 value 文件里。对于大块数据进行拆分，然后进行多次发送，可以在发送的同时进行流量控制，使吞吐量保持在一个较高的水平。我们的流量控制方法非常简单粗暴，在发送每两个 4k 数据之间，直接加一个延时，延时的方法是让 CPU 自旋一会。并且，存储节点也做了读缓存，把存储节点的读缓存，批量拆分传到计算节点。最后，回到一个宏观的位置上来看，通过这次比赛，我们严格按照计算存储分离的思想来设计了我们的系统架构。对基于共享存储的计算存储分离架构有了一些认知和理解。首先，我们看计算节点我们的架构只支持一个 RW 节点，进行数据的写入。但是 RO 节点在理论上是可以无限扩展的。并且，由于底层的共享存储，所以主从复制的延迟可以做到非常低。当 RW 写入一个 kv 数据，对于 RO 节点，它只需要更新已经存在自己 buffer pool 中的数据，而如果发现 RW 写入的数据不在它的 buffer pool 中，那它什么也不做。只有在 RO 节点读取数据时，发现要请求的数据不在自己的buffer pool中，它才去下面的存储节点中拉取这个数据到自己的 buffer pool 中。这样看来，我们在实现高可用功能时候，可以很直接的进行主从切换，RO 节点可以迅速提升为 RW 节点，直接开始对外服务。再看存储节点我们当前只是在单个节点上保证了数据的持久性，而这种 kv 存储可以扩展为分布式架构，采用多副本存储，从而能获得更好的容错性，和更好的读写性能。所以这样一整套架构，可以解决很多实际的痛点，因此，会成为当今云数据库的一个趋势。

缘起TaurusDB是华为云自主研发的最新一代云原生分布式数据库，完全兼容mysql8.0，采用计算与存储分离、日志即数据的架构设计，支持1写15读，性能达到原生Mysql的7倍。Taurus构建在共享分布式存储上，存储空间最高达128T，能跨AZ部署，具有可靠、高性能、易伸缩等特性。华为云TaurusDB性能挑战赛是由华为云主办的数据库领域顶级赛事，大赛将综合科研教学成果及商业领域需求，探索数据库领域的技术问题的可行性，为需求方和开发者提供联接的桥梁；并联合合作伙伴，搭建一个技术交流、人才培养、机遇共创数据库开发者平台和生态。听起来很激动人心吧，关键是奖金也很多, 同时还能刷脸! 最早是听一个同事说起的，恰好本人的工作也是“新一代数据库”开发，看着这么多人工智能的比赛不能参加，只能后悔自己选错了专业，但是机会来了，终于有自己擅长的领域了，心想不能错过这次机会，一边默默加了收藏。比赛内容一句话概括，就是实现一个kvstore，初赛是单机引擎，复赛要求存储计算分离，并且kv都是定长的，如果通用性做得好，可以直接用作块存储。题目初赛和复赛稍有区别，这里只说复赛的题目。存储引擎K,V都是定长的，key 8bytes， value 4K bytes。 测试分为三轮，第一轮, 16个线程写，每个线程写400万次；第二轮，16个线程读，每个线程按顺序读取400万次；第三轮，16个线程读,每个线程逆序读取400万次。第三轮的逆序是局部随机，总体逆序，也即在10M的数据范围内随机读，然后以10M为单位逆序推进。 成绩就是看总时间，时间越短越好。前面已经说过，初赛要实现的是单机引擎，复赛要实现的是存储计算分离的引擎，最大的限制是计算节点不能持久化任何数据。预选赛不得不说，华为可真会玩，这次预选赛竟然还要做题，并且是必须要学习他们的资料才能通过的题目，题目包括数据库的基本常识，但是也有产品介绍，经过深夜两个小时的学习，我算是第一次知道了这么多种不同的产品究竟是干嘛的。第一次答题还错了一道，以防万一，又做了一遍，这次错了两道，算了不玩了，95分也够了，睡觉去。但是心里总是不舒服，究竟是哪错了，又看了一遍，原来是幻读的理解这道题错了。初赛不出意外，预选赛顺利通过，初赛就开始写代码了，初赛只要写对差不多就可以晋级复赛。 当然任何一个程序员都不会满足刚好够用的状态，因此正常能想到的优化都加上了： 比如Direct IO, 多文件做数据分区，引入写buffer，比较频繁修改元数据，读取使用自己实现的page cache，以免4K读不能打满磁盘带宽。复赛复赛要求存储计算分离, 我认真做了一些分析，同时也对他们的硬件做了测试，分析下来，这个比赛比拼的点和我平时在工作中要追求的还是很不一样的。 平时无论做什么系统，都是在延迟差不多的情况下，把吞吐量做高，这次比赛最关键的一个点是：延迟第一，延迟是最重要的，特别是写的阶段，因为并发只有16，想通过聚合换吞吐量都不好使了。首先考虑持久化方法：4K恰好能对齐IO，所以key和value要分开存储,      想使用rocksdb之类的存储引擎即使不被禁止也是没有竞争力的。value非常随机，基本不用考虑压缩，就算有一点点好处，实现起来也太复杂了。再次考虑如何优化IO:SSD的IO吞吐量高于4K * iops, 不管是读还是写，IO聚合是必须的。单文件会遇到文件系统瓶颈，需要多文件, 也即要对数据做partition。关于同步IO还是异步IO的选择, 因为延迟优先，所以应该选同步IO。最后考虑网络框架:首先，我直接放弃考虑任何已有的网络框架，因为这是benchmark， 再小的开销也是开销，都会让程序变慢。其次，实际上任何IO      multiplexing的框架都会造成额外的延迟，不仅复杂，也是得不尝失的。综上，我决定就使用最简单的阻塞式IO来做socket通信。总体设计计算节点和存储节点分工, 关键就是索引维护在哪？经过思考, 决定索引维护在计算节点。 索引的内容是: key -> <file_id, pos>, 索引在计算节点的内存中维护为hash表。因为build索引大概需要400ms，写入再读取index比重新构建一遍index时间还长, 所以索引不需要持久化, 这其实是一个反直觉的决定。 计算节点在发送第一个读请求之前，会从存储节点把所有写入的key和pos发送过来, 然后由计算节点构造索引。存储节点起16个线程，listen在16个不同的端口。计算节点也会有16个线程， 每个计算节点的线程只会连接一个存储节点的端口，从而和一个存储节点线程通信。写入请求：写入过程不同的线程完全独立，每个线程负责一部分数据。请求发到存储节点后由接受请求的线程写入。读取过程:读取过程每个存储线程会读取任意一个线程写入的数据。由计算节点指定要读取那个分区的数据。也即写请求发到哪个存储线程，就由那个存储线程写入，每个存储线程实际上就对应了一个数据分区。 读请求发到一个存储线程，它可能要跨线程读取其它分区的数据。存储文件存储节点把数据分为16个partition，每个partition由一个线程负责写入。 每个partition共三个文件: 之所以有三个文件，是因为首先key和value要分开存储，这就要用两个文件；其次为了优化写，额外引入了文件做写入buffer。文件命名规则如下, 以第一个分区为例:00.k: 保存写入的key。 fallocate 4M * 8B， mmap到内存。00.v:      保存写入的value。fallocate 4M *      4K， DIO读写。00.b:      用作写入buffer。fallocate 16K      buffer + 4K 元数据，mmap到内存。写入原子性先写key和value，再更新key count。 key count改成功，则写成功；否则写失败，下次重启进程当作这次写没发生过。换句话说，key count改成功实际上表示这次写入commit成功。key count记录在00.k的第一个8字节, 如前所诉, 00.k是mmap到内存的，所以更新key count是没有什么代价的。value先记录到写buffer里，然后批量刷到00.v文件。key file内容如下:key countk1k2k3k4k5k6……value file内容如下:value countv1v2v3v4v5v6……buffer file内容如下:b0b1b2b3…………b15flushed poswrite buffer也是mmap到内存的， 前64K记录数据。 紧跟64K的8个字节记录flushed pos。 因为mmap必须以page为单位，所以实际内存占用64K + 4K。 它实际上是一个mmap持久化的ring buffer。 Ring Buffer的元数据包括filled pos和flushed pos。 filled pos由key count可以算出来, 所以不需要单独再记。build indexbuild index实际上是构造一个key -> offset的hash表。 要在400ms内完成build index，难点是如何并行：基本思路是把key做partition，每个partition内独立构造hash。这本质上是一个MapReduce的过程。map阶段: 并行划分range, 16个线程，每个线程负责处理一个key文件。reduce阶段: 并行构造hash, 16个线程，每个线程处理一个range。线程同步: 第二阶段开始之前要等第一全部完成，也即两个Stage之间是个Barrier, 这个同步过程和map reduce的shuffle是类似的。读取cache的实现cache是value的镜像，value文件分成了16个，cache也对应分成16组。 因为顺序和热点访问模式对cache都很友好，cache不需要特别大，每一组cache大小为64M。为了应对热点读，cache的最小单元设为16M，借用CPU cache的术语，我把它叫cache line，这是一个很大的值。 cache的内存因为是定长的，所以通过mmap一次申请好，不需要动态分配。 cache的索引本质是一个hash，但是不用解决冲突, 用file offset直接计算得到索引的下标。对16组cache中的每一组来说，有4个cache line, 每个cache line有三种状态，用一个uint32_t表示：Invalid: UINT32_MAXLocked:      UINT32_MAX - 1Valid:      file_offset »12cache line的状态被叫做indexStat，它被单独记在另外一个小数组里。读取不用加锁，使用double check即可:读取之前检查IndexStat有效，并且offset和我要读取的内容匹配。拷贝cache line的内容到私有buffer。拷贝完cache line的内容后再检查IndexStat是否发生过变化, 如果indexStat没有变化过，则说明我们拷贝的cache      line内容是对的。为了让上述double check生效, 更新cache的线程需要在写入之前把indexStat改为Locked，更新完成后再把indexStat改为有效值。关于网络通信关于网络框架还有一个问题，就是是否有必要用UDP，犹豫之下，觉得UDP还是会更复杂，稳妥起见，选择了TCP。后来得知在测试环境里UDP是不同的，也就释然了。但是TCP看起来开箱即用，用起来却暗藏机关，至少要调整以下三个参数:tcp_nodelaytcp_quickacksend/recv      buf最后为了规避TCP的流控，我们要避免另外两个坑:避免发送太快，超过交换机的队列长度，从而导致丢包，因为TCP的工作方式就是，只要你给它数据，它就会不停的加大，发送窗口，直到发生丢包，然后触发限流。要避免这种情况，本质是要限制TCP的连接数， 因为只要连接数限制住了，发送窗口总长度也就限制住了。避免TCP”冷却”之后重新进入慢启动状态，如果有root权限，是可以通过sysctl关闭slow start的，但是我们没法控制系统参数，这就要求我们一个连接最好要不停的发包，不要停下来。有人定义了packet格式，而我遵循一切从简的原则，没有实现通常RPC要有的功能:没有定义pcode，因为整个通信过程就只有读和写两种request，每一个socket只用来发送一种类型的request，如果要发送不同的request，只需要切换socket即可。没有实现序列化，因为request很简单，只需要把结构体直接发送到socket即可。细节决定性能细节也就是很多关于性能的小点：首先关于文件IO: 同步IO比异步IO延迟要小; open的时候加入O_NOATIME避免读取操作也修改元数据其次关于内存分配: 分配完内后提前触发page fault至少可以让性能更稳定，如果不能提高性能的话；      分配内存可以尝试hugepage, 失败之后再使用4K page; mmap的内存可以不用清零最好关于CPU, 绑核，通用可以让延迟更稳定, 理论上对性能是有提升的。正确性测试如前所属，我基本上是一切从简，但即使如此，提交了好多次，都通不过正确性测试。为了排查问题，专门写了一个随机的验证程序，这个比官方的测试强度高多了。确实发现了一个readv之后更新iovec的bug，还有一处cache的bug。 事后看来，在这个测试上花的时间非常值得，否则我可能到最后都没有成绩。总结这次比赛感觉有点像马拉松，听完大家的分享，感觉每个人的时间都比较有限，大家都是争分夺秒,每个人都有一些优化没来得及试。本人最大的一个遗憾是读预取没有实现。另外一个是写的过程中网络和IO并行化做的不好。最后听了第一名的方案，深有体会，要想拿到最好的成绩，需要把写和读分开考虑，同时把网络传输和本地IO分开考虑。单纯从工程上说，我的代码有一些特有的风格, 简单来说就是总爱重复造轮子，不愿意引入依赖：没有用pthread mutex/cond，全部用atomic      ops + futex没有spin，等待的地方都有睡眠和唤醒机制另外，本人虽然工作中用C++, 但是我情愿用plain old C, 所以我很少用高级C++特性。如果未来还做这种系统实现的比赛，希望有可以利用RDMA的和NVM的比赛, 毕竟，新硬件总是有更多的可能。当然比赛的设置要考虑引入更多自由度，这样会更加有趣。 

赛题分析赛题要求一个无状态的计算节点和一个存储节点，并要求保证程序崩溃时的数据完整性，所以当计算节点写入时必须等待存储节点的 ack，而存储节点需快快确保数据写入到 page cache。赛题说明 16 个线程，每个线程写入 4 百万条记录，按写入顺序读取及热点区间读取，所以数据按写入线程分离存储。此外 Key 大小固定 8B，value 大小固定 4KB，所以需要批量写入才能打满带宽，并且索引只需要保存位置序号就可以，减小了索引的大小。整体架构针对赛题的要求，可以把问题分解成三个模块来看，分别是计算节点，存储节点和网络通信，因此我们设计了如下图所示的总体结构。在存储节点上，数据分为 16 组存储，按照写入线程分组，保证同一线程的数据写入到同一分组，这样在读取阶段不论是按写入顺序读取还是热点区间读取都可以一次从一个分组中读取一整块 cache，降低网络开销，另外这样并发管理也比较简单，因为一个线程只会对应到一个文件，所以读写的时候是不需要对分组加锁的。具体到到每个分组内部，key 和 value 是分离存储的，因为 key 和 value都是定长的，kv 分离以后恢复索引时只需要读取 key 文件就够了。最后存储节点会保证一旦写入成功数据就不会再丢失，也就是可以容忍 kill -9 退出。我们把索引放在计算节点，并且使用 TCP 进行节点间通信。由于并发数目不高，所以计算节点初始化时创建 16 条 tcp 连接，每个前台线程对应一条连接，在存储节点为每个 tcp 连接创建一个新线程。数据在写入时首先由计算节点发送写请求到存储节点，存储节点收到请求并确认数据成功写入不会丢失后，会把存储的位置回复给计算节点，然后计算节点把位置代入内存索引后返回。读取时计算节点首先根据内存索引判断数据在不在 cache pool 里，如果不在就去向存储节点读取一块新的 cache，然后从 cache 中读数据。存储节点之前我们也提到存储节点按写入线程分组，每个分组里包含四类文件，value data 文件保存 value，key data文件保存 key，两者各有一个 mmap buffer 文件，用来将写入 batch 到一起再刷盘。然后有一个全局的 mmap meta file，记录各个分组当前的数据长度，也就是各分组分别有多少个 kv 对，主要用于数据恢复和重建索引。数据写入时直接将key和value写入对应分组的mmap buffer，两者都写入成功后更新 meta file。只有当 mmap buffer 写满了以后才会 flush 到磁盘中，并且 flush 操作都是用 directIO 进行的。采用这种设计使得写入均是内存操作，将数据写入到 mmap 管理的 page cache 中即可返回，并且我们对mmap使用了mmap_lock标记使其一直锁定在内存中，只有当程序退出时才会刷盘。每次向data文件刷盘都是以一个 buffer 为单位，这样可以最大化利用 nvme 磁盘带宽，采用 directIO 的方式刷盘可以跳过 page cache，一方面减少了一次内存复制，另一方面降低了阶段切换时清空 page cache 的时间。而 mmap 的机制保障了即使进程意外退出，操作系统也会让 mmap buffer 中的数据安全落盘，不会引起数据丢失。我们实际为每个 key 和 data 文件维护了多个 mmap buffer，当一个 buffer 写满时转入后台 flush，接下来的写入会写进另一个 buffer。这是因为写入操作的开销是由网络传输开销和磁盘 IO 开销两部分组成的，单个buffer的情况下两者完全串行执行，在发生刷盘时写入操作需要消耗网络传输加上磁盘IO的时间。采用多个 buffer 以后相当于将磁盘 IO 与网络开销并行化了，产生的阻塞会减少很多。对于数据读取操作，读请求会将 offset 对齐到 cache 长度，也就是 10MB，然后存储节点直接以 directIO 方式从对齐后的 offset 处读出这一块数据返回即可。当存储节点意外关闭时，因为我们已经确保了所有数据都能安全落盘，唯一需要恢复的就是 mmap buffer 文件当前的写入位置，所以只需要从 meta file 中读取个分组的长度，对 buffer 长度取余便可以计算出各 buffer 的当前写入位置了。计算节点计算节点中主要包含了索引和 cache 两部分。索引部分，索引存储在 hash 表中，每个 entry 的格式为 (key, 分组编号+分组内偏移量)。因为 key 和 value 都是大小固定的，因此偏移量只需要保存它是分组内的第几个 kv 对，所以只需要 4 字节。因此每个 entry 的空间占用为 key 8字节加分组编号 4 字节加偏移量 4 字节，总共 16 字节，那么 6400 万个 entry 一共需要大约 1G 左右空间，因此可以完全保存在内存里。我们实现了一个原子的 hash 表。hash 表底层是一个大小为 8000 万左右的数组，以线性探测法处理 hash 冲突。说hash表的每一个 entry 由两个 64 位无符号整数组成，分别代表 key 与索引，并初始化为0。因为 key 本身可能是0，所以我们让分组编号从1开始，然后对索引部分的原子变量做 cas 操作来实现原子代入。代码如下：因为计算节点本身是无状态的，所以重启时需要恢复索引。我们把索引恢复的时机放在第一次 get 操作的时候，这样可以避免写入阶段计算节点请求恢复索引。索引恢复由 16 个线程并行执行，每一个线程向存储节点请求一整个 key 文件，因为 key 在 key 文件中的位置与 value 在 value 文件中的位置是一样的，所以遍历 key 文件就可以重建索引了。如果每次 get 都去存储节点读取，那么网络延迟开销太大，无法打满带宽。所以我们每次向存储节点请求数据时都读取一整块数据保存在内存 cache 里，大小为 10MB。由于我们不确定是不是完全按照 10MB 对齐的，因此我们为每个分组准备了两个 cache，这样当 cache miss 时，可以保证前一块 cache 的数据一定已经被读完了，可以被新的 cache 置换掉。此外我们还实现了 cache 预取机制。由于赛题要求顺序读取及热点区间读取，热点区间读取是按照数据的写入顺序以 10MB 数据粒度分区，分区逆序推进，在每个 10MB 数据分区内随机读取，所以当向存储节点请求一个新 cache 完成时，另一个线程会根据当前两个 cache 的 offset 之差向存储节点预取下一块 cache。在顺序读取阶段差为整数，因此会顺序预取，在热点区间读取阶段差为负数，因此会逆序预取。总结我们的最好成绩是 786 秒，其中写用了 505 秒，顺序读取用了 134 秒，热点读取用了 147 秒，最终排名第 5 名。此外各阶段分别跑出的最佳成绩为505/132/142秒，可惜我们对读操作的优化是最后一天完成的，但是最后一天的评测环境不太好，写性能一直上不去（我们的写入时间基本稳定在520秒以内，但是最后一天一直在560秒+）。在热点读阶段实际消耗在读取上的时间为133秒，但是恢复索引使用了9 秒，这里还有很大的改进空间。考虑到评测系统的带宽大约15Gbps，我们的读取性能已经基本跑满网络带宽了。第一次参加这种类型的比赛，我们学习和积累了很多经验，希望来年还有机会参加，取得更好的成绩。 作者:ADSL

“华为是个可怕的对手，一旦下定决心做某件事，鲜有做不成的。”这句在圈内少有达成共识的话，也正在一步一步得到应验。很多人或许以为，华为的优势并非软件而是硬件，但其实在数据库软件领域，华为也玩得风生水起。9月18-20日，2019华为全联接大会在上海世博中心举办。会上，笔者又一次采访到了华为云数据库服务总经理苏光牛，对华为云数据库研发路线图有了更清晰的认识。3个新品+2个解决方案此次HC大会上，华为云总计发布了3款数据库新品，分别是多模NoSQL数据库GeminiDB、云原生分布式数据库TaurusDB和频繁曝光的GaussDB数据库全新上云，以及2个解决方案，分别是MySQL云灾备及RDS for MCS解决方案。 事实上，GeminiDB、TaurusDB、GaussDB这三个名字并不陌生。GeminiDB 早在今年7月份就开始定向邀测，此次发布是正式公测，线上可以直接申请。TaurusDB目前是公测阶段，会上展示了测试结果。 而GuassDB全新上云，实际是高斯100（内部代号）上云，苏光牛表示，云上版本是完整的，不会做删减，还会针对云上的特点，对运维、安全方面进行增强，目前开始邀测。 MySQL云灾备DRS解决方案，该方案上半年刚荣获了2019年度DTCC最佳创新解决方案奖，此前笔者文章有过介绍，这里就不再赘述，有兴趣的朋友可以自行搜索。 至于RDS for MCS解决方案，据苏光牛介绍，既具备虚机的隔离性，又保持了容器的优势，在提供云盘可靠性的同时，性能也得到提升。性能提升是因为采用Extend buffer pool方案，结合华为容器和100us云盘技术，实现超越本地云盘性能1+倍。在苏光牛看来，RDS for MCS解决方案与GeminiDB类似，都是独此一家，极具竞争力。完备的数据库版图众所周知，数据库市场主要分为了以下几个板块：1、OLTP数据库，2、OLAP数据库3、NoSQL数据库4、工具生态类产品而前三种又可以分为托管（即第三方的商业数据库和开源数据库）和自研数据库产品。在OLTP板块，华为云托管产品有MySQL、PostgreSQL、SQL Server，自研方面有TaurusDB，TaurusDB定位MySQL生态，而GuassDB（高斯100），定位在于与鲲鹏产业生态结合，并高度兼容更多传统数据库的接口和语法。在OLAP板块，华为云有自研的DWS（即高斯200），据苏光牛介绍，目前有300多家商用客户，如上海德邦、广联达、国家开放大学等。在NoSQL板块，华为云托管的有Redis、Memchache等，自研方面有GeminiDB。而多模的GeminiDB毫无疑问是华为云的重点。工具类产品，华为云有数据复制服务DRS、数据管理服务DAS、数据安全服务DBSS等。苏光牛表示，这个版块，华为云的重点是数据同步、数据迁移，这部分核心在线迁移和预检查功能，而数据管理服务也是发力重点，目的是为了让客户更专注业务而不是数据。综上所述，华为云数据库在四大板块均有布局，尤其在NoSQL板块，竞争对手较为薄弱，这方面华为云优势明显。其次，目前主流数据库产品，包括Oracle、MySQL、SQL Server等，基本上都是支持X86架构的，而华为GaussDB数据库对于异构计算的支持，无疑是一个巨大优势，这意味着，GaussDB不仅针对传统服务器市场，还包括未来5G和IOT带来的更多计算场景，潜力巨大，这也是此次HC大会，鲲鹏产业生态吸引众多厂商云集的核心原因。而此次发布的GeminiDB、TaurusDB、GaussDB，凸显的是华为云在自研数据库产品方面的加强，以及多元、多模、性能的整体特征。而这些特征与华为对云数据库未来的趋势判断有着直接关系。多元化、高性能、安全可信的研发路线在进行数据库研发时，华为云都会考虑哪些方面的因素，遵循怎样的路线图？据苏光牛介绍，总结下来有以下有6个方面，而这6个方面就是华为云对未来数据库趋势的判断。1、多元;多元化的算力是云数据库未来趋势之一，苏光牛表示，未来不可能只有一个X86，会有Kunpeng处理器等ARM芯片，因此，作为底层的数据库，一定要能支持多元算力。2、多模;是多个数据模型。通过一个融合的模型帮助用户更好的管理多个数据模型，而不是每种数据装一个数据库，这样徒增运维难度。3、性能;数据库不谈性能那就是耍流氓，极致的性能，一直是华为云数据库研发团队永远需要考虑的问题。4、超大容量;在性能的基础上考虑容量才更有意义。5、安全可信;重要性不言而喻，华为无论是内部还是对外的产品，始终保持安全可信。6、运维与AI结合;也就是”自治”，让运维变得更简单，进一步释放云服务的价值。写在最后数据库领域，华为看似新进者，实际是厚积薄发，胜在积累深厚。过去30年，华为服务企业客户的经验和13年的数据库技术研发积累，为华为云数据库赢得了极佳的起跑位，并且，华为已经逐步构建起IT架构的底层生态，包括芯片，数据库、操作系统，这一点无比重要。不过，数据库这种重要性堪比芯片、操作系统的基础软件，并非短期可成，需要庞大的用户使用反馈及漫长的时间去优化迭代，Oracle就是如此，因此，对于华为乃至华为云而言，长期的积累和好的起跑位并不代表能懈怠，未来还有很长的路要走。附：HC大会，华为云数据库给出的新案例及相关数据。 GeminiDB+天地图 国家地理信息公共服务平台天地图是网络化地理信息共享与服务门户，集成了来自国家、省、市(县)以及相关专业部门、企事业单位的地理信息资源，但随着地理信息成果的极大丰富和地理信息集成服务能力的不足，以及日均API和服务调用超过4亿次的高需求，原有平台已不能满足此高要求。 天地图将全部44项在线业务迁移部署在华为云上，数据更新效率得到明显提升，原来需要15天才能完成的16TB全库数据恢复，现在2~3天就能完成；过去需要5小时才能完成的300GB数据迁移，现在1小时就能完成。天地图原采用的是社区版的MongoDB，集群的shard主备阶段数据同步时，会触发备节点CPU100%，而采用GeminiDB后，因为GeminiDB基于华为最新一代DFV存储计算分离架构，DFV DDS集群每个shard写数据到存储池，不存在往备节点写数据的场景，因此避免备节点内存空消耗。 GeminiDB+锦江都城对酒店业来说，对于云的核心需求是稳定和安全，对连锁酒店而言，PMS业务系统的迁移是一个⾼风险项⽬——涉及各种渠道、银⾏⽀付接口、酒店硬件设备和公安接口等多达几百项变更。一旦迁移开始，就不存在回滚的可能性。如果说第一次上云，锦江都城的IT团队经历的是大大小小的“战役”，那么，云迁移就是一场“生死战”。 华为云精准而迅速地找出了锦江都城的痛点，并根据其业务需求，对整个架构做了变动。据锦江都城IT总监凌晨回忆，迁移开始前的两个月，锦江都城的IT项目团队和华为云一起做了很多迁移准备的工作，甚至列了一个精确到每分钟的详细矩阵列表，本来计划了12小时的迁移时间，只用了1小时就完成了迁移。凌晨表示，“第三方的数据库升级是最大的难点。”据了解，华为云根据实际情况对数据库进行了“大动刀”：不仅更换了基础设施，还优化了数据库与系统的连接，令运⾏效率、稳定性和响应速度都大幅提升。此前，锦江都城PMS系统的MySQL数据库版本是5.5，迁到华为云以后升级到了5.6。“这是许多软件公司都不得不放弃的事情，因为在迁移的同时做升级，是高风险高难度的。为完成此次迁移，华为派出数据库问题专家团队驻场”完成向华为云迁移后，锦江都城的系统负载实现了3/4的降幅，能维持在仅20%左右，基本上不存在资源压⼒和系统稳定性⽅面的隐患。TaurusDB+安心保险 安心保险是全国首批创新型互联网保险公司，业务庞大，吞吐量很高，原有MySQL已经无法满足业务需求。传统HA方案引入binlog，带来额外的IO成本，面临的挑战主要表现在半同步模式在极端场景可能丢数据，高可用OR高可靠，性能被binlog拖住。因此，安信保险也曾在原有数据库架构上进行创新，比如对账系统解决高可用/高可靠问题，让丢失数据可找回，故障写入对账日志，切换后可继续。其次，对健康险核心数据库分片，应对业务演进，实现海量存储，高性能，弹性扩容，预警等复杂化方案。采用华为云TaurusDB方案后，因其基于计算存储分离架构，将数据持久化放入新一代存储中，数据多副本强一致，0丢失，计算节点故障秒级恢复，并提供7倍于原生MySQL的性能，业务透明扩展，安心保险3S内完成场景切换；存储3副本容错，单点故障0中断；支持跨AZ部署和跨Region容灾，安心保险面临的难题完美解决。GaussDB+思普软件 思普软件是一家产品全生命周期解决方案供应商，其核心系统PLM从流程标准化、设计标准化、人员与知识管理标准化三个方面提供可持续改善的管理解决方案，同时提供全方位的数据安全保证解决方案，帮助制造企业建立属于自己的个性化产品开发体系。此次思普软件携手华为云GaussDB将PLM系统迁移到云上，华为云为其量身打造了一套迁移方案:华为云GaussDB免运维、安全补丁及时更新，全自研自主可控，兼容Oracle数据库语法，支持多核高并发，智能优化器，支持两地三中心，支持快速闪回，数据不丢失，保证PLM的数据安全。本文转载【老鱼笔记】公众号。

1.概述            华为云TaurusDB是华为云自主研发的最新一代云原生分布式数据库，采用计算与存储分离、日志即数据的架构设计，实现数据库性能方面的大幅提升，具备极致可靠、极致性价比、多维拓展、完全可信等诸多特性。            赛题以此为背景，目标是设计一个计算存储分离的KV存储引擎。首先回顾下赛题，本次大赛的目的是设计一个KV存储引擎，复赛加入了计算存储分离的要求，引入了网络通信。同时，赛题要求程序能保证在应用层崩溃的情况下的数据安全性，追求更高的性能。因此，大赛主要考察点有5点：即读写吞吐量最大化；支持异常退出的缓冲设计；高效紧凑的索引结构；合理的缓存预读机制；以及高速稳定的RPC设计。主要考察点集中在文件IO和网络IO上，需要选手对操作系统底层有较多的了解。2.测试为了达到最优的性能目标目标，首先进行的是性能测试，这里对测评环境下的SSD，网络进行了详细的测试，结合运行环境的限制，最终确定磁盘采用direct方式调用，以2M单位写，16M或32M读。 由于网络环境在测评阶段发生过变动，限速环境下丢包率高，使用16连接4K大小调用，pipeline的方式请求大块数据，即柱状图最右侧1212M/s，用多连接打满带宽，后期去除限速后，采用单tcp连接128K调用，即最高的1939M/s。3 具体设计3.1整体架构设计确定了硬件的吞吐量，就可以对程序进行整体的设计了，计算节点和存储节点都根据其功能分为3层。计算节点前部分的KV接口层负责适配调用接口及记录必要的参数，因为计算节点无状态，没有持久化功能，KV抽象层通过对RPC client的包装，抽象出KV的存储层，实现接口和代码复用。存储节点除了RPC服务层，KV管理层负责管理到存储层的读写缓冲，文件系统层则负责将抽象的存储调用映射到多个磁盘文件。可以看出，计算节点和存储节点都有使用读缓冲提升性能，读取时，计算节点负责建立索引和预读，而存储节点抽象为一个块存储，写入时，存储节点则抽象为一个RPC服务端，计算节点远程调用。3.2存储设计存储引擎，首要设计存储的结构，这里采用KV分离的日志式存储的方式，KV在顺序上一一对应，可以通过读key文件快速建立索引，同时考虑到文件管理迁移的情况，文件以1G进行分片。3.3索引设计索引是加速读取必不可少的，为了将6400w索引到内存中并能提供高性能插的入和检索，采用了hash+array+linked list结构，同时能应对数据倾斜的情况，通过细粒度锁提升并发度，hash和array的长度也是可调的以适应不同场景。       索引以key和offset作为一个单元，将key文件全部读入内存，插的入新KV时直接hash到对应slot，append到后面，当需要查找时，对索引进行排序，key为第一优先级，offset为第二优先级，通过二分查找upper_bound方式，找到最大的offset值，即最新value对应offset，具备处理重复key的能力。3.4RPC协议设计而针对网络传输，设计了二进制的RPC协议，整体协议由计算端发起，无状态。设计考虑到应对各种网络环境和传输方式，请求和响应具备batch能力，最大化利用带宽。同时包头尽量4bytes对齐，提升payload的拷贝效率。4 具体功能实现 结构和协议设计完成后，下面就需要实现具体功能了。4.1日志式存储引擎实现首先是基于日志的存储部分，该部分抽象为writer，reader和file operator三部分，writer负责写入，通过mmap使用page cache作为缓冲、meta和keys的存储，同时使用精心设计的lock free ring buffer提升高并发写入性能，flusher和loader负责异步刷盘，重叠CPU/IO时间，达到最大吞吐量。读缓存使用最简单的hash，在顺序读时高效实现最优缓存策略。reader会读写缓冲，保证任何情况下写即可见。4.2单机KV存储引擎实现基于之前的日志式存储引擎，加上索引模块，记录key和对应存储偏移，即可完成单机版的KV存储引擎。系统初始化时，restorer负责多线程读取keys，并以(key,offset)进行排序，即前文介绍的索引初始化及查找算法。索引基于linked list+array的结构，固定大小分配自内存池，无碎片，统一生命周期管理。同时基于底层存储引擎特性，保证KV写入即可见的基本要求。4.3RPC实现对于client有两套调用流程，分别用于适配延迟敏感的写入操作和追求极致吞吐量的读取操作。首先，每个KV agent初始化一个client，client预先建立多条tcp连接。对于时延敏感的写入，采用单路阻塞IO模型，确认持久化后返回；对于追求吞吐量的读取，采用pipeline请求+多路复用IO模型，pipeline并行度可根据网络状况进行调整。      考虑到多路复用IO模型带来的时延问题，server线程采用简单的阻塞IO模型，单线程单socket。keys数据传输zero copy，提升性能。协议解析使用会话协议缓冲，采用生产消费模型，非常便于扩展协议。4.4计算存储分离的KV存储引擎实现上图展示的是初始化和写入的流程，首先计算节点restorer通过RPC拉取已有的keys数据，完成索引建立，保证能感知到已写入的KV。然后写入时，计算节点先通过RPC协议包装请求，等待写入完成后，将key和data offset记录到索引中，最后返回set。这样保证数据持久化后才返回请求，同时保证计算节点和存储节点实时一致。由于计算节点的实时性，读取并不需要做额外同步，直接通过索引获取当前key的offset，然后调用计算节点的reader，这时存储节点抽象为一个块存储，reader通过RPC完成cache miss时的读取功能，这里关闭了计算节点的loader跨块预读的功能，降低网络带宽占用，降低get KV的时延。5 细节优化5.1无锁环形缓冲由于写入是顺序进行的，低写入延迟是提升性能的决定性因素。这里将meta存储在page cache(mmap)中，对抗应用层崩溃，同时提升写入速度。meta数据按操作线程进行CPU cache line对齐，避免写入造成cache invalidate。通过filled数组和多个bound变量CAS操作保证write和flush操作安全，所以在写缓冲充足时，所有写入操作都是无锁无等待的。本地测试多线程写同一writer，flush到内存，可打满内存带宽到40GBps。上图为cache line对齐的meta结构。上图为bound的逻辑关系示意及具体实现结构。            上图为对filled数组和bound移动的核心代码。5.2 SpinLock & SpinRWLock锁操作是在多线程编程中比不可少的，但mutex是一个非常重的操作。这里针对多线程快速同步设计了两套基于原子操作和自旋的锁。实现基于原生C++11，且占用非常小的空间，RW lock仅占2个ptr大小。RW lock代码比较多就不贴这，实现参考java的ReentrantReadWriteLock非公平实现方法。非公平锁吞吐量高，故这里选择非公平方式。5.3 多存储单元虽然针对多线程传统设计了诸多优化，多存储单元的方式还是一种非常简单直接的避免冲突方式。根据线程id路由到不同存储单元上写入，能直接消除线程冲突。但在读的时候，不会总是落在同一单元中，这里通过prefer项，利用读写聚集性，减少多单元检索的开销。5.4 预读预读是重叠CPU和IO的一种方案。这里，预读由独立线程loader完成的，初赛阶段由于不存在网络延迟，预读能够提升整体吞吐量，提升若干秒的性能。而复赛阶段由于存在网络传输：  ∵网络吞吐量 < 磁盘吞吐量 and 网络延迟 >> 磁盘延迟  ∴关闭跨块预读的收益 > 预读收益复赛阶段预读仅包含values整块预读，块大小设定为32MB，由于reader的cache极大（使用了2GB），也起到了预读作用。            下图所示为预读预测代码，通过分析跨块时的访问模式，智能地进行正向和反向预读。    5.5内存管理 & 对齐 & Misc这里总结下内存相关优化点，不展开：内存管理-            VM使用RAII思想管理-            预分配一大块mmap-            offset原子加分配内存-            生命周期统一管理内存分配-            固定大小&对齐的内存分配-            array+linked list方式实现动态数组对齐-            DIO操作内存和缓存的VM都是4KB对齐，单独管理+populate&lock-            代码中设计了AVX2的memcpy(由于gcc版本没开)Misc-            索引重载符号使用std::sort,std::upper_bound-            keys传输使用mmap实现zero copy-            RPC请求栈上内存构建，减少系统调用，利用CPU cache-            数据分片参数使用类模板，编译阶段优化除法为位运算6 最优成绩复赛：-            最优成绩性能    484.889s(写)+133.776s(读)+134.711s(索引+随机读)+0.012s(Misc)=753.388s-            由于网络存在波动且传输数据较多，很难遇到各阶段都达到最优    写阶段最优： 484.889s    读取并恢复索引：~0.6s    读阶段最优：132.263s-(~0.6s(恢复索引))=131.663s 初赛(保留kill恢复能力，未达到最大吞吐量)：-            最优成绩性能130.782s(写)+73.802s(顺序读)+72.827s(随机读)+0.008(Misc)=277.419s7 总结-            现实问题受环境影响，不存在永恒的最优方案，需要测试实验作为先导，知己知彼才能百战不殆-            良好的抽象有利于最大程度复用已有代码，同时具备良好的可维护性和扩展性-            追求极致性能时，在细节上的优化是必不可少的 最后感谢华为云提供这次比赛机会，通过这次比赛学习到了很多知识，使我受益匪浅。作者：0xCC