Measure your medium
Every layout decision (page size, row-group size, file size, read size) rests on what the storage underneath costs per access. Most systems inherit those sizes from defaults tuned for different hardware. What does your storage actually cost, and what follows for your sizes?
You will end with three measured numbers for your storage, and the unit size and concurrency that follow from them.
This is a measurement procedure, not a decision between options.
Work through it
Measure three numbers
On your actual storage, at your actual request size: latency (time to the first byte), bandwidth (bytes per second once streaming), and how many requests can be in flight at once. An afternoon's work, and it invalidates most inherited configuration.
Compute the minimum efficient request
Latency × bandwidth is the request size at which you get most of the bandwidth. If your unit is below it: you pay latency for nothing. If far above it: you pay rewrite cost for nothing. Object storage at about 50 ms and 80 MB/s per connection gives about 4 MB.
Compute the queue depth you need
Requests in flight = target throughput × latency ÷ request size. Then check whether your reader can sustain that many. A synchronous reader, memory-mapped files that fault in one page at a time, or a single-threaded scan cannot, and then throughput is capped at request size ÷ latency whatever hardware you bought.
Classify the access as predictable or not
Predictable (scans): you are limited by bandwidth; batch and prefetch. Unpredictable (point lookups): you are limited by latency, and concurrency is the only lever that exists.
Decide honestly whether you know more than the kernel
Bypassing the operating system's cache (direct I/O) pays only if your engine knows its access pattern better than the kernel does and you will invest in acting on that. If not: use buffered I/O and stop there.
Check alignment
Align reads and writes to the device's block boundaries. It is free, and misalignment can cost a factor of four.