Apache9 commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-640971625
> Why don't we use the RegionLocator Interface? We skip it in here. Was wondering why. Seems to have basics. Easy to implement. Which place do you mean? > Could you transport this as a Scan? Convert the 'simple API' into a Scan behind the scenes so we don't have to do stuff like this? (I hear you on not wanting to support full Scan and have some sympathy but I am kicking against a simple API that seems arbitrary and unsatisfactory -- hence the questions. Pardon if annoying... also trying to figure what is going on in here... Takes me a while. I'm slow. Thanks). I think for now it is enough. As I've said in the design doc, 10k entries in root table is still fine to get them all thpugh a single rpc call. And 10k entries in root table is for 100M regions for a whole cluster, which far beyond our goal of supporting 1M regions. And this does not impact the user facing API I'd say. There is no paging support in the client facing API right? For normal read/write, we do not expose any locating related API to users, all locating logic are internal. If you want to improve performance, you can add a prefetch parameter to the locateMeta method(not GetAllMetaRegionLocations). And for RegionLocator, where we expose the region location related API to user, there are only two types, one is get a single region location, the other is to get all the region locations, there is no paging support. And I stand my point that this is better than provide a Scan interface. Scan are too flexible. I've been asked many times why a raw scan can not support filter and finally I just give up and let them go, and then they start to ask why the filter has a very strange behavior. Why? Because lots of filter are not designed to deal with delete marker! That's why I do not want to support it at the first place... ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
