Loading

The Different Types of MuleSoft Object Stores Explained

Veröffentlichungsdatum: Mar 2, 2024
Lösung
MuleSoft has several different types of Object Stores, and it can be confusing to understand which should be used for different use-cases. This article will help explain the differences, when each should be used and how to know which one is being used by your application.

The three types of Object Store are:
  1. Anypoint Object Store V2
  2. CloudHub Object Store V1
  3. Mule Object Store



1. Anypoint Object Store V2 (OSv2)

Object Store V2 is the latest version of CloudHub Object Store. This is a Cloud Service that is external to the Mule Application. It is only used by CloudHub deployed applications. CloudHub Runtimes for Mule 3 support both Object Store V1 and Object Store V2, while newer CloudHub Runtimes 4x and above now only support Object Store V2.

You can tell your application is using OSv2, by looking in Runtime Manager --> Application --> Object Store page, and you can see keys being populated there. If the page is blank, you are not using OSv2.

Key features of OSv2

  • Key time to live (TTL) is 30 days, and extended by 30 days if accessed. This is conditional, please reference OSv2 FAQ. Some Mule 4 Runtimes have the ability to configure a custom time to live period for keys stored in Object Store V2, please review How to configure Entry Time to Live when using Anypoint Object Store v2 (OSv2)
  • Unlimited number of entries, unlimited total size of object stores.
  • Max value size 10 MB.
  • Max key length 256 characters.
  • Supported in each deployment region, and is co-located with your CloudHub application
  • Secured end-to-end with TLS-transport
  • Encrypts persistent storage to FIPS 140-2 compliant standards
  • Supported by Object Store Connector, but attributes like Expiration Interval, Max Entries are _not_ configurable.
  • Standard version provides a maximum API request rate limit of 10 TPS.
  • Premium OSv2 provides a maximum API request rate limit of 100 TPS (upgradable through Object Store Premium subscription purchase).

Use-Case

  • CloudHub deployed applications that need to persist key:value data in a simple database.
  • CloudHub applications that need to share data between workers in a multi-worker Fabric deployment. *** please note Limitation in below section.
Documentation:


Limitations

Distributed Locking capability is not available in CloudHub. Applications using high concurrency or multi-workers (fabric) deployments need to cater for simultaneous key writes or accesses. It is not recommended to use OSv2 for any solution that requires high concurrency or multi-worker configurations. More information available here Limitations of using OSv2 in CloudHub applications



2. CloudHub Object Store V1 (OSv1)

ObjectStore V1 is the original Cloud-based Object Store for CloudHub applications. This version is now deprecated and will be End-of-Life (EOL) at some time in the future. The end of life date is not yet announced, but customers are encouraged to use OSv2 when possible.

You can tell your application is using OSv1, by looking in Runtime Manager --> Application --> Application Data page, and you can see the keys being populated there. If the page is blank, you are not using OSv1.

Key Features of OSv1

  • Maximum of 100,000 key:value pairs per application
  • 768 byte key size
  • 1 MB value size
  • 1 GB of data per application
  • Supported by ObjectStore Connector, but attributes like entryTTL, Expiration Interval, Max Entries are _not_ configurable.
  • No API Rate limit.

Use-Case

  • CloudHub deployed applications that need to persist key:value data in a simple database.
  • CloudHub applications that need to share data between workers in a multi-worker Fabric deployment

Cautions

  • Object Store V1 is a deprecated service. Please use OSv2 for any new projects.
  • Mule Runtime 4x does not support Object Store V1.

Documentation: https://docs.mulesoft.com/runtime-manager/managing-application-data-with-object-stores


3. Mule Object Store

Mule Object Store is the original on-premise based Object Store that is part of Mule Runtime. Different to the above two Object Stores, this one is fully customisable to user preferences, can be "in-memory" for fast performance, or "persistent" on disk for reliability and is not a Cloud service. 
  • Mule ObjectStores are entirely customisable. There is no limit on key or value size, and no limit on the maximum size of the store.
  • Supported by ObjectStore connector, and all attributes are fully customisable.
  • Can be in-memory or persistent to disk.
  • If persistent, the object store will locally persist at <MULE_HOME>/.mule/<<app>>/objectstore/.

