BLOB Management via File-Database Hybrid Transactions

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current systems fail to effectively manage Binary Large Objects (BLOBs) by not fulfilling the ACID requirements of atomicity, consistency, isolation, and durability, especially when dealing with large data sizes, and lack efficient transaction support for preserving file identity.

Innovation Solution

A system combining a file subsystem and a database subsystem, where a globally unique identifier (GUID) and version index are used to create a bijective relation between file names and BLOB names, enabling database transactions to ensure ACID compliance and preserve file identity through unique and versioned file names.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If standard file systems are used to store BLOBs, then storage capability is provided, but transaction support and ACID requirements are not fulfilled

Engineering Contradiction:

ImproveACID complianceVSAvoidtransaction support

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent merges a file system with a database management system to create a hybrid system that provides both file storage capabilities and database transaction support. The file system component handles BLOB storage while the database component manages transactions, ensuring ACID compliance for operations on large binary objects.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The system combines multiple functions into a single integrated platform: file storage, transaction management, BLOB handling, and database operations. This multi-functional system can handle both traditional file operations and database transactions on large objects, making it versatile for various applications.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Productivity

If standard database systems are used to manage BLOBs, then transaction support is provided, but performance degrades with large data sizes

Engineering Contradiction:

ImproveperformanceVSAvoiddata size

Core Design Contradiction:

ProductivityVSQuantity of substance

Solution Approach 1:

The system segments BLOB data into fixed-size blocks that can be independently managed. This allows the file system to efficiently handle large files by working with smaller blocks, improving performance while maintaining the ability to manage very large data sizes through block-level operations.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent introduces a BLOB store as an intermediary component between the database system and the file system. This mediator handles the actual storage and retrieval of large binary objects, allowing the database to manage transactions without directly handling the performance burden of large data I/O operations.

Inventive Principle:

Principle #24Intermediary (Mediator)

3Reliability

If file names are changed during BLOB modification, then data integrity is maintained, but file identity is lost

Engineering Contradiction:

Improvedata integrityVSAvoidfile identity

Core Design Contradiction:

ReliabilityVSLoss of information

Solution Approach 1:

The system creates a copy of the BLOB data with a new version identifier when modifications are made, rather than overwriting the original. This allows the original file identity to be preserved while maintaining data integrity through versioned copies, enabling backup and restore operations.

Inventive Principle:

Principle #26Copying

Solution Approach 2:

The patent changes parameters such as version identifiers and timestamps when BLOBs are modified, rather than changing the fundamental file identity. This allows the system to track modifications and maintain data integrity while preserving the original file's identity for backup and recovery purposes.

Inventive Principle:

Principle #35Parameter changes

4Reliability

If BLOBs are stored in a file system without transaction support, then storage efficiency is improved, but atomicity and consistency cannot be guaranteed

Engineering Contradiction:

ImproveatomicityVSAvoidsystem architecture

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The system merges file system storage with database transaction management in a single integrated architecture. This combination ensures that operations on BLOBs maintain atomicity and consistency through database transactions while preserving the storage efficiency of the file system.

Inventive Principle:

Principle #5Merging (Combining)

Solution Approach 2:

The BLOB store acts as an intermediary that bridges the file system and database transaction system. It enables atomic operations on large binary objects by coordinating between the file system's storage capabilities and the database's transaction management, ensuring consistency without requiring complex distributed system architecture.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS7890481B2System and method for managing binary large objects

Publication Date: 2011.02.15 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

The invention regards a system (10) and method for managing BLOBs. The system combines a file subsystem (20) and a database subsystem (30), wherein the database subsystem (30) comprises relations between file names of files (40) comprising a BLOB (50) and BLOB names. In the event of modification of a file (40) containing a BLOB (50), a new file, having a new file name, is created, where a relation between the new file name and the BLOB name is created within a database transaction in the database subsystem (30). By thus extending the ACID-properties of database transactions to files, it is ensured that operations on BLOBs in the system (10) meet the ACID-requirements while keeping the efficiency of operations on files.