On Mon, Dec 20, 2010 at 5:41 PM, Brian Mitchell <[email protected]> wrote:
>
>
> On Dec 20, 2010, at 17:19, Jan Lehnardt <[email protected]> wrote:
>
>> Hi Brian,
>>
>> On 20 Dec 2010, at 23:08, Jan Lehnardt wrote:
>>
>>> On 20 Dec 2010, at 23:05, Brian Mitchell wrote:
>>>
>>>> I have verified that CouchDB users love URLs but don't tend to read them
>>>> because their database is too slow.
>>>>
>>>> (Joking aside, I find it annoying that people can't ever manage to answer
>>>> things without storming off and writing long blog posts on methods of
>>>> measurement or simply never actually answering things with any more
>>>> substance than the things they seem to attack as poor evidence. I do
>>>> realize there is a large gap here and apples vs. oranges isn't productive,
>>>> but neither is this.)
>>>
>>> +1
>>
>> Paul on IRC reminds me that this might have been target at me, funny :)
>
> I saw your reply after I hit send. :-) Paul's response was funny but I've
> seen this go down too many times not to let a short little rant out.
>
Apologies for being dismissive, I didn't read the subject thoroughly
enough to figure out it was that specific slide. A more on topic reply
would've been along the lines of:
Yup, Mongo is generally faster with these types of benchmarks.
>> The blog posts are for background which is generally lacking as these
>> benchmarks keep coming up. I did point out why this is a bad scenario for
>> CouchDB and offered an explanation of better scenarios, but I can't go and
>> define your scenario because, well, it's yours. That is the whole point of
>> my stupid benchmarks are stupid argument.
>>
>> I also did offer more information if requested and I am happy to go into the
>> details of why CouchDB performs better under concurrent load if requested.
>> If you are requesting that, can you formulate a question? :)
>
> You did all I can ask for in the sense of constructive response... though I
> do think the CouchDB community seems shy on providing people with simple
> ranges of data to help them decide to invest time into more refined
> measurement.
>
> The truth is that couchdb does have it's strengths that don't tend to show
> well in many cases. On the other hand, some applications do need performance
> numbers that don't easily come from a standard couched setup. Knowing this
> before diving into dangerous comparisons will help avoid the awkwardness as
> people try to measure things that don't really represent the priorities of a
> project well. Right now you have to dig deeper than most people will ever
> look to find these numbers. They are hidden whether that is done
> intentionally or not.
>
> I'd think that it'd be in the community's favor to be as clear as possible
> with what kind of ballpark the DB is in. People who miss out on the great
> parts of CouchDB because they only focus on speed (so they chose something
> else) are probably not the prime targets of this project anyway. If people
> here disagree, then some serious work needs to be done on improving these
> numbers (IMO, there is a lot of speed to gain).
>
> Brian.
>
>
I don't think its at all fair to characterize the CouchDB community as
shy about providing data. All we require is a question that can be
reasonably answered without making wild assumptions because as you
point out it would more often than not just set people up for
disappointment.
HTH,
Paul Davis
