druid

History

Gian Merlino e4e5f0375b SegmentAllocateAction (fixes #1515 ) This is a feature meant to allow realtime tasks to work without being told upfront what shardSpec they should use (so we can potentially publish a variable number of segments per interval). The idea is that there is a "pendingSegments" table in the metadata store that tracks allocated segments. Each one has a segment id (the same segment id we know and love) and is also part of a sequence. The sequences are an idea from @cheddar that offers a way of doing replication. If there are N tasks reading exactly the same data with exactly the same logic (think Kafka tasks reading a fixed range of offsets) then you can place them in the same sequence, and they will generate the same sequence of segments.	2015-11-11 16:54:35 -08:00
..
src	SegmentAllocateAction (fixes #1515 )	2015-11-11 16:54:35 -08:00
pom.xml	bump next snapshot to 0.9.0	2015-10-20 13:46:13 -07:00

Gian Merlino e4e5f0375b SegmentAllocateAction (fixes #1515 )

This is a feature meant to allow realtime tasks to work without being told upfront
what shardSpec they should use (so we can potentially publish a variable number
of segments per interval).

The idea is that there is a "pendingSegments" table in the metadata store that
tracks allocated segments. Each one has a segment id (the same segment id we know
and love) and is also part of a sequence.

The sequences are an idea from @cheddar that offers a way of doing replication.
If there are N tasks reading exactly the same data with exactly the same logic
(think Kafka tasks reading a fixed range of offsets) then you can place them
in the same sequence, and they will generate the same sequence of segments.

2015-11-11 16:54:35 -08:00

src

SegmentAllocateAction (fixes #1515 )

2015-11-11 16:54:35 -08:00

pom.xml

bump next snapshot to 0.9.0

2015-10-20 13:46:13 -07:00