本文来自Pingcap DevCon 2021上的涂鸦Smart Liu Xisong的共享，其中包括物联网领域的TIDB，尤其是在智能家居行业中。
涂鸦情报是一个全球物联网开发平台，它建立了互连的开发标准，并连接品牌，OEM制造商，开发人员，零售商和行业的智能需求。基于全球公共云，智能场景和智能设备的互连。它涵盖了三个方面：硬件开发工具，全球公共云和智能业务平台开发；它提供了从技术到营销渠道的全面授权，以创建中性和开放的开发者生态学。
目前，涂鸦在国内外拥有100,000多个合作伙伴。物联网和物联网开发人员平台的生态客户数量已达到320,000+.hotels（paas）等。Graffiti可以使欧美品牌和中国品牌，包括飞利浦，国内海尔和三个主要运营商。
涂鸦设备在世界上每天都有840亿个请求。峰值的平均数量可以达到150万TP，平均响应时间需求小于10毫秒。由于涂鸦是物联网行业，其与传统行业不同。没有低峰值点。写作数量很大。涂鸦已被选为六年来探索最合适的数据架构。
涂鸦之所以拥有如此大量的数据，是因为人们应该在家中使用智能设备，例如智能电灯和扫地机器人。设备连接到网络后，它具有与涂鸦平台进行通信的能力。涂鸦平台的重要作用，宙斯系统负责处理数据报告。业务拓扑如下图所示。收集在智能设备上报告的MQTT消息后，应用程序网关将被发送到KAFKA和NSQ。处理后，将其放入存储后。本文主要描述从宙斯到存储的产品选择。
涂鸦在早期就使用了AWS Aurora。这是一个分离的架构。涂鸦在Aurora上稳定运行了三年。在最初的三年中，奥罗拉（Aurora）完全满足了需求。六到七年前，物联网相对不受欢迎。智能家居设备并不那么受欢迎，用户使用不多。但是，随着业务的扩大，该设备近年来已经增长了指数水平。Raurora无法承受增加的数据量，尤其是物联网响应时间在10毫秒内。即使执行了拆分表，拆卸集群也无法满足涂鸦的业务需求。
因此，涂鸦开始尝试使用Apache Ignite，这也是分布式的KV系统。它类似于pingcap tikv。它基于Java架构。它的作品相对较大。1G数据是一个分区，其扩展没有tikv。我们将Aurora悬挂在IGNITE背后的灾难恢复中，数据将同时编写为Aurora。但是，随着业务量的激增，IGNITE无法满足涂鸦的业务需求，需要扩展，并且它是扩展IGNITE体系结构时必须停止。这是物联网难以忍受的。
当涂鸦试图在2019年替换IGNITE群集时，美国的存储设备已达到12个节点。与杭州举行的拖船活动有关，我们进行了TIDB 3.0的验证测试。涂鸦，因为延迟很高，并且吞吐量不能上升。几个月后，我不得不停止它。时间到2020年，TIDB 4.0上网了。我们再次测试了TIDB 4.0，与3.0相比，我们取得了长足的进步，但是高延迟和吞吐量不足的问题仍然存在。目前，Pingcap R＆D团队对此问题进行了深入分析，发现主要时间是在SQL Parser层上，并且TIKV的基础层的存储完全是闲置的。延迟在SQL解析器层上消耗，尽管物联网所写的数据很高，但业务逻辑并不那么复杂。您可以删除SQL层并直接写入TIKV层吗？我们指的是Pingcap的官方API文档，声称Java，Go and Rust支持Java，Go和Rust，并开始尝试探索。
在线申请的结果令人惊讶，并被整个公司认可。在世界各地我们推出了TIDB 4.0之后。经过一年的测试，在正常操作中找不到问题。最初需要12台机器。现在，在相同的配置下，只能完成3台机器。也就是说，最初的四分之一。当涂鸦吞吐量发射时，已经有200,000 TPS。从北美的集群来看，当时的版本为4.0.8，查询的响应时间为150微秒的99％，写作为360微米。），有类似场景的朋友可以尝试一下。
但是我们很长一段时间没有新的挑战，因为当AWS部署时，它被部署在三个可用区域中。例如，法兰克福的部署是ABC的三个领域。费用，涂鸦的所有申请也被部署在三个地区，还需要交叉区域呼叫。TIKV在诸如Double之类的同一区域中没有调用策略，因此此成本的成本很高。一个机器，但成本高于原始成本。当前解决方案基于基于RPC的压缩，以减少网络流量。但是，此流量只能解决区域副本的流量，并且跨区域的代码副本的副本尚未删除。我们发现此类问题的原因是因为TIKV的服务器没有过滤服务器。。需要存储在TIKV存储中的数据来过滤本地应用程序，然后将其填充。后续版本可能会启动基于服务器的过滤，减少服务器的负载，并且流量成本也可能降低**。
物联网行业专注于降低成本的原因，因为物联网行业的毛利率非常低，我们需要降低每个模块的成本。2020年6月，AWS推出了C6G的产品，以及成本绩效索赔要比上一代C5高40％，因此我们尝试了AWS C6G，但是当我汇编TIUP的直接部署时，我发现响应时间比X86架构慢。6比7次，TIUP由一般汇编版本部署，这不太适合硬件。测试和验证后，发现现有的TIKV版本不支持SSE指令集，这意味着RockSDB版本当前是当前的TIKV 4.0使用不支持SSE指令集。
SSE指令集主要用于CRC验证，哈希和浮动 - 点操作。在那个时候，折扣计划是混合部署。TIKV使用X86体系结构。其他节点使用了ARM架构，但这也带来了不便。这是一段时间的手臂，这非常麻烦，因此X86 Architecture的总体缩减。今年，TIKV推出了5.0版。TIKV 5.0是优化Aarch 64的CRC32C指令集，这是SSE 4.2指令集，但先决条件是RockSDB版本大于6.1.2，而RockSDB版本的TIKV 5.0版本为6.4.6，，6.4.6，，，，tiksdb版本。您可以在tikv.decline上找到针对SSE指令的TIKV的优化。
将来，在TIDB 5.0和5.1的帮助下，涂鸦有信心，它可以花费更多的商业增长。预计TIKV在年底的流量将转为三到四次。大数据平台还使用TIDB作为大屏幕显示器，并且IoT设备流也在考虑使用TIKV 5.1作为存储，这提高了易用性。TIDB ARM版本的部署还计划在下半年进行。