# `Nebulex.Adapters.Partitioned`
[🔗](https://github.com/elixir-nebulex/nebulex/blob/v2.6.6/lib/nebulex/adapters/partitioned.ex#L1)

Built-in adapter for partitioned cache topology.

## Overall features

  * Partitioned cache topology (Sharding Distribution Model).
  * Configurable primary storage adapter.
  * Configurable Keyslot to distributed the keys across the cluster members.
  * Support for transactions via Erlang global name registration facility.
  * Stats support rely on the primary storage adapter.

## Partitioned Cache Topology

There are several key points to consider about a partitioned cache:

  * _**Partitioned**_: The data in a distributed cache is spread out over
    all the servers in such a way that no two servers are responsible for
    the same piece of cached data. This means that the size of the cache
    and the processing power associated with the management of the cache
    can grow linearly with the size of the cluster. Also, it means that
    operations against data in the cache can be accomplished with a
    "single hop," in other words, involving at most one other server.

  * _**Load-Balanced**_:  Since the data is spread out evenly over the
    servers, the responsibility for managing the data is automatically
    load-balanced across the cluster.

  * _**Ownership**_: Exactly one node in the cluster is responsible for each
    piece of data in the cache.

  * _**Point-To-Point**_: The communication for the partitioned cache is all
    point-to-point, enabling linear scalability.

  * _**Location Transparency**_: Although the data is spread out across
    cluster nodes, the exact same API is used to access the data, and the
    same behavior is provided by each of the API methods. This is called
    location transparency, which means that the developer does not have to
    code based on the topology of the cache, since the API and its behavior
    will be the same with a local cache, a replicated cache, or a distributed
    cache.

  * _**Failover**_: Failover of a distributed cache involves promoting backup
    data to be primary storage. When a cluster node fails, all remaining
    cluster nodes determine what data each holds in backup that the failed
    cluster node had primary responsible for when it died. Those data becomes
    the responsibility of whatever cluster node was the backup for the data.
    However, this adapter does not provide fault-tolerance implementation,
    each piece of data is kept in a single node/machine (via sharding), then,
    if a node fails, the data kept by this node won't be available for the
    rest of the cluster members.

> Based on **"Distributed Caching Essential Lessons"** by **Cameron Purdy**
  and [Coherence Partitioned Cache Service][oracle-pcs].

[oracle-pcs]: https://docs.oracle.com/cd/E13924_01/coh.340/e13819/partitionedcacheservice.htm

## Additional implementation notes

`:pg2` or `:pg` (>= OTP 23) is used under-the-hood by the adapter to manage
the cluster nodes. When the partitioned cache is started in a node, it creates
a group and joins it (the cache supervisor PID is joined to the group). Then,
when a function is invoked, the adapter picks a node from the group members,
and then the function is executed on that specific node. In the same way,
when a partitioned cache supervisor dies (the cache is stopped or killed for
some reason), the PID of that process is automatically removed from the PG
group; this is why it's recommended to use consistent hashing for distributing
the keys across the cluster nodes.

> **NOTE:** `pg2` will be replaced by `pg` in future, since the `pg2` module
  is deprecated as of OTP 23 and scheduled for removal in OTP 24.

This adapter depends on a local cache adapter (primary storage), it adds
a thin layer on top of it in order to distribute requests across a group
of nodes, where is supposed the local cache is running already. However,
you don't need to define any additional cache module for the primary
storage, instead, the adapter initializes it automatically (it adds the
primary storage as part of the supervision tree) based on the given
options within the `primary_storage_adapter:` argument.

## Usage

When used, the Cache expects the `:otp_app` and `:adapter` as options.
The `:otp_app` should point to an OTP application that has the cache
configuration. For example:

    defmodule MyApp.PartitionedCache do
      use Nebulex.Cache,
        otp_app: :my_app,
        adapter: Nebulex.Adapters.Partitioned
    end

Optionally, you can configure the desired primary storage adapter with the
option `:primary_storage_adapter`; defaults to `Nebulex.Adapters.Local`.

    defmodule MyApp.PartitionedCache do
      use Nebulex.Cache,
        otp_app: :my_app,
        adapter: Nebulex.Adapters.Partitioned,
        primary_storage_adapter: Nebulex.Adapters.Local
    end

Also, you can provide a custom keyslot function:

    defmodule MyApp.PartitionedCache do
      use Nebulex.Cache,
        otp_app: :my_app,
        adapter: Nebulex.Adapters.Partitioned,
        primary_storage_adapter: Nebulex.Adapters.Local

      @behaviour Nebulex.Adapter.Keyslot

      @impl true
      def hash_slot(key, range) do
        key
        |> :erlang.phash2()
        |> :jchash.compute(range)
      end
    end

Where the configuration for the cache must be in your application environment,
usually defined in your `config/config.exs`:

    config :my_app, MyApp.PartitionedCache,
      keyslot: MyApp.PartitionedCache,
      primary: [
        gc_interval: 3_600_000,
        backend: :shards
      ]

If your application was generated with a supervisor (by passing `--sup`
to `mix new`) you will have a `lib/my_app/application.ex` file containing
the application start callback that defines and starts your supervisor.
You just need to edit the `start/2` function to start the cache as a
supervisor on your application's supervisor:

    def start(_type, _args) do
      children = [
        {MyApp.PartitionedCache, []},
        ...
      ]

See `Nebulex.Cache` for more information.

## Options

This adapter supports the following options and all of them can be given via
the cache configuration:

  * `:primary` - The options that will be passed to the adapter associated
    with the local primary storage. These options will depend on the local
    adapter to use.

  * `:keyslot` - Defines the module implementing `Nebulex.Adapter.Keyslot`
    behaviour.

  * `:task_supervisor_opts` - Start-time options passed to
    `Task.Supervisor.start_link/1` when the adapter is initialized.

  * `:join_timeout` - Interval time in milliseconds for joining the
    running partitioned cache to the cluster. This is to ensure it is
    always joined. Defaults to `:timer.seconds(180)`.

## Shared options

Almost all of the cache functions outlined in `Nebulex.Cache` module
accept the following options:

  * `:timeout` - The time-out value in milliseconds for the command that
    will be executed. If the timeout is exceeded, then the current process
    will exit. For executing a command on remote nodes, this adapter uses
    `Task.await/2` internally for receiving the result, so this option tells
    how much time the adapter should wait for it. If the timeout is exceeded,
    the task is shut down but the current process doesn't exit, only the
    result associated with that task is skipped in the reduce phase.

## Telemetry events

This adapter emits all recommended Telemetry events, and documented
in `Nebulex.Cache` module (see **"Adapter-specific events"** section).

Since the partitioned adapter depends on the configured primary storage
adapter (local cache adapter), this one may also emit Telemetry events.
Therefore, there will be events emitted by the partitioned adapter as well
as the primary storage adapter. For example, for the cache defined before
`MyApp.PartitionedCache`, these would be the emitted events:

  * `[:my_app, :partitioned_cache, :command, :start]`
  * `[:my_app, :partitioned_cache, :primary, :command, :start]`
  * `[:my_app, :partitioned_cache, :command, :stop]`
  * `[:my_app, :partitioned_cache, :primary, :command, :stop]`
  * `[:my_app, :partitioned_cache, :command, :exception]`
  * `[:my_app, :partitioned_cache, :primary, :command, :exception]`

As you may notice, the telemetry prefix by default for the partitioned cache
is `[:my_app, :partitioned_cache]`, and the prefix for its primary storage
`[:my_app, :partitioned_cache, :primary]`.

See also the [Telemetry guide](http://hexdocs.pm/nebulex/telemetry.html)
for more information and examples.

## Adapter-specific telemetry events

This adapter exposes following Telemetry events:

  * `telemetry_prefix ++ [:bootstrap, :started]` - Dispatched by the adapter
    when the bootstrap process is started.

    * Measurements: `%{system_time: non_neg_integer}`
    * Metadata:

      ```
      %{
        adapter_meta: %{optional(atom) => term},
        cluster_nodes: [node]
      }
      ```

  * `telemetry_prefix ++ [:bootstrap, :stopped]` - Dispatched by the adapter
    when the bootstrap process is stopped.

    * Measurements: `%{system_time: non_neg_integer}`
    * Metadata:

      ```
      %{
        adapter_meta: %{optional(atom) => term},
        cluster_nodes: [node],
        reason: term
      }
      ```

  * `telemetry_prefix ++ [:bootstrap, :exit]` - Dispatched by the adapter
    when the bootstrap has received an exit signal.

    * Measurements: `%{system_time: non_neg_integer}`
    * Metadata:

      ```
      %{
        adapter_meta: %{optional(atom) => term},
        cluster_nodes: [node],
        reason: term
      }
      ```

  * `telemetry_prefix ++ [:bootstrap, :joined]` - Dispatched by the adapter
    when the bootstrap has joined the cache to the cluster.

    * Measurements: `%{system_time: non_neg_integer}`
    * Metadata:

      ```
      %{
        adapter_meta: %{optional(atom) => term},
        cluster_nodes: [node]
      }
      ```

## Stats

This adapter depends on the primary storage adapter for the stats support.
Therefore, it is important to ensure the underlying primary storage adapter
does support stats, otherwise, you may get unexpected errors.

## Extended API

This adapter provides some additional convenience functions to the
`Nebulex.Cache` API.

Retrieving the primary storage or local cache module:

    MyCache.__primary__()

Retrieving the cluster nodes associated with the given cache `name`:

    MyCache.nodes()

Get a cluster node based on the given `key`:

    MyCache.get_node("mykey")

Joining the cache to the cluster:

    MyCache.join_cluster()

Leaving the cluster (removes the cache from the cluster):

    MyCache.leave_cluster()

## Caveats of partitioned adapter

For `c:Nebulex.Cache.get_and_update/3` and `c:Nebulex.Cache.update/4`,
they both have a parameter that is the anonymous function, and it is compiled
into the module where it is created, which means it necessarily doesn't exists
on remote nodes. To ensure they work as expected, you must provide functions
from modules existing in all nodes of the group.

# `do_put_all`

# `eval_stream`

Helper to perform `stream/3` locally.

# `with_dynamic_cache`

Helper function to use dynamic cache for internal primary cache storage
when needed.

---

*Consult [api-reference.md](api-reference.md) for complete listing*