+1
On Mon, 20 Dec 2021 at 13:42, Lan Liang <liangyuanpen...@163.com> wrote: > My two cents +1 , In my case, i sometimes need to run pulsar standalone in > some server with limited resources. > > > > Proposed changes > > The other point i can think of is maybe schema storage also need to change > from using BK to using local filesystem or some else. > > > > > > > Best Regards, > Lan Liang > On 12/17/2021 12:35，Sijie Guo<guosi...@gmail.com> wrote： > +1 > > On Tue, Dec 14, 2021 at 9:18 AM Matteo Merli <mme...@apache.org> wrote: > > https://github.com/apache/pulsar/issues/13302 > > Copying here for quoting convenience > ---- > > > > > ## Motivation > > Pulsar standalone is the "Pulsar in a box" version of a Pulsar cluster, > where > all the components are started within the context of a single JVM process. > > Users are using the standalone as a way to get quickly started with Pulsar > or > in all the cases where it makes sense to have a single node deployment. > > Right now, the standalone is starting by default with many components, > several of > which are quite complex, since they are designed to be deployed in a > distributed > fashion. > > ## Goal > > Simplify the components of Pulsar standalone to achieve: > > 1. Reduce complexity > 2. Reduce startup time > 3. Reduce memory and CPU footprint of running standalone > > ## Proposed changes > > The proposal here is to change some of the default implementations that are > used for the Pulsar standalone. > > 1. **Metadata Store implementation** --> > Change from ZooKeeper to RocksDB > > 2. **Pulsar functions package backend** --> > Change from using DistributedLog to using local filesystem, storing > the > jars directly in the data folder instead of uploading them into BK. > > 3. **Pulsar functions state store implementation** --> > Change the state store to be backed by a MetadataStore based backed, > with the RocksDB implementation. > > 4. **Table Service** --> > Do not start BK table service by default > > ## Compatibility considerations > > In order to avoid compatibility issues where users have existing Pulsar > standalone services that they want to upgrade without conflicts, we will > follow the principle of keeping the old defaults where there is existing > data on the disk. > > We will add a file, serving the purpose as a flag, in the `data/standalone` > directory, for example `new-2.10-defaults`. > > If the file is present, or if the data directory is completely missing, we > will adopt the new set of default configuration settings. > > If the file is not there, we will continue to use existing defaults and we > will > not break the upgrade operation. > > > > > > -- > Matteo Merli > <mme...@apache.org> > >
