GridFS：它给了我们什么
GridFS: what it gives us
我正在阅读 "Seven Databases in Seven Weeks"。你能给我解释一下下面的文字吗：
One downside of a distributed system can be the lack of a single
coherent filesystem. Say you operate a website where users can upload
images of themselves. If you run several web servers on several
different nodes, you must manually replicate the uploaded image to
each web server’s disk or create some alternative central system.
Mongo handles this scenario by its own distributed filesystem called
GridFS.
为什么需要复制手动上传的图片？他们是否意味着某些服务器将具有 linux 而其中一些服务器将具有 Windows？
是否所有复制的数据存储都倾向于实现自己的文件系统？
在这种情况下，恕我直言，作者说每个网络服务器都有自己的磁盘存储，不与其他人共享 - 有那个 - 上传路径可以是 /home/server/app/uploads 并且因为它是服务器文件系统的一部分而不是与服务提供商完全共享作为一种安全性。要填充这些内容，我们需要一个 script/job 将数据同步到幕后的其他地方。
这种情况可能是将 GridFS 与 mongo 一起使用的情况。
gridFS 的工作原理：
GridFS divides the file into parts, or chunks 1, and stores each
chunk as a separate document. By default, GridFS uses a chunk size of
255 kB; that is, GridFS divides a file into chunks of 255 kB with the
exception of the last chunk. The last chunk is only as large as
necessary. Similarly, files that are no larger than the chunk size
only have a final chunk, using only as much space as needed plus some
additional metadata.
回复评论：
BSON 是二进制格式，mongo 有特殊的复制机制来复制集合数据（gridFS 是一个特殊的 set of 2 collections）。它使用 OpLog 将差异发送到副本集中的其他服务器。 More here
欢迎任何评论！
关于数据分发的必要性及其复杂性
让我们更详细地剖析这个例子。假设您有一个 Web 应用程序，人们可以在其中上传图像。您启动服务器，将图像保存到 /home/server/app/uploads 中的本地计算机，用户使用该应用程序。到目前为止，还不错。
现在，您的应用程序成为下一件大事，您有数以万计的并发用户，而您的单个服务器根本无法再处理该负载。幸运的是，除了将图像存储在本地文件系统中这一事实之外，您还以一种可以轻松放置另一个实例并在它们之间分配负载的方式实现了应用程序。但现在问题来了：您的应用程序的第二个实例将无法访问存储在第一个实例中的图像——这很糟糕。
有多种方法可以克服这个问题。让我们以 NFS 为例。现在您的第二个实例可以访问图像，甚至可以存储新图像，但这会将所有图像放在一台机器上，迟早会 运行 磁盘 space.
扩展存储容量很容易成为应用程序中非常昂贵的部分。这就是 GridFS 提供帮助的地方。它使用相当简单的 MongoDB 方法在多台机器上分发数据，这个过程称为 sharding。基本上，它是这样工作的：不是访问本地文件系统，而是通过 MongoDB 数据库驱动程序访问 GridFS（以及其中包含的文件）。
至于 OS：通常，我会尽可能避免在部署中混合使用不同的 OSes。如今，一般项目几乎没有理由这样做。我假设您指的是该文本的 "different nodes" 部分。这仅指您涉及多台机器这一事实。但他们完全可以 运行 相同 OS.
分片与复制
Note The following is vastly simplified, because going into details would well exceed the scope of one or more books.
您引用的摘录有点混淆了两个概念，并且对 GridFS 的工作原理不够清楚。
让我们先把涉及到的两个概念弄清楚一点。
Replication大致相当于一个RAID1：数据存储在两台或多台机器上，每台机器保存所有数据。
Sharding（也称为"data partitioning"）大致相当于RAID0：每台机器只保存数据的一个子集，尽管你可以访问整个数据透明地设置（在本例中为文件），分布式存储系统负责查找您请求的数据（并在您保存文件时决定将数据存储在何处）
现在，MongoDB允许你有一个混合形式，大致相当于RAID10：数据分布（"partitioned"或"sharded"）在两个或多个分片之间，但每个分片可能（而且几乎总是应该）由一个副本集组成，它是 MongoDB 个奇数个实例，它们都包含相同的数据。这种混合形式称为 "sharded cluster with a replication factor of X"，其中 X 表示 non-hidden members per replica set.
分片集群的优点是不再有单点故障：
- 根据您的复制因子，一个或多个副本集成员可能会失败，而集群仍在工作
- 有保存元数据的服务器（例如，数据的哪一部分存储在哪个分片上）。这些被称为 config servers。从 MongoDB 版本 3.0.x (iirc) 开始，它们自己形成一个副本集——如果一个节点出现故障，问题不大。
- 您通过
mongos sharded cluster query router 访问一个分片集群，其中您通常每个应用程序实例都有一个（并且通常与您的应用程序实例在同一台服务器上）。但是：可以为大多数驱动程序提供多个要连接的 mongos 实例。因此，如果其中一个 mongos 实例失败，驱动程序将很乐意使用您配置的下一个实例。
另一个优点是，如果您需要添加额外的存储或拥有超过当前系统可以处理的 IOPS，您可以添加另一个分片：MongoDB 将负责在旧分片之间分配现有数据分片和新分片自动。 MongoDB 文档中的 introduction to Sharding 详细介绍了如何完成此操作。
第三个优势——恕我直言，也是影响最大的一个——你可以在相对便宜的商品硬件上分发（和复制）数据，而大多数其他技术在分片集群上提供 GridFS 的好处需要你必须拥有专业且昂贵的硬件。
缺点当然是这种设置只有在你有大量数据时才可行，因为设置分片集群需要很多机器:
- 至少 3 个配置服务器
- 至少一个分片，应该由一个副本集组成。最小设置是两个数据承载节点加上一个 arbiter
但是：一般情况下，为了使用 GridFS，您甚至不需要副本集 ;)。
继续我们上面的示例：您的应用程序的两个实例都可以很好地访问相同的 MongoDB 持有 GridFS 的实例。
是否所有复制的数据存储都倾向于实现自己的文件系统？
复制了？不必要。例如 DRBD，可以描述为 "RAID1 over ethernet".
假设我们在这里有与上面相同的概念混淆：分布式 文件系统 根据其定义实现文件系统。
我正在阅读 "Seven Databases in Seven Weeks"。你能给我解释一下下面的文字吗：
One downside of a distributed system can be the lack of a single coherent filesystem. Say you operate a website where users can upload images of themselves. If you run several web servers on several different nodes, you must manually replicate the uploaded image to each web server’s disk or create some alternative central system. Mongo handles this scenario by its own distributed filesystem called GridFS.
为什么需要复制手动上传的图片？他们是否意味着某些服务器将具有 linux 而其中一些服务器将具有 Windows？
是否所有复制的数据存储都倾向于实现自己的文件系统？
在这种情况下，恕我直言，作者说每个网络服务器都有自己的磁盘存储，不与其他人共享 - 有那个 - 上传路径可以是 /home/server/app/uploads 并且因为它是服务器文件系统的一部分而不是与服务提供商完全共享作为一种安全性。要填充这些内容，我们需要一个 script/job 将数据同步到幕后的其他地方。
这种情况可能是将 GridFS 与 mongo 一起使用的情况。
gridFS 的工作原理：
GridFS divides the file into parts, or chunks 1, and stores each chunk as a separate document. By default, GridFS uses a chunk size of 255 kB; that is, GridFS divides a file into chunks of 255 kB with the exception of the last chunk. The last chunk is only as large as necessary. Similarly, files that are no larger than the chunk size only have a final chunk, using only as much space as needed plus some additional metadata.
回复评论： BSON 是二进制格式，mongo 有特殊的复制机制来复制集合数据（gridFS 是一个特殊的 set of 2 collections）。它使用 OpLog 将差异发送到副本集中的其他服务器。 More here
欢迎任何评论！
关于数据分发的必要性及其复杂性
让我们更详细地剖析这个例子。假设您有一个 Web 应用程序，人们可以在其中上传图像。您启动服务器，将图像保存到 /home/server/app/uploads 中的本地计算机，用户使用该应用程序。到目前为止，还不错。
现在，您的应用程序成为下一件大事，您有数以万计的并发用户，而您的单个服务器根本无法再处理该负载。幸运的是，除了将图像存储在本地文件系统中这一事实之外，您还以一种可以轻松放置另一个实例并在它们之间分配负载的方式实现了应用程序。但现在问题来了：您的应用程序的第二个实例将无法访问存储在第一个实例中的图像——这很糟糕。
有多种方法可以克服这个问题。让我们以 NFS 为例。现在您的第二个实例可以访问图像，甚至可以存储新图像，但这会将所有图像放在一台机器上，迟早会 运行 磁盘 space.
扩展存储容量很容易成为应用程序中非常昂贵的部分。这就是 GridFS 提供帮助的地方。它使用相当简单的 MongoDB 方法在多台机器上分发数据，这个过程称为 sharding。基本上，它是这样工作的：不是访问本地文件系统，而是通过 MongoDB 数据库驱动程序访问 GridFS（以及其中包含的文件）。
至于 OS：通常，我会尽可能避免在部署中混合使用不同的 OSes。如今，一般项目几乎没有理由这样做。我假设您指的是该文本的 "different nodes" 部分。这仅指您涉及多台机器这一事实。但他们完全可以 运行 相同 OS.
分片与复制
Note The following is vastly simplified, because going into details would well exceed the scope of one or more books.
您引用的摘录有点混淆了两个概念，并且对 GridFS 的工作原理不够清楚。
让我们先把涉及到的两个概念弄清楚一点。 Replication大致相当于一个RAID1：数据存储在两台或多台机器上，每台机器保存所有数据。
Sharding（也称为"data partitioning"）大致相当于RAID0：每台机器只保存数据的一个子集，尽管你可以访问整个数据透明地设置（在本例中为文件），分布式存储系统负责查找您请求的数据（并在您保存文件时决定将数据存储在何处）
现在，MongoDB允许你有一个混合形式，大致相当于RAID10：数据分布（"partitioned"或"sharded"）在两个或多个分片之间，但每个分片可能（而且几乎总是应该）由一个副本集组成，它是 MongoDB 个奇数个实例，它们都包含相同的数据。这种混合形式称为 "sharded cluster with a replication factor of X"，其中 X 表示 non-hidden members per replica set.
分片集群的优点是不再有单点故障：
- 根据您的复制因子，一个或多个副本集成员可能会失败，而集群仍在工作
- 有保存元数据的服务器（例如，数据的哪一部分存储在哪个分片上）。这些被称为 config servers。从 MongoDB 版本 3.0.x (iirc) 开始，它们自己形成一个副本集——如果一个节点出现故障，问题不大。
- 您通过
mongossharded cluster query router 访问一个分片集群，其中您通常每个应用程序实例都有一个（并且通常与您的应用程序实例在同一台服务器上）。但是：可以为大多数驱动程序提供多个要连接的 mongos 实例。因此，如果其中一个 mongos 实例失败，驱动程序将很乐意使用您配置的下一个实例。
另一个优点是，如果您需要添加额外的存储或拥有超过当前系统可以处理的 IOPS，您可以添加另一个分片：MongoDB 将负责在旧分片之间分配现有数据分片和新分片自动。 MongoDB 文档中的 introduction to Sharding 详细介绍了如何完成此操作。
第三个优势——恕我直言，也是影响最大的一个——你可以在相对便宜的商品硬件上分发（和复制）数据，而大多数其他技术在分片集群上提供 GridFS 的好处需要你必须拥有专业且昂贵的硬件。
缺点当然是这种设置只有在你有大量数据时才可行，因为设置分片集群需要很多机器:
- 至少 3 个配置服务器
- 至少一个分片，应该由一个副本集组成。最小设置是两个数据承载节点加上一个 arbiter
但是：一般情况下，为了使用 GridFS，您甚至不需要副本集 ;)。 继续我们上面的示例：您的应用程序的两个实例都可以很好地访问相同的 MongoDB 持有 GridFS 的实例。
是否所有复制的数据存储都倾向于实现自己的文件系统？
复制了？不必要。例如 DRBD，可以描述为 "RAID1 over ethernet".
假设我们在这里有与上面相同的概念混淆：分布式 文件系统 根据其定义实现文件系统。