共计 4724 个字符，预计需要花费 12 分钟才能阅读完成。
大家好，首先非常感谢大家参加本次 KaiwuDB 1.0 系列产品发布会。作为国内数据库新生品牌力量，KaiwuDB 是浪潮集团控股的数据库企业，咱们聚焦在工业物联网、数字能源、交通车联网、智慧产业等疾速倒退的重要畛域，心愿为各大行业客户提供残缺的数据服务解决方案。
01 为什么咱们关注上述提到的几大畛域？
首先，当然是市场自身的的力量，物联网现有规模曾经以百亿美元来掂量，同时还在一直成长；其次，从政策上看，数字能源、工业互联网都是国家重点倒退的行业和畛域，是将来国家经济倒退的重要驱动力。分享一组基于 IDC 等权威机构综合得出的数据：
以后寰球已接入的互联网设施高达 130 亿且这个数字预计 4 年后翻番；预计到 2030 年，寰球 3/4 的设施都将是物联网设施。
物联网设施须要接入互联网并须要具备肯定的数据采集和传输能力，预计直到 2025 年，物联网设施产生的数据会达到 79.4 ZB，同时这个数字还在以每年 60% 的速度增长，这是真正的数据爆炸。这样量级的数据给 IT 基础设施，特地是数据基础设施带来的挑战是前所未有的。
02 物联网数据不正是时序数据么？这些挑战不正是时序数据库已解决或正在解决的问题么？
答：Yes and no！
时序数据是物联网数据中占比最大的局部，所以物联网数据面临的挑战也是时序数据库要解决的问题，比方海量时序数据写入、大规模数据聚合等。值得注意的是，传统数据库的技术形式是很难应答如此大量级的数据。
好在时序数据也具备某些特点，比方它的写入基本上以追加写入为主，更新和删除操作较少；它的查问通常是以工夫范畴作为条件等。针对这些个性，咱们能够有方向地优化引擎，这也正是为什么会呈现时序数据库这一大钻研方向。
时序数据的体量个别是比拟宏大的，而且增速较快。大量数据会带来十分强的程度扩大需要，所以弹性伸缩是一个根本的治理需要。时序数据还具备一个独有特点：物联网设施规模十分宏大，假如把这些数据设施看成数据对象，传统数据库是无奈治理的。
如果仍旧采纳传统形式治理设施，势必将带来重大的性能问题。所以 海量时序数据、程度扩大 等这些的确是时序数据库所要解决的外围的问题。
然而，物联网利用要解决的数据又不仅仅是时序数据。比方数字能源场景下存在用电量、发电量等时序数据；另一方面也会波及很多关系性的数据，比方在能源计价，缴费，能源交易等场景下存在的高价值关系型数据。这就意味着，须要把时序数据和关系数据进行深度交融，能力更加全面地满足客户需要。
此外大量物联网数据势必也会带来昂扬的治理老本，用户会心愿把数据价值最大化进而笼罩治理老本。换言之，咱们数据库厂商须要用数据帮忙企业判断趋势，辅助决策甚至实现主动疾速响应，助力企业打造外围竞争力。
然而，很显然这些都不是明天的时序数据库的强项。所以说，物联网场景下肯定是须要一款很弱小的时序计算引擎，但又不止于时序数据库。
03 那针对当下现状，KaiwuDB 1.0 时序数据库具备哪些外围劣势？
这里，咱们对 KaiwuDB 1.0 时序数据库的技术劣势做了一个总结：“快人一步”：
时序数据库最大的挑战—解决海量数据，所以“快 ”是至关重要的；
产品最终是服务于“人 ”，也就是咱们的用户。一款产品好不好，最终肯定是用户说了算；
数据库是物联网利用的重要基础设施，但它也只是物联网利用中的一环，提供“一 ”站式整体解决方案，能力更好地解决用户业务难点；
对于物联网来说，分“布”式不是一个可选项，而是一个必选项。
04“快”能够说是 KaiwuDB 最闪亮的一点
咱们一起来看看如下几组数据：KaiwuDB 可反对每秒 100 万记录入库操作；千万记录简单查问毫秒内可实现；20 亿记录数据摸索 1 秒内实现；500 万记录数据可实现 15 层下钻。上述数据都已在先前与用户的单干中失去验证。
说到这里，可能有搭档想问：明天的市场有那么多的产品，凭什么说本人快呢？这里我就要来介绍一下 KaiwuDB 的外围专利技术—实时就地计算。
传统计算机在解决数据时，须要把数据读取到内存上再进行组织解决，磁盘上的数据其实是被组织成页的模式配置在内存中。咱们须要把页 Page 还原成记录 Record 后，数据库能力进行解决。
这里就会产生屡次转换，这种转换对于传统数据库来说是十分必要。然而从性能角度看，如果利用上没有大量的并发更新，比方时序数据这种模式，那这样的操作形式其实是会带来的额定开销，简略来说就是不够快！
随着硬件的倒退，咱们能够有内存数据库，把数据都放在内存里计算。然而当呈现时序数据后，它还是会受内存限度，无奈高效地解决这种需要，并且在扩展性上也有肯定的问题。
上述现状也促使咱们推出就地实时计算这一专利技术，咱们不再因循传统的从磁盘到内存多种转换解决的模式，而是把磁盘和内存融为一体，把磁盘映射成内存，让计算引擎间接面对数据。换言之，咱们把 计算推向数据，而不是把数据移向计算。
其中，咱们采纳的映射的形式是 Memory-mapped I/O 技术。咱们把文件映射到内存地址上，和传统的 IO 形式相比，Memory-mapped I/O 在很多的场景下具备性能劣势。比方传统的 IO 在读取数据时，须要把数据从零碎的缓冲区复制到用户空间的缓冲区，Memory-mapped I/O 是不须要这步操作的，所以它会更快。
当然，可能也有懂 Memory-mapped I/O 技术搭档会示意这不是一项很新的技术并且它也存在局限性，为什么 KaiwuDB 就地实时计算能够让它在时序数据上体现的这么好？起因是：咱们在 Memory-mapped I/O 的根底上又进一步发展了各项优化工作：
第一点，咱们抓住就地计算适宜时序数据这一特点进行重点优化。时序数据写入量尽管十分大，但基本上都是追加写入 Append 操作，比拟少有更新和删除的操作，也不会对已有的数据做出改变。所以，咱们能够对 Memory-mapped I/O 取长补短，通过系统调度去躲避 Memory-mapped I/O 体现不好的中央。
第二点，咱们优化了数据存储格局。在设计时序数据存储格局时，咱们基本上把数据记录做成定场，这样不论是从写入还是查问，咱们都能够十分迅速的计算并记录在文件上。这样带来的好处是：在写入时，咱们能够比拟好地做空间预调配，并且让不同的过程去负责不同的数据的插入。在查问时，咱们能够十分快地定位到指定数据的偏移量，也能定位到咱们须要的数据，大幅晋升查问效率。
第三点，咱们具备比拟独特的数据编码技术—把变长的字段通过编码变成等长的字段。在数据记录里，咱们只存等长的编码数据，原始数据存在编码的字典中。不仅保障了数据等长，能够帮忙咱们疾速定位；而且因为应用了编码数据，泛滥过滤条件在编码数据时即可利用，进而在查问、条件过滤时的性能也更高。此外基于数据定长的个性，咱们能够做到十分高效地并发，每个工作都能够很容易地通晓要解决的数据的终点和起点。
05 刚刚谈完了“快”，当初咱们来谈谈“人”
数据库作为 IT 的基础设施具备很强的专业性，如果把软件比喻成“车”，数据库软件能够说是“F1”，须要受过专业训练的人才能够驾驭。这也是让很多用户频繁头疼的一大问题，因为人才不好找，特地是时序数据库这样一个细分畛域，存在很多本人的个性，应用门槛会更高。
所以，咱们心愿通过低学习老本，让用户疾速上手 KaiwuDB 产品。这里咱们做出的抉择—融入数据库 SQL 大生态。数据库曾经是一款利用了几十年的产品，SQL 的大生态中蕴含了很多开发者和管理者都十分相熟操作形式。
所以，咱们反对开发者使用类 SQL 的语言来实现时序数据操作，包含建表、删表、数据插入、数据查问等；兼容 PostgreSQL 数据类型和语法；反对几十种工夫、数学、字符串、聚合等内置函数及自定义函数；反对命令行的工具；反对 DBeaver 等支流数据库管理工具等。
咱们的主旨：大幅度降低用户学习老本，帮忙懂数据库的搭档数天内就能上手操作 KaiwuDB 1.0。
06 除兼容外，咱们也尽量简化了用户的治理和保护老本
这里举两个例子：1）生命周期治理；2）智能预计算。
1、生命周期治理。家喻户晓时序数据具备一个特点—不同工夫范畴内的数据应用频率不同。最近数据往往是最常被应用到的，因而会产生时序数据的生命周期治理问题。比方最近的数据，即最热的数据，咱们心愿可能用最快的速度去拜访它，把它缓存在内存里。针对热数据咱们会将其寄存在高性能存储中，与之对应的称为冷数据，它的利用频率较低，所以从老本上思考，能够把它放在性能差一点同时也是更便宜的存储上。
在生命周期治理中，咱们把数据按工夫维度切开存储。把最新的数据缓存在内存里，落盘的数据则是依照用户的工夫定义放在不同的文件中，新旧数据可按需放在不同的介质上。此外，咱们还反对 TimeBound SQL 关键字，它定义数据的有效期，如果过期咱们就会主动执行删除，从而节俭用户空间。
2、智能预计算。时序数据在查问时存在另一个特点—查问是依照工夫去做聚合的。为优化这部分性能，咱们采取了智能预计算形式，提前把数据依照小时或天（用户能够定义范畴）来做预计算。
如果发现用户所做的查问是能够利用到预计算后果时，咱们就会抉择相应的预计算后果来解决查问。因为预计算是提前做的，而且预计算表的后果比原始的数据会小很多，所以预计算的查问会节俭很多工夫。而且一次的预计算其实是能够服务很多的查问，所以预计算对整体的性能的晋升是十分大的。
在 KaiwuDB 1.0 外面，预计算对用户来说是无感知的。也就是说用户侧的查问无需任何改变，咱们会依据查问内容来判断是否存在对应的预计算后果，从而反对它解决查问，主动抉择用原始数据或预计算后果。
07 一站式服务是一个很大的话题，因为数据服务蕴含的内容很丰盛
数据服务蕴含数据摄入、数据治理、数据安全、数据目录等。所以坦诚地说，KaiwuDB 一站式指标并不是要做到如此八面玲珑的一站式。
咱们更多关注以 KaiwuDB 为外围，用户可能须要的相干服务。咱们的指标是心愿用户应用 KaiwuDB 后，能够在最短的工夫内发明价值。总结下来，咱们的服务次要落地在两点：一个是入口，一个是进口。
入口：数据的生产者，把数据生产进去后，怎么把数据接入到 KaiwuDB 中？
进口：数据消费者，当他要用 KaiwuDB 中的数据时，怎么能用得更棘手？
先说入口，这里咱们提供了一项很重要的数据摄入服务。咱们所要解决的物联网数据大多是异构的—他们别离从不同的设施通过不同的零碎，依照不同的规范产生进去。所以，数据摄入肯定要可能匹配多种不同的数据源。因为物联网采集的数据品质，通常来说是无奈保障可用性的，前期会存在大量数据治理的工作。
如果能把数据验证、数据转换等数据治理工作前置，无疑能够帮忙前期节俭大量资源，并且可能让数据更快地被利用起来。针对此，KaiwuDB 推出了两款组件：Streamer 和 Streamer x。它们的作用是可能接入不同格局的数据，包含 CSV 文件、JSON 文件、MQTT 导出的数据、其余数据库导出的数据等。并且，咱们还反对用户自定义 ETL 脚本，辅助用户在数据摄入过程即能实现数据验证、数据转换等治理工作。
从性能方面思考，咱们采纳了 C++ 来实现 Streamer，针对特定场景做了性能优化，所以即便和市面上支流的流解决工具比照，咱们的 Streamer 体现也是十分好的。此外，咱们还提供了快照点复原性能，保证数据在摄入过程中，指标端和源端的数据一致性。
接着咱们来看进口端。咱们依据时序数据常见场景，凋谢了比拟容易生产的接口。对于利用开发者，特地是微服务开发者，咱们提供了“数据即服务”的形式。并且，咱们还有对图形化开发者工具的反对，可实现通过 API 进行开发测试。总之，咱们心愿数据生产能够更轻松、更便捷。