Actionbase – लाइक, हाल ही में देखा गया, और फॉलो के लिए डेटाबेस
(github.com/kakao)लाइक, हाल ही में देखे गए प्रोडक्ट, और फॉलो फीचर के लिए डेटाबेस Actionbase को हमने open source के रूप में जारी किया है।
नमस्ते, मैं Kakao में Actionbase को साथ मिलकर बना रहा एक डेवलपर हूँ।
कल शाम 8 बजे (27 तारीख) हमने Hacker News(Show HN) पर Actionbase पोस्ट किया, और पोस्ट होने के लगभग 1 घंटा 30 मिनट के भीतर यह पहले पेज पर नंबर 1 पर पहुँच गया। सच कहें तो हमारा लक्ष्य सिर्फ पहले पेज पर टिके रहना था, लेकिन उम्मीद से बेहतर प्रतिक्रिया मिली।
इसे क्यों बनाया?
लाइक, हाल ही में देखे गए प्रोडक्ट, और फॉलो जैसे फीचर हर service में थोड़े अलग दिखते हैं, लेकिन इनके लिए मिलती-जुलती data structure और processing pattern बार-बार बनाने पड़ते हैं।
समस्या यह थी कि हर टीम forward/reverse list, count, और index को थोड़ा-थोड़ा अलग तरीके से implement करती थी। retry और event order handling का तरीका भी सबका अलग था, इसलिए कई बार data में हल्का-सा mismatch हो जाता था, और likes count जैसे aggregate data बनाने के तरीके भी अलग-अलग होने से operations मुश्किल हो जाते थे।
यह कैसे काम करता है?
Actionbase इसे किसने(actor) किस पर(target) क्या किया(action) के relationship model के रूप में परिभाषित करता है, और write के समय सब कुछ पहले से compute कर देता है। read सिर्फ साधारण lookup होता है, इसलिए तेज और predictable रहता है।
प्रोडक्शन में उपयोग
पहला production उपयोग KakaoTalk Gifting Wish में हुआ था। उस समय इसमें बहुत-सी कमियाँ थीं, लेकिन उस उम्मीद पर खरा उतरने के लिए हमने बहुत कुछ सुधारा, और वही अनुभव इस प्रोजेक्ट की growth का बड़ा कारण बना।
फिलहाल यह कई Kakao services में प्रति मिनट 10 लाख से अधिक requests को कई वर्षों से संभाल रहा है। storage HBase आधारित है, और अलग-अलग scale के लिए lightweight storage (SlateDB आधारित) भी तैयार किया जा रहा है।
शुरू करें
इसे Docker से तुरंत चलाकर देख सकते हैं:
docker run -it ghcr.io/kakao/actionbase:standalone
- 📦 GitHub: https://github.com/kakao/actionbase
- 🚀 क्विक स्टार्ट: https://actionbase.io/quick-start/
सवाल, feedback, और star—सबका हम स्वागत करेंगे।
@em3s, @zipdoki, @eazyhozy की ओर से
Q&A
Q: क्या यह Redis से भी नहीं हो सकता?
हो सकता है। हम भी hot data के लिए Redis को cache की तरह इस्तेमाल करते हैं। लेकिन scale बढ़ने पर टीमों द्वारा duplicate implementation होने लगी, और event order बिगड़ने से data गलत होने की समस्या भी आई।
Q: PostgreSQL/MySQL sharding कर लें तो नहीं चलेगा?
बहुत-सी टीमें ऐसा ही करती हैं। हमें जिन समस्याओं का सामना करना पड़ा, वे थीं hot entity, cross-shard query, और हर service की अलग cache strategy। हमें ऐसा model चाहिए था जो हर बार sharding strategy design किए बिना horizontal scale कर सके।
Q: Write-time precompute कैसे काम करता है?
write के समय WAL record → lock → state transition → count/index calculation → save → CDC publish. read में सिर्फ एक GET या SCAN करना होता है।
Q: अगर event order गड़बड़ा जाए तो?
हर mutation के साथ एक version (आमतौर पर timestamp) जोड़ा जाता है। अगर event like(t=100) → like(t=300) → unlike(t=200) के क्रम में पहुँचें, तब भी version के आधार पर final state सही रूप से converge करती है। लक्ष्य यह है कि वही event replay करने पर भी state उसी नतीजे पर converge करे।
Q: वास्तविक performance कैसी है?
KakaoTalk Gifting के production में यह लगातार प्रति मिनट 10 लाख से अधिक, और peak पर लगभग 20 लाख requests संभाल रहा है। read latency p50 लगभग 2~3ms, p99 लगभग 10ms है। यहाँ मुख्य बात absolute number से ज़्यादा यह है कि latency bounded रहती है। क्योंकि read aggregation नहीं बल्कि precomputed lookup है, इसलिए data बढ़ने पर भी performance degrade नहीं होती।
Q: यह किन use cases के लिए उपयुक्त है?
लाइक/reaction, follow/follower, और हाल ही में देखे गए प्रोडक्ट इसके मुख्य use case हैं। recommendation/ML feature के लिए CDC के जरिए training data दिया जा सकता है, लेकिन यह recommendation को सीधे serve करने के लिए नहीं है। chat message के लिए शायद यह सबसे अच्छा विकल्प नहीं है—क्योंकि वहाँ pagination, search, और threading जैसे अलग access pattern चाहिए होते हैं। e-commerce cart में transaction की जरूरत होती है, लेकिन Actionbase cross-edge transaction को support नहीं करता।
Q: क्या यह overengineering नहीं है? / क्या इसकी जरूरत सिर्फ बड़ी कंपनियों को होती है?
हो सकता है। ईमानदारी से कहें तो छोटे scale पर अच्छी तरह tuned PostgreSQL + Redis ही सही जवाब है। जिन समस्याओं को Actionbase हल करता है—sharding complexity, cache invalidation, और टीमों के बीच duplicate काम—वे तब सामने आती हैं जब scale काफी बड़ा हो जाए या कई टीमें एक जैसे फीचर बना रही हों। हमने उस दीवार से कई बार टकराने के बाद इसे बनाया। इसलिए छोटे deployment में भी इस्तेमाल हो सके, इसके लिए lightweight backend (SlateDB) भी तैयार किया जा रहा है।
24 टिप्पणियां
ओह... मैं lightweight backend वर्ज़न का भी इंतज़ार करूँगा/करूँगी!!
धन्यवाद! हल्के backend के लिए मैंने SlateDB-आधारित दिशा तय कर रखी है, जिसमें सिर्फ S3 होना काफी है, लेकिन अभी तक इसे गंभीरता से शुरू नहीं कर पाया हूँ.
क्या आप इसे किस तरह के environment में इस्तेमाल करने की सोच रहे हैं, यह जानना चाहूँगा. साइड प्रोजेक्ट? छोटा production? प्राथमिकताएँ तय करने में संदर्भ के तौर पर मदद मिलेगी.
समय मिले तो HBase/SlateDB वोटिंग में भी कृपया हिस्सा लें. दिशा तय करने में community की राय मददगार होगी: https://github.com/kakao/actionbase/discussions/144
मुझे लगता है कि यह एक बेहद व्यावहारिक प्रोजेक्ट है।
बहुत शानदार!
धन्यवाद! Show HN में जो ध्यान नहीं मिल पाया, उसकी कमी मैं यहाँ पूरी कर रहा हूँ।
वैसे, यह जानने की जिज्ञासा है कि आपको इसका कौन-सा हिस्सा व्यावहारिक लगा। क्या आपने ऐसा मिलता-जुलता समस्या अनुभव की है? या आप ऐसी functionality लागू करने की स्थिति में हैं?
और, चूँकि टिप्पणी करने का मौका मिला है, एक बात कहना चाहता था। दस्तावेज़ में हमने लिखा है कि unbounded traversal नहीं करते, लेकिन bounded multi-hop इस साल की योजना में है। जैसे "दोस्त द्वारा पसंद किए गए प्रोडक्ट" जैसी 2-hop query। https://actionbase.io/ko/stories/unified-graph/
मुझे जो बात व्यावहारिक लगी, वह यह थी कि
मैंने भी इसी तरह की चिंता पहले की है, और Redis जैसे KV store के आधार पर code level पर abstraction layer लागू करने का अनुभव भी रहा है, इसलिए मुझे लगा कि दस्तावेज़ जिस लक्ष्य और दिशा की बात करना चाहता है, साथ ही उसकी पूरी संरचना भी, सब बहुत व्यावहारिक हैं।
और यह भी बहुत शानदार लगा कि कई टीमों की ज़रूरतों और चिंताओं को समेटकर कंपनी का एक internal product बनाया गया और उसे open source के रूप में जारी किया गया। हाहा
आखिर में, अगर ज़रा और जोड़ूँ, तो जो लोग इसे इस्तेमाल करेंगे उनके लिए अभी का दस्तावेज़ भी काफ़ी है, लेकिन अगर ऐसे deployment examples हों जिन्हें copy-paste स्तर पर follow किया जा सके, और recommended use cases या infra references को example के रूप में शामिल किया जाए, तो यह और भी आकर्षक लगेगा।
फ़ाइटिंग!
अरे, आपने भी ऐसा ही विचार किया है, यह जानकर सच में बहुत खुशी हुई। और इसे शानदार कहा, उसके लिए दिल से धन्यवाद।
आपने जो बात कही, उससे मैं सहमत हूँ। मैं भी चाहता हूँ कि जिन हिस्सों को टूल की तरह इस्तेमाल करना है, उन्हें आसानी से सेटअप कर सकूँ और उन समस्याओं पर ध्यान दूँ जिन्हें मुझे वास्तव में हल करना है।
हालाँकि, अभी यह open source का शुरुआती चरण है, और सीमित समय में इस core value को कैसे पहुँचाया जाए, फिलहाल हमारा फोकस उसी पर था। अगर यह ठीक से पहुँच ही न पाए, तो वे लोग भी वास्तविक समस्याएँ हल नहीं कर पाएँगे जो ऐसा कर सकते थे। अब हम उसी दिशा में आगे बढ़ने की कोशिश कर रहे हैं। लेकिन, internal stack HBase + Kafka के साथ जाना बेहतर होगा, या फिर अतिरिक्त नए development effort के बावजूद SlateDB + S2 के साथ जाना चाहिए, इस पर हम feedback लेना चाहते हैं। हमारी तरफ़ से HBase engineers इसे ऑपरेट कर रहे हैं, इसलिए हम इसे आराम से इस्तेमाल कर पा रहे हैं, लेकिन बहुत-सी जगहों पर ऐसा नहीं होगा। कृपया अपनी राय ज़रूर दें (सिर्फ़ voting ही सही):
https://github.com/kakao/actionbase/discussions/144
मुझे लगता है कि आपने जिस 2-hop query जैसी roadmap की बात की, वह भी बहुत आकर्षक है।
लेकिन मेरा मानना है कि अगर मौजूदा docs में कहना चाही गई बात को code जैसे examples के साथ अच्छी तरह पिरोया जाए, तो प्रतिक्रिया कहीं ज़्यादा विस्फोटक होगी।
सहमत हूँ। "उदाहरणों में अच्छे से पिरोकर समझाना"। लेकिन यह जितना दिखता है, उतना आसान नहीं है... मैं इस पर कई पहलुओं से सोचकर देखूँगा। धन्यवाद!
क्या आपने हमारे सहयोगी द्वारा मेहनत से तैयार की गई यह इंटरैक्टिव गाइड देखी है: https://actionbase.io/guides/build-your-social-media-app/ । यह उसी तरह की एक कोशिश थी। इससे मुझे फिर से सोचने का मौका मिला कि क्या यह आपके बताए दिशा-निर्देश के अनुरूप है। हम लगातार कोशिश करते रहेंगे.
अरे, और एक बात जो नया कमेंट जोड़ते समय मेरी नज़र से छूट गई थी: सिर्फ गाइड ही नहीं, कुल मिलाकर दस्तावेज़ों की संरचना में भी काफ़ी मेहनत महसूस होती है।
हालाँकि, जैसा मैंने पहले कहा था, अगर उदाहरण के लिए तैयार की गई कॉन्फ़िगरेशन को
git cloneके ज़रिए आसानी से फ़ॉलो किया जा सके, तो यह और भी बेहतर होगा।मैं नीचे की टिप्पणी में साथ ही जवाब दूँगा।
मुझे लगा था कि मैंने इस पर कमेंट किया था, लेकिन दिखा नहीं, इसलिए शुरुआत से फिर लिख रहा हूँ...(हाय)
हल्के मन से किए गए मेरे कमेंट के मुकाबले आपने इतने मन से जवाब दिया, उसके लिए धन्यवाद.. हाहा;;
खैर, मैं जो कहना चाहता था वह यह है कि जो छोटी टीम या बड़ी टीम इसे अपनाना चाहती है, उनके माहौल काफ़ी अलग-अलग होंगे। और जब कोई हल्के मन से सोचे कि इसे एक बार अपनाकर देखें?, तब सबसे आसानी से समझाने वाला रूप शायद उस भाषा में लिखा हुआ example project होगा जिसे टीम इस्तेमाल करती है।
अगर पहले major भाषाओं में example project बनाए जाएँ और उनके आधार पर quick start तैयार किया जाए, तो लोग इसे कहीं ज़्यादा सहजता से पढ़ पाएँगे। और
git cloneकरके झटपट आज़माकर देख लेना ही इसकी असली आकर्षक बात है, मेरा ऐसा मानना है।और मुझे यह भी लगता है कि best practice समझाने के लिए भी यही तरीका सबसे अच्छा है।
बेशक, मुझे पता है कि प्रोजेक्ट की प्रकृति के कारण ऐसा करना आसान नहीं होगा, लेकिन फिर भी मुझे लगता है कि वही सबसे आकर्षक तरीका है।
साथ ही, अगर संभव हो तो pulumi या terraform जैसे टूल्स के साथ example तैयार किया जाए, तो और भी अच्छा होगा।
यह बिल्कुल अप्रत्याशित दृष्टिकोण है। ऐसे सुझाव के लिए सच में बहुत धन्यवाद। समुदाय से मिल सकने वाला यह एक बहुत अच्छा अनुभव है.
आपने जो दिशा बताई है, उसे कैसे लागू किया जाए इस पर मैं विचार करूँगा। pulumi या terraform उदाहरणों पर भी। शायद हम दिशा को व्यवस्थित करके समुदाय से समर्थन का अनुरोध भी कर सकते हैं। उस समय यदि आप योगदान दें, तो उसके लिए मैं और भी आभारी रहूँगा।
इसके अलावा, मैं यह भी सोच रहा हूँ कि vibe coding के दौर में यह उसकी बुनियाद कैसे बन सकता है। जब आप कहते हैं, "ऐप्लिकेशन बना दो", तो वह React, Svelte आदि में लिख देता है। ठीक उसी तरह की स्थिति। जब कहा जाए, "like फीचर जोड़ दो", तब Actionbase वह भूमिका निभाए — मेरा मतलब वही है।
यह हिस्सा भी लगातार मेरे दिमाग में घूम रहा है। इसलिए मैंने documentation पर बहुत ध्यान दिया है ताकि AI tools इसे पढ़ सकें, और हाल में मैं इसकी संभावनाएँ भी देख रहा हूँ।
संदर्भ:
llms.txt - https://actionbase.io/llms-txt/
Anthropic hackathon विजेता recipe प्रयास - https://github.com/kakao/actionbase/discussions/90
मुझे लगता है कि समान use case वाले स्थानों पर इसका अच्छा उपयोग हो सकता है। इसे सार्वजनिक करने के लिए धन्यवाद!
हालाँकि, ingestion में Lock इस्तेमाल करने वाले हिस्से में कोई समस्या नहीं आई थी क्या, यह जानने की जिज्ञासा है। डेटा write के मामले में ट्रैफ़िक लगभग कितना था? Lock contention आदि की वजह से कोई समस्या हुई थी क्या, यह भी जानना चाहता हूँ।
बहुमूल्य सवाल के लिए धन्यवाद!
Lock edge (source, target) pair यूनिट पर लिया जाता है (उदाहरण: Alice→Phone). केवल उसी edge पर एक साथ write होने पर ही contention होता है, और वास्तविकता में एक ही user का एक ही target पर एक साथ like दबाना बहुत दुर्लभ होता है, इसलिए contention कम रहता है। यही हमारे database use case की विशेषता है।
Write ट्रैफ़िक peak के आधार पर प्रति मिनट कई लाख requests के स्तर का है। Read 1 million+ है और write उससे कम हैं।
बेंचमार्क देखें (read 85%, write 15%) - https://actionbase.io/ko/operations/benchmarks/
Hot entity (लोकप्रिय product आदि) में lock contention हो सकता है, और इसका कारण count update है (HBase Increment). इस हिस्से को हम अलग से optimize करके संभाल रहे हैं। High-frequency write से संबंधित: https://actionbase.io/ko/stories/kakaotalk-gift-recent-views/
ओ.....
धन्यवाद! अगर आपकी रुचि हो, तो कृपया आगे की दिशा के बारे में अपनी राय भी यहाँ साझा करें: https://github.com/kakao/actionbase/discussions/144
वाह, यह बहुत उपयोगी लग रहा है।
धन्यवाद! क्या आपको भी ऐसी मिलती-जुलती functionality लागू करते समय कोई समस्या हुई थी? हम इस पर community की राय ले रहे हैं कि हमें अगला काम किसे प्राथमिकता देनी चाहिए: https://github.com/kakao/actionbase/discussions/144
डेवलपर documentation वाकई बहुत अच्छी तरह से लिखी गई है। stories के ज़रिए दिखाए गए use case, quick start, और FAQ इतने समृद्ध थे कि वे किसी technical blog के स्तर के लगे।
वाह, आपका बहुत-बहुत धन्यवाद। 5 जनवरी को open source रिलीज़ के बाद 27 तारीख को community रिलीज़ तक, हमने documentation पर काफ़ी मेहनत की थी, इसलिए आपने उसे पहचाना यह देखकर खुशी हुई।
यह open source का शुरुआती चरण है, इसलिए हमने "यह क्या है, और इसकी ज़रूरत क्यों है" पर फोकस किया, और शायद इसी वजह से ऐसा नतीजा निकला। documentation देखते समय अगर कोई कमी लगे तो बेझिझक बताइए!
संदर्भ के लिए, अगर आप https://actionbase.io/llms-txt/ का उपयोग करें, तो आपको ऐसे नतीजे मिल सकते हैं जिनकी आपने उम्मीद नहीं की हो। हाल ही में मैंने देखा कि Actionbase को अच्छी तरह न जानने वाला कोई व्यक्ति इस prompt की मदद से जटिल ज़रूरतों के लिए सबसे उपयुक्त निष्कर्ष तक पहुँच गया, और तब फिर से महसूस हुआ कि दुनिया सच में बदल गई है।
ChatGPT, Claude, Gemini आदि में नीचे दिया गया इस्तेमाल करके देखें।
शक होना स्वाभाविक है। लेकिन यह बनावटी नहीं है。
मैंने पहले कमेंट में 4 लिंक डाल दिए थे, तो 30 मिनट के लिए shadowban हो गया। उस दौरान संदर्भ समझाने वाली बात दिख ही नहीं रही थी, इसलिए लोग बस आगे बढ़ गए। उस समय मैं सच में घबरा गया था। लगा कि बात दबकर रह जाएगी। लिंक हटाकर फिर से कमेंट किया, तब जाकर वह 1वें स्थान पर गया, और उस पर जवाब भी आने लगे।
जिस कमेंटर की आपने बात की, मैंने भी देखा कि उसने अभी कुछ ही समय पहले साइन अप किया था। फिर भी मुझे अच्छा लगा। कम से कम कोई प्रतिक्रिया तो थी। इसलिए मैंने भी ध्यान से जवाब लिखा। "why not redis?" इसके लिए मैं पहले से तैयार था। DB से जुड़ी किसी भी चीज़ पर यह सवाल पक्का आता है। मैंने सोचा, क्या सच में मैं इतनी गंभीरता से तैयारी करूँ और फिर भी ऐसा सवाल आएगा? लेकिन एक दिन पहले s2-streamstore वाले समय समझ आ गया था। क्योंकि वहाँ "TCP se hi karo" जैसा जवाब आया था। इसलिए तैयारी कर ली थी।
संदर्भ के लिए, मैंने टीम के लोगों से साफ़ कहा था कि बिल्कुल upvote या कमेंट न करें। कहीं गलती से कुछ कर न दें, इसलिए उनसे login भी हटाए रखने को कहा था। मुझे पहले से पता था कि HN इस मामले में संवेदनशील है।
खैर, समझाने पर भी शायद आप यक़ीन न करें... तो कृपया हमारा repo एक बार देख लीजिए। यह बचा हुआ code है। जिन साथियों ने मेरे साथ काम किया, वे यह लिखाई देखकर आहत न हों, इसलिए मैं यह विस्तार से लिख रहा हूँ। https://github.com/kakao/actionbase/discussions/32 कृपया एक बार देखिए। धन्यवाद।
और,
https://actionbase.io/ko/stories/kakaotalk-gift-wish/ यह भी। अगर आपने बड़े पैमाने के systems पर कभी विचार किया है, तो इसमें मददगार बातें मिल सकती हैं। मैंने पूरी ईमानदारी और मेहनत से लिखा है।
आह, और नीचे मेरा X देखें तो आपको पता चल जाएगा, लेकिन 1वां स्थान उस comment के लिखे जाने से पहले का है। वह comment शायद तब लिखा गया होगा जब वह 2~3वें स्थान पर गिर गया था। snacks खाने की जगह पर
두쫀쿠केस से निकालते ही comment आया, तो मैं भागकर गया और comment लिखा। उसके बाद 12 घंटे तक यह 30वें स्थान तक धकेला गया, और अब यह दूसरे page पर है T_TX पर भी पोस्ट किया है: https://x.com/enmskim/status/2016412136482996689
x: https://x.com/enmskim/status/2016941043628097965