Redka - Redis का SQLite के साथ पुनर्निर्मित संस्करण

• Redka का लक्ष्य Redis की खूबियों को SQLite के साथ फिर से लागू करना है, ताकि यह Redis API के साथ संगत रहे
• मुख्य विशेषताएँ:
  • डेटा को RAM के आकार में फिट करना जरूरी नहीं
  • ACID transactions का समर्थन
  • SQL views के जरिए डेटा क्वेरी और reporting क्षमता बेहतर
  • In-process (Go API) और Standalone (RESP) server दोनों का समर्थन
  • Redis-संगत commands और protocol का समर्थन
• फिलहाल विकास जारी है, और support status व roadmap के लिए नीचे दिए गए दस्तावेज़ देखें

समर्थित commands

• Redka का लक्ष्य Redis के 5 मुख्य data types — String, List, Set, Hash, Sorted Set — का समर्थन करना है
• String, Hash, Key management, और transaction commands पहले से समर्थित हैं, जबकि List, Set, और Sorted Set विकास में हैं
• विस्तृत command सूची के लिए मूल लेख देखें

इंस्टॉलेशन

Standalone server

• Release page से अपने OS के अनुसार binary file डाउनलोड करके चलाएँ
• Docker का उपयोग करने पर docker pull nalgeon/redka से image डाउनलोड करें

Go module

• go get github.com/nalgeon/redka से module इंस्टॉल करें
• SQLite driver के रूप में github.com/mattn/go-sqlite3 या modernc.org/sqlite का उपयोग करें

उपयोग का तरीका

Standalone server

• डाउनलोड की गई binary file को redka [-h host] [-p port] [db-path] के रूप में चलाएँ
  • डिफ़ॉल्ट मान हैं host localhost, port 6379, और DB path नहीं होने पर (in-memory)
• Docker उपयोग करते समय docker run command से चलाएँ। विस्तृत options के लिए मूल लेख देखें
• server चलने के बाद redis-cli, redis-py, go-redis जैसे Redis-संगत clients से कनेक्ट किया जा सकता है

In-process server

• redka.Open() function से DB object बनाएँ। driver import करना अनिवार्य है
• redka.DB object के methods को कॉल करके विभिन्न commands चलाएँ
• View (read-only) और Update (write-enabled) methods से transaction handling करें

Persistence

• Redka, SQLite database में rkey, rstring, rhash tables का उपयोग करके डेटा स्टोर करता है
• हर data type के लिए views (vstring, vhash आदि) के माध्यम से SQL से डेटा क्वेरी किया जा सकता है

Performance

• redis-benchmark tool से Redis और Redka की performance की तुलना की गई
  • Redka में SET लगभग 6 गुना और GET लगभग 2 गुना धीमा है
  • फिर भी यह लगभग 23K writes/sec और 57K reads/sec स्तर की performance दिखाता है
• container में चलाने पर performance में कमी आ सकती है

Roadmap

• 1.0 release में Redis 2.x दौर की मुख्य सुविधाओं पर केंद्रित implementation की योजना है
  • String, Hash, Key management, transaction support पूरा
  • Sorted Set विकास में
  • List, Set नियोजित
• भविष्य के versions में Stream, HyperLogLog, Geo जैसे data types और Pub/Sub फीचर जोड़ने की योजना है
• Lua scripting, authentication/ACL, multi DB, Watch/Unwatch आदि को लागू करने की योजना नहीं है
• cluster और sentinel फीचर्स भी लागू नहीं किए जाएँगे

GN⁺ की राय

• Redis के साथ बड़े पैमाने पर संगत रहते हुए persistence देने का Redka का तरीका दिलचस्प है। ACID transactions का समर्थन भी इसका एक मजबूत पक्ष लगता है।
• performance के मामले में यह Redis तक नहीं पहुँचता, लेकिन जहाँ persistence ज़रूरी हो वहाँ यह एक व्यवहारिक विकल्प हो सकता है।
• हालांकि यह अभी विकास के शुरुआती चरण में है, इसलिए stability को लेकर थोड़ा और देखना होगा, और roadmap में कई फीचर्स का न होना वास्तविक अपनाने के समय ध्यान देने योग्य है।
• In-memory उपयोग में यह शायद Redis को नहीं हरा पाएगा, लेकिन SQLite-आधारित persistence layer के रूप में यह उपयोगी साबित हो सकता है।
• आजकल edge computing environments में lightweight stack की मांग बढ़ रही है, और ऐसे क्षेत्रों में Redis की जगह Redka आज़माया जा सकता है।

