Hi Ravindra,
1. Table status file for each transaction can be named based on timestamp. 2. How is the state of the data(store) being maintained if the user keeps reverting data to different transaction points frequently. Will the query operations take more time. 3. If clean files should wait till the transaction cleanup for removing the compacted segments it can be suggested to the user to configure smaller transaction retention value. 4. If there are large no of segments already present and the IUD , alter table and delete segment operations are required to open and close the transactions wont this impact the performance of these operations. 5. Suppose a user has created a carbon store in older carbon version and decides to copy the store or directly upgrade to the latest carbon version would this transaction feature be supported for the older carbon version store or data. Regards Chetan On 2019/08/23 12:37:30, Ravindra Pesala <ravi.pes...@gmail.com> wrote: > Hi All, > > CarbonData allows to store the data incrementally and do the Update/Delete > operations on the stored data. But the user always can access the latest > state of data at that point of time. > > In the current system, it is not possible to access the old version of > data. And it is not possible to rollback to the old version in case of some > issues in current version data. > > This proposal adds the automatic versioning of data that we store and we > can access any historical version of that data. > > > The design is attached on the jira > https://issues.apache.org/jira/browse/CARBONDATA-3500 Please check it. > > -- > Thanks & Regards, > Ravindra. >
