[
https://issues.apache.org/jira/browse/KUDU-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16499287#comment-16499287
]
Andrew Wong commented on KUDU-1861:
-----------------------------------
Thanks for the input Alexey! You're right that if the goal for this is
performance, range partitioning would be preferable. I wasn't a huge fan of
tying the desired end behavior (sequential inserts) to the table schema and the
distribution of inserts across generator threads, but for performance, it's a
good call.
> kudu test loadgen: change default behavior to avoid compactions on tablet
> servers
> ----------------------------------------------------------------------------------
>
> Key: KUDU-1861
> URL: https://issues.apache.org/jira/browse/KUDU-1861
> Project: Kudu
> Issue Type: Improvement
> Components: util
> Affects Versions: 1.2.0
> Reporter: Alexey Serbin
> Assignee: Andrew Wong
> Priority: Major
>
> In the context of use case to '...generate as many Kudu blocks as
> possible...', the 'kudu test loadgen' tool can do better job if exercising a
> load pattern which maximizes throughput and avoids compaction activity on
> tablet servers.
> In short, the default behavior should change for the auto-created table case,
> so the tool would:
> # create a table with N partitions (where n == number of generator threads)
> # let each worker thread insert sequentially into its own partition
> Current option of having hash-partioned auto-created table should be
> preserved, but turned off by default. For some test scenarios, it makes
> sense to exercise data load patterns which involve a lot of compaction
> activity on the tablet servers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
