Add unique_id() builtin.

[petermattis]

Unique IDs are composed of the current time in milliseconds, a 31-bit
random number and a 32-bit node-id. If two unique IDs are generated within
the same millisecond on a server, the random number is incremented instead
of being generated fresh. This ensures that unique ID generation is
monotonic on a single server and k-sorted across servers.

Fixes #2513.

[petermattis]

@vivekmenezes This will be of interest to your current_timestamp work. I think you'll just need to add another field here, populate it when the context is created and use it from the current_timestamp function.

[vivekmenezes]

awesome!

[tamird]

LGTM

[bdarnell]

What value does the randomness add? It could be used to avoid collisions if the node ID was not present, but since it is there (timestamp, counter, nodeID) seems to be sufficient for uniqueness (resetting the counter to 0 every millisecond. Or not; I don't see a reason to care about the IDs being monotonic per node).

One downside to a counter that starts from 0 is that it leaks a little more information about the state of the cluster (e.g. the rate of ID generation at the time the record was created). But if we're concerned about that we may want to obscure the node ID as well. (timestamp plus a sufficiently large random value would be my preferred solution if we don't want to leak too much information).

[bdarnell]

If we swap the random field for a counter it might also make sense to reorder the fields to (timestamp, nodeID, counter). This way records that were created on the same node would be more likely to be adjacent for future access (although the effectiveness of this will be limited to records created the same millisecond so I'm not sure it makes sense).

[petermattis]

I'm not entirely sure about the randomness either. I was initially following in the footsteps of Twitter's snowflake ID, though clearly we've already diverged from there. The possibilities here are:

• timestamp+random+nodeID - guaranteed unique.
• timestamp+counter+nodeID - guaranteed unique, monotonic on a single node.
• timestamp+random - probabilistically unique. also makes the encoded ID slightly larger.
• timestamp+nodeID+counter - guaranteed unique, monotonic and sequential on a single node within the timestamp granularity.

The advantage to per-node monotonicity is that the insertion of multiple rows into a table will behave as expected:

  INSERT INTO t VALUES (unique_id(), "hello"), (unique_id(), "world")

Without the per-node monotonicity guarantee, the ordering of these rows would be random. We could definitely document this, but it seemed too surprising when I thought about it.

[spencerkimball]

Worth mentioning that time stamp + counter is equivalent to using our hlc
time stamp, assuming you keep one stamp in nanos, not millis.

On Monday, September 21, 2015, Peter Mattis [email protected]
wrote:

In sql/parser/builtins.go
#2570 (comment):

• // TODO(pmattis): We could squeeze a bit more space out of the encoding. For
• // example, we could limit the node-id to 16-bits and the random component to
• // 16-bits and handle overflow of the rand value by incrementing the
• // millisecond component.
• //
• // TODO(pmattis): Do we have to worry about persisting the milliseconds value
• // periodically to avoid the clock ever going backwards (e.g. due to NTP
• // adjustment)?
• millis := uint64(time.Now().UnixNano() / int64(time.Millisecond))
• uniqueIDState.Lock()
• if millis <= uniqueIDState.millis {

•   millis = uniqueIDState.millis
  

•   uniqueIDState.rand++
  

• } else {

•   uniqueIDState.millis = millis
  

•   uniqueIDState.rand = uint32(rand.Int31())
  

I'm not entirely sure about the randomness either. I was initially
following in the footsteps of Twitter's snowflake ID, though clearly we've
already diverged from there. The possibilities here are:

• timestamp+random+nodeID - guaranteed unique.
• timestamp+counter+nodeID - guaranteed unique, monotonic on a single
  node.
• timestamp+random - probabilistically unique. also makes the encoded
  ID slightly larger.
• timestamp+nodeID+counter - guaranteed unique, monotonic and
  sequential on a single node within the timestamp granularity.

The advantage to per-node monotonicity is that the insertion of multiple
rows into a table will behave as expected:

INSERT INTO t VALUES (unique_id(), "hello"), (unique_id(), "world")

Without the per-node monotonicity guarantee, the ordering of these rows
would be random. We could definitely document this, but it seemed too
surprising when I thought about it.

—
Reply to this email directly or view it on GitHub
https://github.com/cockroachdb/cockroach/pull/2570/files#r39966596.

[petermattis]

Another option:

• nanos+nodeID where we bump the nanos value if it the clock ever returns the same one. This would be the smallest encoding of the existing proposed options.

[bdarnell]

Why would someone use unique_bytes() instead of unique_int()? Just for the extra nodeID address space? This doesn't seem like something we want to expose, especially for multi-tenant hosted solutions where the number of nodes is not something the client should care (or even know) about.

Another thing to consider: a common trick with bigtable was to prefix your keys with something not strictly ordered (either a hash of something or a random number) so you didn't end up with a single tablet as a hotspot for all your writes. We may want to wait until we get some experience to settle on a final id generation scheme.

[petermattis]

Yes, exposing both unique_bytes() and unique_int() is ugly and awkward. Do you think 1<<15 node-ids is sufficient?

Perhaps these functions should be renamed experimental_unique_bytes() and experimental_unique_int() until we get some experience with them. Not adding them at all sounds like just punting the problem to the future.

[petermattis]

FYI, the bigtable trick can be accomplished using the existing functions:

  SELECT to_hex((random() * 100.0)::int) || unique_bytes()

[bdarnell]

Renaming them to experimental_* SGTM.

[petermattis]

Added the experimental_ prefix.

[jusongchen]

@petermattis, This is about type casts. Will cockroach support both of the following?
a) SELECT to_hex((random() * 100.0)::int)
b) SELECT to_hex( cast (random() * 100.0) as int) )

