मोबाइल डेवलपमेंट में SQLite: यह क्या है और कैसे काम करता है

SQLite क्या है?

SQLite C भाषा में लिखी एक लाइब्रेरी है जो बिना समर्पित सर्वर के रिलेशनल DBMS को लागू करती है। यह सीधे एप्लिकेशन में एम्बेड होती है, डिवाइस के फ़ाइल सिस्टम पर एक सामान्य फ़ाइल में डेटा पढ़ती और लिखती है। लाइब्रेरी का आकार लगभग 600 KB है, जो SQLite को सबसे हल्का पूर्ण-विशेषताओं वाला SQL डेटाबेस बनाता है।

SQLite SQL:1999 मानक के अधिकांश भाग का समर्थन करता है, जिसमें JOIN, उप-क्वेरी, ट्रिगर, व्यू, इंडेक्स और विंडो फ़ंक्शन शामिल हैं। सीमाएँ ALTER TABLE (सीमित समर्थन) और पूर्ण RIGHT/FULL OUTER JOIN से संबंधित हैं। फिर भी, मोबाइल एप्लिकेशन के लिए, SQLite की कार्यक्षमता 99% स्थानीय भंडारण मामलों में पर्याप्त है।

Stack Overflow डेवलपर सर्वेक्षण (2025) के अनुसार, SQLite एम्बेडेड समाधानों के लिए सबसे लोकप्रिय डेटाबेस है और MySQL और PostgreSQL के बाद सभी DBMS में लोकप्रियता में तीसरे स्थान पर है। मोबाइल डेवलपमेंट में, SQLite का उपयोग हर एप्लिकेशन में किया जाता है — सीधे या रैपर के माध्यम से।

SQLite की प्रमुख विशेषताएँ

शून्य कॉन्फ़िगरेशन — SQLite को इंस्टॉलेशन, अनुमति सेटअप, उपयोगकर्ता निर्माण या सेवा शुरू करने की आवश्यकता नहीं है। लाइब्रेरी प्रोजेक्ट से लिंक होती है, और डेटाबेस एक फ़ंक्शन को कॉल करके बनाया जाता है। यह क्लाइंट-सर्वर DBMS की तुलना में डिप्लॉयमेंट को मौलिक रूप से सरल बनाता है, जिसमें सर्वर इंस्टॉलेशन, पोर्ट कॉन्फ़िगरेशन और उपयोगकर्ता सेटअप की आवश्यकता होती है।

SQLite डेटाबेस फ़ाइल एक सामान्य क्रॉस-प्लेटफ़ॉर्म फ़ाइल है जिसे कॉपी, विश्लेषण, नेटवर्क पर भेजा या बैकअप से पुनर्स्थापित किया जा सकता है। फ़ाइल प्रारूप API स्तर पर स्थिर है: 2004 में बनाई गई SQLite 3 फ़ाइलें लाइब्रेरी के वर्तमान संस्करण से खुलती हैं, जो दीर्घकालिक डेटा संगतता सुनिश्चित करता है।

SQLite कैसे काम करता है: आर्किटेक्चर और भंडारण

SQLite की आर्किटेक्चर में आठ वर्चुअल मशीनें शामिल हैं: Tokenizer, Parser, Code Generator, VM, B-Tree, Pager, OS Interface और Utilities। SQL क्वेरी Tokenizer (टोकन में विभाजन), Parser (AST निर्माण), Code Generator (बाइटकोड में रूपांतरण) से गुज़रती है और वर्चुअल मशीन पर निष्पादित होती है, जो B-Tree और Pager के माध्यम से डेटा पेज पढ़ती है।

SQLite तालिकाओं और इंडेक्स को संग्रहीत करने के लिए B-Tree का उपयोग करता है। प्रत्येक तालिका एक अलग B-Tree के रूप में संग्रहीत होती है, जहाँ लीफ नोड्स में डेटा पंक्तियाँ होती हैं। इंडेक्स भी B-Tree के रूप में संग्रहीत होते हैं लेकिन लीव्स में कुंजियों के साथ। Pager फ़ाइल से मेमोरी में पेज (डिफ़ॉल्ट 4096 बाइट) लोड करने का प्रबंधन करता है, जो जर्नल या WAL के माध्यम से ACID ट्रांज़ैक्शन प्रदान करता है।

