I'm testing currently very simple implementation
that stores content in custom xattr (as I understand xattrs lay in same
key-value storage as omap)
Most objects are less than 8k.
Initial intention was to eliminate crashes of allocator like this
http://tracker.ceph.com/issues/22510
I expected that if there will be only key-values it will be somehow
easier for allocator.
And reduce space overhead of cause.
In current test at least S3 latency decreased by 30%.
I'll tell if this approach will show any useful results.
On 12/23/2017 04:38 AM, Robin H. Johnson wrote:
On Thu, Dec 21, 2017 at 07:35:26PM +0300, Aleksei Gutikov wrote:
Hi all.
While rgw bucket index, theoretically, with reasonable latency can
handle up to 10M objects (100 shards of 100k each),
and rgw user's bucket index can handle, theoretically again, up to 100k
buckets.
One of the scaling concerns I'd talked about before was bucket indices:
even with shards as you note, performance of large buckets isn't great.
I have pondered about how to redesign the index for performance, and one
of the better performing options I decided at least for the moment was
probably going to be via multiple levels of index.
Or, maybe it is possible to store small pieces of data in omap?
As I understand space overhead would be much smaller in this case.
And what about backfilling and remapping for omap?
I'd go for the OMAP rather than packing into a single RADOS object.
However, how small are you talking about?
Beyond 128 bytes I think it would still be better in an object.
--
Best regards,
Aleksei Gutikov
Software Engineer | synesis.ru | Minsk. BY
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
