You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by "Chenini, Mohamed " <MC...@geico.com> on 2010/12/20 22:32:51 UTC
Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Hi,
I found this info on the net at
http://www.slideshare.net/danglbl/schemaless-databases
Does anyone knows if this was verified?
Thanks,
Mohamed
====================
This email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 20, 2010 at 5:41 PM, Brian Mitchell <bi...@gmail.com> wrote:
>
>
> On Dec 20, 2010, at 17:19, Jan Lehnardt <ja...@apache.org> 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
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Huw Selley <hu...@netdev.co.uk>.
Hi,
On 21 Dec 2010, at 04:14, Anand Chitipothu wrote:
>> [...]
>> Generally the question that tends to matter is: Can view generation
>> keep up with inserts, on average? Once the index is built, responses
>> to it are fast, so the index build time matters. On desktop-class
>> hardware, I tend to expect between 500-1000 documents per second can
>> be processed (for documents about as complex and large as a tweet). Of
>> course this # will vary widely depending on hardware and the # of keys
>> you emit.
>> [...]
>
> In my experience, I've seen that view generation starts with a speed
> of 1000 docs/secs and drops to less than 50 docs/sec as the size of
> view file increases.
I have been doing some testing recently on server grade hardware and processing docs of about 1K each and emitting a small amount of data. I found that the rate of processing was pretty good overall - just over 2100/s. I didn't grow my databases past 6 Million docs though.
Of course as Chris says your stats will vary depending on hardware and what is emitted.
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Anand Chitipothu <an...@gmail.com>.
> [...]
> Generally the question that tends to matter is: Can view generation
> keep up with inserts, on average? Once the index is built, responses
> to it are fast, so the index build time matters. On desktop-class
> hardware, I tend to expect between 500-1000 documents per second can
> be processed (for documents about as complex and large as a tweet). Of
> course this # will vary widely depending on hardware and the # of keys
> you emit.
>[...]
In my experience, I've seen that view generation starts with a speed
of 1000 docs/secs and drops to less than 50 docs/sec as the size of
view file increases.
Anand
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Dec 20, 2010 at 2:41 PM, Brian Mitchell <bi...@gmail.com> wrote:
[snip]
>
> 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).
>
I think the performance question is a good one. It's hard to answer
because we've seen so many different performance #s depending on
workload.
As far as rough #s, this bash script inserts about 2500 documents a
second into CouchDB on my MacBook Air.
https://github.com/apache/couchdb/blob/trunk/test/bench/benchbulk.sh
Generally the question that tends to matter is: Can view generation
keep up with inserts, on average? Once the index is built, responses
to it are fast, so the index build time matters. On desktop-class
hardware, I tend to expect between 500-1000 documents per second can
be processed (for documents about as complex and large as a tweet). Of
course this # will vary widely depending on hardware and the # of keys
you emit.
BigCouch also makes partitioning this view generation load easier, so
that more of the mapping can be done in parallel.
Chris
> Brian.
>
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Brian Mitchell <bi...@gmail.com>.
On Dec 20, 2010, at 17:19, Jan Lehnardt <ja...@apache.org> 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.
> 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.
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Jan Lehnardt <ja...@apache.org>.
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 :)
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? :)
Thanks for your feedback.
Cheers
Jan
--
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Jan Lehnardt <ja...@apache.org>.
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
>
> I still love CouchDB.
>
> On Dec 20, 2010, at 16:41, Paul Davis <pa...@gmail.com> wrote:
>> I have verified that the URL can be resolved and contains a slide deck
>> about various database technologies.
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Brian Mitchell <bi...@gmail.com>.
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.)
I still love CouchDB.
On Dec 20, 2010, at 16:41, Paul Davis <pa...@gmail.com> wrote:
> I have verified that the URL can be resolved and contains a slide deck
> about various database technologies.
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Paul Davis <pa...@gmail.com>.
I have verified that the URL can be resolved and contains a slide deck
about various database technologies.
On Mon, Dec 20, 2010 at 4:32 PM, Chenini, Mohamed <MC...@geico.com> wrote:
>
> Hi,
>
>
>
> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
>
>
>
>
>
>
>
>
>
> Does anyone knows if this was verified?
>
>
>
> Thanks,
>
> Mohamed
>
> ====================
> This email/fax message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution of this
> email/fax is prohibited. If you are not the intended recipient, please
> destroy all paper and electronic copies of the original message.
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Miles,
On 21 Dec 2010, at 00:12, Miles Fidelman wrote:
> Jan Lehnardt wrote:
>
>> I think the author's comment on slide 35 sums it up pretty nicely:
>>
>> "Of course this is just one (lame) test."
>>
>> Coming up good numbers is hard which means that people with easy ways to make them come up with bad ones.
>>
> Let's see... 43 slides giving a pretty good overview of the history and state of noSQL databases (including several that are new to me), and all anybody has commented on was one slide on an avowedly lame benchmark.
Mohammed asked to verify the insert benchmark numbers, hence the focus on that topic.
> Personally, I thought it was a very informative slide deck, of particular relevance to a project I'm working on.
I'm in no way discrediting the rest of the slide deck, I just picked up and emphasised a point the author made him/herself. I haven't had the time to look at the rest of the slides in detail, but it seems valuable.
> Thanks for the pointer Mohamed.
Thanks indeed!
Cheers
Jan
--
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Miles Fidelman <mf...@meetinghouse.net>.
Jan Lehnardt wrote:
> Hi,
>
> On 20 Dec 2010, at 22:32, Chenini, Mohamed wrote:
>
>
>> Hi,
>>
>> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
>>
>>
> I think the author's comment on slide 35 sums it up pretty nicely:
>
> "Of course this is just one (lame) test."
>
> Coming up good numbers is hard which means that people with easy ways to make them come up with bad ones.
>
Let's see... 43 slides giving a pretty good overview of the history and
state of noSQL databases (including several that are new to me), and all
anybody has commented on was one slide on an avowedly lame benchmark.
Personally, I thought it was a very informative slide deck, of
particular relevance to a project I'm working on. Thanks for the
pointer Mohamed.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In<fnord> practice, there is. .... Yogi Berra
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Sebastian Cohnen <se...@googlemail.com>.
On 20.12.2010, at 23:24, Paul Davis wrote:
> On Mon, Dec 20, 2010 at 5:20 PM, Sebastian Cohnen
> <se...@googlemail.com> wrote:
>> question inside :)
>>
>> On 20.12.2010, at 23:02, Jan Lehnardt wrote:
>>
>>> Hi,
>>>
>>> On 20 Dec 2010, at 22:32, Chenini, Mohamed wrote:
>>>
>>>> Hi,
>>>>
>>>> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
>>>> [...]
>>>> Does anyone knows if this was verified?
>>>
>>> I think the author's comment on slide 35 sums it up pretty nicely:
>>>
>>> "Of course this is just one (lame) test."
>>>
>>> Coming up good numbers is hard which means that people with easy ways to make them come up with bad ones.
>>>
>>> I've written about the difficulties on benchmarks databases on my blog:
>>>
>>> http://jan.prima.de/~jan/plok/archives/175-Benchmarks-You-are-Doing-it-Wrong.html
>>> http://jan.prima.de/~jan/plok/archives/176-Caveats-of-Evaluating-Databases.html
>>>
>>> They should give you a few pointers on why this is hard.
>>>
>>> --
>>>
>>> To the point: CouchDB generally performs best with concurrent load. In the case of loading data into CouchDB, bulk requests* will speed up things again. To push CouchDB to a write limit, you want to use concurrent bulk requests (specific numbers will depend on your data and hardware).
>>
>> Does this really speed up things? I've tried this approach (concurrent bulk inserts) with small/big docs and small/big bulk chunk sizes: the difference was not significant. I thought this was reasonable, since writes are serialized anyways. The setup was one box generating documents, creating bulks and keep them in memory and bulk insert batches of complete docs (incl. simple monotonic increasing ints as doc ids) to another node. delayed commit was off.
>>
>
> I think delayed commit would need to be on there otherwise you'll be
> hitting fsync barriers for every bulk docs call which are serialized
> by the updater. Theoretically the speedups would come from letting the
> kernel manage the file buffers and what not.
delayed_commit was off because I needed to test insertion of lots of data (more than what would fit nicely into memory). I wanted to figure out, if normal bulk vs concurrent bulks does have an impact on insert performance. the difference was, as I said, not significant better or worse. btw: I didn't saturated the disks (mid-classed SSDs), since couch was eating up the CPU (3GHz Core 2 Duo). This was some time ago, maybe this is more disk bound now.
>
>>>
>>> * http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
>>>
>>> Unfortunately this means that these one-off benchmarks don't show any good numbers for CouchDB, yet fortunately this shows easily that these one-off benchmarks don't really reflect common real-world usage and should be discouraged.
>>>
>>> Hope that helps, let us know if you have any more questions :)
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>
>>
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 20, 2010 at 5:20 PM, Sebastian Cohnen
<se...@googlemail.com> wrote:
> question inside :)
>
> On 20.12.2010, at 23:02, Jan Lehnardt wrote:
>
>> Hi,
>>
>> On 20 Dec 2010, at 22:32, Chenini, Mohamed wrote:
>>
>>> Hi,
>>>
>>> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
>>> [...]
>>> Does anyone knows if this was verified?
>>
>> I think the author's comment on slide 35 sums it up pretty nicely:
>>
>> "Of course this is just one (lame) test."
>>
>> Coming up good numbers is hard which means that people with easy ways to make them come up with bad ones.
>>
>> I've written about the difficulties on benchmarks databases on my blog:
>>
>> http://jan.prima.de/~jan/plok/archives/175-Benchmarks-You-are-Doing-it-Wrong.html
>> http://jan.prima.de/~jan/plok/archives/176-Caveats-of-Evaluating-Databases.html
>>
>> They should give you a few pointers on why this is hard.
>>
>> --
>>
>> To the point: CouchDB generally performs best with concurrent load. In the case of loading data into CouchDB, bulk requests* will speed up things again. To push CouchDB to a write limit, you want to use concurrent bulk requests (specific numbers will depend on your data and hardware).
>
> Does this really speed up things? I've tried this approach (concurrent bulk inserts) with small/big docs and small/big bulk chunk sizes: the difference was not significant. I thought this was reasonable, since writes are serialized anyways. The setup was one box generating documents, creating bulks and keep them in memory and bulk insert batches of complete docs (incl. simple monotonic increasing ints as doc ids) to another node. delayed commit was off.
>
I think delayed commit would need to be on there otherwise you'll be
hitting fsync barriers for every bulk docs call which are serialized
by the updater. Theoretically the speedups would come from letting the
kernel manage the file buffers and what not.
>>
>> * http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
>>
>> Unfortunately this means that these one-off benchmarks don't show any good numbers for CouchDB, yet fortunately this shows easily that these one-off benchmarks don't really reflect common real-world usage and should be discouraged.
>>
>> Hope that helps, let us know if you have any more questions :)
>>
>> Cheers
>> Jan
>> --
>>
>
>
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Sebastian Cohnen <se...@googlemail.com>.
On 20.12.2010, at 23:34, Jan Lehnardt wrote:
>
> On 20 Dec 2010, at 23:20, Sebastian Cohnen wrote:
>
>> question inside :)
>>
>> On 20.12.2010, at 23:02, Jan Lehnardt wrote:
>>
>>> Hi,
>>>
>>> On 20 Dec 2010, at 22:32, Chenini, Mohamed wrote:
>>>
>>>> Hi,
>>>>
>>>> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
>>>> [...]
>>>> Does anyone knows if this was verified?
>>>
>>> I think the author's comment on slide 35 sums it up pretty nicely:
>>>
>>> "Of course this is just one (lame) test."
>>>
>>> Coming up good numbers is hard which means that people with easy ways to make them come up with bad ones.
>>>
>>> I've written about the difficulties on benchmarks databases on my blog:
>>>
>>> http://jan.prima.de/~jan/plok/archives/175-Benchmarks-You-are-Doing-it-Wrong.html
>>> http://jan.prima.de/~jan/plok/archives/176-Caveats-of-Evaluating-Databases.html
>>>
>>> They should give you a few pointers on why this is hard.
>>>
>>> --
>>>
>>> To the point: CouchDB generally performs best with concurrent load. In the case of loading data into CouchDB, bulk requests* will speed up things again. To push CouchDB to a write limit, you want to use concurrent bulk requests (specific numbers will depend on your data and hardware).
>>
>> Does this really speed up things? I've tried this approach (concurrent bulk inserts) with small/big docs and small/big bulk chunk sizes: the difference was not significant. I thought this was reasonable, since writes are serialized anyways. The setup was one box generating documents, creating bulks and keep them in memory and bulk insert batches of complete docs (incl. simple monotonic increasing ints as doc ids) to another node. delayed commit was off.
>
> Have you tested these against single doc inserts?
sorry, should have mentioned that I've tested bulk vs concurrent bulk inserts
> Cheers
> Jan
> --
>
>>
>>>
>>> * http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
>>>
>>> Unfortunately this means that these one-off benchmarks don't show any good numbers for CouchDB, yet fortunately this shows easily that these one-off benchmarks don't really reflect common real-world usage and should be discouraged.
>>>
>>> Hope that helps, let us know if you have any more questions :)
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>
>
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Jan Lehnardt <ja...@apache.org>.
On 20 Dec 2010, at 23:20, Sebastian Cohnen wrote:
> question inside :)
>
> On 20.12.2010, at 23:02, Jan Lehnardt wrote:
>
>> Hi,
>>
>> On 20 Dec 2010, at 22:32, Chenini, Mohamed wrote:
>>
>>> Hi,
>>>
>>> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
>>> [...]
>>> Does anyone knows if this was verified?
>>
>> I think the author's comment on slide 35 sums it up pretty nicely:
>>
>> "Of course this is just one (lame) test."
>>
>> Coming up good numbers is hard which means that people with easy ways to make them come up with bad ones.
>>
>> I've written about the difficulties on benchmarks databases on my blog:
>>
>> http://jan.prima.de/~jan/plok/archives/175-Benchmarks-You-are-Doing-it-Wrong.html
>> http://jan.prima.de/~jan/plok/archives/176-Caveats-of-Evaluating-Databases.html
>>
>> They should give you a few pointers on why this is hard.
>>
>> --
>>
>> To the point: CouchDB generally performs best with concurrent load. In the case of loading data into CouchDB, bulk requests* will speed up things again. To push CouchDB to a write limit, you want to use concurrent bulk requests (specific numbers will depend on your data and hardware).
>
> Does this really speed up things? I've tried this approach (concurrent bulk inserts) with small/big docs and small/big bulk chunk sizes: the difference was not significant. I thought this was reasonable, since writes are serialized anyways. The setup was one box generating documents, creating bulks and keep them in memory and bulk insert batches of complete docs (incl. simple monotonic increasing ints as doc ids) to another node. delayed commit was off.
Have you tested these against single doc inserts?
Cheers
Jan
--
>
>>
>> * http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
>>
>> Unfortunately this means that these one-off benchmarks don't show any good numbers for CouchDB, yet fortunately this shows easily that these one-off benchmarks don't really reflect common real-world usage and should be discouraged.
>>
>> Hope that helps, let us know if you have any more questions :)
>>
>> Cheers
>> Jan
>> --
>>
>
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Sebastian Cohnen <se...@googlemail.com>.
question inside :)
On 20.12.2010, at 23:02, Jan Lehnardt wrote:
> Hi,
>
> On 20 Dec 2010, at 22:32, Chenini, Mohamed wrote:
>
>> Hi,
>>
>> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
>> [...]
>> Does anyone knows if this was verified?
>
> I think the author's comment on slide 35 sums it up pretty nicely:
>
> "Of course this is just one (lame) test."
>
> Coming up good numbers is hard which means that people with easy ways to make them come up with bad ones.
>
> I've written about the difficulties on benchmarks databases on my blog:
>
> http://jan.prima.de/~jan/plok/archives/175-Benchmarks-You-are-Doing-it-Wrong.html
> http://jan.prima.de/~jan/plok/archives/176-Caveats-of-Evaluating-Databases.html
>
> They should give you a few pointers on why this is hard.
>
> --
>
> To the point: CouchDB generally performs best with concurrent load. In the case of loading data into CouchDB, bulk requests* will speed up things again. To push CouchDB to a write limit, you want to use concurrent bulk requests (specific numbers will depend on your data and hardware).
Does this really speed up things? I've tried this approach (concurrent bulk inserts) with small/big docs and small/big bulk chunk sizes: the difference was not significant. I thought this was reasonable, since writes are serialized anyways. The setup was one box generating documents, creating bulks and keep them in memory and bulk insert batches of complete docs (incl. simple monotonic increasing ints as doc ids) to another node. delayed commit was off.
>
> * http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
>
> Unfortunately this means that these one-off benchmarks don't show any good numbers for CouchDB, yet fortunately this shows easily that these one-off benchmarks don't really reflect common real-world usage and should be discouraged.
>
> Hope that helps, let us know if you have any more questions :)
>
> Cheers
> Jan
> --
>
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Jan Lehnardt <ja...@apache.org>.
Hi,
On 20 Dec 2010, at 22:32, Chenini, Mohamed wrote:
> Hi,
>
> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
> [...]
> Does anyone knows if this was verified?
I think the author's comment on slide 35 sums it up pretty nicely:
"Of course this is just one (lame) test."
Coming up good numbers is hard which means that people with easy ways to make them come up with bad ones.
I've written about the difficulties on benchmarks databases on my blog:
http://jan.prima.de/~jan/plok/archives/175-Benchmarks-You-are-Doing-it-Wrong.html
http://jan.prima.de/~jan/plok/archives/176-Caveats-of-Evaluating-Databases.html
They should give you a few pointers on why this is hard.
--
To the point: CouchDB generally performs best with concurrent load. In the case of loading data into CouchDB, bulk requests* will speed up things again. To push CouchDB to a write limit, you want to use concurrent bulk requests (specific numbers will depend on your data and hardware).
* http://wiki.apache.org/couchdb/HTTP_Bulk_Document_API
Unfortunately this means that these one-off benchmarks don't show any good numbers for CouchDB, yet fortunately this shows easily that these one-off benchmarks don't really reflect common real-world usage and should be discouraged.
Hope that helps, let us know if you have any more questions :)
Cheers
Jan
--
Re: Comparison of MongoDB & CouchDB: MongoDB seems better on insert
Posted by Benoit Chesneau <bc...@gmail.com>.
On Mon, Dec 20, 2010 at 10:32 PM, Chenini, Mohamed <MC...@geico.com> wrote:
>
> Hi,
>
>
>
> I found this info on the net at http://www.slideshare.net/danglbl/schemaless-databases
>
>
>
>
>
>
>
>
>
> Does anyone knows if this was verified?
>
>
why should it be verified ? About which concerns ?
About the sentence "not very efficient for throughput", I don't see
why, also in which case.
- benoît.