On Wed, Jun 20, 2018 at 12:45 PM Enrico Olivelli <eolive...@gmail.com>
wrote:

>
>
> Il mer 20 giu 2018, 16:52 Sijie Guo <guosi...@gmail.com> ha scritto:
>
>> On Wed, Jun 20, 2018 at 4:09 AM Enrico Olivelli <eolive...@gmail.com>
>> wrote:
>>
>>> Hi,
>>> I am experimenting DBLedgerStorage with some project.
>>> With my workloads I don't see much benefit, or sometimes a performance
>>> degradation,
>>>
>>
>> Do you have a performance comparison? Or can you describe what have you
>> observed?
>>
>
> No real 'sharable' numbers, just run a bunch of benchmarks of one
> application. My data has no real meaning.
>
>
>
>
>>
>>> just by keeping the same bookie and application configuration (just
>>> switching the storage manager classe name in the bookie configuration).
>>>
>>> Which is the expected workload for DBLedgerStorage ?
>>> (Usually I am using the default SortedLedgerStorage)
>>>
>>
>> Ideally it should be working out better when you have large number of
>> ledgers per bookie (let's say more than 10k ledgers).
>>
>
> My test created only a few ledger ( less then 10) so maybe this is why I
> see no benefit.
>
As far as I understand RocksDB is used for indexes and maybe with a few
> ledgers the overhead is greater than the gain in term of resource saving.
> I have to tune my test with more concurrency.
>

> In this project I will have concurrent readers and writers, but readers
> will access data at any point of ledgers, so no usual 'tailing reads'. I
> will be using ledgers more likes files than like streams.
>

Are you fetching data by entry ids or would you expect to fetch entries by
their *bytes* offset?

In other words, does this https://github.com/apache/bookkeeper/issues/1376
meet your requirement if you are looking for an interface to fetch entries
more about their "bytes" offset?


> So having rocks db to store offsets seems a very good chance for me.
> In real systems I will have thousands of active ledgers per bookie.
> I have to use a more complex suite of benchmarks for the use case.
>
> I will be back with more interesting comparisons
>
> Thank you
> Enrico
>
>
>
>
>>
>>>
>>> Cheers
>>> Enrico
>>>
>>>
>>>
>>> --
>
>
> -- Enrico Olivelli
>

Reply via email to