Double-Indexed Key Lists for Multi-Tenant KIPO Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing key-per IO (KIPO) processing for multiple tenants faces challenges in managing key index lists, particularly during atomic operations, leading to bandwidth loss when some keys need to be updated or manipulated, affecting other tenants.
Innovation Solution
Implementing indirect-double-indexing to maintain a duplicated key-index list during key manipulation requests, allowing all tenants to continue working until the request is complete, and then switching to the updated table.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the key index list is updated to manipulate keys atomically, then key management reliability is improved, but tenant bandwidth and continuous operation are lost
Solution Approach 1:
The key index list is segmented into multiple independent lists (first key index list, second key index list, third key index list). Each list can be updated independently without affecting others, allowing atomic operations on individual keys while maintaining continuous access for tenants through alternative lists.
Solution Approach 2:
Different portions of the key index data are assigned different qualities or states. The spare entry in the local key index list can be in a different state (uninitialized or initialized) compared to active entries, allowing selective manipulation of specific keys without affecting the entire list structure or other tenants' operations.
2Ease of operation
If the key index list remains static, then operational simplicity is maintained, but adaptability to key manipulation requests is reduced
Solution Approach 1:
The system transitions from a static key index list to a dynamic multi-list structure. The controller can switch between different key index lists (first, second, third) based on operational needs, allowing the system to adapt to key manipulation requests while maintaining operational continuity through dynamic list selection and switching.
Solution Approach 2:
The spare entry acts as an intermediary element in the key index list. It can temporarily hold key information during manipulation operations, serving as a buffer that enables key updates without disrupting ongoing tenant operations. The intermediary spare entry facilitates smooth transitions during key management activities.
3Adaptability or versatility
If a tenant requests key manipulation, then key management flexibility is improved, but other tenants experience bandwidth loss
Solution Approach 1:
The key index list is segmented into multiple independent lists that can be updated independently. When one tenant requests key manipulation, only the specific portion of the key index structure needs to be updated, while other segments remain unchanged and accessible to other tenants, preventing system-wide bandwidth loss.
Solution Approach 2:
The system maintains multiple copies of the key index list (first, second, third key index lists). When a tenant requests key manipulation, the operation can be performed on one copy while other tenants continue to access different copies, eliminating bandwidth loss for non-affected tenants and enabling continuous operation.
Data Source
AI summary
The present disclosure generally relates improved key-per IO (KIPO) processing for multiple tenants. Rather than when a tenant requests a key change to stop tenants from working, indirect-double-indexing can be used to prevent bandwidth loss in tenants during adaptions for other tenants. When a tenant requests to manipulate the key-index table, the system will keep working. The current key index list will be duplicated. While the duplicated key-index list is manipulated according to the request, all tenants may still work on their current key-index tables until the request is complete. Once the request is complete, the tenant with the request will switch to the new table, while the old table is updated. Once the old table is updated, the tenant will switch to the updated table for continued work. No tenant, including the tenant that makes the request, continues working as the request is completed.