JSON 非常慢：这就是更快的方法！[译]

最新推荐文章于 2024-04-24 00:40:05 发布

JingFeng.Huang

最新推荐文章于 2024-04-24 00:40:05 发布

阅读量753

点赞数 22

文章标签： json

本文链接：https://blog.csdn.net/hjingfeng/article/details/136765293

版权

大家好，我是feng，欢迎关注公众号和我一起探索AI世界。如果文章对你有所启发，请为我点赞、转发以及在下方留言自己的理解！

是的，你没听错！JSON是 Web 开发中普遍存在的数据交换格式，无处不在的可能会减慢您的应用程序的速度。在速度和响应能力至关重要的世界中，检查 JSON 的性能影响至关重要，这项技术我们常常认为是理所当然的。在本博客中，我们将深入探讨JSON 可能成为应用程序瓶颈的原因，并探索更快的替代方案和优化技术，以使您的应用程序保持最佳运行状态。

一、JSON 是什么以及为什么您应该关心？

JSON 是JavaScript Object Notation的缩写，是一种轻量级数据交换格式，已成为 Web 应用程序中传输和存储数据的首选。其简单性和人类可读的格式使人类和机器都可以轻松使用。但是为什么要在 Web 开发项目的上下文中关心 JSON？

JSON 是将应用程序中的数据粘合在一起的粘合剂。它是服务器和客户端之间通信数据的语言，也是数据存储在数据库和配置文件中的格式。从本质上讲，JSON 在现代 Web 开发中发挥着关键作用。

了解 JSON 及其细微差别不仅是任何 Web 开发人员的基本技能，而且对于优化应用程序也至关重要。随着我们深入研究此博客，您将发现为什么 JSON 在性能方面可以成为一把双刃剑，以及这些知识如何对您的开发之旅产生重大影响。

二、JSON 的流行以及人们使用它的原因......

JSON 在 Web 开发领域的受欢迎程度怎么强调都不为过。由于以下几个令人信服的原因，它已成为数据交换的事实上的标准：

使用起来很方便！

人类可读的格式：JSON 使用简单的、基于文本的结构，开发人员和非开发人员都可以轻松阅读和理解。这种人类可读的格式增强了协作并简化了调试。
与语言无关：JSON 不依赖于任何特定的编程语言。它是一种通用数据格式，几乎所有现代编程语言都可以解析和生成，因此具有高度通用性。
数据结构一致性：JSON 使用键值对、数组和嵌套对象强制数据结构一致。这种一致性使其在各种编程场景中都可预测且易于使用。
浏览器支持：Web 浏览器原生支持 JSON，允许 Web 应用程序与服务器无缝通信。这种原生支持对其在 Web 开发中的采用做出了重大贡献。
JSON API：许多 Web 服务和 API 默认提供 JSON 格式的数据。这进一步巩固了 JSON 作为 Web 开发中数据交换首选的角色。
JSON Schema：开发人员可以使用 JSON Schema 来定义和验证 JSON 数据的结构，为其应用程序添加额外的清晰度和可靠性。

鉴于这些优势，全球开发人员依赖 JSON 来满足数据交换需求也就不足为奇了。然而，当我们更深入地探索博客时，我们将发现与 JSON 相关的潜在性能挑战以及如何有效解决这些挑战。

三、对速度的需要

应用程序速度和响应能力的重要性

在当今快节奏的数字环境中，应用程序速度和响应能力是不容谈判的。用户期望跨网络和移动应用程序即时访问信息、快速交互以及无缝体验。这种对速度的需求是由以下几个因素驱动的：

用户期望：用户已经习惯了数字交互中闪电般的快速响应。他们不想等待网页加载或应用程序响应。即使是几秒钟的延迟也会导致沮丧和放弃。
竞争优势：速度可以成为显着的竞争优势。快速响应的应用程序往往比反应迟缓的应用程序更有效地吸引和留住用户。
搜索引擎排名：像 Google 这样的搜索引擎将页面速度视为排名因素。加载速度更快的网站往往在搜索结果中排名更高，从而提高可见性和流量。
转化率：尤其是电子商务网站，他们敏锐地意识到速度对转化率的影响。更快的网站可以带来更高的转化率，从而增加收入。
移动性能：随着移动设备的普及，对速度的需求变得更加重要。移动用户的带宽和处理能力通常有限，因此需要快速的应用程序性能。

JSON 是否会减慢我们的应用程序速度？

现在，让我们解决核心问题：JSON 是否会减慢我们的应用程序速度？

正如前面提到的，JSON 是一种非常流行的数据交换格式。它灵活、易于使用且得到广泛支持。然而，这种广泛采用并不能使其免受性能挑战。

