On Wed, Jan 10, 2018 at 11:57 AM, Adar Lieber-Dembo <[email protected]>
wrote:
>
> As far as specific bottlenecks are concerned, the spreading of LBM
> metadata across multiple files is a main contributor to our long
> startup times, and that's one of the biggest scalability bottlenecks
> AFAIK.
>
I think the context of the doc Andrew posted is more about tablet-meta and
consensus-meta and less about LBM meta. Improving LBM meta to be more
efficiently stored (perhaps rolled into the same storage as other bits of
metadata) is a nice idea as well, and maybe there are some shared bits of
infrastructure here though?
(eg if we imported rocksdb, lmdb, or built a simple KV-store abstraction
maybe we could use it for all these use cases equally)
>
> > With these points in mind, it seems the reasonable path forward is go
> with
> > 1. and introduce a flag for users to colocate WALs and metadata.
>
> Makes sense. Will colocation be enabled by default for new clusters?
> How about using the flag to define an explicit metadata directory,
> with the default being empty ("use the WAL directory")? That'd make it
> similar to fs_data_dirs, which is nice. If the metadata directory
> can't be found in directory specified by this gflag (or in the WAL
> directory, if blank), we can fall back to looking in the first data
> directory.
>
That sounds reasonable to me.
-Todd
--
Todd Lipcon
Software Engineer, Cloudera
