You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Alex Besogonov <al...@gmail.com> on 2011/12/11 13:00:58 UTC
Unique instance IDs?
I wonder, why there are no unique instance IDs in CouchDB? I'm
thinking about 'the central server replicates 2000000 documents to a
million of clients' scenario.
Right now it's not possible to make replication on the 'big central
server' side to be stateless, because the other side tries to write
replication document which is later used to establish common ancestry.
Server can ignore/discard it, but then during the next replication
client would just have to replicate all the changes again. Of course,
the results would be consistent in any case but quite a lot of
additional traffic might be required.
It should be simple to assign each instance a unique ID (computed
using UUID and the set of applied replication filters) and use it to
establish common replication history. It can even be compatible with
the way the current replication system works and basically the only
visible change should be the addition of UUID to database info.
Or am I missing something?
Re: Unique instance IDs?
Posted by Alex Besogonov <al...@gmail.com>.
On Sun, Dec 11, 2011 at 8:19 PM, Randall Leeds <ra...@gmail.com> wrote:
> I proposed UUIDs for databases a long, long time ago and it's come up
> a few times since. If the UUID is database-level, then storing it with
> the database is dangerous -- copying a database file would result in
> two CouchDB's hosting "the same" (but really different) databases. If
> the UUID is host-level, then this reduces to a re-invention of DNS. In
> other words, all DBs should already be uniquely identified by their
> URLs.
Do people really copy databases? In this case a UUID for DB instance
and UUID for the host should do fine. Host UUIDs can be generated
during couchdb installation, it should be the easiest way.
There's no good way to uniquely identify hosts, unfortunately (or
fortunately). MAC addresses are not reliable and the set of network
interfaces can change rapidly.
And URLs are definitely out of the question - I'm thinking to use my
replicator in home devices that might have duplicate host names with
IP addresses assigned by DHCP.
> Regarding your second paragraph, replicating couches _could_ try to
> establish common ancestry only by examining a local checkpoint of
> replication, but the couch replicator looks for the log on both
> couches to ensure that the database hasn't been deleted+recreated nor
> has it crashed before certain replicated changes hit disk, as a double
> check that the sequence numbers have the expected shared meaning.
Yes, I guessed that's what ensure_full_commit is used for.
> It seems like maybe you're wondering about whether couch could
> generate snapshot ids that are more meaningful than the sequence
> number. For a single pair of couches the host-db-seq combo is enough
> information to replicate effectively. When there's more hosts involved
> we can talk about more powerful checkpoint ids that would be shareable
> or resolvable to find common ancestry between more than two
> replicating hosts to speed up those scenarios. My intuition always
> says that this leads to hash trees, but I haven't thought about it
> deeply enough to fully conceive of what this accomplishes or how it
> would work.
Hash trees are definitely interesting, especially since I really want to
have deterministic IDs for revisions. But their overhead is something to
be considered. Right now I'm at 150000 document insertions/sec for
non-bulk updates and I really like the speed.
Re: Unique instance IDs?
Posted by Adam Kocoloski <ko...@apache.org>.
On Dec 11, 2011, at 10:21 PM, Jason Smith wrote:
> On Mon, Dec 12, 2011 at 9:52 AM, Paul Davis <pa...@gmail.com> wrote:
>> On Sun, Dec 11, 2011 at 7:19 PM, Randall Leeds <ra...@gmail.com> wrote:
>>> On Sun, Dec 11, 2011 at 04:00, Alex Besogonov <al...@gmail.com> wrote:
>>>> I wonder, why there are no unique instance IDs in CouchDB? I'm
>>>> thinking about 'the central server replicates 2000000 documents to a
>>>> million of clients' scenario.
>>>>
>>>> Right now it's not possible to make replication on the 'big central
>>>> server' side to be stateless, because the other side tries to write
>>>> replication document which is later used to establish common ancestry.
>>>> Server can ignore/discard it, but then during the next replication
>>>> client would just have to replicate all the changes again. Of course,
>>>> the results would be consistent in any case but quite a lot of
>>>> additional traffic might be required.
>>>>
>>>> It should be simple to assign each instance a unique ID (computed
>>>> using UUID and the set of applied replication filters) and use it to
>>>> establish common replication history. It can even be compatible with
>>>> the way the current replication system works and basically the only
>>>> visible change should be the addition of UUID to database info.
>>>>
>>>> Or am I missing something?
>>>
>>> I proposed UUIDs for databases a long, long time ago and it's come up
>>> a few times since. If the UUID is database-level, then storing it with
>>> the database is dangerous -- copying a database file would result in
>>> two CouchDB's hosting "the same" (but really different) databases. If
>>> the UUID is host-level, then this reduces to a re-invention of DNS. In
>>> other words, all DBs should already be uniquely identified by their
>>> URLs.
>>>
>>> Regarding your second paragraph, replicating couches _could_ try to
>>> establish common ancestry only by examining a local checkpoint of
>>> replication, but the couch replicator looks for the log on both
>>> couches to ensure that the database hasn't been deleted+recreated nor
>>> has it crashed before certain replicated changes hit disk, as a double
>>> check that the sequence numbers have the expected shared meaning.
>>>
>>> It seems like maybe you're wondering about whether couch could
>>> generate snapshot ids that are more meaningful than the sequence
>>> number. For a single pair of couches the host-db-seq combo is enough
>>> information to replicate effectively. When there's more hosts involved
>>> we can talk about more powerful checkpoint ids that would be shareable
>>> or resolvable to find common ancestry between more than two
>>> replicating hosts to speed up those scenarios. My intuition always
>>> says that this leads to hash trees, but I haven't thought about it
>>> deeply enough to fully conceive of what this accomplishes or how it
>>> would work.
>>>
>>> -R
>>
>> I did have a shimmering of an idea for this awhile back. Basically we
>> do both host and db uuid's and the information we use to identifiy
>> replications is a hash of the concatenation.
>>
>> That way we can copy db's around and not muck with things as well as
>> error out a bit. Though this still has a bit of an issue if we copy
>> the host uuid around as well. Though we migth be able to look for a
>> mac address or something and then fail to boot if the check fails
>> (with an optional override if someone changes a nic).
>
> A couch URL is its unique identifier. A database URL is its unique
> identifier. This sounds like a too-clever-by-half optimization. IMHO.
>
> --
> Iris Couch
Clever or not, transitive replication checkpoints would be a pretty significant optimization. I don't think it has to end up in the land of hash trees, though I'll grant that those structures are a fine tool to quickly identify discrepancies between any two databases (and they map nicely to couch_btree to boot).
Adam
Re: Unique instance IDs?
Posted by Jason Smith <jh...@iriscouch.com>.
I think my point is, if URLs don't work, nothing will. There's no free lunch.
But if an optimization surfaces, I will happily stand corrected.
On Thu, Dec 15, 2011 at 5:52 AM, Joan Touzet <jo...@atypical.net> wrote:
> -1 on using URI/URLs, for the simple fact that mobile and desktop
> devices often don't have a stable hostname and/or IP address. This is a
> huge area where CouchDB is used, increasingly so, and attempting to tie
> a DB UUID to something inherently variable on the platform is doomed to
> fail.
>
> Renaming my PC or phone, getting a new DHCP address, connecting to a
> different network or changing the MAC address of my NIC should not
> invalidate my DBs, their "UUIDs", or cause unreasonable problems for
> replication.
>
> -Joan
--
Iris Couch
Re: Unique instance IDs?
Posted by Riyad Kalla <rk...@gmail.com>.
Robert, to your point, when would you copy an entire DB to another live
server and *not* have the intention of the two be replicas of each other?
The UUID would be akin to a social-security-number for the docs, so if I
have a doc "A" in Server1 with a SSN of "333-90-3231", and that same doc
existed on another server, say Servers 2 and 3, I would *expect* that any
doc claiming that social security number would be making a claim of
identity with any other doc with the same SSN.
The same way you might resolve a record for someone at the DMV along with
the IRS to establish they are the same person.
The same way two docs in two different locations with the same ID are an
indicator of identity. Especially with a UUID (i.e. the chances of that
equality existing by chance as compared to a sequential value are
astronomically small).
Seems like UUIDs are an excellent way to go for doc IDs if you need them
(and not some more domain-specific ID).
On Thu, Feb 2, 2012 at 8:43 AM, Kevin R. Coombes
<ke...@gmail.com>wrote:
> I don't think it's such a slam-dunk, but maybe I'm guilty of a
> goal-tending violation.
>
> It depends on whether you intend to keep replicating the two copies to
> keep them synchronized. If you want that (and most of the time, I do),
> then I think it's an advantage to keep the same "UUID". The (matching)
> internal UUIDs indicates that you think of these two things as the same
> abstract entity. The full URL distinguishes the "physical" copies.
>
> If on the other hand, you expect the copies to evolve into something
> differently over time, then I can see how you might want different UUIDs.
> But again, the full, easy-to-construct URL distinguishes them.
>
> As far as I can tell, the existing system still lets you have it both
> ways....
>
>
> On 2/2/2012 8:45 AM, Robert Newson wrote:
>
>> ... until you copy the database (and its uuid) and have two databases
>> with the same uuid. This has always been the slam-dunk argument
>> against database uuid's.
>>
>> B.
>>
>> On 2 February 2012 09:41, Kevin R. Coombes<ke...@gmail.com>>
>> wrote:
>>
>>> For CouchDB, I think UUIDs are clearly the way to go. After all, given
>>> the
>>> UUID, database, and hostname, you can construct the desired URL
>>> directly by
>>> forming
>>> http://hostname:5984/database/**UUID<http://hostname:5984/database/UUID>
>>> As Noah points out, if you used this entire URL as the identifier (by
>>> which
>>> I assume he means the _id field), then you would lose the ability to copy
>>> the document elsewhere. This would, of course, break replication
>>> completely.
>>>
>>> Keeping the UUIDs as they are gives the best of both worlds. Easy
>>> replication, and (as long as the database is hosted at the same place) an
>>> easy way for humans and programs to construct stable URIs or URLs that
>>> point
>>> to each document.
>>>
>>> -- Kevin
>>>
>>>
>>> On 1/22/2012 12:44 PM, Noah Slater wrote:
>>>
>>>> Sorry to bump this old thread, but just going through my backlog.
>>>>
>>>> With regard to URLs, I think there is some confusion about the purpose
>>>> of
>>>> a
>>>> URL here.
>>>>
>>>> If I write a a cool essay, say, and I stick that up at
>>>> nslater.org/my-cool-essay, then I can link to it from other places on
>>>> the
>>>> web using that address. I might also want to put my cool essay on
>>>> Dropbox,
>>>> or post it to Tumblr, or send it in an email. Now my cool essay has lots
>>>> of
>>>> URLs. Each one of them perfectly valid. I don't have to go and edit the
>>>> original copy at nslater.org/my-cool-essay, because I am making copies
>>>> of
>>>> it. My cool essay is completely unaware of the URLs that are being used
>>>> to
>>>> point to it. And it doesn't care that many URLs point to it.
>>>>
>>>> Yes, URLs can be used as identifiers. But when you do this, you tie the
>>>> thing you're naming to the place you're hosting it. Sometimes that is
>>>> useful, other times it will cripple you. There is nothing about URLs
>>>> that
>>>> requires you to do this. I would hazard a guess that 99% of URLs are
>>>> de-coupled from the things they point to. WebArch is much more robust
>>>> when
>>>> the identity of the object is de-coupled from the URL. Look at Atom, the
>>>> ID
>>>> element is supposed to be a URL, but they recommend a non-dereferencable
>>>> format, precisely to decouple posts from the location you happen to be
>>>> hosting them this month.
>>>>
>>>> Hey, if we're gonna use URLs, maybe we want to go down the same route?
>>>>
>>>> http://en.wikipedia.org/wiki/**Tag_URI<http://en.wikipedia.org/wiki/Tag_URI>
>>>>
>>>>
>>>> At this point, I'm not sure what they buy us over UUIDs.
>>>>
>>>> Thoughts?
>>>>
>>>> Thanks,
>>>>
>>>> N
>>>>
>>>>
Re: Unique instance IDs?
Posted by "Kevin R. Coombes" <ke...@gmail.com>.
I don't think it's such a slam-dunk, but maybe I'm guilty of a
goal-tending violation.
It depends on whether you intend to keep replicating the two copies to
keep them synchronized. If you want that (and most of the time, I do),
then I think it's an advantage to keep the same "UUID". The (matching)
internal UUIDs indicates that you think of these two things as the same
abstract entity. The full URL distinguishes the "physical" copies.
If on the other hand, you expect the copies to evolve into something
differently over time, then I can see how you might want different
UUIDs. But again, the full, easy-to-construct URL distinguishes them.
As far as I can tell, the existing system still lets you have it both
ways....
On 2/2/2012 8:45 AM, Robert Newson wrote:
> ... until you copy the database (and its uuid) and have two databases
> with the same uuid. This has always been the slam-dunk argument
> against database uuid's.
>
> B.
>
> On 2 February 2012 09:41, Kevin R. Coombes<ke...@gmail.com> wrote:
>> For CouchDB, I think UUIDs are clearly the way to go. After all, given the
>> UUID, database, and hostname, you can construct the desired URL directly by
>> forming
>> http://hostname:5984/database/UUID
>> As Noah points out, if you used this entire URL as the identifier (by which
>> I assume he means the _id field), then you would lose the ability to copy
>> the document elsewhere. This would, of course, break replication
>> completely.
>>
>> Keeping the UUIDs as they are gives the best of both worlds. Easy
>> replication, and (as long as the database is hosted at the same place) an
>> easy way for humans and programs to construct stable URIs or URLs that point
>> to each document.
>>
>> -- Kevin
>>
>>
>> On 1/22/2012 12:44 PM, Noah Slater wrote:
>>> Sorry to bump this old thread, but just going through my backlog.
>>>
>>> With regard to URLs, I think there is some confusion about the purpose of
>>> a
>>> URL here.
>>>
>>> If I write a a cool essay, say, and I stick that up at
>>> nslater.org/my-cool-essay, then I can link to it from other places on the
>>> web using that address. I might also want to put my cool essay on Dropbox,
>>> or post it to Tumblr, or send it in an email. Now my cool essay has lots
>>> of
>>> URLs. Each one of them perfectly valid. I don't have to go and edit the
>>> original copy at nslater.org/my-cool-essay, because I am making copies of
>>> it. My cool essay is completely unaware of the URLs that are being used to
>>> point to it. And it doesn't care that many URLs point to it.
>>>
>>> Yes, URLs can be used as identifiers. But when you do this, you tie the
>>> thing you're naming to the place you're hosting it. Sometimes that is
>>> useful, other times it will cripple you. There is nothing about URLs that
>>> requires you to do this. I would hazard a guess that 99% of URLs are
>>> de-coupled from the things they point to. WebArch is much more robust when
>>> the identity of the object is de-coupled from the URL. Look at Atom, the
>>> ID
>>> element is supposed to be a URL, but they recommend a non-dereferencable
>>> format, precisely to decouple posts from the location you happen to be
>>> hosting them this month.
>>>
>>> Hey, if we're gonna use URLs, maybe we want to go down the same route?
>>>
>>> http://en.wikipedia.org/wiki/Tag_URI
>>>
>>>
>>> At this point, I'm not sure what they buy us over UUIDs.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>>
>>> N
>>>
Re: Unique instance IDs?
Posted by Robert Newson <rn...@apache.org>.
... until you copy the database (and its uuid) and have two databases
with the same uuid. This has always been the slam-dunk argument
against database uuid's.
B.
On 2 February 2012 09:41, Kevin R. Coombes <ke...@gmail.com> wrote:
> For CouchDB, I think UUIDs are clearly the way to go. After all, given the
> UUID, database, and hostname, you can construct the desired URL directly by
> forming
> http://hostname:5984/database/UUID
> As Noah points out, if you used this entire URL as the identifier (by which
> I assume he means the _id field), then you would lose the ability to copy
> the document elsewhere. This would, of course, break replication
> completely.
>
> Keeping the UUIDs as they are gives the best of both worlds. Easy
> replication, and (as long as the database is hosted at the same place) an
> easy way for humans and programs to construct stable URIs or URLs that point
> to each document.
>
> -- Kevin
>
>
> On 1/22/2012 12:44 PM, Noah Slater wrote:
>>
>> Sorry to bump this old thread, but just going through my backlog.
>>
>> With regard to URLs, I think there is some confusion about the purpose of
>> a
>> URL here.
>>
>> If I write a a cool essay, say, and I stick that up at
>> nslater.org/my-cool-essay, then I can link to it from other places on the
>> web using that address. I might also want to put my cool essay on Dropbox,
>> or post it to Tumblr, or send it in an email. Now my cool essay has lots
>> of
>> URLs. Each one of them perfectly valid. I don't have to go and edit the
>> original copy at nslater.org/my-cool-essay, because I am making copies of
>> it. My cool essay is completely unaware of the URLs that are being used to
>> point to it. And it doesn't care that many URLs point to it.
>>
>> Yes, URLs can be used as identifiers. But when you do this, you tie the
>> thing you're naming to the place you're hosting it. Sometimes that is
>> useful, other times it will cripple you. There is nothing about URLs that
>> requires you to do this. I would hazard a guess that 99% of URLs are
>> de-coupled from the things they point to. WebArch is much more robust when
>> the identity of the object is de-coupled from the URL. Look at Atom, the
>> ID
>> element is supposed to be a URL, but they recommend a non-dereferencable
>> format, precisely to decouple posts from the location you happen to be
>> hosting them this month.
>>
>> Hey, if we're gonna use URLs, maybe we want to go down the same route?
>>
>> http://en.wikipedia.org/wiki/Tag_URI
>>
>>
>> At this point, I'm not sure what they buy us over UUIDs.
>>
>> Thoughts?
>>
>> Thanks,
>>
>> N
>>
>
Re: Unique instance IDs?
Posted by "Kevin R. Coombes" <ke...@gmail.com>.
For CouchDB, I think UUIDs are clearly the way to go. After all, given
the UUID, database, and hostname, you can construct the desired URL
directly by forming
http://hostname:5984/database/UUID
As Noah points out, if you used this entire URL as the identifier (by
which I assume he means the _id field), then you would lose the ability
to copy the document elsewhere. This would, of course, break
replication completely.
Keeping the UUIDs as they are gives the best of both worlds. Easy
replication, and (as long as the database is hosted at the same place)
an easy way for humans and programs to construct stable URIs or URLs
that point to each document.
-- Kevin
On 1/22/2012 12:44 PM, Noah Slater wrote:
> Sorry to bump this old thread, but just going through my backlog.
>
> With regard to URLs, I think there is some confusion about the purpose of a
> URL here.
>
> If I write a a cool essay, say, and I stick that up at
> nslater.org/my-cool-essay, then I can link to it from other places on the
> web using that address. I might also want to put my cool essay on Dropbox,
> or post it to Tumblr, or send it in an email. Now my cool essay has lots of
> URLs. Each one of them perfectly valid. I don't have to go and edit the
> original copy at nslater.org/my-cool-essay, because I am making copies of
> it. My cool essay is completely unaware of the URLs that are being used to
> point to it. And it doesn't care that many URLs point to it.
>
> Yes, URLs can be used as identifiers. But when you do this, you tie the
> thing you're naming to the place you're hosting it. Sometimes that is
> useful, other times it will cripple you. There is nothing about URLs that
> requires you to do this. I would hazard a guess that 99% of URLs are
> de-coupled from the things they point to. WebArch is much more robust when
> the identity of the object is de-coupled from the URL. Look at Atom, the ID
> element is supposed to be a URL, but they recommend a non-dereferencable
> format, precisely to decouple posts from the location you happen to be
> hosting them this month.
>
> Hey, if we're gonna use URLs, maybe we want to go down the same route?
>
> http://en.wikipedia.org/wiki/Tag_URI
>
>
> At this point, I'm not sure what they buy us over UUIDs.
>
> Thoughts?
>
> Thanks,
>
> N
>
Re: Unique instance IDs?
Posted by Noah Slater <ns...@tumbolia.org>.
Sorry to bump this old thread, but just going through my backlog.
With regard to URLs, I think there is some confusion about the purpose of a
URL here.
If I write a a cool essay, say, and I stick that up at
nslater.org/my-cool-essay, then I can link to it from other places on the
web using that address. I might also want to put my cool essay on Dropbox,
or post it to Tumblr, or send it in an email. Now my cool essay has lots of
URLs. Each one of them perfectly valid. I don't have to go and edit the
original copy at nslater.org/my-cool-essay, because I am making copies of
it. My cool essay is completely unaware of the URLs that are being used to
point to it. And it doesn't care that many URLs point to it.
Yes, URLs can be used as identifiers. But when you do this, you tie the
thing you're naming to the place you're hosting it. Sometimes that is
useful, other times it will cripple you. There is nothing about URLs that
requires you to do this. I would hazard a guess that 99% of URLs are
de-coupled from the things they point to. WebArch is much more robust when
the identity of the object is de-coupled from the URL. Look at Atom, the ID
element is supposed to be a URL, but they recommend a non-dereferencable
format, precisely to decouple posts from the location you happen to be
hosting them this month.
Hey, if we're gonna use URLs, maybe we want to go down the same route?
http://en.wikipedia.org/wiki/Tag_URI
At this point, I'm not sure what they buy us over UUIDs.
Thoughts?
Thanks,
N
Re: Unique instance IDs?
Posted by Joan Touzet <jo...@atypical.net>.
On Wed, Dec 14, 2011 at 04:13:41PM -0800, Randall Leeds wrote:
> I might argue that these bits at the end are link and network layer
> issues that we don't care about.
On the contrary - until there is a solution in the mainline to deal with
NATs and firewalls, you cannot assume that a CouchDB instance can be
seen publicly. A very common use case (for the application I've been
working on) is for a desktop machine, behind a NAT, to have continuous
2-way replication with a public server. Imagine 30 or so machines
connected to such a central server. 31 databases, 62 ongoing
replications, but only one them has a valid URL. Each desktop will have
to pull from and push to the central server; the central server on its
*own* cannot access the machines behind the firewalls.
This is not so unusual a case, is it?
> pulling from or pushing to the device. In this case, the db on the
> mobile device can be identified by a bare database name without any
> URL at all. Examples: Pull http://remotecouch/mydb -> mydb; Push mydb
> -> http://remotercouch/mydb. The replicator works like this today.
See above - the same approach (the exact opposite of what you've
suggested) is the most workable solution *today*.
> The CouchDB community is being very radical by suggesting that we
> might _serve_ content or address content stored on a mobile device.
Yes! And further more solving how to serve data from behind a NAT or
firewall is equally challenging - but doable.
> Given the commitment CouchDB has made to HTTP so far, I hesitate to
> say that the solution to this problem is to subvert URLs.
I'm not saying that's the solution. I'm saying that URLs cannot
necessarily identify all participants in a replication scenario
reliably, especially given RFC 1918 space, variable host names, mobile
platforms and NAT.
> Again, this is getting away from the transitive checkpoint problem,
> which may turn out to obviate the need for identification of databases
> in the first place. Or, as I put it earlier, to focus the problem on
> "what is in this database" rather than "what database this is".
+100 on solving things this way. :)
-Joan
Re: Unique instance IDs?
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Dec 14, 2011 at 14:52, Joan Touzet <jo...@atypical.net> wrote:
> -1 on using URI/URLs, for the simple fact that mobile and desktop
> devices often don't have a stable hostname and/or IP address. This is a
> huge area where CouchDB is used, increasingly so, and attempting to tie
> a DB UUID to something inherently variable on the platform is doomed to
> fail.
>
> Renaming my PC or phone, getting a new DHCP address, connecting to a
> different network or changing the MAC address of my NIC should not
> invalidate my DBs, their "UUIDs", or cause unreasonable problems for
> replication.
>
> -Joan
I might argue that these bits at the end are link and network layer
issues that we don't care about. As far as the Web is concerned, the
URL is the address and it's more than just convenience and readability
that separates that from an IP address. URLs are foundational to
resource identification on the Web, and I'm really hesitant to "work
around" that (nevertheless I've dreaming up and reading all kinds of
ways to do just this these days, and it's pretty hard). I definitely
don't mean to condescendingly suggest you don't know this already; I'm
just restating the basic facts.
Take, for example, the mobile use case. Most people, I'd submit, want
to push from and pull data to a mobile device. Given that the device
doesn't have a stable address (neither in IP nor URL space), most
would punt on the problem of serving from the mobile device, i.e.
pulling from or pushing to the device. In this case, the db on the
mobile device can be identified by a bare database name without any
URL at all. Examples: Pull http://remotecouch/mydb -> mydb; Push mydb
-> http://remotercouch/mydb. The replicator works like this today.
I think it's generally accepted that URLs don't point at the same
device all the time. In practice, obviously, they very frequently
"point at many devices" in that reverse proxies are used all over the
Web for load balancing. I might say it's out of scope for CouchDB to
worry about tying a stable URL to a mobile device. For the ops person
in the datacenter the story right now is clear: if you want to copy
your database, you should probably also copy the hostname over to the
new box or replication starts over.
The CouchDB community is being very radical by suggesting that we
might _serve_ content or address content stored on a mobile device.
Given the commitment CouchDB has made to HTTP so far, I hesitate to
say that the solution to this problem is to subvert URLs.
Again, this is getting away from the transitive checkpoint problem,
which may turn out to obviate the need for identification of databases
in the first place. Or, as I put it earlier, to focus the problem on
"what is in this database" rather than "what database this is".
-Randall
Re: Unique instance IDs?
Posted by Joan Touzet <jo...@atypical.net>.
-1 on using URI/URLs, for the simple fact that mobile and desktop
devices often don't have a stable hostname and/or IP address. This is a
huge area where CouchDB is used, increasingly so, and attempting to tie
a DB UUID to something inherently variable on the platform is doomed to
fail.
Renaming my PC or phone, getting a new DHCP address, connecting to a
different network or changing the MAC address of my NIC should not
invalidate my DBs, their "UUIDs", or cause unreasonable problems for
replication.
-Joan
Re: Unique instance IDs?
Posted by Tobias Bradtke <we...@googlemail.com>.
Am 13.12.2011 02:12, schrieb Paul Davis:
> On Mon, Dec 12, 2011 at 6:30 PM, Jason Smith<jh...@iriscouch.com> wrote:
>> On Tue, Dec 13, 2011 at 12:01 AM, Paul Davis
>> <pa...@gmail.com> wrote:
>>> I think you've contradicted yourself. If a URL is the universal name
>>> for a database, then how are we able to server different databases
>>> from the same URL?
>> The contradiction was intentional. URLs are usually but not always
>> stable. To re-invent a "universal identifier" for a "resource" sounds
>> futile, IMHO.
>>
> I'm going to be pedantic here a bit. And this is on purpose and I've
> warned people. But I'll hopefully tie it back to reality.
>
> First, URL stands for "uniform resource locator" where URI stands for
> "uniform resource identifier". There's a very very important
> distinction between these two things.
>
> In CouchDB land we allow sharing of URL's between to resources (ie,
> delete db, create db) are two logically distinct databases until a
> replication pulls the new one into the "replicated web of dbs" where
> things get a bit more subtle.
>
> But this recycling of URLs I think firmly places them outside the
> scope of URIs in this instance. If we had URLs of the form
> "http://host:port/$UUID" then I would argue in favor of the "URL is
> URI" or perhaps "URL contains URI" type of approach. Though, we don't.
> The URL is merely an alias to the actual database resource.
The distinction of the terms URI and URL or URN and such is rather
historically. In fact there is no specification for URL anymore, see:
http://www.tbray.org/ongoing/When/200x/2003/02/27/URL
An URI in the form of "http://example:port/some/path/or/uuid" would be
globaly unique and as a nice sideeffect you can just dereference it to
actually find and access the databse.
Just my two Cents :)
Re: Unique instance IDs?
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 12, 2011 at 6:30 PM, Jason Smith <jh...@iriscouch.com> wrote:
> On Tue, Dec 13, 2011 at 12:01 AM, Paul Davis
> <pa...@gmail.com> wrote:
>> I think you've contradicted yourself. If a URL is the universal name
>> for a database, then how are we able to server different databases
>> from the same URL?
>
> The contradiction was intentional. URLs are usually but not always
> stable. To re-invent a "universal identifier" for a "resource" sounds
> futile, IMHO.
>
I'm going to be pedantic here a bit. And this is on purpose and I've
warned people. But I'll hopefully tie it back to reality.
First, URL stands for "uniform resource locator" where URI stands for
"uniform resource identifier". There's a very very important
distinction between these two things.
In CouchDB land we allow sharing of URL's between to resources (ie,
delete db, create db) are two logically distinct databases until a
replication pulls the new one into the "replicated web of dbs" where
things get a bit more subtle.
But this recycling of URLs I think firmly places them outside the
scope of URIs in this instance. If we had URLs of the form
"http://host:port/$UUID" then I would argue in favor of the "URL is
URI" or perhaps "URL contains URI" type of approach. Though, we don't.
The URL is merely an alias to the actual database resource.
>> Tying a database to a URL is merely an artificial limitation because
>> we haven't thought of anything better. If we *did* think of a way to
>> uniquely identify databases that didn't break due to ops requirements
>> then that would be a much better fit to the CouchDB model. It is
>> difficult but that's because we haven't yet thought of a good way to
>> deal with what happens OOB when ops teams change server
>> configurations.
>
> All great points. My personal candidate is to look at the rsync
> protocol. From a foggy memory:
>
> * No names, no ids. It's always comparing data against data.
> * Both sides do normal and rolling checksums (perhaps memorized or
> incremental map/reduced for couch)
> * Always 1 round-trip. Receiver sends its checksums to sender, sender
> sends back the updates.
I'm no sure I see your point. Rsync is a significantly different
protocol than CouchDB replication. In fact, the entire point of
CouchDB's replication checkpoints is to avoid rolling checksum style
replication. Ie, replication in the extreme best case is O(1) for
CouchDB. Rsync would have to be at least O(N+M) to do checksums of
both for the comparison.
> People is interested in CouchDB might find this OLS talk and
> transcript fascinating.
>
> http://olstrans.sourceforge.net/release/OLS2000-rsync/OLS2000-rsync.html
>
> --
> Iris Couch
Re: Unique instance IDs?
Posted by Jason Smith <jh...@iriscouch.com>.
On Tue, Dec 13, 2011 at 12:01 AM, Paul Davis
<pa...@gmail.com> wrote:
> I think you've contradicted yourself. If a URL is the universal name
> for a database, then how are we able to server different databases
> from the same URL?
The contradiction was intentional. URLs are usually but not always
stable. To re-invent a "universal identifier" for a "resource" sounds
futile, IMHO.
> Tying a database to a URL is merely an artificial limitation because
> we haven't thought of anything better. If we *did* think of a way to
> uniquely identify databases that didn't break due to ops requirements
> then that would be a much better fit to the CouchDB model. It is
> difficult but that's because we haven't yet thought of a good way to
> deal with what happens OOB when ops teams change server
> configurations.
All great points. My personal candidate is to look at the rsync
protocol. From a foggy memory:
* No names, no ids. It's always comparing data against data.
* Both sides do normal and rolling checksums (perhaps memorized or
incremental map/reduced for couch)
* Always 1 round-trip. Receiver sends its checksums to sender, sender
sends back the updates.
People is interested in CouchDB might find this OLS talk and
transcript fascinating.
http://olstrans.sourceforge.net/release/OLS2000-rsync/OLS2000-rsync.html
--
Iris Couch
Re: Unique instance IDs?
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Dec 14, 2011 at 10:52, Alex Besogonov <al...@gmail.com> wrote:
> On Wed, Dec 14, 2011 at 3:55 AM, Randall Leeds <ra...@gmail.com> wrote:
>> I think you miss the point that was made above about mirrors, still,
>> unless I misunderstand. B may have other changes interleaves with
>> those received from A, whether from interactive updates or other
>> replications, making its hashes different.
> Of course. But that's not a problem, because we save all the A's
> changeset hashes
> that we've seen during the replication. B's resulting hash would be
> different, but we don't
> care about it.
>
> Also, since merging is commutative and associative we can reorder changesets
> in any way, so interleaving changes in itself should be OK.
I might need you to restart your solution for me to understand. If the
hash tree isn't of the sequence or id index, then I'm not seeing what
this applies to except the rev tree of a single document. Documents do
already have a sort of hash, as you identified, in their revision id.
Comparing the presence of these on the client and server is already
part of the replication protocol. However, since CouchDB is _not_ a
versioned document store ("_rev is only for MVCC"), there's no need to
optimize the problem of diffing the revs present. Only the newest revs
need ever be replicated.
The sequence number checkpointing is an optimization to avoid
comparing the revs for all documents. I think progress looks like
finding a way to skip large chunks of the seq index because they
contain changes already received, possibly from elsewhere.
So I'm not sure what your solution proposes. Can you go further?
-Randall
Re: Unique instance IDs?
Posted by Alex Besogonov <al...@gmail.com>.
On Wed, Dec 14, 2011 at 3:55 AM, Randall Leeds <ra...@gmail.com> wrote:
> I think you miss the point that was made above about mirrors, still,
> unless I misunderstand. B may have other changes interleaves with
> those received from A, whether from interactive updates or other
> replications, making its hashes different.
Of course. But that's not a problem, because we save all the A's
changeset hashes
that we've seen during the replication. B's resulting hash would be
different, but we don't
care about it.
Also, since merging is commutative and associative we can reorder changesets
in any way, so interleaving changes in itself should be OK.
Re: Unique instance IDs?
Posted by Randall Leeds <ra...@gmail.com>.
On Tue, Dec 13, 2011 at 20:08, Alex Besogonov <al...@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 10:26 PM, Paul Davis
> <pa...@gmail.com> wrote:
>>> * Merkle trees are great for two-way synchronization, but it's not immediately clear to me how you'd use them to bootstrap a single source -> target replication. I might just be missing a straightforward extension of the tech here.
>> This is the point that's important with checksums and so on. Merkle
>> trees are great when you want to mirror structured data but CouchDB
>> replication is a mirror operation. Think, N db's replicating to a
>> central DB. you have a mixture of things which breaks checksums (or at
>> least any obvious application I can think of given our internal
>> structures)
> Uhm. What are the things that break checksums? Right now revision IDs
> are _almost_
> deterministic and it's not that hard to make them completely
> deterministic. And for
> replication purposes nothing else matters.
>
> To be exact: the only entity used for ID generation is '[Deleted,
> OldStart, OldRev, Body, Atts2]'
> tuple and only 'Atts2' field can be non-deterministic. And that can be
> fixed (with other minor
> forward-looking features like explicit versioning).
>
> Then it's easy to devise a protocol to replicate based on hash trees.
> I'm thinking about
> this protocol:
> 1) The current state of replicated database is identified by a hash.
> Suppose that we
> have unidirectional replication A->B.
>
> Let's denote state of the initial database A as A1 and B's as B1.
>
> We store the ancestry as a list of hashes outside database (so it
> doesn't influence the
> hash of the database).
>
> 2) As the first step B sends its list of replication ancestry.
>
> It's actually not even required to send the whole hashes each time,
> just send the first
> 4 bytes of each hash. That way even 1 million records of replication
> history would take
> only 4Mb. The 'A' server then replies with its own set of hashes with
> the matching
> initial bytes. If there are none, then the client falls back to the
> usual replication.
>
> So at this step 'B' knows the most recent common ancestor and requests
> the changes
> that have happened since that point of time. Each changeset, naturally, has its
> own hash.
>
> 3) After these changes are applied and merged, B's state is the A1
> state plus all the
> B's changes that might have happened ever since. Then B stores the hashes
> of the changesets that have been applied.
>
> That's it. Should work, as far as I see (it's 3am local time, so I
> might miss something).
>
> Overhead: 16 bytes for the hash information for each changeset.
I think you miss the point that was made above about mirrors, still,
unless I misunderstand. B may have other changes interleaves with
those received from A, whether from interactive updates or other
replications, making its hashes different.
Re: Unique instance IDs?
Posted by Alex Besogonov <al...@gmail.com>.
On Mon, Dec 12, 2011 at 10:26 PM, Paul Davis
<pa...@gmail.com> wrote:
>> * Merkle trees are great for two-way synchronization, but it's not immediately clear to me how you'd use them to bootstrap a single source -> target replication. I might just be missing a straightforward extension of the tech here.
> This is the point that's important with checksums and so on. Merkle
> trees are great when you want to mirror structured data but CouchDB
> replication is a mirror operation. Think, N db's replicating to a
> central DB. you have a mixture of things which breaks checksums (or at
> least any obvious application I can think of given our internal
> structures)
Uhm. What are the things that break checksums? Right now revision IDs
are _almost_
deterministic and it's not that hard to make them completely
deterministic. And for
replication purposes nothing else matters.
To be exact: the only entity used for ID generation is '[Deleted,
OldStart, OldRev, Body, Atts2]'
tuple and only 'Atts2' field can be non-deterministic. And that can be
fixed (with other minor
forward-looking features like explicit versioning).
Then it's easy to devise a protocol to replicate based on hash trees.
I'm thinking about
this protocol:
1) The current state of replicated database is identified by a hash.
Suppose that we
have unidirectional replication A->B.
Let's denote state of the initial database A as A1 and B's as B1.
We store the ancestry as a list of hashes outside database (so it
doesn't influence the
hash of the database).
2) As the first step B sends its list of replication ancestry.
It's actually not even required to send the whole hashes each time,
just send the first
4 bytes of each hash. That way even 1 million records of replication
history would take
only 4Mb. The 'A' server then replies with its own set of hashes with
the matching
initial bytes. If there are none, then the client falls back to the
usual replication.
So at this step 'B' knows the most recent common ancestor and requests
the changes
that have happened since that point of time. Each changeset, naturally, has its
own hash.
3) After these changes are applied and merged, B's state is the A1
state plus all the
B's changes that might have happened ever since. Then B stores the hashes
of the changesets that have been applied.
That's it. Should work, as far as I see (it's 3am local time, so I
might miss something).
Overhead: 16 bytes for the hash information for each changeset.
Re: Unique instance IDs?
Posted by Randall Leeds <ra...@gmail.com>.
On Mon, Dec 12, 2011 at 19:31, Adam Kocoloski <ko...@apache.org> wrote:
> On Dec 12, 2011, at 10:26 PM, Paul Davis wrote:
>
>>> * Merkle trees are great for two-way synchronization, but it's not immediately clear to me how you'd use them to bootstrap a single source -> target replication. I might just be missing a straightforward extension of the tech here.
>>
>> This is the point that's important with checksums and so on. Merkle
>> trees are great when you want to mirror structured data but CouchDB
>> replication is a mirror operation. Think, N db's replicating to a
>> central DB. you have a mixture of things which breaks checksums (or at
>> least any obvious application I can think of given our internal
>> structures)
>
> You're missing a rather important s/is/isn't/ there ;-) But yeah, I agree.
Ah, thanks. That's why hash trees are a dead-end.
I think this is why I started to go down the replicating checkpoints
road in the first place.
Make documents like _checkpoint/<id>.
Instrument reading by protecting everything but _id. These become opaque.
Replicate them. Hoo-ray!
Diff/bisect the history of them using _revs_diff.
Something like this?
Re: Unique instance IDs?
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 12, 2011 at 9:31 PM, Adam Kocoloski <ko...@apache.org> wrote:
> On Dec 12, 2011, at 10:26 PM, Paul Davis wrote:
>
>>> * Merkle trees are great for two-way synchronization, but it's not immediately clear to me how you'd use them to bootstrap a single source -> target replication. I might just be missing a straightforward extension of the tech here.
>>
>> This is the point that's important with checksums and so on. Merkle
>> trees are great when you want to mirror structured data but CouchDB
>> replication is a mirror operation. Think, N db's replicating to a
>> central DB. you have a mixture of things which breaks checksums (or at
>> least any obvious application I can think of given our internal
>> structures)
>
> You're missing a rather important s/is/isn't/ there ;-) But yeah, I agree.
There was something shiny on the tv and I got distracted. But yeah,
replication != mirror.
Re: Unique instance IDs?
Posted by Adam Kocoloski <ko...@apache.org>.
On Dec 12, 2011, at 10:26 PM, Paul Davis wrote:
>> * Merkle trees are great for two-way synchronization, but it's not immediately clear to me how you'd use them to bootstrap a single source -> target replication. I might just be missing a straightforward extension of the tech here.
>
> This is the point that's important with checksums and so on. Merkle
> trees are great when you want to mirror structured data but CouchDB
> replication is a mirror operation. Think, N db's replicating to a
> central DB. you have a mixture of things which breaks checksums (or at
> least any obvious application I can think of given our internal
> structures)
You're missing a rather important s/is/isn't/ there ;-) But yeah, I agree.
Re: Unique instance IDs?
Posted by Paul Davis <pa...@gmail.com>.
> * Merkle trees are great for two-way synchronization, but it's not immediately clear to me how you'd use them to bootstrap a single source -> target replication. I might just be missing a straightforward extension of the tech here.
This is the point that's important with checksums and so on. Merkle
trees are great when you want to mirror structured data but CouchDB
replication is a mirror operation. Think, N db's replicating to a
central DB. you have a mixture of things which breaks checksums (or at
least any obvious application I can think of given our internal
structures)
Re: Unique instance IDs?
Posted by Adam Kocoloski <ko...@apache.org>.
On Dec 12, 2011, at 10:10 PM, Jason Smith wrote:
> On Tue, Dec 13, 2011 at 8:40 AM, Paul Davis <pa...@gmail.com> wrote:
>>> If there were a hypothetical single query which let the receiver
>>> assess its exact relationship to an arbitrary sender's data, I don't
>>> think "starts over" would sound as awful.
>>>
>>
>> I agree whole heartedly. And the easiest way I see to making that
>> happen is to decouple the host and db identities in such a way that
>> this is a reality. Its possible there's something elegant we could
>> pull from things like merkle trees. I've spent time considering it and
>> haven't thought of anything but I'd be tickled pink if there were a
>> reasonable solution there.
>
> Yeah. That is why I keep thinking of a checksum that works well with
> incremental map/reduce. I always recall that CRC32 is a commutative,
> associative checksum algorithm. It could hypothetically give you a
> checksum of the entire tree, and all subtrees down to the leaves, as a
> Couch reduce function. So the idea is to reduce the by_seq index. You
> get checksums of the database or subsets free or cheap.
>
> At this point I am out of my expertise though so I defer.
>
> --
> Iris Couch
Yep, that's a Merkle tree, and brings us back to where this thread sat 24 hours ago. Couple of points:
* You want to stuff the checksums in the id_tree, not the seq_tree. If you use the seq_tree you'll never be able to apply updates that get the checksums aligned.
* Merkle trees are great for two-way synchronization, but it's not immediately clear to me how you'd use them to bootstrap a single source -> target replication. I might just be missing a straightforward extension of the tech here.
Adam
Re: Unique instance IDs?
Posted by Jason Smith <jh...@iriscouch.com>.
On Tue, Dec 13, 2011 at 8:40 AM, Paul Davis <pa...@gmail.com> wrote:
>> If there were a hypothetical single query which let the receiver
>> assess its exact relationship to an arbitrary sender's data, I don't
>> think "starts over" would sound as awful.
>>
>
> I agree whole heartedly. And the easiest way I see to making that
> happen is to decouple the host and db identities in such a way that
> this is a reality. Its possible there's something elegant we could
> pull from things like merkle trees. I've spent time considering it and
> haven't thought of anything but I'd be tickled pink if there were a
> reasonable solution there.
Yeah. That is why I keep thinking of a checksum that works well with
incremental map/reduce. I always recall that CRC32 is a commutative,
associative checksum algorithm. It could hypothetically give you a
checksum of the entire tree, and all subtrees down to the leaves, as a
Couch reduce function. So the idea is to reduce the by_seq index. You
get checksums of the database or subsets free or cheap.
At this point I am out of my expertise though so I defer.
--
Iris Couch
Re: Unique instance IDs?
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 12, 2011 at 7:25 PM, Jason Smith <jh...@iriscouch.com> wrote:
> On Tue, Dec 13, 2011 at 8:03 AM, Paul Davis <pa...@gmail.com> wrote:
>> Having a UUID for every database created is the ideal
>> harmonious-to-theory manifestation of "what is a db?" but we have to
>> deal with reality when people may copy a file which makes things a bit
>> weird when there are two instances of a UUID db.
>
> You didn't say "harsh reality," but to list some legitimate situations
> where people might copy .couch files:
>
> * Restoring from backups
> * Cloning a VMWare image
> * Booting an EC2 AMI
> * NAS storage clusters
> * Couchbase mobile bootstrapping
Exactly the sorts of reasons why I haven't just slapped a UUID in to
the db header. :D
>
>>> There's actually no problem with moving DBs around today, except that
>>> replication starts over (unless you change host names to match).
>>
>> The "except that replication starts over" is a very significant caveat
>> that I would say contradicts the entire "no problem" description.
>
> Nobody has shown that "replication starts over" is bad. The implicit
> assumption is that starting over is costly. At present, yes, that is
> true, but that's mostly a bunch of "no-op" round-trips diffing the
> revs.
>
No-op round trips are fine until you have to make millions of them
over edge networks. Now there obviously isn't a huge uproar over this
inefficiency because we'd be having a very different conversation if
there had been. But the fact remains that the current situation is
just bad and the only reason there hasn't been an uproar is because we
don't yet have a huge enterprise company that's been running some
phone replication db for fifteen years without upgrading.
Its always better to fix errors in our model before they cause issues though.
> If there were a hypothetical single query which let the receiver
> assess its exact relationship to an arbitrary sender's data, I don't
> think "starts over" would sound as awful.
>
I agree whole heartedly. And the easiest way I see to making that
happen is to decouple the host and db identities in such a way that
this is a reality. Its possible there's something elegant we could
pull from things like merkle trees. I've spent time considering it and
haven't thought of anything but I'd be tickled pink if there were a
reasonable solution there.
> --
> Iris Couch
Re: Unique instance IDs?
Posted by Adam Kocoloski <ko...@apache.org>.
On Dec 12, 2011, at 8:25 PM, Jason Smith wrote:
> On Tue, Dec 13, 2011 at 8:03 AM, Paul Davis <pa...@gmail.com> wrote:
>> Having a UUID for every database created is the ideal
>> harmonious-to-theory manifestation of "what is a db?" but we have to
>> deal with reality when people may copy a file which makes things a bit
>> weird when there are two instances of a UUID db.
>
> You didn't say "harsh reality," but to list some legitimate situations
> where people might copy .couch files:
>
> * Restoring from backups
> * Cloning a VMWare image
> * Booting an EC2 AMI
> * NAS storage clusters
> * Couchbase mobile bootstrapping
>
>>> There's actually no problem with moving DBs around today, except that
>>> replication starts over (unless you change host names to match).
>>
>> The "except that replication starts over" is a very significant caveat
>> that I would say contradicts the entire "no problem" description.
>
> Nobody has shown that "replication starts over" is bad. The implicit
> assumption is that starting over is costly. At present, yes, that is
> true, but that's mostly a bunch of "no-op" round-trips diffing the
> revs.
>
> If there were a hypothetical single query which let the receiver
> assess its exact relationship to an arbitrary sender's data, I don't
> think "starts over" would sound as awful.
>
> --
> Iris Couch
Starting over is quite painful for a large target database. Streaming _changes from the source is cheap, but the _missing_revs / _revs_diff API call involves a bunch of random id_tree lookups on the target. If you've got spinning rust and IDs that don't follow the sequence numbers these "no-op" checks basically top out around 100 IDs / sec / spindle. Assume 50 MM documents in the target DB and you're looking at a week of no-ops before the real replication starts up again. Not pretty.
Adam
Re: Unique instance IDs?
Posted by Jason Smith <jh...@iriscouch.com>.
On Tue, Dec 13, 2011 at 8:03 AM, Paul Davis <pa...@gmail.com> wrote:
> Having a UUID for every database created is the ideal
> harmonious-to-theory manifestation of "what is a db?" but we have to
> deal with reality when people may copy a file which makes things a bit
> weird when there are two instances of a UUID db.
You didn't say "harsh reality," but to list some legitimate situations
where people might copy .couch files:
* Restoring from backups
* Cloning a VMWare image
* Booting an EC2 AMI
* NAS storage clusters
* Couchbase mobile bootstrapping
>> There's actually no problem with moving DBs around today, except that
>> replication starts over (unless you change host names to match).
>
> The "except that replication starts over" is a very significant caveat
> that I would say contradicts the entire "no problem" description.
Nobody has shown that "replication starts over" is bad. The implicit
assumption is that starting over is costly. At present, yes, that is
true, but that's mostly a bunch of "no-op" round-trips diffing the
revs.
If there were a hypothetical single query which let the receiver
assess its exact relationship to an arbitrary sender's data, I don't
think "starts over" would sound as awful.
--
Iris Couch
Re: Unique instance IDs?
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 12, 2011 at 5:39 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 09:01, Paul Davis <pa...@gmail.com> wrote:
>> On Mon, Dec 12, 2011 at 1:09 AM, Jason Smith <jh...@iriscouch.com> wrote:
>>> On Mon, Dec 12, 2011 at 5:16 AM, Paul Davis <pa...@gmail.com> wrote:
>>>>> A couch URL is its unique identifier. A database URL is its unique
>>>>> identifier. This sounds like a too-clever-by-half optimization. IMHO.
>>>>>
>>>>> --
>>>>> Iris Couch
>>>>
>>>> To this I ask simply: What's the URL of my phone? Tying a URL to a
>>>> database is like identifying a person by their address. A UUID per
>>>> created database is much more fine grained, but has operations issues
>>>> with file handling and what not.
>>>
>>> Hi, Paul. A database is not a person. It is a resource, with a
>>> universal location.
>>>
>>> Databases can be replicated, or copied, or restored from backup. (Same
>>> for .ini files.)
>>>
>>> One .couch file can be served from different URLs; and one URL might
>>> serve different .couch files over time. The current replicator
>>> understands this and if anything seems fishy, it double-checks. (For
>>> example, the instance_start_time helps to detect wholesale replacement
>>> of .couch files.)
>>>
>>> The web assumes that mostly, but not always, a stable URL represents a
>>> stable resource. So does the replicator. Getting away from that seems
>>> difficult.
>>>
>>> --
>>> Iris Couch
>>
>> I think you've contradicted yourself. If a URL is the universal name
>> for a database, then how are we able to server different databases
>> from the same URL?
>>
>> Tying a database to a URL is merely an artificial limitation because
>> we haven't thought of anything better. If we *did* think of a way to
>> uniquely identify databases that didn't break due to ops requirements
>> then that would be a much better fit to the CouchDB model. It is
>> difficult but that's because we haven't yet thought of a good way to
>> deal with what happens OOB when ops teams change server
>> configurations.
>
> Using anything other than the URL is a re-invention of DNS.
Whut?
> IMO, the more interesting thing to ask is "What is the URL of my
> phone?" and "How can it be sticky when I'm mobile?"
>
A URL is not the same as a database. Perhaps I'm having issues
conveying why that is so, but I'm that's the point I'm generally
trying to make.
In other words, URL is a locator, its answering the "where is this
thing at?" And as the phone (or even laptop) situation shows, there is
more than one answer, but the *implicit* idea I'm trying to point is
that the definition of "thing" in that question is a constant.
Having a UUID for every database created is the ideal
harmonious-to-theory manifestation of "what is a db?" but we have to
deal with reality when people may copy a file which makes things a bit
weird when there are two instances of a UUID db.
> There's actually no problem with moving DBs around today, except that
> replication starts over (unless you change host names to match).
The "except that replication starts over" is a very significant caveat
that I would say contradicts the entire "no problem" description.
> So
> let's get back to the transitive checkpoints discussion.
>
> It's a very 2.0 idea, but, imagine a CouchDB consumes the following
> changes feed during a pull replication:
>
> ...
> {"seq":121,"id":"f39f35c075587342826f133327e0b69e","changes":[{"rev":"1-719a49d5a340bc043d36913e5ecaad0b"}]}
> {"seq":122,"id":"ca809b23ca16c761b24e82b5f247008c","changes":[{"rev":"1-d995113da09a9b058df55cef982aa8f6"}]}
>
> If we pretend that the above changes, without loss of generality,
> become local seq # 151 and 152 of the target couch, then a downstream
> replicator might see the following in the changes feed:
>
> {"seq":152,"id":"ca809b23ca16c761b24e82b5f247008c","changes":[{"rev":"1-d995113da09a9b058df55cef982aa8f6"},{"source":"https://othercouch/","seq":122}]}
>
> Further downstream couches might see:
>
> {"seq":1043,"id":"ca809b23ca16c761b24e82b5f247008c","changes":[{"rev":"1-d995113da09a9b058df55cef982aa8f6"},{"source":"https://othercouch/","seq":123},
> {"source":"https://couchtwo/","seq":152}]}
>
> Alternatively, a checkpoint entry in the sequence index might have its
> own id and not refer to a document update. In this way, the question
> "What checkpoints does this couch have?" becomes much more interesting
> than, and possibly obviates entirely, the question "What couch am I
> talking to?" The latter is a statement about identity when what we
> should care about is content.
>
> Some care would need to be taken to consider information leakage in
> certain scenarios and it may be desirable to allow signed checkpoints
> if couches are going to need guarantees about which changes they're
> receiving and who created them.
>
> -Randall
There's definitely considerations we need to make here in terms of
information leakage. On one hand, improving replication efficiency is
awesome, but there are obvious cases where I don't want to tell people
who I've replicated with.
More importantly though, we can address the "have I replicated to you
before?" question and that's important enough to be seriously
considering alternatives to host based replication identifiers.
Re: Unique instance IDs?
Posted by Randall Leeds <ra...@gmail.com>.
On Mon, Dec 12, 2011 at 09:01, Paul Davis <pa...@gmail.com> wrote:
> On Mon, Dec 12, 2011 at 1:09 AM, Jason Smith <jh...@iriscouch.com> wrote:
>> On Mon, Dec 12, 2011 at 5:16 AM, Paul Davis <pa...@gmail.com> wrote:
>>>> A couch URL is its unique identifier. A database URL is its unique
>>>> identifier. This sounds like a too-clever-by-half optimization. IMHO.
>>>>
>>>> --
>>>> Iris Couch
>>>
>>> To this I ask simply: What's the URL of my phone? Tying a URL to a
>>> database is like identifying a person by their address. A UUID per
>>> created database is much more fine grained, but has operations issues
>>> with file handling and what not.
>>
>> Hi, Paul. A database is not a person. It is a resource, with a
>> universal location.
>>
>> Databases can be replicated, or copied, or restored from backup. (Same
>> for .ini files.)
>>
>> One .couch file can be served from different URLs; and one URL might
>> serve different .couch files over time. The current replicator
>> understands this and if anything seems fishy, it double-checks. (For
>> example, the instance_start_time helps to detect wholesale replacement
>> of .couch files.)
>>
>> The web assumes that mostly, but not always, a stable URL represents a
>> stable resource. So does the replicator. Getting away from that seems
>> difficult.
>>
>> --
>> Iris Couch
>
> I think you've contradicted yourself. If a URL is the universal name
> for a database, then how are we able to server different databases
> from the same URL?
>
> Tying a database to a URL is merely an artificial limitation because
> we haven't thought of anything better. If we *did* think of a way to
> uniquely identify databases that didn't break due to ops requirements
> then that would be a much better fit to the CouchDB model. It is
> difficult but that's because we haven't yet thought of a good way to
> deal with what happens OOB when ops teams change server
> configurations.
Using anything other than the URL is a re-invention of DNS.
IMO, the more interesting thing to ask is "What is the URL of my
phone?" and "How can it be sticky when I'm mobile?"
There's actually no problem with moving DBs around today, except that
replication starts over (unless you change host names to match). So
let's get back to the transitive checkpoints discussion.
It's a very 2.0 idea, but, imagine a CouchDB consumes the following
changes feed during a pull replication:
...
{"seq":121,"id":"f39f35c075587342826f133327e0b69e","changes":[{"rev":"1-719a49d5a340bc043d36913e5ecaad0b"}]}
{"seq":122,"id":"ca809b23ca16c761b24e82b5f247008c","changes":[{"rev":"1-d995113da09a9b058df55cef982aa8f6"}]}
If we pretend that the above changes, without loss of generality,
become local seq # 151 and 152 of the target couch, then a downstream
replicator might see the following in the changes feed:
{"seq":152,"id":"ca809b23ca16c761b24e82b5f247008c","changes":[{"rev":"1-d995113da09a9b058df55cef982aa8f6"},{"source":"https://othercouch/","seq":122}]}
Further downstream couches might see:
{"seq":1043,"id":"ca809b23ca16c761b24e82b5f247008c","changes":[{"rev":"1-d995113da09a9b058df55cef982aa8f6"},{"source":"https://othercouch/","seq":123},
{"source":"https://couchtwo/","seq":152}]}
Alternatively, a checkpoint entry in the sequence index might have its
own id and not refer to a document update. In this way, the question
"What checkpoints does this couch have?" becomes much more interesting
than, and possibly obviates entirely, the question "What couch am I
talking to?" The latter is a statement about identity when what we
should care about is content.
Some care would need to be taken to consider information leakage in
certain scenarios and it may be desirable to allow signed checkpoints
if couches are going to need guarantees about which changes they're
receiving and who created them.
-Randall
Re: Unique instance IDs?
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 12, 2011 at 1:09 AM, Jason Smith <jh...@iriscouch.com> wrote:
> On Mon, Dec 12, 2011 at 5:16 AM, Paul Davis <pa...@gmail.com> wrote:
>>> A couch URL is its unique identifier. A database URL is its unique
>>> identifier. This sounds like a too-clever-by-half optimization. IMHO.
>>>
>>> --
>>> Iris Couch
>>
>> To this I ask simply: What's the URL of my phone? Tying a URL to a
>> database is like identifying a person by their address. A UUID per
>> created database is much more fine grained, but has operations issues
>> with file handling and what not.
>
> Hi, Paul. A database is not a person. It is a resource, with a
> universal location.
>
> Databases can be replicated, or copied, or restored from backup. (Same
> for .ini files.)
>
> One .couch file can be served from different URLs; and one URL might
> serve different .couch files over time. The current replicator
> understands this and if anything seems fishy, it double-checks. (For
> example, the instance_start_time helps to detect wholesale replacement
> of .couch files.)
>
> The web assumes that mostly, but not always, a stable URL represents a
> stable resource. So does the replicator. Getting away from that seems
> difficult.
>
> --
> Iris Couch
I think you've contradicted yourself. If a URL is the universal name
for a database, then how are we able to server different databases
from the same URL?
Tying a database to a URL is merely an artificial limitation because
we haven't thought of anything better. If we *did* think of a way to
uniquely identify databases that didn't break due to ops requirements
then that would be a much better fit to the CouchDB model. It is
difficult but that's because we haven't yet thought of a good way to
deal with what happens OOB when ops teams change server
configurations.
Re: Unique instance IDs?
Posted by Jason Smith <jh...@iriscouch.com>.
On Mon, Dec 12, 2011 at 5:16 AM, Paul Davis <pa...@gmail.com> wrote:
>> A couch URL is its unique identifier. A database URL is its unique
>> identifier. This sounds like a too-clever-by-half optimization. IMHO.
>>
>> --
>> Iris Couch
>
> To this I ask simply: What's the URL of my phone? Tying a URL to a
> database is like identifying a person by their address. A UUID per
> created database is much more fine grained, but has operations issues
> with file handling and what not.
Hi, Paul. A database is not a person. It is a resource, with a
universal location.
Databases can be replicated, or copied, or restored from backup. (Same
for .ini files.)
One .couch file can be served from different URLs; and one URL might
serve different .couch files over time. The current replicator
understands this and if anything seems fishy, it double-checks. (For
example, the instance_start_time helps to detect wholesale replacement
of .couch files.)
The web assumes that mostly, but not always, a stable URL represents a
stable resource. So does the replicator. Getting away from that seems
difficult.
--
Iris Couch
Re: Unique instance IDs?
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Dec 11, 2011 at 9:21 PM, Jason Smith <jh...@iriscouch.com> wrote:
> On Mon, Dec 12, 2011 at 9:52 AM, Paul Davis <pa...@gmail.com> wrote:
>> On Sun, Dec 11, 2011 at 7:19 PM, Randall Leeds <ra...@gmail.com> wrote:
>>> On Sun, Dec 11, 2011 at 04:00, Alex Besogonov <al...@gmail.com> wrote:
>>>> I wonder, why there are no unique instance IDs in CouchDB? I'm
>>>> thinking about 'the central server replicates 2000000 documents to a
>>>> million of clients' scenario.
>>>>
>>>> Right now it's not possible to make replication on the 'big central
>>>> server' side to be stateless, because the other side tries to write
>>>> replication document which is later used to establish common ancestry.
>>>> Server can ignore/discard it, but then during the next replication
>>>> client would just have to replicate all the changes again. Of course,
>>>> the results would be consistent in any case but quite a lot of
>>>> additional traffic might be required.
>>>>
>>>> It should be simple to assign each instance a unique ID (computed
>>>> using UUID and the set of applied replication filters) and use it to
>>>> establish common replication history. It can even be compatible with
>>>> the way the current replication system works and basically the only
>>>> visible change should be the addition of UUID to database info.
>>>>
>>>> Or am I missing something?
>>>
>>> I proposed UUIDs for databases a long, long time ago and it's come up
>>> a few times since. If the UUID is database-level, then storing it with
>>> the database is dangerous -- copying a database file would result in
>>> two CouchDB's hosting "the same" (but really different) databases. If
>>> the UUID is host-level, then this reduces to a re-invention of DNS. In
>>> other words, all DBs should already be uniquely identified by their
>>> URLs.
>>>
>>> Regarding your second paragraph, replicating couches _could_ try to
>>> establish common ancestry only by examining a local checkpoint of
>>> replication, but the couch replicator looks for the log on both
>>> couches to ensure that the database hasn't been deleted+recreated nor
>>> has it crashed before certain replicated changes hit disk, as a double
>>> check that the sequence numbers have the expected shared meaning.
>>>
>>> It seems like maybe you're wondering about whether couch could
>>> generate snapshot ids that are more meaningful than the sequence
>>> number. For a single pair of couches the host-db-seq combo is enough
>>> information to replicate effectively. When there's more hosts involved
>>> we can talk about more powerful checkpoint ids that would be shareable
>>> or resolvable to find common ancestry between more than two
>>> replicating hosts to speed up those scenarios. My intuition always
>>> says that this leads to hash trees, but I haven't thought about it
>>> deeply enough to fully conceive of what this accomplishes or how it
>>> would work.
>>>
>>> -R
>>
>> I did have a shimmering of an idea for this awhile back. Basically we
>> do both host and db uuid's and the information we use to identifiy
>> replications is a hash of the concatenation.
>>
>> That way we can copy db's around and not muck with things as well as
>> error out a bit. Though this still has a bit of an issue if we copy
>> the host uuid around as well. Though we migth be able to look for a
>> mac address or something and then fail to boot if the check fails
>> (with an optional override if someone changes a nic).
>
> A couch URL is its unique identifier. A database URL is its unique
> identifier. This sounds like a too-clever-by-half optimization. IMHO.
>
> --
> Iris Couch
To this I ask simply: What's the URL of my phone? Tying a URL to a
database is like identifying a person by their address. A UUID per
created database is much more fine grained, but has operations issues
with file handling and what not.
Granted the obvious "what if there were a chip that uniquely
identified all machines" is kinda scary so I think we just need to get
close enough and warn users when they might be headed for a world of
hurt.
Also, "we support transitive replication" would make for an amusing
bullet point on the front page. :D
Re: Unique instance IDs?
Posted by Jason Smith <jh...@iriscouch.com>.
On Mon, Dec 12, 2011 at 9:52 AM, Paul Davis <pa...@gmail.com> wrote:
> On Sun, Dec 11, 2011 at 7:19 PM, Randall Leeds <ra...@gmail.com> wrote:
>> On Sun, Dec 11, 2011 at 04:00, Alex Besogonov <al...@gmail.com> wrote:
>>> I wonder, why there are no unique instance IDs in CouchDB? I'm
>>> thinking about 'the central server replicates 2000000 documents to a
>>> million of clients' scenario.
>>>
>>> Right now it's not possible to make replication on the 'big central
>>> server' side to be stateless, because the other side tries to write
>>> replication document which is later used to establish common ancestry.
>>> Server can ignore/discard it, but then during the next replication
>>> client would just have to replicate all the changes again. Of course,
>>> the results would be consistent in any case but quite a lot of
>>> additional traffic might be required.
>>>
>>> It should be simple to assign each instance a unique ID (computed
>>> using UUID and the set of applied replication filters) and use it to
>>> establish common replication history. It can even be compatible with
>>> the way the current replication system works and basically the only
>>> visible change should be the addition of UUID to database info.
>>>
>>> Or am I missing something?
>>
>> I proposed UUIDs for databases a long, long time ago and it's come up
>> a few times since. If the UUID is database-level, then storing it with
>> the database is dangerous -- copying a database file would result in
>> two CouchDB's hosting "the same" (but really different) databases. If
>> the UUID is host-level, then this reduces to a re-invention of DNS. In
>> other words, all DBs should already be uniquely identified by their
>> URLs.
>>
>> Regarding your second paragraph, replicating couches _could_ try to
>> establish common ancestry only by examining a local checkpoint of
>> replication, but the couch replicator looks for the log on both
>> couches to ensure that the database hasn't been deleted+recreated nor
>> has it crashed before certain replicated changes hit disk, as a double
>> check that the sequence numbers have the expected shared meaning.
>>
>> It seems like maybe you're wondering about whether couch could
>> generate snapshot ids that are more meaningful than the sequence
>> number. For a single pair of couches the host-db-seq combo is enough
>> information to replicate effectively. When there's more hosts involved
>> we can talk about more powerful checkpoint ids that would be shareable
>> or resolvable to find common ancestry between more than two
>> replicating hosts to speed up those scenarios. My intuition always
>> says that this leads to hash trees, but I haven't thought about it
>> deeply enough to fully conceive of what this accomplishes or how it
>> would work.
>>
>> -R
>
> I did have a shimmering of an idea for this awhile back. Basically we
> do both host and db uuid's and the information we use to identifiy
> replications is a hash of the concatenation.
>
> That way we can copy db's around and not muck with things as well as
> error out a bit. Though this still has a bit of an issue if we copy
> the host uuid around as well. Though we migth be able to look for a
> mac address or something and then fail to boot if the check fails
> (with an optional override if someone changes a nic).
A couch URL is its unique identifier. A database URL is its unique
identifier. This sounds like a too-clever-by-half optimization. IMHO.
--
Iris Couch
Re: Unique instance IDs?
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Dec 11, 2011 at 7:19 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Sun, Dec 11, 2011 at 04:00, Alex Besogonov <al...@gmail.com> wrote:
>> I wonder, why there are no unique instance IDs in CouchDB? I'm
>> thinking about 'the central server replicates 2000000 documents to a
>> million of clients' scenario.
>>
>> Right now it's not possible to make replication on the 'big central
>> server' side to be stateless, because the other side tries to write
>> replication document which is later used to establish common ancestry.
>> Server can ignore/discard it, but then during the next replication
>> client would just have to replicate all the changes again. Of course,
>> the results would be consistent in any case but quite a lot of
>> additional traffic might be required.
>>
>> It should be simple to assign each instance a unique ID (computed
>> using UUID and the set of applied replication filters) and use it to
>> establish common replication history. It can even be compatible with
>> the way the current replication system works and basically the only
>> visible change should be the addition of UUID to database info.
>>
>> Or am I missing something?
>
> I proposed UUIDs for databases a long, long time ago and it's come up
> a few times since. If the UUID is database-level, then storing it with
> the database is dangerous -- copying a database file would result in
> two CouchDB's hosting "the same" (but really different) databases. If
> the UUID is host-level, then this reduces to a re-invention of DNS. In
> other words, all DBs should already be uniquely identified by their
> URLs.
>
> Regarding your second paragraph, replicating couches _could_ try to
> establish common ancestry only by examining a local checkpoint of
> replication, but the couch replicator looks for the log on both
> couches to ensure that the database hasn't been deleted+recreated nor
> has it crashed before certain replicated changes hit disk, as a double
> check that the sequence numbers have the expected shared meaning.
>
> It seems like maybe you're wondering about whether couch could
> generate snapshot ids that are more meaningful than the sequence
> number. For a single pair of couches the host-db-seq combo is enough
> information to replicate effectively. When there's more hosts involved
> we can talk about more powerful checkpoint ids that would be shareable
> or resolvable to find common ancestry between more than two
> replicating hosts to speed up those scenarios. My intuition always
> says that this leads to hash trees, but I haven't thought about it
> deeply enough to fully conceive of what this accomplishes or how it
> would work.
>
> -R
I did have a shimmering of an idea for this awhile back. Basically we
do both host and db uuid's and the information we use to identifiy
replications is a hash of the concatenation.
That way we can copy db's around and not muck with things as well as
error out a bit. Though this still has a bit of an issue if we copy
the host uuid around as well. Though we migth be able to look for a
mac address or something and then fail to boot if the check fails
(with an optional override if someone changes a nic).
Re: Unique instance IDs?
Posted by Randall Leeds <ra...@gmail.com>.
On Sun, Dec 11, 2011 at 04:00, Alex Besogonov <al...@gmail.com> wrote:
> I wonder, why there are no unique instance IDs in CouchDB? I'm
> thinking about 'the central server replicates 2000000 documents to a
> million of clients' scenario.
>
> Right now it's not possible to make replication on the 'big central
> server' side to be stateless, because the other side tries to write
> replication document which is later used to establish common ancestry.
> Server can ignore/discard it, but then during the next replication
> client would just have to replicate all the changes again. Of course,
> the results would be consistent in any case but quite a lot of
> additional traffic might be required.
>
> It should be simple to assign each instance a unique ID (computed
> using UUID and the set of applied replication filters) and use it to
> establish common replication history. It can even be compatible with
> the way the current replication system works and basically the only
> visible change should be the addition of UUID to database info.
>
> Or am I missing something?
I proposed UUIDs for databases a long, long time ago and it's come up
a few times since. If the UUID is database-level, then storing it with
the database is dangerous -- copying a database file would result in
two CouchDB's hosting "the same" (but really different) databases. If
the UUID is host-level, then this reduces to a re-invention of DNS. In
other words, all DBs should already be uniquely identified by their
URLs.
Regarding your second paragraph, replicating couches _could_ try to
establish common ancestry only by examining a local checkpoint of
replication, but the couch replicator looks for the log on both
couches to ensure that the database hasn't been deleted+recreated nor
has it crashed before certain replicated changes hit disk, as a double
check that the sequence numbers have the expected shared meaning.
It seems like maybe you're wondering about whether couch could
generate snapshot ids that are more meaningful than the sequence
number. For a single pair of couches the host-db-seq combo is enough
information to replicate effectively. When there's more hosts involved
we can talk about more powerful checkpoint ids that would be shareable
or resolvable to find common ancestry between more than two
replicating hosts to speed up those scenarios. My intuition always
says that this leads to hash trees, but I haven't thought about it
deeply enough to fully conceive of what this accomplishes or how it
would work.
-R