On Fri, Feb 20, 2009 at 7:34 PM, Chris Anderson wrote:
> I think so. I think that there could be proxy overlap / redundancy
> across all levels of the tree, and also in the case of a flat tree.
>
> As long as the proxies agree on how to hash from URLs to nodes it
> should just work.
I've been thi
On Fri, Feb 20, 2009 at 4:15 PM, Mike Malone wrote:
> Hi, I don't think I've commented on this list before so let me briefly
> introduce myself. I'm Mike Malone. I live in San Francisco. I'm a developer
> (primarily web dev) and have some experience working with large clustered
> databases. I work
Hi, I don't think I've commented on this list before so let me briefly
introduce myself. I'm Mike Malone. I live in San Francisco. I'm a developer
(primarily web dev) and have some experience working with large clustered
databases. I worked for Pownce.com, but moved to Six Apart when they
acquired
On Fri, Feb 20, 2009 at 2:45 PM, Damien Katz wrote:
>
> On Feb 20, 2009, at 4:37 PM, Stefan Karpinski wrote:
>
>>>
>>> Trees would be overkill except for with very large clusters.
>>>
>>
>>> With CouchDB map views, you need to combine results from every node in a
>>> big merge sort. If you combine
On Fri, Feb 20, 2009 at 1:37 PM, Stefan Karpinski
wrote:
>
> That makes sense and it clarifies one of my questions about this topic. Is
> the goal of partitioned clustering to increase performance for very large
> data sets, or to increase reliability? It would seem from this answere that
> the g
On Feb 20, 2009, at 4:37 PM, Stefan Karpinski wrote:
Trees would be overkill except for with very large clusters.
With CouchDB map views, you need to combine results from every node
in a
big merge sort. If you combine all results at a single node, the
single
clients ability to simultane
>
> Trees would be overkill except for with very large clusters.
>
> With CouchDB map views, you need to combine results from every node in a
> big merge sort. If you combine all results at a single node, the single
> clients ability to simultaneously pull data and sort data from all other
> nodes
On Feb 20, 2009, at 1:55 PM, Stefan Karpinski wrote:
Hi, I thought I'd introduce myself since I'm new here on the couchdb
list. I'm Stefan Karpinski. I've worked in the Monitoring Group at
Akamai, Operations R&D at Citrix Online, and I'm nearly done with a
PhD in computer networking at the mome
On Fri, Feb 20, 2009 at 10:55 AM, Stefan Karpinski
wrote:
> Hi, I thought I'd introduce myself since I'm new here on the couchdb
> list. I'm Stefan Karpinski. I've worked in the Monitoring Group at
> Akamai, Operations R&D at Citrix Online, and I'm nearly done with a
> PhD in computer networking a
Hi, I thought I'd introduce myself since I'm new here on the couchdb
list. I'm Stefan Karpinski. I've worked in the Monitoring Group at
Akamai, Operations R&D at Citrix Online, and I'm nearly done with a
PhD in computer networking at the moment. So I guess I've thought
about this kind of stuff a bi
Any thoughts as to how (or even if) this tree-wise result aggregation
would work for externals?
I'm thinking specifically about couchdb-lucene, where multi-node
results aggregation is possible, given a framework like you propose
here. The results that couchdb-lucene produces can already be
aggrega
On Thu, Feb 19, 2009 at 6:39 PM, Ben Browning wrote:
> Overall the model sounds very similar to what I was thinking. I just
> have a few comments.
>
>> In this model documents are saved to a leaf node depending on a hash
>> of the docid. This means that lookups are easy, and need only to touch
>>
Overall the model sounds very similar to what I was thinking. I just
have a few comments.
> In this model documents are saved to a leaf node depending on a hash
> of the docid. This means that lookups are easy, and need only to touch
> the leaf node which holds the doc. Redundancy can be provided
13 matches
Mail list logo
