Document design for increasingly large documents

our current problem is how to handle a document when it reaches the maximum size of 20mb. We have multiple docs and per doc, we have irregular data input. So the doc increases when users add new data in our frontend. The problem is now how to handle a doc if it reaches after months or years the limit.

My first idea was to create a doc every month to keep it small and to avoid to get to the limit. The second idea was to check the size of the doc and create a new one if it is just before the limit. The third idea was to create a doc for every entry but we have a table where we show all entries per doc and if we change it to one doc per entry than we have too many queries at this point.

Do you have any idea or are there any best practices in such cases? I searched a lot but can’t find anything.

Thanks in advance!

This sounds like a decent idea to me. Not knowing the nature of your data, maybe there’s a natural way to split it up so that you only need recent data. Another idea would be to “link” a document to other documents as necessary. doc1 contains 50 records, let’s say, plus a string with a key “doc2”. doc2 would have the next 50 records, and so on.

I’m wondering what you mean by this. Why isn’t a single query enough to return all your docs? Maybe you can post your querie(s) to the N1QL forum if you’re having trouble with indexing/optimization?

Thanks for your reply. I guess we choose the solution to split the docs into pieces as we show them. In our case, we have a table where we show 500 entries. The user can switch over a button to the next page with 500 entries and so on. So splitting the doc’s into these table pieces is the way we go now.

1 Like