在某些情况下， JSON可能是降低应用程序速度的罪魁祸首。解析 JSON 数据的过程，尤其是在处理大型或复杂结构时，可能会消耗宝贵的毫秒时间。此外，低效的序列化和反序列化可能会影响应用程序的整体性能。

在接下来的部分中，我们将探讨 JSON 可能成为应用程序瓶颈的具体原因，更重要的是，如何缓解这些问题。当我们继续前进时，请记住，我们的目标不是诋毁 JSON，而是了解其局限性并发现优化其性能的策略，以追求更快、响应更快的应用程序。

LinkedIn 将 Protocol Buffers 与 Rest.li 集成以提高微服务性能领英工程

四、为什么 JSON 会很慢

尽管 JSON 被广泛使用，但它也不能幸免于性能挑战。让我们探讨一下 JSON 潜在缓慢的原因，并了解为什么它可能并不总是数据交换的最快选择。

1. 解析开销

当 JSON 数据到达您的应用程序时，它必须经过解析过程才能将其转换为可用的数据结构。解析可能相对较慢，尤其是在处理大量或深层嵌套的 JSON 数据时。

2. 序列化和反序列化

JSON 要求数据从客户端发送到服务器时进行序列化（将对象编码为字符串），并在接收时进行反序列化（将字符串转换回可用对象）。这些步骤可能会带来开销并影响应用程序的整体速度。

在微服务架构领域，JSON 通常用于在服务之间传递消息。然而，重要的是要认识到 JSON 消息需要序列化和反序列化，这些过程可能会带来大量开销。

在大量微服务不断通信的场景中，这种开销可能会增加并可能减慢应用程序的速度，从而影响用户体验。

我们面临的第二个挑战是，由于 JSON 的文本性质，序列化和反序列化延迟和吞吐量不是最优的。
—领英

序列化和反序列化

3. 字符串操作

JSON 是基于文本的，严重依赖字符串操作来进行连接和解析等操作。与处理二进制数据相比，字符串处理可能会慢一些。

4. 缺乏数据类型

JSON 具有一组有限的数据类型（例如字符串、数字、布尔值）。复杂的数据结构可能需要效率较低的表示，从而导致内存使用量增加和处理速度变慢。

5. 冗长

JSON 的人类可读设计可能会导致冗长。冗余密钥和重复结构会增加有效负载大小，导致数据传输时间更长。

第一个挑战是 JSON 是一种文本格式，往往很冗长。这会导致网络带宽使用量增加和延迟增加，这并不理想。
—领英

6. 没有二进制支持

JSON 缺乏对二进制数据的本机支持。在处理二进制数据时，开发人员通常需要将其编码和解码为文本，这可能会降低效率。

7. 深度嵌套

在某些场景下，JSON数据可能会深度嵌套，需要递归解析和遍历。这种计算复杂性可能会减慢您的应用程序的速度，尤其是在没有优化的情况下。

五、JSON 的替代方案

虽然 JSON 是一种通用的数据交换格式，但其在某些场景下的性能限制导致人们探索更快的替代方案。让我们深入研究其中一些替代方案，并了解您何时以及为何选择它们：

1. 协议缓冲区（protobuf）

Protocol Buffers，通常称为protobuf ，是Google开发的一种二进制序列化格式。它们专为提高效率、紧凑性和速度而设计。Protobuf 的二进制性质使其在序列化和反序列化方面比 JSON 快得多。

何时选择：当您需要高性能数据交换时，尤其是在微服务架构、物联网应用或网络带宽有限的场景中，请考虑使用protobuf。

protobuf-example,🗜️ 一个使用 Google 协议的示例 Express 应用程序,下载protobuf-example的源码_GitHub_帮酷

🗜️ 一个示例 Express 应用程序，使用 Google 的 Protocol Buffers 来序列化/反序列化 JSON 对象 - GitHub …

github.com

2. 消息包

MessagePack 是另一种以其速度和紧凑性而闻名的二进制序列化格式。它的设计比 JSON 更高效，同时保持与各种编程语言的兼容性。

何时选择：当您需要在速度和跨语言兼容性之间取得平衡时，MessagePack 是一个不错的选择。它适用于实时应用程序和数据大小缩减至关重要的情况。

3.BSON（二进制JSON）

BSON（即二进制 JSON）是一种源自 JSON 的二进制编码格式。它保留了 JSON 的灵活性，同时通过二进制编码提高了性能。BSON 常用于 MongoDB 等数据库。

何时选择：如果您正在使用 MongoDB 或需要一种能够弥补 JSON 和二进制效率之间差距的格式，那么 BSON 是一个很有价值的选择。

4.Apache Avro

