2011-02-28 11 views
11

आप अपने विकास और/या परीक्षण मशीन पर कई परियोजनाओं का प्रबंधन कैसे करते हैं, जब उनमें से कुछ परियोजनाएं Redis डेटाबेस का उपयोग करती हैं?कई परियोजनाओं के साथ एक देव मशीन पर Redis डेटाबेस

  1. Redis नाम दिया नहीं है डेटाबेस (केवल नंबर 0-16)
  2. टेस्ट प्रत्येक रन पर FLUSHDB निष्पादित करने के लिए

अभी संभावना है:

2 प्रमुख समस्याएं हैं , मुझे लगता है कि हमारे पास तीन विकल्प हैं:

  1. प्रत्येक प्रोजेक्ट, प्रत्येक देव और परीक्षण वातावरण के लिए अलग-अलग डेटाबेस असाइन करें
  2. मुख्य का उपयोग करें और के लिए "की तरह redis-namespace
  3. Nuke कुछ का उपयोग कर एक परियोजना का नाम और डेटाबेस किसी भी समय आप परियोजनाओं के बीच स्विच

पहले एक समस्याग्रस्त है बीज अगर कई परियोजनाओं आवंटित" 0 "के साथ उपसर्ग कुंजी 1 "परीक्षण और इस तरह के लिए। भले ही प्रोजेक्ट बी ने "2" और "3" में बदलने का फैसला किया हो, फिर भी परियोजना में किसी अन्य सदस्य के लिए अन्य परियोजनाओं में संघर्ष हो सकता है। दूसरे शब्दों में, यह दृष्टिकोण एससीएम अनुकूल नहीं है।

दूसरे के लिए, यह एक बुरा विचार है क्योंकि यह रनटाइम प्रदर्शन और स्मृति दक्षता पर अनावश्यक ओवरहेड जोड़ता है। और इससे कोई फर्क नहीं पड़ता कि आप क्या करते हैं, जब आप परियोजना में शामिल हो जाते हैं तो एक और प्रोजेक्ट पहले से ही उसी कुंजी का उपयोग कर सकता है।

तीसरा विकल्प समझौता का एक उत्पाद है, लेकिन कभी-कभी मैं अपने स्थानीय डेटा को छूटे रखना चाहता हूं जबकि मैं अन्य परियोजनाओं के लिए छोटे पैच तैनात करता हूं।

मुझे पता है कि यह रेडिस के लिए एक फीचर अनुरोध हो सकता है, लेकिन मुझे अब एक समाधान की आवश्यकता है।

कोई विचार, प्रथाओं?

उत्तर

15

यदि परियोजनाएं स्वतंत्र हैं और इसलिए डेटा साझा करने की आवश्यकता नहीं है, तो कई रेडिस उदाहरणों का उपयोग करना बेहतर होता है - प्रत्येक प्रोजेक्ट कॉन्फ़िगरेशन में डेटाबेस नाम/आईडी के बजाय पोर्ट नंबर होता है। एक उचित नामित कॉन्फ़िगरेशन फ़ाइल और प्रत्येक के लिए स्टार्टअप स्क्रिप्ट बनाएं ताकि आप एक ही क्लिक के साथ चलने वाले किसी भी इंस्टेंस को प्राप्त कर सकें।

सुनिश्चित करें कि आप प्रत्येक कॉन्फ़िगरेशन फ़ाइल में सेव सेटिंग्स को अपडेट करते हैं और साथ ही बंदरगाहों को सेट करते हैं - एक ही dump.rdb फ़ाइल का उपयोग करके कई उदाहरण काम करेंगे, लेकिन कुछ भ्रमित करने वाली बग का कारण बनेंगे।

मैं विकास और परीक्षण के लिए अलग-अलग उदाहरणों का भी उपयोग करता हूं ताकि परीक्षण उदाहरण डिस्क पर कुछ भी लिख न सके और प्रत्येक परीक्षण की शुरुआत में फ़्लश किया जा सके।

0

रेडिस कई डेटाबेस से दूर जा रहा है, इसलिए मैं आपको बाद में उस तंत्र को तुरंत माइग्रेट करना शुरू करने की सलाह दूंगा। इसका मतलब प्रति उदाहरण एक उदाहरण है। रेडिस चलाने के बहुत कम ओवरहेड को देखते हुए, यह संसाधन दृष्टिकोण से कोई समस्या नहीं है।

उस ने कहा, आप डेटाबेस की संख्या निर्दिष्ट कर सकते हैं, और एक नामकरण मानक प्रदान करेंगे। उदाहरण के लिए, 60 डीबीएस कहने के लिए रेडिस कॉन्फ़िगर करें और आप परीक्षण डीबी के लिए 10 जोड़ते हैं। उदाहरण के लिए डीबी 3 परीक्षण के लिए db13 का उपयोग करता है।

ऐसा लगता है जैसे आपके देव, परीक्षण, और प्रोड वातावरण वातावरण एक साथ बंधे हैं। यदि ऐसा है, तो मैं उससे दूर जाने का सुझाव दूंगा। अलग-अलग उदाहरणों का उपयोग करना सबसे आसान मार्ग है, और पार उद्देश्य प्रदूषण के खिलाफ सुरक्षा प्रदान करता है। इसके बीच और रेडिस का भविष्य प्रति-डीबी होने का भविष्य है, अलग-अलग उदाहरण सबसे अच्छा मार्ग है।

+4

मैं असहमत हूं कि कई उदाहरण कम ओवरहेड हैं। पोर्ट नंबर विकास मशीन पर सबसे सीमित संसाधनों में से एक है, और उपलब्धता पर्यावरण पर निर्भर करती है, इस प्रकार टीम में अन्य लोगों के लिए तय नहीं किया जा सकता है। इसका मतलब है कि डिजाइनरों को भी समझना चाहिए कि पर्यावरण परिवर्तनीय कैसे काम करता है। उदाहरण के लिए – kenn

+0

, मेरे पास https://github.com/kenn/redis-mutex जैसी लाइब्रेरी है और वहां, यह परीक्षण के लिए db15 का उपयोग करता है ताकि यह गलती से योगदानकर्ता के वास्तविक डेटा पर कदम न उठाए। – kenn

+0

निश्चित रूप से उपलब्ध बंदरगाहों की एक सीमित संख्या है। लेकिन क्या आपको सच में लगता है कि आपके पास एक एकल देव प्रणाली पर लगभग 64,000 उदाहरण होंगे? व्यावहारिक रूप से बोलते हुए यदि प्रत्येक उदाहरण में 1 एमबी मेमोरी का उपयोग किया जाता है जिसे 64 जीबी रैम वाले सिस्टम पर होना आवश्यक है। मैं उन डेवलपर्स के बारे में भी चिंतित हूं जो पर्यावरण चर को समझ नहीं पाएंगे। जिथब पर आपका उदाहरण प्रोजेक्ट मेरे कई डेटाबेस मिटा देगा। आप बस यह नहीं मान सकते कि एक दिया गया डेटाबेस नंबर "आपका" है, और डेवलपर आपके द्वारा चुने गए किसी भी व्यक्ति का उपयोग नहीं करेंगे। –

संबंधित मुद्दे