[
https://issues.apache.org/jira/browse/KUDU-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16491252#comment-16491252
]
Alexey Serbin commented on KUDU-1861:
-------------------------------------
My 2c: I might be missing something, but I think the introduction of the shared
counter is more 'intrusive', and switching from hash-based partitions to
range-based partitions is less intrusive (if talking about current
implementation). Also, it doesn't require any synchronization between threads
(even if using atomics), which might be better for the data rate output from
the client.
However, feel free to implement whatever way you think is better.
> 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)
