www.ydisp.cn/oss/202207/14/a17a0bc917e73bf950a5250de093a176d34b39.jpg"style="visibility:可见;宽度：877px；height:585px;"data-type="inline">同样，数据库只是在灵活多变的情况下才对今天的实时分析有用。传统的数据库，由于其完全灵活的结构，是脆弱的。无模式的NoSQL数据库也是如此，它能够摄取大量数据，但不擅长提取复杂的洞察力。用户个性化、自动化库存管理、智能操作和其他实时用例需要数据库严格执行模式和具有根据数据本身自动重新定义这些模式的灵活性。这满足了现代分析的要求三个关键要求：支持数据收集的规模和速度支持可以立即适应流数据多样性的灵活模式支持快速和复杂SQLqueriesthatrequirestrictstructuresorpatterns昨天的模式：hardandfragile经典模式是关系数据库表e：实体的行，例如人，以及这些实体的不同属性（年龄或性别）的列。通常存储在SQL语句中，模式还定义了数据库中的所有表以及它们之间的关系。传统上，模式是严格执行的。不符合预定属性或数据类型的输入数据会被数据库自动拒绝，在其位置存储空值或完全跳过整个记录。更改架构是困难且很少见的事情。公司仔细设计他们的ETL数据管道以与他们的模式保持一致（反之亦然）。过去，有充分的理由预先创建和严格执行模式。SQL查询更容易编写。他们跑得也快多了。最重要的是，严格模式可以防止由错误或不匹配的数据引起的查询错误。然而，严格的、不可变的模式在今天有很大的缺点。第一，现在的数据来源和类型比90年代多了很多。他们中的许多人不能轻易地适应相同的模式结构。最值得注意的是直播活动流。流媒体和时间序列数据通常以经常变化的半结构化格式出现。随着这些格式的改变，模式也必须改变。其次，随着业务条件的变化，公司不断需要分析新的数据源，运行不同类型的分析——或者只是更新他们的数据类型或标签。这是一个例子。当我在Facebook的数据基础设施团队工作时，我们参与了一项名为ProjectNectar的雄心勃勃的计划，该计划在用户群中呈爆炸式增长。“花蜜项目”试图用一组标准的属性来记录每个用户的行为。在全球范围内对这种模式进行标准化将使我们能够在全球范围内分析趋势并发现异常情况。经过多次内部辩论，我们的团队同意将每个用户事件存储在Hadoop中，并将时间戳记在名为time_spent的列中，分辨率为一秒。ProjectNectar首次亮相后，我们将其展示给了一群新的应用程序开发人员。他们问的第一个问题是“您能否将列的时间从几秒更改为几毫秒？”换句话说，他们随便要求我们在ProjectNectar架构启动后重建其架构的一个基本方面。ETL管道可以将所有数据源置于同一个传奇屋檐下（即T，代表数据转换）。但是，随着数据源和类型的变化，ETL管道的设置、操作和手动更新既费时又昂贵。灵活性的尝试僵化、不变的模式破坏了当今所有公司都需要的灵活性。一些数据库制造商通过让用户更容易手动修改他们的模式来解决这个问题。然而，这也是一个沉重的代价。使用SQLALTER-TABLE命令更改模式需要大量时间和处理能力，使数据库长时间处于脱机状态。此外，一旦架构更新，很可能会无意中损坏您的数据，从而削弱您的数据管道。以PostgreSQL为例，它是一个流行的事务型数据库，很多公司也用它来进行简单的分析。为了正确摄取当今快速变化的事件流，PostgreSQL必须通过SQL中的手动ALTER-TABLE命令更改其架构。这将锁定数据库表并在ALTER-TABLE完成时冻结所有查询和事务。据说无论你的PostgreSQL表有多大，ALTER-TABLE都会花很长时间。它还需要大量CPU，并存在数据错误和下游应用程序中断的风险。NewSQL数据库也面临同样的问题。CockroachDB承诺以零停机时间在线更改模式。但是，Cockroach告诫不要一次更改多个模式。它还强烈警告不要在交易中改变模式。就像PostgreSQL一样，CockroachDB中的所有模式更改都必须由用户手动完成。因此，CockroachDB的模式远没有它看起来那么灵活。并且，数据错误和数据停机的风险也存在。NoSQL来拯救？其他制造商发布的NoSQL数据库大大放松了模式，或者完全放弃了模式。这种激进的设计选择使得NoSQL数据库——文档数据库、键值存储、面向列的数据库和图形数据库——非常适合存储所有类型的海量数据，无论是结构化、半结构化还是多维。动态数据。数据湖建立在Hadoop等NoSQL数据库之上的数据湖是混合类型可扩展数据存储库的最佳示例。NoSQL数据库在检索大量数据和运行简单查询方面也很快。然而，轻量级/非轻量级模式数据库确实有缺点。虽然查找和简单查询可以快速而简单，但复杂的嵌套查询和必须返回准确答案的查询通常很慢且难以创建。这是由于缺乏SQL支持，以及它们对索引和其他查询优化的支持很差。由于NoSQL过于松散的数据一致性模型，复杂的查询更有可能超时而不返回结果。修复和重新运行查询是一件耗时的麻烦事。当涉及到云计算和开发人员时，这意味着浪费金钱。以作为Hadoop堆栈一部分的Hive分析数据库为例。Hive确实支持灵活的模式，但大致支持。当它遇到不能完全适合现有表和数据库的半结构化数据时，它只是将数据存储为类似JSON的blob，从而保持数据完整性。但是，在查询时，Blob需要先反序列化，这是一个缓慢且低效的过程。或者以使用无模式键值存储的AmazonDynamoDB为例。在读取特定记录时，DynamoDB非常快。多记录查询往往要慢得多，尽管构建二级索引会有所帮助。更大的问题是DynamoDB不支持任何JOIN或任何其他复杂查询。严格和灵活模式的正确方法然而，有一个成功的数据库公式将NoSQL的灵活可扩展性与SQL的准确性和可靠性相结合，同时增加了云原生基础设施的低操作简单性。Rockset是一个建立在RocksDB键值存储之上的实时分析平台。与其他NoSQL数据库一样，Rockset具有高度可扩展性、灵活性，并且能够快速写入数据。但是和SQL关系型数据库一样，Rockset也有严格模式的优势。强大的数据类型和高数据一致性，再加上我们自动高效的ConvergedIndexing这些优势与我们自动高效的数据库相结合，确保您的复杂SQL查询是快速的。Rockset通过检查存储数据的字段和数据类型自动生成架构。Rockset可以处理任何类型的数据，包括。具有深度嵌套数组和对象、混合数据类型和稀疏字段的JSON数据随着时间的推移添加新字段的实时事件流来自新数据源的新数据类型支持无模式摄取和融合索引，使Rockset能够减少数据延迟通过消除对上游数据转换的需要。Rockset还进行了其他优化，以降低存储成本并加快查询速度。对于每条记录的每个字段，Rockset存储数据类型。这最大限度地提高了查询性能并减少了错误。而且，我们通过称为字段交换的功能有效地做到这一点，例如，与基于JSON的无模式文档数据库相比，该功能需要的存储空间最多减少30%。Rockset使用一种叫做类型提升的东西来减少查询处理时间。相同类型的相邻项可以将其类型信息提升为应用于整个项集，而不是存储在列表中的每个单独项。这使向量的CPU指令能够快速处理整个项目集。此实现与我们的ConvergedIndex?一起使Rockset查询能够像具有严格模式的数据库一样快速运行，而不会产生额外的计算。一些NoSQL数据库的制造商声称只有他们可以支持灵活的模式。这不是真的，而且像Rockset这样的现代产品正在破灭是一个神话。
