Strongly Consistent Global Indexes for Apache Phoenix
•
0 likes•524 views
Presentation by Kadir Ozdemir, Principal Architect - Salesforce, recorded at Distributed SQL Summit on Sept 20, 2019. https://vimeo.com/362358494 distributedsql.org/
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Strongly Consistent Global Indexes for Apache Phoenix
Similar to Strongly Consistent Global Indexes for Apache Phoenix (20)
Recently uploaded
Recently uploaded (20)
Strongly Consistent Global Indexes for Apache Phoenix
- 1. Strongly Consistent Global Indexes for Apache Phoenix Kadir Ozdemir September 2019
- 2. Why Phoenix at Salesforce? Massive Data Scale w/ Familiar Interface Trusted storage Consistent Multi-cloud Salesforce Multi-tenancy
- 3. HDFS HBase Server (Da Application Server HBase Region Servers Phoenix Server Phoenix Application Phoenix Client HBase Client SQL Table Scans/ Mutations Table Region RPC
- 4. Secondary Indexing ID Name City 1234 Ashley Seattle 2345 Kadir San Francisco Primary Key Secondary Key
- 5. Secondary Indexing ID Name City 1234 Ashley Seattle 2345 Kadir San Francisco Primary KeyPrimary Key ID Name City 1234 Ashley Seattle 2345 Kadir San Francisco Primary Key City ID Name San Francisco 2345 Kadir Seattle 12345 Ashley Secondary Key Data Table Index Table
- 6. Secondary Indexing - Update ID Name City 1234 Ashley Seattle Primary KeyPrimary Key City ID Name San Francisco 2345 Kadir ID Name City 2345 Kadir San Francisco City ID Name Seattle 12345 Ashley Data Table Index Table
- 7. Secondary Indexing - Update ID Name City 1234 Ashley Seattle Primary KeyPrimary Key City ID Name ID Name City 2345 Kadir San Francisco City ID Name Seattle 12345 Ashley Data Table Index Table
- 8. Global Secondary Indexing - Update ID Name City 1234 Ashley Seattle Primary KeyPrimary Key City ID Name ID Name City 2345 Kadir Seattle City ID Name Seattle 1234 Ashley Seattle 2345 Kadir Data Table Index Table
- 9. Current Design Challenges ● Tries to make tables consistent at the write time by relying on client retries ○ May not handle correlated failures and may leave data table inconsistent with its indexes ● Needs external tools to detect inconsistencies and repair them
- 10. Design Objectives ● Secondary indexes should be always in sync with their data tables ● Strong consistency should not result in significant performance impact ● Strong consistency should not impact scalability significantly
- 11. Observations ● Data must be consistent at read time ○ An index table row can be repaired from the corresponding data table row at read time ● In HBase writes are fast ○ We can add extra write phase without severely impacting write performance
- 12. Strongly Consistent Design Operation Strongly Consistent Design Read 1. Read the index rows and check their status 2. The unverified rows repaired from the data table
- 13. Strongly Consistent Design Operation Strongly Consistent Design Read 1. Read the index rows and check their status 2. The unverified rows repaired from the data table Write 1. Set the status of existing index rows unverified and write the new index rows with the unverified status 2. Write the data table rows 3. Delete the existing index rows and set the status of new rows to verified
- 14. Strongly Consistent Design Operation Strongly Consistent Design Read 1. Read the index rows and check their status 2. The unverified rows repaired from the data table Write 1. Set the status of existing index rows unverified and write the new index rows with the unverified status 2. Write the data table rows 3. Delete the existing index rows and set the status of new rows to verified Delete 1. Set the index table rows with the unverified status 2. Delete the data table rows 3. Delete index table rows
- 15. Correctness Without Concurrent Row Updates ● Missing index row is not possible ○ An index row is updated first before its data row ■ If the index update is failed then the data row update will not be attempted ○ An index row is deleted only after its data table row is deleted ● Verified index row implies existence of the corresponding data row ○ The status for an index row is set to verified only after the corresponding data row is written ○ The status for an index row is set to unverified before the corresponding data row is deleted ● Unverified index rows are not used for serving user queries ○ An unverified index row is repaired from its data row during scans
- 16. Correctness With Concurrent Row Updates ● The third phase is skipped for concurrent updates ○ Detect concurrent updates and leave them in the unverified state ● Use two phase row locking to detect concurrent updates on a data row read the data table (phase 1) index table update (phase 2) update the data table phase 3 index table update Pending Rows add remove
- 17. Performance Impact of Strong Consistency ● Setup: A data table with two indexes on a 10 node cluster ○ 1 billion large rows with random primary key ○ Top N queries on indexes where N is 50 ● Less than 25% increase in write latency ○ Due to setting row status in phase 3 ● No noticeable increase in read latency ○ The number of unverified rows due to pending updates on a given table region is limited by the number of RPC threads and mutation batch size
- 18. Questions?