मनमाने ढंग से डेटाबेस टेबल्स स्टोर करने के लिए डेटा संरचना

Question

मैं एक जेवीएम डेटा स्ट्रक्चर (जावा/स्कैला) डिज़ाइन करना चाहता हूं जिसका उपयोग मनमाने ढंग से संबंधित डेटाबेस टेबल की सामग्री का प्रतिनिधित्व और स्टोर करने के लिए किया जा सकता है। डेटा संरचना तेज होनी चाहिए (बहुत जीसी-गहन, कैश-अनुकूल नहीं) और मेमोरी कुशल है, इसलिए बड़ी टेबल रैम में फिट हो सकती है।

एक मेमोरी-कुशल समाधान प्रत्येक कॉलम को एक आदिम सरणी में अलग से स्टोर करना है, लेकिन मैं कैश मित्रता के बारे में चिंतित हूं क्योंकि एक ही पंक्ति में आइटम एक साथ संग्रहीत नहीं होते हैं। एन कॉलम वाली एक पंक्ति एन कैश मिस लेती है, भले ही कॉलम कितनी संकीर्ण हों।

एक और समाधान प्रत्येक पंक्ति को किसी ऑब्जेक्ट सरणी में संग्रहीत करना है जहां प्रत्येक तत्व फ़ील्ड का प्रतिनिधित्व करता है और पुनर्प्राप्ति पर सही प्रकार पर डाला जाता है, लेकिन इसके लिए उनके बॉक्स वाले रूप में संख्यात्मक प्रकारों को संग्रहीत करने की आवश्यकता होती है, इसलिए यह बहुत स्मृति-कुशल नहीं है। और शायद यह नहीं है कि कैश भी कुशल है।

एक और समाधान प्रत्येक पंक्ति के डेटा को बाइट सरणी में लेआउट करना है, वैसे ही वास्तविक डेटाबेस केवल अपनी बायों को क्रमबद्ध करते हैं, केवल आवश्यक बाइट्स का उपयोग करते हुए। यह कैश-अनुकूल और मेमोरी कुशल है, लेकिन मैं हर एक्सेस पर क्रमबद्धता/डी-क्रमबद्धता की लागत के बारे में चिंतित हूं।

सबसे अच्छा तरीका क्या है?

Answer 1

ऐसा करने का उद्देश्य क्या है? पहिया को फिर से आविष्कार करने के बजाए, आप आसानी से उस डेटा को संग्रहीत कर रहे हैं जिसे आपने अपने डेटाबेस से पुनर्प्राप्त किया है (जैसे ऑब्जेक्ट्स आप इसे मैप करते हैं) जैसे कि कैशिंग परत जैसे ईएच कैश, ओएस कैश, मेमकेचे इत्यादि।

Answer 2

hsqldb या h2 का उपयोग क्यों नहीं करें?

वे दोनों मेमोरी मोड का समर्थन करते हैं और शुद्ध जावा हैं। वे आपको एक्सेस करने के लिए एसक्यूएल का उपयोग करने के लिए मजबूर करते हैं लेकिन दूसरी तरफ, आपको अपने स्वयं के शामिल होने की आवश्यकता नहीं है।

दोनों खुले स्रोत हैं, इसलिए आप इसे प्रदर्शन के लिए आधारभूत आधार के रूप में भी उपयोग कर सकते हैं और देख सकते हैं कि कॉलम/पंक्ति डेटा संरचना द्वारा अपना स्वयं का प्रयास तेजी से किया जाएगा और प्रयास के लायक होंगे।

Answer 3

एक चौथा समाधान प्रत्येक पंक्ति के डेटा को बाइट एरे के बजाए स्ट्रिंग के रूप में स्टोर करना होगा। यह में अधिकतर मामलों में क्रमिकरण लागत से बच सकता है - बशर्ते कि अधिकांश डेटा स्ट्रिंग हों।

यह डीबग करना भी आसान होगा और मंच स्वतंत्र होगा। बेशक इसमें कुछ सीमाएं हैं: उदा। एक फ्लोट का प्रतिनिधित्व नहीं किया जा सकता है, लेकिन एसक्यूएल डेसिमल प्रारूप के समान कुछ में संग्रहीत किया जा सकता है।

कोई भी समाधान एक व्यापार-बंद होगा।

संपादित करें हालांकि, मैं आपके मामले के लिए बाइट सरणी समाधान पसंद करूंगा: प्रति पंक्ति एक बाइट-सरणी। यह निश्चित आकार की पंक्तियों के लिए सबसे कैश-अनुकूल होना चाहिए। लेकिन फिर आपको परिवर्तनीय आकार की पंक्तियों के लिए समाधान भी प्रदान करना चाहिए। एक निम्न-स्तरीय भाषा उस कार्य को बेहतर तरीके से फिट करने लगती है, सी में दो प्रारूपों को परिभाषित किया जा सकता है: निश्चित आकार पंक्तियां जहां तालिका मेटाडाटा में कॉलम-ऑफसेट होते हैं (उदाहरण के लिए कॉलम 1: बाइट्स 0..31, कॉलम 2: बाइट 32..127 इत्यादि), और एक दूसरा परिवर्तनीय आकार पंक्ति प्रारूप, जहां पंक्तियों में कॉलम आकार होते हैं (उदाहरण के लिए बाइट्स 1..3 आकार होते हैं, बाइट्स की निम्न संख्या में डेटा होता है, फिर डेटा के बाद अन्य 4 बाइट आकार होते हैं और इसी तरह)।