जर्नलिंग मोड

WAL (Write-Ahead Logging) मोबाइल एप्लिकेशन के लिए अनुशंसित मोड है। परिवर्तन पहले एक अलग WAL फ़ाइल में लिखे जाते हैं और फिर समय-समय पर मुख्य डेटाबेस में स्थानांतरित किए जाते हैं। WAL डेटाबेस से एक साथ पढ़ने (पुराना डेटा) और लिखने (WAL के माध्यम से) की अनुमति देता है, जो मल्टीथ्रेडेड एप्लिकेशन के प्रदर्शन में सुधार करता है। मानक जर्नल (रोलबैक जर्नल) लेखन के दौरान पढ़ने को अवरुद्ध करता है।

मोड के बीच स्विचिंग एक SQL क्वेरी से की जाती है: PRAGMA journal_mode=WAL. बैकग्राउंड सिंक्रोनाइज़ेशन और एक साथ डेटा पढ़ने वाले UI थ्रेड वाले मोबाइल एप्लिकेशन के लिए, WAL बेहतर प्रदर्शन और इंटरफ़ेस लॉकअप की अनुपस्थिति सुनिश्चित करता है।

मोबाइल डेवलपमेंट में SQLite बनाम अन्य डेटाबेस

SQLite स्थानीय डेटा भंडारण का एकमात्र विकल्प नहीं है, लेकिन सबसे बहुमुखी है। Realm मेमोरी में ऑब्जेक्ट तक सीधी पहुँच की उच्च गति प्रदान करता है लेकिन अपने स्वयं के NoSQL प्रारूप का उपयोग करता है और इसका लाइब्रेरी आकार बड़ा है। iOS पर Core Data SQLite के ऊपर एक ORM परत है जो ऑब्जेक्ट ग्राफ़ प्रबंधन और ऑपरेशन पूर्ववत जोड़ती है।

अधिकांश एप्लिकेशन के लिए, SQLite पूर्वानुमानित प्रदर्शन, शून्य वेंडर लॉक-इन और समय-परीक्षित स्थिरता के कारण इष्टतम विकल्प बना हुआ है। Realm और Core Data जटिल ऑब्जेक्ट ग्राफ़, रिएक्टिव क्वेरी या क्रॉस-डिवाइस सिंक्रोनाइज़ेशन आवश्यकताओं वाले प्रोजेक्ट में उचित हैं।

SQLite, Realm और Core Data के बीच चुनाव प्लेटफ़ॉर्म, ऑब्जेक्ट मॉडल आवश्यकताओं और सिंक्रोनाइज़ेशन रणनीति पर निर्भर करता है। क्रॉस-प्लेटफ़ॉर्म प्रोजेक्ट (KMP, Flutter) के लिए, SQLite एकमात्र सार्वभौमिक विकल्प बना हुआ है जो डेटा मॉडल में बदलाव किए बिना सभी लक्ष्य प्लेटफ़ॉर्म पर काम करता है।

Android पर SQLite: Room और SQLiteOpenHelper

Room Android Jetpack की एक लाइब्रेरी है जो SQLite के ऊपर ORM परत प्रदान करती है। Room एनोटेटेड DAO इंटरफ़ेस से स्वचालित रूप से SQL क्वेरी उत्पन्न करता है, संकलन समय पर क्वेरी शुद्धता को मान्य करता है, और स्कीमा बदलने पर डेटाबेस माइग्रेशन का समर्थन करता है। Android पर SQLite के साथ काम करने का अनुशंसित तरीका Room है।

SQLiteOpenHelper ORM के बिना सीधे SQLite प्रबंधन के लिए निम्न-स्तरीय API है। क्लास डेटाबेस निर्माण, खोलने और अपग्रेड करने का प्रबंधन करता है। SQLiteOpenHelper सरल SQL क्वेरी वाले प्रोजेक्ट या जब Room एब्स्ट्रैक्शन के बिना SQL लॉजिक पर पूर्ण नियंत्रण की आवश्यकता हो, के लिए उपयुक्त है।

