Re: Buckets VS regions
What is the Phoenix version(if you are not on the latest version probably stats inconsistency is already fixed by now), if you are working on test setup and can reproduce it again, create JIRA and please upload the debug log of the query, hbase:meta and system.stats on it (remember these may have sensitive information about your environment and data like hbase:meta has ip-address/hostname and system.stats has data row keys, so upload only if you think it's a test data and hostnames have no significance). Thanks, Ankit Singhal On Mon, Aug 19, 2019 at 11:17 PM venkata subbarayudu wrote: > There are few reasons - around corner cases , starting from a region-split > to any minor compactions during write process, general recommendation is to > not use guide posts for query processing - or - disable guideposts so the > consistency is guaranteed > > > On Tue, Aug 20, 2019 at 11:10 AM jesse wrote: > >> Yes, that seems to be a trick, the issue is only associated a region. >> >> What could be the causes of guidposts not updated? >> >> >> On Mon, Aug 19, 2019, 6:40 PM venkata subbarayudu >> wrote: >> >>> Did you try with updating table statistics, it may be because some times >>> table guideposts are out of sync >>> >>> Below is the SQL to update table stats >>> Update statistics table >>> By default above executes asynchronously, hence it may take some time to >>> update depending on table size >>> >>> On Tue 20 Aug, 2019, 6:34 AM jesse, wrote: >>> And the table is simple and has no index set up. On Mon, Aug 19, 2019, 6:03 PM jesse wrote: > we got some trouble, maybe someone could shed some light on this. > > Table has primary key c1, c2 and c3. > Table is set with SALT_BUCKETS=12. Now it has 14 regions. > > The table has a record with c1='a', c2='b', c3='c' > > If Phoenix query is like: > select * from t where c2='b', it returns some results. > > select * from t where c1='a', it returns empty > select * from t where c2='b' and c1='a', it returns empty > > select * from t where c3='c', it returns right results > select * from t where c2='b' and c3='c', it returns results > > What the heck is going wrong? The system used to work fine. > > > > > > > > > On Mon, Aug 19, 2019, 5:33 PM James Taylor > wrote: > >> It’ll start with 12 regions, but those regions may split as they’re >> written to. >> >> On Mon, Aug 19, 2019 at 4:34 PM jesse wrote: >> >>> I have a table is SALT_BUCKETS = 12, but it has 14 regions, is >>> this right? >>> >>> Thanks >>> >>> >>> > > -- > *Venkata Subbarayudu Amanchi.* >
Re: Buckets VS regions
There are few reasons - around corner cases , starting from a region-split to any minor compactions during write process, general recommendation is to not use guide posts for query processing - or - disable guideposts so the consistency is guaranteed On Tue, Aug 20, 2019 at 11:10 AM jesse wrote: > Yes, that seems to be a trick, the issue is only associated a region. > > What could be the causes of guidposts not updated? > > > On Mon, Aug 19, 2019, 6:40 PM venkata subbarayudu > wrote: > >> Did you try with updating table statistics, it may be because some times >> table guideposts are out of sync >> >> Below is the SQL to update table stats >> Update statistics table >> By default above executes asynchronously, hence it may take some time to >> update depending on table size >> >> On Tue 20 Aug, 2019, 6:34 AM jesse, wrote: >> >>> And the table is simple and has no index set up. >>> >>> On Mon, Aug 19, 2019, 6:03 PM jesse wrote: >>> we got some trouble, maybe someone could shed some light on this. Table has primary key c1, c2 and c3. Table is set with SALT_BUCKETS=12. Now it has 14 regions. The table has a record with c1='a', c2='b', c3='c' If Phoenix query is like: select * from t where c2='b', it returns some results. select * from t where c1='a', it returns empty select * from t where c2='b' and c1='a', it returns empty select * from t where c3='c', it returns right results select * from t where c2='b' and c3='c', it returns results What the heck is going wrong? The system used to work fine. On Mon, Aug 19, 2019, 5:33 PM James Taylor wrote: > It’ll start with 12 regions, but those regions may split as they’re > written to. > > On Mon, Aug 19, 2019 at 4:34 PM jesse wrote: > >> I have a table is SALT_BUCKETS = 12, but it has 14 regions, is this >> right? >> >> Thanks >> >> >> -- *Venkata Subbarayudu Amanchi.*
Re: Buckets VS regions
Yes, that seems to be a trick, the issue is only associated a region. What could be the causes of guidposts not updated? On Mon, Aug 19, 2019, 6:40 PM venkata subbarayudu wrote: > Did you try with updating table statistics, it may be because some times > table guideposts are out of sync > > Below is the SQL to update table stats > Update statistics table > By default above executes asynchronously, hence it may take some time to > update depending on table size > > On Tue 20 Aug, 2019, 6:34 AM jesse, wrote: > >> And the table is simple and has no index set up. >> >> On Mon, Aug 19, 2019, 6:03 PM jesse wrote: >> >>> we got some trouble, maybe someone could shed some light on this. >>> >>> Table has primary key c1, c2 and c3. >>> Table is set with SALT_BUCKETS=12. Now it has 14 regions. >>> >>> The table has a record with c1='a', c2='b', c3='c' >>> >>> If Phoenix query is like: >>> select * from t where c2='b', it returns some results. >>> >>> select * from t where c1='a', it returns empty >>> select * from t where c2='b' and c1='a', it returns empty >>> >>> select * from t where c3='c', it returns right results >>> select * from t where c2='b' and c3='c', it returns results >>> >>> What the heck is going wrong? The system used to work fine. >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Aug 19, 2019, 5:33 PM James Taylor >>> wrote: >>> It’ll start with 12 regions, but those regions may split as they’re written to. On Mon, Aug 19, 2019 at 4:34 PM jesse wrote: > I have a table is SALT_BUCKETS = 12, but it has 14 regions, is this > right? > > Thanks > > >
Re: Buckets VS regions
Did you try with updating table statistics, it may be because some times table guideposts are out of sync Below is the SQL to update table stats Update statistics table By default above executes asynchronously, hence it may take some time to update depending on table size On Tue 20 Aug, 2019, 6:34 AM jesse, wrote: > And the table is simple and has no index set up. > > On Mon, Aug 19, 2019, 6:03 PM jesse wrote: > >> we got some trouble, maybe someone could shed some light on this. >> >> Table has primary key c1, c2 and c3. >> Table is set with SALT_BUCKETS=12. Now it has 14 regions. >> >> The table has a record with c1='a', c2='b', c3='c' >> >> If Phoenix query is like: >> select * from t where c2='b', it returns some results. >> >> select * from t where c1='a', it returns empty >> select * from t where c2='b' and c1='a', it returns empty >> >> select * from t where c3='c', it returns right results >> select * from t where c2='b' and c3='c', it returns results >> >> What the heck is going wrong? The system used to work fine. >> >> >> >> >> >> >> >> >> On Mon, Aug 19, 2019, 5:33 PM James Taylor >> wrote: >> >>> It’ll start with 12 regions, but those regions may split as they’re >>> written to. >>> >>> On Mon, Aug 19, 2019 at 4:34 PM jesse wrote: >>> I have a table is SALT_BUCKETS = 12, but it has 14 regions, is this right? Thanks
Re: Buckets VS regions
And the table is simple and has no index set up. On Mon, Aug 19, 2019, 6:03 PM jesse wrote: > we got some trouble, maybe someone could shed some light on this. > > Table has primary key c1, c2 and c3. > Table is set with SALT_BUCKETS=12. Now it has 14 regions. > > The table has a record with c1='a', c2='b', c3='c' > > If Phoenix query is like: > select * from t where c2='b', it returns some results. > > select * from t where c1='a', it returns empty > select * from t where c2='b' and c1='a', it returns empty > > select * from t where c3='c', it returns right results > select * from t where c2='b' and c3='c', it returns results > > What the heck is going wrong? The system used to work fine. > > > > > > > > > On Mon, Aug 19, 2019, 5:33 PM James Taylor wrote: > >> It’ll start with 12 regions, but those regions may split as they’re >> written to. >> >> On Mon, Aug 19, 2019 at 4:34 PM jesse wrote: >> >>> I have a table is SALT_BUCKETS = 12, but it has 14 regions, is this >>> right? >>> >>> Thanks >>> >>> >>>
Re: Buckets VS regions
we got some trouble, maybe someone could shed some light on this. Table has primary key c1, c2 and c3. Table is set with SALT_BUCKETS=12. Now it has 14 regions. The table has a record with c1='a', c2='b', c3='c' If Phoenix query is like: select * from t where c2='b', it returns some results. select * from t where c1='a', it returns empty select * from t where c2='b' and c1='a', it returns empty select * from t where c3='c', it returns right results select * from t where c2='b' and c3='c', it returns results What the heck is going wrong? The system used to work fine. On Mon, Aug 19, 2019, 5:33 PM James Taylor wrote: > It’ll start with 12 regions, but those regions may split as they’re > written to. > > On Mon, Aug 19, 2019 at 4:34 PM jesse wrote: > >> I have a table is SALT_BUCKETS = 12, but it has 14 regions, is this >> right? >> >> Thanks >> >> >>
Re: Buckets VS regions
It’ll start with 12 regions, but those regions may split as they’re written to. On Mon, Aug 19, 2019 at 4:34 PM jesse wrote: > I have a table is SALT_BUCKETS = 12, but it has 14 regions, is this > right? > > Thanks > > >