Use-Case

  • Mule application that needs to persist key:value data to be referenced by different flows or for a different mule event.
  • Mule Runtime Standalone or Hybrid deployment, either single server or HA Cluster (HA Cluster needs to use "in-memory" for data replication and accessibility from different mule nodes)
  • Mule Object Stores, when used in CloudHub, are _not_ available to other workers of the application in Multi-worker Fabric deployments. For this functionality, OSv2 is recommended.
  • Upon application stop, restart and redeployment, the ObjectStore data is expected to survive as long as the location of the ObjectStore data is not deleted/tampered.

Cautions

  • If limits are not set mule object store has the potential to consume all JVM heap (in-memory) or all disk space (disk persistence). Either of these scenarios may cause a crash of the Mule Runtime. To avoid this, make use of the attributes such as MaxEntries, EntryTTL to limit the number of key:value pairs and to ensure old keys are removed.
  • If you see that the ObjectStore data is getting deleted upon redeploy/restart, please ask MuleSoft Support to provide the patch "SE-12341" for the Runtime version 4.x.
  • The persistence of Mule ObjectStore is not supported for Runtime Fabric if "Persistence Gateway" is not configured. This is because when a mule node in Runtime Fabric is restarted, the pod within Kubernetes is destroyed, so anything stored in a persistent file store is lost and not transferred to the new pod. However, it is possible to preserve Object Store in memory. This is achieved by deploying an application into more than one replica in "clustered" mode and leaving the "updateStrategy" as "rolling" (default) where application availability is guaranteed by incrementally updating replicas. In this way, Object Store key-values are transferred from old to new replicas since there is always a living replica during the whole re-deployment. To have database persistent Object Stores in Runtime Fabric, please refer to doc "Persistent Gateway" for the steps to configure Persistent Gateway. Please also see "Object Store Feature Support in MuleSoft Runtime Fabric" for a more detailed explanation of the Object Store for Runtime Fabric.

Documentation: 
  https://docs.mulesoft.com/mule-runtime/3.8/mule-object-stores
  https://docs.mulesoft.com/mule-runtime/4.3/mule-object-stores
 

ObjectStore Platform Support Matrix

 CloudHubHybrid On-PremiseRuntime Fabric
Anypoint Object Store V2Yes1NoNo
CloudHub Object Store V1YesNoNo
Mule Object StoreYes2YesYes2

1. Not Supported by Mule 3 (Mule 4 only)
2. File persistence not supported (In-Memory only)



Object Store Connector

The same Mule Object Store Connector can be used for all three object stores and is the recommended method to write and read key:values to Object Stores.
However the Object Store attributes like entityTTL, max entries etc are ignored by OSv1 and OSv2, as they have their own limits pre-set as part of the platform feature set.
Please reference the Object Store Connector documentation for the correct configuration required to use the different Object Stores

In addition to configuring the connector to use the various Object Stores, Object Store V2, must be enabled in the Applications Settings Page "Use Object Store v2"
Not selecting "Use Object Store v2" option in the application settings page can result in different behaviours depending on which version of Mule is in use. If Mule 4, not selecting "Use Object Store v2" will force the application to use Mule Object Store (Not OSv1, as OSv1 is not supported with Mule 4). If the runtime is Mule 3, then not selecting this option will then default to either OSv1 or Mule Object Store, dependent on the configuration of the Mule Object Store Connector in the application.

Configuration in the Object Store connector can determine if that specific Object Store will or will not use Anypoint Object Store V2 or CloudHub Object Store V1. The ObjectStore connector attribute persistent="false" will force that object store to use "in-memory" object store, rather than OSv2 or OSv1. Please see How to use ObjectStore V2 and Mule ObjectStore (In-Memory) objectstores in the same Mule 4 CloudHub Application


Documentation: https://docs.mulesoft.com/connectors/object-store/object-store-connector

 

Nummer des Knowledge-Artikels

001123185

 
Laden
Salesforce Help | Article