Room के लिए एंटिटी और DAO का उदाहरण

Room में एक एंटिटी को @Entity से और DAO को @Dao से एनोटेट किया जाता है। Room एनोटेटेड विधियों को SQL क्वेरी में अनुवादित करता है: @Insert INSERT उत्पन्न करता है, @Query निर्दिष्ट SQL के साथ SELECT उत्पन्न करता है। माइग्रेशन को Migration वर्गों के माध्यम से पुराने और नए स्कीमा संस्करण निर्दिष्ट करके जोड़ा जाता है। Room संकलन समय पर SQL को मान्य करता है, जिससे उत्पादन में सिंटैक्स त्रुटियाँ समाप्त होती हैं।

@Entity
data class User(
    @PrimaryKey val id: Long,
    val name: String,
    @ColumnInfo(name = "created_at")
    val createdAt: Long
)

@Dao
interface UserDao {
    @Query("SELECT * FROM user ORDER BY name ASC")
    suspend fun getAllUsers(): List<User>

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insertUser(user: User)

    @Query("DELETE FROM user WHERE id = :id")
    suspend fun deleteUser(id: Long)
}

Room स्वचालित रूप से UserDao_Impl कार्यान्वयन उत्पन्न करता है, जिसमें आंतरिक RoomDatabase के माध्यमից रनटाइम SQLite क्वेरी शामिल हैं। कोरूटीन (suspend) के कारण, DAO विधियाँ बैकग्राउंड थ्रेड पर एसिंक्रोनस रूप से निष्पादित होती हैं, UI को ब्लॉक किए बिना। @Query में Flow रिटर्न प्रकार तालिका बदलने पर स्वचालित रूप से परिणाम अपडेट करते हैं।

iOS पर SQLite: FMDB और GRDB

FMDB SQLite C API पर एक Objective-C रैपर है, ऐतिहासिक रूप से iOS के लिए पहली लोकप्रिय लाइब्रेरी। यह क्वेरी निष्पादित करने और परिणाम प्राप्त करने के लिए FMDatabase और FMResultSet ऑब्जेक्ट प्रदान करता है। FMDB सरल और न्यूनतम है, लेकिन Swift-विशिष्ट निर्माणों — ऑप्शनल, Codable, async/await का समर्थन नहीं करता है।

GRDB SQLite के साथ काम करने के लिए एक आधुनिक Swift लाइब्रेरी है। यह type-safe API, Codable समर्थन, Combine Publishers, async/await, माइग्रेशन और रीयल-टाइम परिवर्तन अवलोकन प्रदान करता है। GRDB Swift Concurrency के साथ पूर्ण एकीकरण और बेहतर कोड पठनीयता के कारण नए Swift प्रोजेक्ट के लिए पसंद किया जाता है।

Swift में GRDB उदाहरण

GRDB FetchableRecord और TableRecord प्रोटोकॉल का अनुपालन करने वाले Record वर्गों के माध्यम से तालिकाओं को परिभाषित करता है। क्वेरी raw SQL के बजाय type-safe सिंटैक्स के साथ Swift में लिखी जाती हैं। GRDB स्कीमा वर्जनिंग और ऐप संस्करणों के बीच माइग्रेशन के लिए DatabaseMigrator का भी समर्थन करता है।

struct User: Codable, FetchableRecord, TableRecord {
    var id: Int64
    var name: String
    var createdAt: Date
}

let dbPool = try DatabasePool(path: dbPath)
var migrator = DatabaseMigrator()
migrator.registerMigration("v1") { db in
    try db.create(table: "user") { t in
        t.autoIncrementedPrimaryKey("id")
        t.column("name", .text).notNull()
        t.column("createdAt", .datetime).notNull()
    }
}

let users = try await dbPool.read { db in
    try User.order(Column("name")).fetchAll(db)
}

