Hi,
> This seems of very limited value if, for example, if the user desired DESC
> order, then the endpoint would return
>
> Endpoint 1: (C, B, A)
> Endpoint 2: (F, E, D)
As David said, the server returns
Endpoint 2: (F, E, D)
Endpoint 1: (C, B, A)
in this case.
Here is an use case I think:
A system has time series data. Each node in the system has
data for one day. If a client requests "SELECT * FROM data
WHERE server = 'server1' ORDER BY created_at DESC", the
system returns the followings:
Endpoint 20230428: (DATA_FOR_2023_04_28)
Endpoint 20230427: (DATA_FOR_2023_04_27)
Endpoint 20230426: (DATA_FOR_2023_04_26)
...
If we have the "ordered" flag, the client can assume that
received data are sorted. In other words, if the client
reads data from Endpoint 20230428 -> Endpoint 20230427 ->
Endpoint 20230426, the data the client read is sorted.
If we don't have the "ordered" flag and we use "the relative
ordering of data from different endpoints is implementation
defined", we can't implement a general purpose Flight based
client library (Flight SQL based client library, Flight SQL
based ADBC driver and so on). The client library will have
the following code:
# TODO: How to detect server_type?
if server_type == "DB1"
# DB1 returns ordered result.
endpoints.each do |endpoint|
yield(endpoints.read)
end
else
# Other DBs doesn't return ordered result.
# So, we read data in parallel for performance.
threads = endpoints.collect do |endpoint|
Thread.new do
yield(endpoints.read)
end
end
threads.each do |thread|
thread.join
end
end
The client library needs to add 'or server_type == "DB2"' to
'if server_type == "DB1"' when DB2 also adds support for
ordered result. If DB2 2.0 or later is only ordered result
ready, the client library needs more condition 'or
(server_type == "DB2" and server_version > 2.0)'.
So I think that the "ordered" flag is useful.
Thanks,
--
kou
In <CAFhtnRxzMaoqmzWPkqsLoJZW5jmx=d_i9ojd9xy1ydkgkgz...@mail.gmail.com>
"Re: [DISCUSS][Format][Flight] Ordered data support" on Thu, 27 Apr 2023
10:55:32 -0400,
Andrew Lamb <al...@influxdata.com> wrote:
> I wonder if we have considered simply removing the statement "There is no
> ordering defined on endpoints. Hence, if the returned data has an ordering,
> it should be returned in a single endpoint." and replacing it with
> something that says "the relative ordering of data from different endpoints
> is implementation defined"
>
> I am struggling to come up with a concrete usecase for the "ordered" flag.
>
> The ticket references "distributed sort" but most distributed sort
> algorithms I know of would produce multiple sorted streams that need to be
> merged together. For example
>
> Endpoint 1: (B, C, D)
> Endpoint 2: (A, E, F)
>
> It is not clear how the "ordered" flag would help here
>
> If the intent is somehow to signal the client it doesn't have to merge
> (e.g. with data like)
>
> Endpoint 1: (A, B, C)
> Endpoint 2: (D, E, F)
>
> This seems of very limited value if, for example, if the user desired DESC
> order, then the endpoint would return
>
> Endpoint 1: (C, B, A)
> Endpoint 2: (F, E, D)
>
> Which doesn't seem to conform to the updated definition
>
> Andrew
>
>
> On Tue, Apr 25, 2023 at 8:56 PM Sutou Kouhei <k...@clear-code.com> wrote:
>
>> Hi,
>>
>> I would like to propose adding support for ordered data to
>> Apache Arrow Flight. If anyone has comments for this
>> proposal, please share them at here or the issue for this
>> proposal: https://github.com/apache/arrow/issues/34852
>>
>> This is one of proposals in "[DISCUSS] Flight RPC/Flight
>> SQL/ADBC enhancements":
>>
>> https://lists.apache.org/thread/247z3t06mf132nocngc1jkp3oqglz7jp
>>
>> See also the "Flight RPC: Ordered Data" section in the
>> design document for the proposals:
>>
>>
>> https://docs.google.com/document/d/1jhPyPZSOo2iy0LqIJVUs9KWPyFULVFJXTILDfkadx2g/edit#
>>
>> Background:
>>
>> Currently, the endpoints within a FlightInfo explicitly have
>> no ordering.
>>
>> This is unnecessarily limiting. Systems can and do implement
>> distributed sorts, but they can't reflect this in the
>> current specification.
>>
>> Proposal:
>>
>> Add a flag to FlightInfo. If the flag is set, the client may
>> assume that the data is sorted in the same order as the
>> endpoints. Otherwise, the client cannot make any assumptions
>> (as before).
>>
>> This is a compatible change because the client can just
>> ignore the flag.
>>
>> Implementation:
>>
>> https://github.com/apache/arrow/pull/35178 is an
>> implementation of this proposal. The pull requests has the
>> followings:
>>
>> 1. Format changes:
>>
>> https://github.com/apache/arrow/pull/35178/files#diff-53b6c132dcc789483c879f667a1c675792b77aae9a056b257d6b20287bb09dba
>> * format/Flight.proto
>>
>> 2. Documentation changes:
>>
>> https://github.com/apache/arrow/pull/35178/files#diff-839518fb41e923de682e8587f0b6fdb00eb8f3361d360c2f7249284a136a7d89
>> * docs/source/format/Flight.rst
>>
>> 3. The C++ implementation and an integration test:
>> * cpp/src/arrow/flight/
>>
>> 4. The Java implementation and an integration test (thanks to David Li!):
>> * java/flight/
>>
>> 5. The Go implementation and an integration test:
>> * go/arrow/flight/
>> * go/arrow/internal/flight_integration/
>>
>> Next:
>>
>> I'll start a vote for this proposal after we reach a consensus
>> on this proposal.
>>
>> It's the standard process for format change.
>> See also:
>>
>> * [VOTE] Formalize how to change format
>> https://lists.apache.org/thread/jlc4wtt09rfszlzqdl55vrc4dxzscr4c
>> * GH-35084: [Docs][Format] Add how to change format specification
>> https://github.com/apache/arrow/pull/35174
>>
>>
>> Thanks,
>> --
>> kou
>>