Apache Avro 是一个数据序列化框架，专注于提供紧凑的二进制格式。它是基于模式的，允许高效的数据编码和解码。

何时选择：Avro 适合模式演化很重要的场景，例如在数据存储中，以及当您需要在速度和数据结构灵活性之间取得平衡时。

这些替代方案比 JSON 提供了不同程度的性能改进，并且选择取决于您的具体用例。通过考虑这些替代方案，您可以优化应用程序的数据交换流程，确保速度和效率处于开发工作的最前沿。

JSON、Protobufs、MessagePack、BSON 和 Avro 之间的区别

六、每个字节的意义：优化数据格式

在数据交换领域，效率和速度至关重要，数据格式的选择可以带来截然不同的结果。本节探讨从简单的 JSON 数据表示到更高效的二进制格式（如Protocol Buffers、MessagePack、BSON 和 Avro）的旅程。我们将深入研究每种格式的细微差别，并演示为什么每个字节都很重要。

开始：JSON 数据

我们从简单的 JSON 数据结构开始我们的旅程。以下是我们的示例 JSON 数据的片段：

{
  "id": 1,                                 // 14 bytes
  "name": "John Doe",                      // 20 bytes
  "email": "johndoe@example.com",          // 31 bytes
  "age": 30,                               // 9 bytes
  "isSubscribed": true,                    // 13 bytes
  "orders": [                              // 11 bytes
    {                                      // 2 bytes
      "orderId": "A123",                   // 18 bytes
      "totalAmount": 100.50                // 20 bytes
    },                                     // 1 byte
    {                                      // 2 bytes
      "orderId": "B456",                   // 18 bytes
      "totalAmount": 75.25                 // 19 bytes
    }                                      // 1 byte
  ]                                        // 1 byte
}

JSON 总大小：~ 139 字节

虽然 JSON 用途广泛且易于使用，但它有一个缺点——它的文本性质。每个字符、每个空格和每个引号都很重要。在数据大小和传输速度至关重要的场景中，这些看似微不足道的字符可能会产生重大影响。

七、效率挑战：使用二进制格式减小大小

现在，让我们提供其他格式的数据表示并比较它们的大小：

协议缓冲区（protobuf）：

syntax = "proto3";

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
  int32 age = 4;
  bool is_subscribed = 5;
  repeated Order orders = 6;

  message Order {
    string order_id = 1;
    float total_amount = 2;
  }
}

0A 0E 4A 6F 68 6E 20 44 6F 65 0C 4A 6F 68 6E 20 44 6F 65 65 78 61 6D 70 6C 65 2E 63 6F 6D 04 21 00 00 00 05 01 12 41 31 32 33 03 42 DC CC CC 3F 05 30 31 31 32 34 34 35 36 25 02 9A 99 99 3F 0D 31 02 42 34 35 36 25 02 9A 99 99 3F

协议缓冲区总大小：~ 38 字节

消息包：

（注意：MessagePack 是二进制格式，这里的表示形式是人类无法读取的。）

二进制表示（十六进制）：

a36a6964000000000a4a6f686e20446f650c6a6f686e646f65406578616d706c652e636f6d042100000005011241313302bdcccc3f0530112434353625029a99993f

消息包总大小：~34 字节

BSON（二进制 JSON）：

（注意：BSON 是一种二进制格式，这里的表示形式不是人类可读的。）

二进制表示（十六进制）：

3e0000001069640031000a4a6f686e20446f6502656d61696c006a6f686e646f65406578616d706c652e636f6d1000000022616765001f04370e4940

BSON总大小：~ 43 字节

Avro：

（注意：Avro 使用模式，因此数据与模式信息一起编码。）

二进制表示（十六进制）：

0e120a4a6f686e20446f650c6a6f686e646f65406578616d706c652e636f6d049a999940040a020b4108312e3525312e323538323539

Avro总大小：~ 32 字节

（这些替代方案的实际字节数可能会有所不同，提供这些数字只是为了提供一般理解。）

现在您可能想知道为什么即使其中一些格式输出二进制，它们的大小却不同。Avro、MessagePack 和 BSON 等二进制格式具有不同的内部结构和编码机制，这可能会导致二进制表示形式的变化，即使它们最终表示相同的数据。以下是这些差异如何产生的简要概述：

1.Avro：

Avro 使用模式来编码数据，并且该模式通常包含在二进制表示中。
Avro 基于模式的编码通过提前指定数据的结构来实现高效的数据序列化和反序列化。
Avro 的二进制格式被设计为自描述的，这意味着模式信息包含在编码数据中。这种自描述性使 Avro 能够保持不同版本的数据模式之间的兼容性。