[yangeok]

जब scheduler के साथ redis जोड़ना हो, तब यह काफ़ी काम का रहेगा, हाहा

[GN⁺]

Hacker News राय

• Redis के "सब कुछ एक ही thread में serialized" बिना-concurrency वाले मॉडल का किस हद तक पालन किया जाए, इस पर सोच है
• SQLite की low-level library का उपयोग करके, WAL को enable करके, हर read-only goroutine के लिए connection इस्तेमाल करके, और dedicated writer thread को buffered channel/queue के ज़रिए write batches भेजकर SQLite में बेहतर performance मिल सकती है
• इससे SQLite के built-in per-connection mutexes को बंद करने के बाद भी thread safety बनी रह सकती है, क्योंकि हर connection एक समय में केवल एक ही thread में इस्तेमाल होगा
• network request/socket से आने वाले parameter bytes को buffer में copy करना, या SQLite से सीधे socket में copy करना जैसी arena-style large buffers का उपयोग करने से individual string allocation और passing कम हो सकती है, जिससे काफी समय बचता है
• ये Go में SQLite से maximum write throughput निकालने की कोशिश के अनुभव से निकले हुए टिप्स हैं
• Redis और SQLite दोनों पसंद हैं, इसलिए दोनों को मिलाने का फैसला किया गया। SQLite बहुत सारे छोटे queries के लिए optimized है, इसलिए relational engine Redis के जितना करीब आ सकता है, उतना आ चुका है और इसलिए यह अच्छा fit लगता है
• TigerBeetle के state machine को replace करके Redis API implement करने वाले किसी व्यक्ति का इंतज़ार है
• ऐसा Redis alternative अच्छा होगा जिसमें यह सोचने की ज़रूरत न पड़े कि data set memory में fit होता है या नहीं
• Redis की पूरी value proposition यही है कि वह memory में काम करता है और memory जैसी performance देता है। अगर disk पर जाना है, तो Redis इस्तेमाल करने की वजह लगभग नहीं बचती
• network I/O जुड़ने पर Redis की शानदार performance का बड़ा हिस्सा गायब हो जाता है। SaaS hosted Redis service इस्तेमाल करने पर performance को बड़ा झटका लगता है। अगर अपने cluster में Redis-compatible key/value store को अधिक आसानी से चलाया जा सके, तो यह एक फ़ायदा है
• यह या Garnet, इनमें से कौन Redis commands ज़्यादा support करता है, यह जानने की जिज्ञासा है। local debugging के लिए किसी program में Redis-compatible features का एक subset embed करना चाहता हूँ, और बीच में एक API है जिससे unsupported Redis commands के खिलाफ सुरक्षा की जा सकती है
• जब Foursquare ने MongoDB को मशहूर बनाया था, तब किसी ने MySQL में implement किए गए NoSQL DB का एक PoC पोस्ट किया था, लेकिन वह लोकप्रिय नहीं हुआ। फिर भी इससे यह सोचने पर मजबूर होना पड़ता है कि हर बार DB की ज़रूरत होने पर SQL को फिर से invent न करना पड़े, इसके लिए हमने कितनी performance sacrifice की। ऐसे experiments पसंद हैं और कभी-कभी ये नए projects तक ले जाते हैं
• Redis को DB के आगे cache layer की तरह इस्तेमाल करता हूँ। यह concept समझ में नहीं आता
• लेकिन SetMaxConnections(1) इस्तेमाल किया जा रहा है, जबकि WAL mode (जो उपयोग में है) में SQLite ऐसे writes support करता है जो reads को block नहीं करते, इसलिए read concurrency की अनुमति देने में फ़ायदा हो सकता है