Database architecture. How more expedient?

Question

NoSQL

Hi all!
Initial data:
- There is a limited VPS traffic
- There is a nosql database - There are a
thousand records in one document (in the byte ratio, for example, 1:40 tobish ~ 40Kb)
- Fast connection > 10Mb / s (fast client
) 1000 entries x 10 A kind of poll. To prove me right.
What is the best way to implement it in terms of economy and performance in general?
1) Read all 40Kb and give it to the client in one request. And already on the client side, show them 10 pcs.
2) Each time to form a request from the client to the server when reading the next portion of data and read at a time only a portion of 10 pieces.
PS: The question from my side arose because of a dispute with a colleague who makes the client part and he is for the 2nd option, but I do the server side and categorically for the 1st option.

Answer 1

It all depends on average usage.
If 99% watch 10, then show 10.
But if they usually watch 500-600.
Then take everything out.
Each request also costs something there is an overhead.
Those. one request for 40KB of data, better than 100 for 400 bytes.

Answer 2

You will notice what word you called the target entity.
Recording.
Store records atomically. You will probably need some relationship between records and other entities. In such cases, it is already more convenient to use relational DBMS.

Answer 3

compression (gzip) return html \ json on the server is enabled?