2. 消息包：

MessagePack 是一种二进制序列化格式，直接对数据进行编码，不包含架构信息。
它使用具有可变长度整数和可变长度字符串的紧凑二进制表示形式，以最大限度地减少空间使用。
MessagePack 不包含 schema 信息，因此更适合提前已知 schema 并在发送方和接收方之间共享的场景。

3.BSON：

BSON 是 JSON 数据的二进制编码，包含每个值的类型信息。
BSON 的设计与 JSON 紧密相关，但它添加了 JSON 所缺少的二进制数据类型，例如日期和二进制数据。
与 MessagePack 一样，BSON 不包含架构信息。

这些设计和编码方面的差异导致二进制表示形式的变化：

Avro 包含架构信息并且具有自描述性，这导致二进制大小稍大，但提供了架构兼容性。
MessagePack 由于采用变长编码，所以高度紧凑，但缺少 schema 信息，适合 schema 已知的场景。
BSON 与 JSON 密切相关，并且包含类型信息，与 MessagePack 等纯二进制格式相比，它会增加大小。

总之，这些差异源于每种格式的设计目标和特征。Avro 优先考虑模式兼容性，MessagePack 侧重于紧凑性，BSON 维护类似 JSON 的结构并添加了二进制类型。格式的选择取决于您的具体用例和要求，例如架构兼容性、数据大小和易用性。

八、优化 JSON 性能

JSON 虽然具有令人难以置信的通用性并在 Web 开发中广泛采用，但也并非没有速度挑战。该格式的人类可读性质可能会导致更大的数据有效负载和更慢的处理时间。那么，问题来了：我们如何优化 JSON，使其更快、更高效？在本指南中，我们将探索可用于增强 JSON 性能的实用策略和优化，确保它仍然是现代 Web 开发中的一个有价值的工具，同时提供应用程序所需的速度和效率。

以下是一些优化 JSON 性能的实用技巧，以及代码示例和最佳实践：

1. 最小化数据大小：

使用简短的描述性键：选择简洁但有意义的键名称以减少 JSON 对象的大小。

// Inefficient
{
  "customer_name_with_spaces": "John Doe"
}

// Efficient
{
  "customerName": "John Doe"
}

尽可能缩写：在不牺牲清晰度的情况下，考虑使用键或值的缩写。

// Inefficient
{
  "transaction_type": "purchase"
}
 
// Efficient
{
  "txnType": "purchase"
}

2. 明智地使用数组：

最小化嵌套：避免深度嵌套数组，因为它们会增加解析和遍历 JSON 的复杂性。

// Inefficient
{
  "order": {
    "items": {
      "item1": "Product A",
      "item2": "Product B"
    }
  }
}

// Efficient
{
  "orderItems": ["Product A", "Product B"]
}

3.优化数字表示：

尽可能使用整数：如果一个值可以表示为整数，请使用它而不是浮点数。

// Inefficient
{
  "quantity": 1.0
}

// Efficient
{
  "quantity": 1
}

4. 去除冗余：

避免重复数据：通过引用共享值消除冗余数据。

// Inefficient
{
  "product1": {
    "name": "Product A",
    "price": 10
  },
  "product2": {
    "name": "Product A",
    "price": 10
  }
}

// Efficient
{
  "products": [
    {
      "name": "Product A",
      "price": 10
    },
    {
      "name": "Product B",
      "price": 15
    }
  ]
}

5.使用压缩：

应用压缩算法：如果适用，请使用Gzip 或Brotli 等压缩算法来减少传输过程中 JSON 有效负载的大小。

// Node.js example using zlib for Gzip compression
const zlib = require('zlib');

const jsonData = {
  // Your JSON data here
};

zlib.gzip(JSON.stringify(jsonData), (err, compressedData) => {
  if (!err) {
    // Send compressedData over the network
  }
});

6. 使用服务器端缓存：

缓存 JSON 响应：实施服务器端缓存以高效存储和提供 JSON 响应，减少重复数据处理的需要。

7. 分析和优化：

分析性能：使用分析工具来识别 JSON 处理代码中的瓶颈，然后优化这些部分。

请记住，您实施的具体优化应符合应用程序的要求和约束。

九、现实世界的优化：在实践中加速 JSON

在本节中，我们将深入研究在 JSON 中遇到性能瓶颈并成功解决的实际应用程序和项目。我们将探讨组织如何解决 JSON 的局限性以及这些优化为其应用程序带来的切实好处。从 LinkedIn 和 Auth0 等知名平台到 Uber 等颠覆性科技巨头，这些示例为提高速度和响应能力所采用的策略提供了宝贵的见解，同时尽可能地利用 JSON 的多功能性。