JFYI, phoenix.query.rowKeyOrderSaltedTable is deprecated and is not honored from v4.4, so please use phoenix.query.force.rowkeyorder instead. I have updated the docs(http://localhost:8000/tuning.html) now accordingly.
On Mon, Oct 17, 2016 at 3:14 AM, Josh Elser <josh.el...@gmail.com> wrote: > Not 100% sure, but yes, I believe this is correct. One of the servers > would get 0-99, the other 100-199. The server to use up that batch of 100 > values would then request 200-299, etc. Setting the cache to be 0 would > likely impact the performance of Phoenix. > > Using some external system to perform the global ordering may result in > better performance. Some testing would probably be needed :) > > For the final rowKeyOrderSaltedTable question, yes, I believe that query > would work as you intend. > > > F21 wrote: > >> I am using Phoenix 4.8.1 with HBase 1.2.3 and the Phoenix Query Server. >> >> I want to use a sequence to generate a monotonically increasing id for >> each row. Since the documentation states that 100 sequence numbers are >> cached by default in the client (in my case, I assume the caching would >> happen in the query server), what is the behavior if I have 2 query >> servers (load-balanced)? Does this mean Server A would generate numbers >> starting from 0, and Server B would generate numbers starting from 100? >> I need to make sure that the id is in order on a global basis for the >> whole table. Would setting the CACHE to 0 be the best of achieving this? >> >> Also, as the ID is monotonically increasing, I plan to salt the table >> using something like (no manual split points): >> >> CREATE TABLE mytable (id BIGINT NOT NULL PRIMARY KEY, VARCHAR) >> SALT_BUCKETS = 20; >> >> Without setting phoenix.query.rowKeyOrderSaltedTable to true, would I >> still be able to get my records in order if I select them using >> something like this? >> >> SELECT * FROM mytable WHERE id > 5 && id < 100 ORDER BY id >> >> Thanks, >> >> Francis >> >>
