[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14204508#comment-14204508 ] cuijianwei commented on HBASE-10999: In last few months, we have updated Themis to achieve better performance and include more features: 1. Improve the single-row write performance from 23%(relative drop compared with HBase's put) to 60%(for most test cases). For single-row write transaction, we only write lock to MemStore in prewrite-phase, then, we erase correpsonding lock, write data and commit information to HLog in commit-phase. This won't break the correctness of percolator algorithm and will help improve the performance a lot for single-row write. 2. Support HBase 0.98. We create a branch: https://github.com/XiaoMi/themis/tree/for_hbase_0.98 to make themis support HBase 0.98(Currently, support HBase 0.98.5). All the functions of master branch will also be implemented in this branch. 3. Transaction TTL support and Old Data Clean. Users could set TTL for read/write transaction respectivley. Then, old data which could not be read will be cleaned periodly. 4. MapReduce Support. We implement ThemisTableInputFormat to scan data from themis-enable table in Map Job and ThemisTableOutputFormat to write data by themis transaction in Reducer Job. Mult-table scan and write are also supportted. 5. Implement Zookeeper based WorkerRegister. As mentioned in percolator paper, Running workers write a token into the Chubby lockservice, ZookeeperWorkerRegister implements this function and will help resolve conflict more efficiently. 6. Table Schema Support. Users could set THEMIS_ENABLE attribute to true to family which needs themis transaction, then, themis will automatically set corresponding attributes to the family and create lock family. For more details, please see: https://github.com/XiaoMi/themis (for HBase 0.94) and https://github.com/XiaoMi/themis/tree/for_hbase_0.98 (for HBase 0.98). Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14054613#comment-14054613 ] cuijianwei commented on HBASE-10999: [~stack], thanks for your comment and sorry for replying late. We finished the performance test after applying concurrent write for multi-row transactions. I send an email to the mail list to introduce the Themis project, hope more discussions about transaction on HBase:) Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of percolator is 23% of HBase. The drop derives from the overhead of percolator logic, the performance test result is similar as the result reported by google's paper. 4. Performance improvement. The write performance of
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033382#comment-14033382 ] stack commented on HBASE-10999: --- [~jeffreyz] bq. Stack What's your thoughts on this? Thanks. My thoughts are that hbase is fat enough already with enough scope. That said, everyone wants transactions so I could see an implementation coming into core. [~cuijianwei] You still haven't posted notice of this fine work up on the list (smile). Go easy Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of percolator is 23% of HBase. The drop derives from the overhead of percolator logic, the performance test result is similar as the result reported by google's paper. 4. Performance improvement.
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010663#comment-14010663 ] Jeffrey Zhong commented on HBASE-10999: --- [~cuijianwei] It seems the WorkerRegister hasn't fully been implemented. The current code is based on 0.94 while Hbase CP has incompatible changes since then. What's your plan to incorporate Themis into HBase: move the code into HBase code base or still put Themis as a third party library outside of HBase. If leaving Themis outside, I can image transaction will become one of core functionalities and will be hard to fix when there is any issue and also hard to correlate release cycles. [~saint@gmail.com] What's your thoughts on this? Thanks. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010679#comment-14010679 ] cuijianwei commented on HBASE-10999: [~stack], thanks for your suggestion, sorry to reply late. The performance of themis write in current version is not good enough. In recent weeks, we optimized the performance of multi-row transactions by concurrent prewrite/commit. The performance after adopting concurrent prewrite/commit has improved significantly when doing multi-row transactions. We are trying to optimize single-row transaction and will update the performance report, then, we will post a note on dev list with new result :) Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14010744#comment-14010744 ] cuijianwei commented on HBASE-10999: [~jeffreyz], thanks for your concern. The WorkerRegister hasn't fully been implemented. As mentioned in percolator paper, clients which use transaction could register a ephemeral node in zookeeper through WorkerRegister. Then, if clients fail and exit, other clients could know the failed clients quickly when their ephemeral nodes deleted, this could help to resolve lock conflict more efficiently. In current version, themis resolve lock conflict by TTL of lock, and we will implement the WorkerRegister logic in next version. I agree that transaction will become one of the core functionalities. We hope themis could come into HBase code base if possible and work as a component of HBase to provide transaction function. The implementation of themis is based on CP and won't change the source code of HBase. Users could invoke themis APIs only when they need transaction. And we can respond more quickly if there is any issue about transaction function. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983904#comment-13983904 ] cuijianwei commented on HBASE-10999: [~eincs], thanks for your comments. I agree that Percolator and Haeinsa each have benefits. I think Percolator and Haeinsa might differ from some aspects, including isolation level, global timestamp oracle and snapshot read. Last week, we made our Percolator implementation on HBase(named themis) open source in github : https://github.com/XiaoMi/themis/, including modules of themis and results of performance test. I am glad that if you can have a look at themis, and any comment and suggestion will is welcomed. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13983979#comment-13983979 ] stack commented on HBASE-10999: --- [~cuijianwei] Suggest you post a note on dev list about your new project. Not everyone reads JIRAs and of those who do, more than they would be interested in a percolator clone. Good stuff. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of percolator is 23% of HBase. The drop derives from the overhead of percolator logic, the performance test result is similar as the result reported by google's paper. 4. Performance improvement. The write performance of percolator decreases more compared with HBase. This is because percolator's write needs to read
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13979621#comment-13979621 ] James Lee commented on HBASE-10999: --- [~stack], Thank you for mentioning Haeinsa. I'm one of the developer of Haeinsa. [~cuijianwei] is right. Haeinsa is designed to handle handful of rows(about lees than 100s of rows). We are using Haeinsa for OLTP, and it tends to be small number of rows in single transaction. It might be a problem on the system which needed to handle large number of read on rows in single transaction. You can see this information on wiki page of Haeinsa project. https://github.com/VCNC/haeinsa/wiki/How-to-Use#important-information Actually, our first attempt to implementing cross-row transaction on HBase was cloning the Percolator. But there were several reason why we built Haeinsa rather than implementing Percolator: Stronger isolation level than snapshot-isolation was needed, Better latency was needed for our OLTP system, and so on. There are several benefits Percolator over Haeinsa in some cases, as cuijianwei mentioned, It might be great to see open-sourced implementation of the Percolator for HBase. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13980430#comment-13980430 ] stack commented on HBASE-10999: --- Thanks [~eincs] for dropping by. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of percolator is 23% of HBase. The drop derives from the overhead of percolator logic, the performance test result is similar as the result reported by google's paper. 4. Performance improvement. The write performance of percolator decreases more compared with HBase. This is because percolator's write needs to read data out to check write conflict and needs two Rpcs which do prewriting and commiting respectively. We are investigating ways to improve the write performance.
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13976125#comment-13976125 ] stack commented on HBASE-10999: --- [~cuijianwei] Looking forward to it. Any comment on how it relates to the work of our friends at VCNC, https://github.com/VCNC/haeinsa announced here: https://www.mail-archive.com/user@hbase.apache.org/msg27565.html Thanks. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of percolator is 23% of HBase. The drop derives from the overhead of percolator logic, the performance test result is similar as the result reported by google's paper. 4. Performance improvement. The write performance of percolator decreases more compared with HBase. This is because
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13976279#comment-13976279 ] cuijianwei commented on HBASE-10999: [~stack], thanks for your comment. Haeinsa is an interesting project to implement cross-row transaction on HBase. We analyzed Haeinsa's implementation before deciding to implement percolator algorithm. In my opinion, an important difference between percolator and Haeinsa is that percolator provides global database snapshot for read while Haeinsa always returns the data of newest committed transactions. If our analysis is right, the read of Haeinsa needs two phases. Firstly, Haeinsa needs to read back the data and locks of transaction rows where the data and locks will be both cached in client side. After this, Haeinsa needs to read back the locks of transaction rows again to check the locks are not changed, so that won't return incomplete transactions to users. The two-phase read might make Haeinsa not easy to read large volume of data for two reasons：a). it is not easy to cached data and locks for a large number of rows in client side; b) when scanning a large range of rows, newer writes have a greater possibility to change the locks of scanning rows which will make read fail more easily. On the other hand, percolator will use the a global incremental timestamp to define the database snapshot for read. The client will return the row to user if no lock conflict discovered, so that does not need to cache any data and lock in client side. The Haeinsa project does not provides global database snapshot so that it does not depend a Global Incremental Timestamp Service, which makes its implementation more independent. However, in my opinion, the global database snapshot is important for transactions as analyzed above; and we find it is not difficult to implement a Global Incremental Timestamp Service. Consequently, we implemented percolator algorithm to do cross-row transaction. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975375#comment-13975375 ] cuijianwei commented on HBASE-10999: [~vrodionov], sorry for replying late. Thanks for your concern. We will make this implementation open source and put to github as soon as possible. This might need one or two weeks, please have a wait:) Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of percolator is 23% of HBase. The drop derives from the overhead of percolator logic, the performance test result is similar as the result reported by google's paper. 4. Performance improvement. The write performance of percolator decreases more compared with HBase. This is because percolator's
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973351#comment-13973351 ] Vladimir Rodionov commented on HBASE-10999: --- I might be wrong in my assumptions, but it seems that you are doing cross region RPCs from inside Coprocessors (RegionObservers?). If this is true than how have you implemented deadlock prevention when all RPC threads on some RS can be blocked, processing incoming and outgoing requests? This subject (cross region RPCs from RegionObserver) has been discussed several times in the past and now is being considered as an anti-pattern. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of percolator is 23% of HBase. The drop derives from the
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973620#comment-13973620 ] cuijianwei commented on HBASE-10999: [~vrodionov], thanks for your comment. The cross region works are done in client-side. The corpocessors (server side) do percolator logics(prewrite/commit/read) only for single row under the regions, the client will combine the single-row results from coprocessors of different regions to finish the whole transaction; therefore, there won't be RPCs from inside corprocessors. For example, if one cross-row transaction will mutate two rows 'rowA' and 'rowB' belonging to different regions, the prewrite/commit requests of 'rowA' and 'rowB' will be sent to region servers from client-side and processed by percolator coprocessors respectively. After that, the client will receive the results from both coprocessors, and the client could judge whether the transaction is done successfully or failed because of conflict from the coprocessors' result. Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test
[jira] [Commented] (HBASE-10999) Cross-row Transaction : Implement Percolator Algorithm on HBase
[ https://issues.apache.org/jira/browse/HBASE-10999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13973773#comment-13973773 ] Vladimir Rodionov commented on HBASE-10999: --- [~cuijianwei]], thank you for clarification. Any chances to look at the code any time soon? Cross-row Transaction : Implement Percolator Algorithm on HBase --- Key: HBASE-10999 URL: https://issues.apache.org/jira/browse/HBASE-10999 Project: HBase Issue Type: New Feature Components: Transactions/MVCC Affects Versions: 0.99.0 Reporter: cuijianwei Assignee: cuijianwei Cross-row transaction is a desired function for database. It is not easy to keep ACID characteristics of cross-row transactions in distribute databases such as HBase, because data of cross-transaction might locate in different machines. In the paper http://research.google.com/pubs/pub36726.html, google presents an algorithm(named percolator) to implement cross-row transactions on BigTable. After analyzing the algorithm, we found percolator might also be a choice to provide cross-row transaction on HBase. The reasons includes: 1. Percolator could keep the ACID of cross-row transaction as described in google's paper. Percolator depends on a Global Incremental Timestamp Service to define the order of transactions, this is important to keep ACID of transaction. 2. Percolator algorithm could be totally implemented in client-side. This means we do not need to change the logic of server side. Users could easily include percolator in their client and adopt percolator APIs only when they want cross-row transaction. 3. Percolator is a general algorithm which could be implemented based on databases providing single-row transaction. Therefore, it is feasible to implement percolator on HBase. In last few months, we have implemented percolator on HBase, did correctness validation, performance test and finally successfully applied this algorithm in our production environment. Our works include: 1. percolator algorithm implementation on HBase. The current implementations includes: a). a Transaction module to provides put/delete/get/scan interfaces to do cross-row/cross-table transaction. b). a Global Incremental Timestamp Server to provide globally monotonically increasing timestamp for transaction. c). a LockCleaner module to resolve conflict when concurrent transactions mutate the same column. d). an internal module to implement prewrite/commit/get/scan logic of percolator. Although percolator logic could be totally implemented in client-side, we use coprocessor framework of HBase in our implementation. This is because coprocessor could provide percolator-specific Rpc interfaces such as prewrite/commit to reduce Rpc rounds and improve efficiency. Another reason to use coprocessor is that we want to decouple percolator's code from HBase so that users will get clean HBase code if they don't need cross-row transactions. In future, we will also explore the concurrent running characteristic of coprocessor to do cross-row mutations more efficiently. 2. an AccountTransfer simulation program to validate the correctness of implementation. This program will distribute initial values in different tables, rows and columns in HBase. Each column represents an account. Then, configured client threads will be concurrently started to read out a number of account values from different tables and rows by percolator's get; after this, clients will randomly transfer values among these accounts while keeping the sum unchanged, which simulates concurrent cross-table/cross-row transactions. To check the correctness of transactions, a checker thread will periodically scan account values from all columns, make sure the current total value is the same as the initial total value. We run this validation program while developing, this help us correct errors of implementation. 3. performance evaluation under various test situations. We compared percolator's APIs with HBase's with different data size and client thread count for single-column transaction which represents the worst performance case for percolator. We get the performance comparison result as (below): a) For read, the performance of percolator is 90% of HBase; b) For write, the performance of percolator is 23% of HBase. The drop derives from the overhead of percolator logic, the performance test result is similar as the result reported by google's paper. 4. Performance improvement. The write performance of percolator decreases more compared with HBase. This is because percolator's write needs to read data out to check write conflict and needs two Rpcs which do prewriting and
