You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Chris Stockton <ch...@gmail.com> on 2011/08/17 02:03:31 UTC
Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Hello,
I have been able to reduce a complex case where a certain sized
document within our application causes "Reduce output must shrink more
rapidly" errors and I am not sure I understand why. I spent a great
deal of time making sure I have stripped the database, the documents
and the views to the bare minimum to make it easy to reproduce, I
would really appreciate if anyone could give me some insight on what
is causing this and if a fix exists, may it be ini settings etc. I
apologize in advanced if this is my lack of understanding views or how
they work as well as to this email being a bit long, but I think it is
required to express the issue in case it is indeed a bug.
Kind Regards,
-Chris
--Reproduce steps--
1) CouchDB Production release 1.10
2) Create a fresh database
3) Create the following design document
{
"_id": "_design/test",
"_rev": "1-19eb11313c2602a00f0105f78202d1f3",
"views": {
"Grid": {
"map": "function(doc) {\n emit(\"result\", doc.data);\n}",
"reduce": "function(keys, values, rereduce) {\n var
container = {};\n\n if(!rereduce) {\n for(var value in values) {\n
for(var col in values[value]) {\n if(values[value]) {\n
if(!container[col]) {\n container[col] = {\n
total: 0\n };\n }\n\n
container[col].total++;\n }\n }\n }\n } else {\n
for(var reduced in values) {\n for(var col in values[reduced])
{\n if(!container[col]) {\n container[col] = {\n
total: 0\n };\n }\n\n container[col].total
+= values[reduced][col].total;\n }\n }\n }\n\n return
container;\n}"
}
},
"language": "javascript"
}
4) Create the following regular document (any id is okay)
{
"_id": "4334dff68f2283e6e8739eabb40a4e7a",
"_rev": "24-524e9c9ebeaf88962f41e3a940788610",
"data": {
"C003089": "c1",
"C006990": "c2",
"C009996": "c3",
"C012132": "c4",
"C015574": "c5",
"C018908": "c6",
"C021545": "c7",
"C024392": "c8",
"C027281": "c9",
"C030392": "c10",
"C033457": null,
"C036671": null,
"C039663": null,
"C042967": null,
"C045398": null,
"C048160": null,
"C051924": null,
"C054920": null,
"C057239": null,
"C060993": null,
"C063309": null,
"C066352": null,
"C069003": null,
"C072467": null,
"C075210": null
}
}
5) Call the view, just a typical call no arguments
http://<SERVER>:5984/db_24/_design/test/_view/Grid
6) Verify the response is CORRECT
{"rows":[{"key":null,"value":{"C003089":{"total":1},"C006990":{"total":1},"C009996":{"total":1},"C012132":{"total":1},"C015574":{"total":1},"C018908":{"total":1},"C021545":{"total":1},"C024392":{"total":1},"C027281":{"total":1},"C030392":{"total":1},"C033457":{"total":1},"C036671":{"total":1},"C039663":{"total":1},"C042967":{"total":1},"C045398":
{"total":1},"C048160":{"total":1},"C051924":{"total":1},"C054920":{"total":1},"C057239":{"total":1},"C060993":{"total":1},"C063309":{"total":1},"C066352":{"total":1},"C069003":
{"total":1},"C072467":{"total":1},"C075210":{"total":1}}}
]}
7) Now, delete the previous document and add the following:
{
"_id": "4334dff68f2283e6e8739eabb40a4e7a",
"_rev": "24-524e9c9ebeaf88962f41e3a940788610",
"data": {
"C003089": "c1",
"C006990": "c2",
"C009996": "c3",
"C012132": "c4",
"C015574": "c5",
"C018908": "c6",
"C021545": "c7",
"C024392": "c8",
"C027281": "c9",
"C030392": "c10",
"C033457": null,
"C036671": null,
"C039663": null,
"C042967": null,
"C045398": null,
"C048160": null,
"C051924": null,
"C054920": null,
"C057239": null,
"C060993": null,
"C063309": null,
"C066352": null,
"C069003": null,
"C072467": null,
"C075210": null,
"C078387": null
}
}
8) Note that all we did was add a single property to the end of
"data", now run the same view again
9) Notice the error:
{"error":"reduce_overflow_error","reason":"Reduce output must shrink
more rapidly: Current output:
'[{\"C003089\":{\"total\":1},\"C006990\":{\"total\":1},\"C009996\":{\"total\":1},\"C012132\":{\"total\":1},\"C015574\":'...
(first 100 of 575 bytes)"}
10) I am confused because all I did is add a single property, not sure
how this affects the reduce function?
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Randall Leeds <ra...@gmail.com>.
On Tue, Aug 16, 2011 at 17:53, Chris Stockton <ch...@gmail.com>wrote:
> Hello,
>
> On Tue, Aug 16, 2011 at 5:37 PM, Randall Leeds <ra...@gmail.com>
> wrote:
> > On Tue, Aug 16, 2011 at 17:03, Chris Stockton <chrisstocktonaz@gmail.com
> >wrote:
> >
> > Since you are collecting and creating keys in the output object creating
> > this single property made the output of reduce larger. CouchDB tries to
> > detect reduce functions that don't actually reduce the data. If you know
> for
> > sure that you are working with a bounded set of properties whose
> occurrences
> > you would like to sum you may set reduce_limit=false in your
> configuration.
> > The default is true so that users don't shoot themselves in the foot
> > (especially because you cannot cancel a run-away reduce if you don't have
> > access to the machine to kill the process).
> >
>
> Thanks Randall for your reply, I changed my view call to [1] and oddly
> it still gives the same error, maybe I am doing something wrong? I
> didn't see anywhere on couchdb wiki anything for reduce_limit.
> Although I think long term that kind of scares me a little bit, if for
> some reason we ran across some new data that caused a infinite reduce
> due to a bug, our couchdbs would all get crippled, do I have any other
> options here?
>
> It would be great if I could impose a size limit for reduce, or even a
> "minimum" size limit, as it is odd to trigger a reduce error on the
> first record, making it have to run at least 100 times should be a
> good test to see if the data is "shrinking" or at least remaining
> constant. Not sure what to suggest here beyond that, I just think it
> doesn't feel quite right, maybe someone has some better suggestion.
>
> [1] http://<server>:59841/db_24/_design/test/_view/Grid?reduce_limit=false
>
After this I'll tell you about how you change that setting, but you should
consider restructuring your map/reduce:
For example, instead of building an object with these counts in memory and
trying to reduce them over reduce/rereduce just emit multiple rows.
map:
for (var col in doc) {
emit(col, 1);
}
reduce:
_sum
This way you can use the built-in reduction by specifying just the string
"_sum" as your reduce, which is much more efficient than doing it yourself.
Also, you don't hit reduce limit.
Anyway, in case you *do* work with your own installation and want to break
the reduce limit sometime, here's how:
If you look in default.ini you will see the section [query_server_config]
with reduce_limit = true.
You could put something like this in your local.ini:
[query_server_config]
reduce_limit = false
If you don't have access to the box you should be able to issue:
PUT http://<server>/_config/query_server_config/reduce_limit
The body of the request should be the quoted json string "false".
For example, with cURL, you might do:
curl -XPUT -H"Content-Type: application/json" -d'"false"' http://
<server>..../_config/query_server_config/reduce_limit
(Note that the data here is single and double quoted to ensure the double
quotes are passed as part of the body and not removed by the shell.)
If you get an error, e.g., because you're using IrisCouch or something other
service which locks down the installation a bit, you'll have to contact
their support.
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Chris Stockton <ch...@gmail.com>.
Hello,
On Tue, Aug 16, 2011 at 5:37 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Tue, Aug 16, 2011 at 17:03, Chris Stockton <ch...@gmail.com>wrote:
>
> Since you are collecting and creating keys in the output object creating
> this single property made the output of reduce larger. CouchDB tries to
> detect reduce functions that don't actually reduce the data. If you know for
> sure that you are working with a bounded set of properties whose occurrences
> you would like to sum you may set reduce_limit=false in your configuration.
> The default is true so that users don't shoot themselves in the foot
> (especially because you cannot cancel a run-away reduce if you don't have
> access to the machine to kill the process).
>
Thanks Randall for your reply, I changed my view call to [1] and oddly
it still gives the same error, maybe I am doing something wrong? I
didn't see anywhere on couchdb wiki anything for reduce_limit.
Although I think long term that kind of scares me a little bit, if for
some reason we ran across some new data that caused a infinite reduce
due to a bug, our couchdbs would all get crippled, do I have any other
options here?
It would be great if I could impose a size limit for reduce, or even a
"minimum" size limit, as it is odd to trigger a reduce error on the
first record, making it have to run at least 100 times should be a
good test to see if the data is "shrinking" or at least remaining
constant. Not sure what to suggest here beyond that, I just think it
doesn't feel quite right, maybe someone has some better suggestion.
[1] http://<server>:59841/db_24/_design/test/_view/Grid?reduce_limit=false
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Randall Leeds <ra...@gmail.com>.
On Tue, Aug 16, 2011 at 17:03, Chris Stockton <ch...@gmail.com>wrote:
> Hello,
>
> I have been able to reduce a complex case where a certain sized
> document within our application causes "Reduce output must shrink more
> rapidly" errors and I am not sure I understand why. I spent a great
> deal of time making sure I have stripped the database, the documents
> and the views to the bare minimum to make it easy to reproduce, I
> would really appreciate if anyone could give me some insight on what
> is causing this and if a fix exists, may it be ini settings etc. I
> apologize in advanced if this is my lack of understanding views or how
> they work as well as to this email being a bit long, but I think it is
> required to express the issue in case it is indeed a bug.
>
> Kind Regards,
>
> -Chris
>
> --Reproduce steps--
>
> 1) CouchDB Production release 1.10
>
> 2) Create a fresh database
>
> 3) Create the following design document
>
> {
> "_id": "_design/test",
> "_rev": "1-19eb11313c2602a00f0105f78202d1f3",
> "views": {
> "Grid": {
> "map": "function(doc) {\n emit(\"result\", doc.data);\n}",
> "reduce": "function(keys, values, rereduce) {\n var
> container = {};\n\n if(!rereduce) {\n for(var value in values) {\n
> for(var col in values[value]) {\n if(values[value]) {\n
> if(!container[col]) {\n container[col] = {\n
> total: 0\n };\n }\n\n
> container[col].total++;\n }\n }\n }\n } else {\n
> for(var reduced in values) {\n for(var col in values[reduced])
> {\n if(!container[col]) {\n container[col] = {\n
> total: 0\n };\n }\n\n container[col].total
> += values[reduced][col].total;\n }\n }\n }\n\n return
> container;\n}"
> }
> },
> "language": "javascript"
> }
>
> 4) Create the following regular document (any id is okay)
> {
> "_id": "4334dff68f2283e6e8739eabb40a4e7a",
> "_rev": "24-524e9c9ebeaf88962f41e3a940788610",
> "data": {
> "C003089": "c1",
> "C006990": "c2",
> "C009996": "c3",
> "C012132": "c4",
> "C015574": "c5",
> "C018908": "c6",
> "C021545": "c7",
> "C024392": "c8",
> "C027281": "c9",
> "C030392": "c10",
> "C033457": null,
> "C036671": null,
> "C039663": null,
> "C042967": null,
> "C045398": null,
> "C048160": null,
> "C051924": null,
> "C054920": null,
> "C057239": null,
> "C060993": null,
> "C063309": null,
> "C066352": null,
> "C069003": null,
> "C072467": null,
> "C075210": null
> }
> }
>
> 5) Call the view, just a typical call no arguments
> http://<SERVER>:5984/db_24/_design/test/_view/Grid
>
> 6) Verify the response is CORRECT
>
> {"rows":[{"key":null,"value":{"C003089":{"total":1},"C006990":{"total":1},"C009996":{"total":1},"C012132":{"total":1},"C015574":{"total":1},"C018908":{"total":1},"C021545":{"total":1},"C024392":{"total":1},"C027281":{"total":1},"C030392":{"total":1},"C033457":{"total":1},"C036671":{"total":1},"C039663":{"total":1},"C042967":{"total":1},"C045398":
>
> {"total":1},"C048160":{"total":1},"C051924":{"total":1},"C054920":{"total":1},"C057239":{"total":1},"C060993":{"total":1},"C063309":{"total":1},"C066352":{"total":1},"C069003":
> {"total":1},"C072467":{"total":1},"C075210":{"total":1}}}
> ]}
>
> 7) Now, delete the previous document and add the following:
> {
> "_id": "4334dff68f2283e6e8739eabb40a4e7a",
> "_rev": "24-524e9c9ebeaf88962f41e3a940788610",
> "data": {
> "C003089": "c1",
> "C006990": "c2",
> "C009996": "c3",
> "C012132": "c4",
> "C015574": "c5",
> "C018908": "c6",
> "C021545": "c7",
> "C024392": "c8",
> "C027281": "c9",
> "C030392": "c10",
> "C033457": null,
> "C036671": null,
> "C039663": null,
> "C042967": null,
> "C045398": null,
> "C048160": null,
> "C051924": null,
> "C054920": null,
> "C057239": null,
> "C060993": null,
> "C063309": null,
> "C066352": null,
> "C069003": null,
> "C072467": null,
> "C075210": null,
> "C078387": null
> }
> }
>
> 8) Note that all we did was add a single property to the end of
> "data", now run the same view again
>
> 9) Notice the error:
> {"error":"reduce_overflow_error","reason":"Reduce output must shrink
> more rapidly: Current output:
>
> '[{\"C003089\":{\"total\":1},\"C006990\":{\"total\":1},\"C009996\":{\"total\":1},\"C012132\":{\"total\":1},\"C015574\":'...
> (first 100 of 575 bytes)"}
>
> 10) I am confused because all I did is add a single property, not sure
> how this affects the reduce function?
>
Since you are collecting and creating keys in the output object creating
this single property made the output of reduce larger. CouchDB tries to
detect reduce functions that don't actually reduce the data. If you know for
sure that you are working with a bounded set of properties whose occurrences
you would like to sum you may set reduce_limit=false in your configuration.
The default is true so that users don't shoot themselves in the foot
(especially because you cannot cancel a run-away reduce if you don't have
access to the machine to kill the process).
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Chris Stockton <ch...@gmail.com>.
Hello,
Thanks for your response Marcello,
On Wed, Aug 17, 2011 at 2:13 PM, Marcello Nuccio
<ma...@gmail.com> wrote:
>
> It says: "SMALL, fixed-size...".
I think it has nothing to do with size, if my documents were 1MB and I
made a 750KB view structure, everything is fine, so "small" here
really means, smaller then the first document you scan... from my
testing anyways.
> How do you lookup documents? By the key "result"?
> Can you emit a value for each data key ("C003089", "C006990", ...)
> then use group_level query parameter to collect statistics?
>
I think this isn't a option as the same view is called without a
reduce to efficiently fetch the docs. Also when I do reduce, I need
every key. I am sure I could redesign but we now have thousands of
customers with these views and a lot of lines of application code that
would need changed, at this point.. it's not reasonable.
Kind Regards,
-Chris
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Marcello Nuccio <ma...@gmail.com>.
2011/8/17 Chris Stockton <ch...@gmail.com>:
> Hello,
>
> On Tue, Aug 16, 2011 at 11:58 PM, Marcello Nuccio
> <ma...@gmail.com> wrote:
>> I don't think this is a bug. Citing from
>> http://guide.couchdb.org/draft/cookbook.html#aggregate
>>
>> As a rule of thumb, the reduce function should reduce to a single
>> scalar value. That is, an integer; a string; or a small, fixed-size
>> list or object that includes an aggregated value (or values) from the
>> values argument.
>>
>> The object returned by your reduce function, is not fixed-size.
>> Actually it is bigger than the input document.
>>
>> Marcello
>>
>
> I actually think we fit the rule of thumb in the sense the object
> returned is fixed size object of scalars. It just so happens to have
> lots of keys.
It says: "SMALL, fixed-size...".
> The reason this is necessary is because we do much more
> then just the total, we do the population variance, population
> standard deviation, square, sums, the average total including nulls,
> and the average total not including nulls.
>
> I wont go too deep into our applications architecture but this record
> represents a "row" in a list of user data with different kinds of data
> types, typically users don't want any kinds of stats etc, so we just
> serve out the documents.
How do you lookup documents? By the key "result"?
Can you emit a value for each data key ("C003089", "C006990", ...)
then use group_level query parameter to collect statistics?
Marcello
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Chris Stockton <ch...@gmail.com>.
Hello,
On Wed, Aug 17, 2011 at 10:55 AM, Robert Newson <rn...@apache.org> wrote:
> The reduce_limit heuristic is there to save you from writing bad
> reduce functions that are destined to fail in production as document
> count increases. The result of a reduce call should be strictly
> smaller than the input size (and preferably a lot smaller).
>
> If the number of keys in the returned object is fixed, you'll probably
> be fine, though testing with a sizeable number of documents (and
> graphing the performance curve) will prove it.
>
> B.
>
Hello Robert,
Basically that is what I'm confused about, the response is a fixed
size statistical aggregation, it does not grow in length, only
increments scalar values. The structure on the first pass is the same
size as the last. I think the view exiting on the first iteration is
undesired behavior and a higher sampling of data / slightly more
forgiving algorithm should be put in place for this. If this simply
won't happen or no one else agrees I will remove the reduce limit..
but I feel like that could be very dangerous and almost would rather
create a patch for our CouchDB's before I did that.
-Chris
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Robert Newson <rn...@apache.org>.
The reduce_limit heuristic is there to save you from writing bad
reduce functions that are destined to fail in production as document
count increases. The result of a reduce call should be strictly
smaller than the input size (and preferably a lot smaller).
If the number of keys in the returned object is fixed, you'll probably
be fine, though testing with a sizeable number of documents (and
graphing the performance curve) will prove it.
B.
On 17 August 2011 18:24, Chris Stockton <ch...@gmail.com> wrote:
> Hello,
>
> On Tue, Aug 16, 2011 at 11:58 PM, Marcello Nuccio
> <ma...@gmail.com> wrote:
>> I don't think this is a bug. Citing from
>> http://guide.couchdb.org/draft/cookbook.html#aggregate
>>
>> As a rule of thumb, the reduce function should reduce to a single
>> scalar value. That is, an integer; a string; or a small, fixed-size
>> list or object that includes an aggregated value (or values) from the
>> values argument.
>>
>> The object returned by your reduce function, is not fixed-size.
>> Actually it is bigger than the input document.
>>
>> Marcello
>>
>
> I actually think we fit the rule of thumb in the sense the object
> returned is fixed size object of scalars. It just so happens to have
> lots of keys. The reason this is necessary is because we do much more
> then just the total, we do the population variance, population
> standard deviation, square, sums, the average total including nulls,
> and the average total not including nulls.
>
> I wont go too deep into our applications architecture but this record
> represents a "row" in a list of user data with different kinds of data
> types, typically users don't want any kinds of stats etc, so we just
> serve out the documents. However some users want statistical
> information about their data, so in those cases we run the reduce, it
> is a win because we have 1 view for both the map and reduce. To
> redesign our map to emit columns means a separate view for statistics,
> which means a couple things that I am not okay with, like double the
> disk space, multiple view calls per statistics load.
>
> At the end of the day I think I disagree that this is not a bug, I
> think there is room for improvement in this area and should be
> discussed. If this is not the appropriate place to do so I can write a
> jira ticket.
>
> -Chris
>
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Chris Stockton <ch...@gmail.com>.
Hello,
On Tue, Aug 16, 2011 at 11:58 PM, Marcello Nuccio
<ma...@gmail.com> wrote:
> I don't think this is a bug. Citing from
> http://guide.couchdb.org/draft/cookbook.html#aggregate
>
> As a rule of thumb, the reduce function should reduce to a single
> scalar value. That is, an integer; a string; or a small, fixed-size
> list or object that includes an aggregated value (or values) from the
> values argument.
>
> The object returned by your reduce function, is not fixed-size.
> Actually it is bigger than the input document.
>
> Marcello
>
I actually think we fit the rule of thumb in the sense the object
returned is fixed size object of scalars. It just so happens to have
lots of keys. The reason this is necessary is because we do much more
then just the total, we do the population variance, population
standard deviation, square, sums, the average total including nulls,
and the average total not including nulls.
I wont go too deep into our applications architecture but this record
represents a "row" in a list of user data with different kinds of data
types, typically users don't want any kinds of stats etc, so we just
serve out the documents. However some users want statistical
information about their data, so in those cases we run the reduce, it
is a win because we have 1 view for both the map and reduce. To
redesign our map to emit columns means a separate view for statistics,
which means a couple things that I am not okay with, like double the
disk space, multiple view calls per statistics load.
At the end of the day I think I disagree that this is not a bug, I
think there is room for improvement in this area and should be
discussed. If this is not the appropriate place to do so I can write a
jira ticket.
-Chris
Re: Bug or my lack of understanding? "Reduce output must shrink more rapidly"
Posted by Marcello Nuccio <ma...@gmail.com>.
I don't think this is a bug. Citing from
http://guide.couchdb.org/draft/cookbook.html#aggregate
As a rule of thumb, the reduce function should reduce to a single
scalar value. That is, an integer; a string; or a small, fixed-size
list or object that includes an aggregated value (or values) from the
values argument.
The object returned by your reduce function, is not fixed-size.
Actually it is bigger than the input document.
Marcello
2011/8/17 Chris Stockton <ch...@gmail.com>:
> Hello,
>
> I have been able to reduce a complex case where a certain sized
> document within our application causes "Reduce output must shrink more
> rapidly" errors and I am not sure I understand why. I spent a great
> deal of time making sure I have stripped the database, the documents
> and the views to the bare minimum to make it easy to reproduce, I
> would really appreciate if anyone could give me some insight on what
> is causing this and if a fix exists, may it be ini settings etc. I
> apologize in advanced if this is my lack of understanding views or how
> they work as well as to this email being a bit long, but I think it is
> required to express the issue in case it is indeed a bug.
>
> Kind Regards,
>
> -Chris
>
> --Reproduce steps--
>
> 1) CouchDB Production release 1.10
>
> 2) Create a fresh database
>
> 3) Create the following design document
>
> {
> "_id": "_design/test",
> "_rev": "1-19eb11313c2602a00f0105f78202d1f3",
> "views": {
> "Grid": {
> "map": "function(doc) {\n emit(\"result\", doc.data);\n}",
> "reduce": "function(keys, values, rereduce) {\n var
> container = {};\n\n if(!rereduce) {\n for(var value in values) {\n
> for(var col in values[value]) {\n if(values[value]) {\n
> if(!container[col]) {\n container[col] = {\n
> total: 0\n };\n }\n\n
> container[col].total++;\n }\n }\n }\n } else {\n
> for(var reduced in values) {\n for(var col in values[reduced])
> {\n if(!container[col]) {\n container[col] = {\n
> total: 0\n };\n }\n\n container[col].total
> += values[reduced][col].total;\n }\n }\n }\n\n return
> container;\n}"
> }
> },
> "language": "javascript"
> }
>
> 4) Create the following regular document (any id is okay)
> {
> "_id": "4334dff68f2283e6e8739eabb40a4e7a",
> "_rev": "24-524e9c9ebeaf88962f41e3a940788610",
> "data": {
> "C003089": "c1",
> "C006990": "c2",
> "C009996": "c3",
> "C012132": "c4",
> "C015574": "c5",
> "C018908": "c6",
> "C021545": "c7",
> "C024392": "c8",
> "C027281": "c9",
> "C030392": "c10",
> "C033457": null,
> "C036671": null,
> "C039663": null,
> "C042967": null,
> "C045398": null,
> "C048160": null,
> "C051924": null,
> "C054920": null,
> "C057239": null,
> "C060993": null,
> "C063309": null,
> "C066352": null,
> "C069003": null,
> "C072467": null,
> "C075210": null
> }
> }
>
> 5) Call the view, just a typical call no arguments
> http://<SERVER>:5984/db_24/_design/test/_view/Grid
>
> 6) Verify the response is CORRECT
> {"rows":[{"key":null,"value":{"C003089":{"total":1},"C006990":{"total":1},"C009996":{"total":1},"C012132":{"total":1},"C015574":{"total":1},"C018908":{"total":1},"C021545":{"total":1},"C024392":{"total":1},"C027281":{"total":1},"C030392":{"total":1},"C033457":{"total":1},"C036671":{"total":1},"C039663":{"total":1},"C042967":{"total":1},"C045398":
> {"total":1},"C048160":{"total":1},"C051924":{"total":1},"C054920":{"total":1},"C057239":{"total":1},"C060993":{"total":1},"C063309":{"total":1},"C066352":{"total":1},"C069003":
> {"total":1},"C072467":{"total":1},"C075210":{"total":1}}}
> ]}
>
> 7) Now, delete the previous document and add the following:
> {
> "_id": "4334dff68f2283e6e8739eabb40a4e7a",
> "_rev": "24-524e9c9ebeaf88962f41e3a940788610",
> "data": {
> "C003089": "c1",
> "C006990": "c2",
> "C009996": "c3",
> "C012132": "c4",
> "C015574": "c5",
> "C018908": "c6",
> "C021545": "c7",
> "C024392": "c8",
> "C027281": "c9",
> "C030392": "c10",
> "C033457": null,
> "C036671": null,
> "C039663": null,
> "C042967": null,
> "C045398": null,
> "C048160": null,
> "C051924": null,
> "C054920": null,
> "C057239": null,
> "C060993": null,
> "C063309": null,
> "C066352": null,
> "C069003": null,
> "C072467": null,
> "C075210": null,
> "C078387": null
> }
> }
>
> 8) Note that all we did was add a single property to the end of
> "data", now run the same view again
>
> 9) Notice the error:
> {"error":"reduce_overflow_error","reason":"Reduce output must shrink
> more rapidly: Current output:
> '[{\"C003089\":{\"total\":1},\"C006990\":{\"total\":1},\"C009996\":{\"total\":1},\"C012132\":{\"total\":1},\"C015574\":'...
> (first 100 of 575 bytes)"}
>
> 10) I am confused because all I did is add a single property, not sure
> how this affects the reduce function?
>