[Data] Always launch one task for read_sql

[bveeramani]

Why are these changes needed?

Each read_sql read tasks attempts to read a different chunk of data using the offset and limit filters. For example, if you have a database with 200 rows, read_sql might launch two tasks that reads offset 0 limit 100 and offset 100 limit 100 to read rows 0-100 and 100-200, respectively.

However, if the underlying database doesn’t have a deterministic ordering, read tasks might read duplicate data.

To fix this correctness issue, this PR makes read_sql always launch one task. Since offset typically requires scanning and discarding rows, this PR's code should perform similarly to the original implementation.

Related issue number

Checks

• I've signed off every commit(by using the -s flag, i.e., git commit -s) in this PR.
• I've run scripts/format.sh to lint the changes in this PR.
• I've included any doc changes needed for https://docs.ray.io/en/master/.
  • I've added any new APIs to the API Reference. For example, if I added a
    method in Tune, I've added it in doc/source/tune/api/ under the
    corresponding .rst file.
• I've made sure the tests are passing. Note that there might be a few flaky tests, see the recent failures at https://flakey-tests.ray.io/
• Testing Strategy
  • Unit tests
  • Release tests
  • This PR is not tested :(

[alexeykudinkin]

@bveeramani

• Might be worthwhile to preserve this functionality of parallel fetching for very large datasets
• We can still preserve parallelism if we'd ask the user for the column we can naturally order by (and use offsets)

[raulchen]

maybe just raise an error. warning is implicit.

[srinathk10]

To understand, if DB table is huge (1B rows or more), will this be single threaded ingest?

[bveeramani]

Yeah. Many DBAPI implementations don't support multithreading

[srinathk10]

If I understand this right, we may end up with very slow ingest with just 1 task for DBs and also OOM kills. While for files, we are able to do support parallel ingests in a scaled out fashion.

[bveeramani]

That's right.

What do we do as an alternative that's both scalable and correct? Many OFFSET implementations require scanning the entire database. So, OFFSET and LIMIT often perform the same or worse than a single task that reads the entire database.