DatabasePool समवर्ती पढ़ने के लिए SQLite के WAL मोड का उपयोग करता है। कई पाठक एक साथ डेटाबेस तक पहुँच सकते हैं जबकि एक एकल लेखक WAL के माध्यम से डेटा अपडेट करता है। GRDB स्वचालित रूप से कनेक्शन और ट्रांज़ैक्शन का प्रबंधन करता है, बिना मैन्युअल सिंक्रोनाइज़ेशन के किसी भी थ्रेड से थ्रेड-सुरक्षित डेटाबेस एक्सेस प्रदान करता है।

SQLite प्रदर्शन अनुकूलन

इंडेक्स SQLite क्वेरी को गति देने का सबसे प्रभावी तरीका है। WHERE, JOIN और ORDER BY में उपयोग किए जाने वाले कॉलम पर इंडेक्स बनाया जाता है। 100000 रिकॉर्ड वाली तालिका के लिए, इंडेक्स किए गए कॉलम पर खोज सेकंड के बजाय मिलीसेकंड में होती है। हालाँकि, इंडेक्स INSERT और UPDATE को धीमा करते हैं, इसलिए उनकी संख्या लेखन आवृत्ति के साथ संतुलित होनी चाहिए।

एक ही ट्रांज़ैक्शन के भीतर बैच इन्सर्ट सामूहिक डेटा लोडिंग को मौलिक रूप से गति देता है। एक-एक करके 1000 रिकॉर्ड डालने में ~1 सेकंड का ओवरहेड होता है। एक ही ट्रांज़ैक्शन में वही 1000 रिकॉर्ड ~5-10 मिलीसेकंड लेता है। अंतर इस प्रकार समझाया गया है कि प्रत्येक व्यक्तिगत INSERT सिंक्रोनस डिस्क लेखन के साथ एक नया ट्रांज़ैक्शन बनाता है।

प्रदर्शन PRAGMA

PRAGMA लाइब्रेरी व्यवहार को कॉन्फ़िगर करने के लिए SQLite कमांड हैं। प्रमुख ऑप्टिमाइज़ेशन प्राग्मा: PRAGMA synchronous=NORMAL (fsync आवृत्ति कम करता है), PRAGMA cache_size=-8000 (8 MB कैश आवंटित करता है), PRAGMA temp_store=MEMORY (मेमोरी में अस्थायी तालिकाएँ)। बड़े डेटा वॉल्यूम वाले मोबाइल एप्लिकेशन के लिए, इन प्राग्मा के संयोजन से क्वेरी 2-3 गुना तेज़ हो जाती हैं।

एक और महत्वपूर्ण अनुकूलन SQL क्वेरी का प्री-कंपाइलेशन (prepared statements) है। यदि कोई क्वेरी बार-बार निष्पादित की जाती है (उदाहरण के लिए, 10000 पंक्तियाँ डालना), तो SQL को एक बार कंपाइल करना और फिर स्टेटमेंट का पुन: उपयोग करना CPU लोड को 30-50% कम करता है। Room और GRDB स्वचालित रूप से prepared statements को कैश करते हैं, लेकिन SQLite C API का सीधे उपयोग करते समय, कंपाइलेशन मैन्युअल रूप से किया जाना चाहिए।

class UserRepository(private val db: RoomDatabase) {

    suspend fun insertBatch(users: List<User>) {
        db.withTransaction {
            users.chunked(500).forEach { batch ->
                batch.forEach { user ->
                    insertUser(user)
                }
            }
        }
    }
}

withTransaction के साथ बैच इन्सर्ट सुनिश्चित करता है कि सभी INSERT ऑपरेशन एक ही ट्रांज़ैक्शन के भीतर निष्पादित हों। चंकिंग (chunked) उप-बैचों में एक ट्रांज़ैक्शन को बहुत बड़ा होने से रोकता है, जो अन्य थ्रेड को लंबे समय तक ब्लॉक कर सकता है। बैकग्राउंड सिंक्रोनाइज़ेशन के लिए, 500 रिकॉर्ड का उप-बैच आकार गति और UI प्रतिक्रिया का इष्टतम संतुलन प्रदान करता है।