传统数据库不适合现代企业架构了？
|
对这个平台的需求不仅仅是对这些事件流进行读写。事件流不只是关于正在发生的事情短暂的、有损的数据喷射，它是对业务从过去到现在的过程中所发生事情的完整的、可靠的、持久的记录。为了充分利用事件流，需要一个用于存储、查询、处理和转换这些流的实时数据平台，而不只是一个短暂的事件数据的“哑巴管道”。 把数据库的存储和处理能力与实时数据结合起来似乎有点古怪。如果我们把数据库看作一种含有一大堆被动数据的容器，那么，事件流看起来离数据库的领域还很远。但是，流处理的想法颠覆了这一点。如果我们把在公司内部发生的任何东西的流看作“数据”，并允许持续“查询”对它的处理、响应和反应，会发生什么事呢？这导致了根本不同的数据库功能框架。 在传统的数据库中，数据是被动地放置的，等待应用程序或人来发出其要响应的查询。在流处理中，这个过程倒过来了：数据是持续的，活动的事件流，馈送到被动的查询中，该查询只是对数据流做出反应和处理。
在某些方面，数据库已经在内部设计中展示了其在表和事件流上的二元性，即使不是其外部特征也是如此。大多数数据库都是围绕提交日志构建的，提交日志充当数据修改事件的持久流。通常，这些日志仅仅是传统数据库中的实现细节，查询无法访问。然而，在事件流的世界，这些日志及其填充的表需要成为一等公民。 但是，集成这两件事的理由不只是基于数据库内部。基本上，应用程序是用存储在表中的数据对世界上发生的事件做出反应 。在我们的零售示例中，销售事件会影响库存事件（数据库表中的状态），从而影响重新订购事件（另一个事件！）。整个业务流程可以由这些应用程序和数据库交互的菊花链形成，创建新事件的同时也改变这个世界的状态（减少库存数量，更新余额等等）。 传统数据库只支持这个问题的一半，剩下的一半嵌入应用程序代码。KSQL 等现代流处理系统正在把这些抽象集合到一起，以开始完成数据库需要跨事件和传统存储数据表进行的操作，但是，事件与数据库的统一只是一个刚开始的运动。 Confluent 的使命 Confluent 的使命是构建这个事件流平台，帮助企业围绕这个事件流平台开始重构自身。创始人和很多早期员工甚至在公司诞生之前就已经开始为这个项目工作了，并一直工作至今。 我们构建该平台的方法是由下而上。通过帮助 Kafka 的核心可靠地进行大规模的存储、读写事件流开始。然后，我们将堆栈移到连接器和 KSQL 上，让事件流变得容易及易于使用，我们认为这对于构建新的主流开发范式是至关重要的。 我们已经在主要的公共云供应商以软件产品和完全托管的云服务形式让这个堆栈变得可用。这使事件流平台可用跨越企业运营的整个环境，并在所有环境中集成数据和事件。 整个生态系统有大量机会在这个新的基础设施上进行构建：从实时监控和分析，到物联网、微服务、机器学习管道和架构，数据移动和集成。 随着这个新的平台和生态系统的兴起，我们认为，它可以成为正在通过软件定义和执行其业务的转型公司的主要部分。随着它成长为这个角色，我认为，无论是在其范围还是战略重要性上，事件流平台将会和关系数据库平起平坐。在 Confluent，我们的目标是使之实现。 作者介绍 Jay Kreps，Confluent 的首席执行官，也是 Apache Kafka 的联合创始人之一。他曾是 LinkedIn 的资深架构师。 【编辑推荐】
点赞 0 （编辑：威海站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