Since the :: form is a postgres historical usage, I would rather cockroach to only support cast(). The :: form looks so odd to me.

regards,
Jusong Chen

[petermattis]

@jusongchen We currently support both syntaxes. Everything new looks odd, so I'm not sure that is a good reason to get rid of it. On the other hand, I don't see a strong reason for keeping the :: syntax other than to make transitioning from postgres easier.

[jusongchen]

@peter, here are reasons to get rid of the ::syntax
a) This postgres dialect has little value unless cockroachDB wants to be
100% compatible with postgres
b) The more special keywords, operators or delimitors , the harder for a
developer to learn/master the language
c) compared to the ::syntax, cast() is much easier to read and understand

regards,

Jusong

On Tue, Sep 22, 2015 at 7:35 AM, Peter Mattis [email protected]
wrote:

@jusongchen https://github.com/jusongchen We currently support both
syntaxes. Everything new looks odd, so I'm not sure that is a good reason
to get rid of it. On the other hand, I don't see a strong reason for
keeping the :: syntax other than to make transitioning from postgres
easier.

—
Reply to this email directly or view it on GitHub
#2570 (comment)
.

Jusong Chen
408 315 2288

[petermattis]

@jusongchen Thanks for the feedback. You've definitely got strong opinions about the syntax which we'll take under consideration. If you have the energy, it would be worthwhile to gather a list of all the non-standard syntax in our grammar. Unfortunately, the only way to discover this syntax currently is by looking at the grammar (sql.y).

[jusongchen]

@pmattis, Regarding non-standard syntax, here are operators postgres
introduced to implement their corresponding math functions. I recommend
cockroach NOT to support these operators as a function like sqrt(2) is
much easier to understand than its operator form.

Operator

Description

^

exponentiation

|/

square root

||/

cube root

!

factorial

!!

factorial (prefix operator)

@

absolute value

regards,
Jusong

On Tue, Sep 22, 2015 at 2:59 PM, Peter Mattis [email protected]
wrote:

@jusongchen https://github.com/jusongchen Thanks for the feedback.
You've definitely got strong opinions about the syntax which we'll take
under consideration. If you have the energy, it would be worthwhile to
gather a list of all the non-standard syntax in our grammar. Unfortunately,
the only way to discover this syntax currently is by looking at the grammar
(sql.y
https://github.com/cockroachdb/cockroach/blob/master/sql/parser/sql.y).

—
Reply to this email directly or view it on GitHub
#2570 (comment)
.

[petermattis]

@jusongchen I specifically pointed you at our grammar because we already do not support these operators. And to make sure we're on the same page: we would like to support ANSI SQL syntax where it exists, but do not plan to limit ourselves to strict ANSI SQL. You'll be fighting a losing battle if you continue to suggest otherwise.

[petermattis]

@jusongchen Upon re-reading the above, I realize it was overly terse and direct. Your input is definitely desired on these topics. If you feel strongly that CockroachDB should limit itself to strict ANSI SQL, file an issue so that we can discuss and come to a conclusion. I have strong feelings myself about not wanting to limit ourselves to ANSI SQL, but my feelings are less strong when there is functionality overlap (as in the case of the :: operator). So there is discussion to be had and hopefully a conclusion to be reached that will clarify the decision making process as we implement SQL functionality.