You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2020/10/26 14:56:30 UTC

[GitHub] [pulsar] jiazhai commented on a change in pull request #8368: [Issue 8364][docs] Update decommission content in different releases

jiazhai commented on a change in pull request #8368:
URL: https://github.com/apache/pulsar/pull/8368#discussion_r512024872



##########
File path: site2/website/versioned_docs/version-2.6.1/administration-zk-bk.md
##########
@@ -163,17 +163,50 @@ BookKeeper is responsible for all durable message storage in Pulsar. BookKeeper
 
 > For a guide to managing message persistence, retention, and expiry in Pulsar, see [this cookbook](cookbooks-retention-expiry.md).
 
-### Deploy BookKeeper
+### Hardware considerations
 
-BookKeeper provides [persistent message storage](concepts-architecture-overview.md#persistent-storage) for Pulsar.
+Bookie hosts are responsible for storing message data on disk. In order for bookies to provide optimal performance, ensuring that the bookies have a suitable hardware configuration is essential. You can choose two key dimensions to bookie hardware capacity:
 
-Each Pulsar broker needs to have its own cluster of bookies. The BookKeeper cluster shares a local ZooKeeper quorum with the Pulsar cluster.
+* Disk I/O capacity read/write
+* Storage capacity
 
-### Configure bookies
+Message entries written to bookies are always synced to disk before returning an acknowledgement to the Pulsar broker. To ensure low write latency, BookKeeper is designed to use multiple devices:
+
+* A **journal** to ensure durability. For sequential writes, having fast [fsync](https://linux.die.net/man/2/fsync) operations on bookie hosts is critical. Typically, small and fast [solid-state drives](https://en.wikipedia.org/wiki/Solid-state_drive) (SSDs) should suffice, or [hard disk drives](https://en.wikipedia.org/wiki/Hard_disk_drive) (HDDs) with a [RAID](https://en.wikipedia.org/wiki/RAID)s controller and a battery-backed write cache. Both solutions can reach fsync latency of ~0.4 ms.

Review comment:
       @codelipenghui . this is not only hdd, it is hdd with raid card(which contains cache)




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org