हेरोकू

Question

पर तैनाती के लिए एक बहु-किरायेदार रेल 3 एप लिखना मैं हेरोकू पर तैनाती के लिए एक रेल 3 ऐप का निर्माण कर रहा हूं, और मुझे आश्चर्य है कि मेरे मॉडल में बहु-किरायेदारी को संभालने के तरीके पर कोई सिफारिशें हैं या नहीं। एक साल पहले, एक संबंधित प्रश्न (#3776593) यहां पोस्ट किया गया था, लेकिन इसे कई जवाब नहीं मिला। मैंने Guy Naor's presentation on writing multi-tenant applications with Rails भी देखा है, लेकिन ऐसा लगता है कि 3 प्रस्तावित समाधानों में से 2 हेरोोकू पर काम नहीं करेंगे। मैं इनसे लिंक करूंगा, लेकिन नए स्टैक ओवरफ्लो उपयोगकर्ता 2 हाइपरलिंक तक सीमित हैं।

मैं भी निम्नलिखित उपकरणों का सामना करना पड़ा:

• http://samuel.kadolph.com/2010/12/simple-rails-multi-tenancy/
• http://blog.codecrate.com/2011/03/multitenant-locking-down-your-app-and.html

हूं कि आप या तो multitenant मणि या साधारण-रेल-बहु के साथ अनुभव है किरायेदारी मणि ऐसा लगता है कि सबसे सरल समाधान यह है कि मेरे सभी मॉडलों पर केवल एक संबंधित_टी को रखना होगा, जो कि खाते के तहत होना चाहिए, लेकिन मैं वास्तव में जानना चाहता हूं कि आप असली दुनिया में क्या उपयोग कर रहे हैं!

Answer 1

दृष्टिकोण "शेयर कुछ भी नहीं" से हैं, जो आम तौर पर "किरायेदार कुछ" के लिए एक डेटाबेस का मतलब है, जिसका अर्थ है कि प्रत्येक तालिका में कई किरायेदारों से पंक्तियां होती हैं। स्पेक्ट्रम (नीचे) अलगाव की डिग्री, लागत (लागत प्रति किरायेदार, जो है), और आपदा वसूली की आसानी से तोड़ दिया जा सकता है।

• प्रति किरायेदार एक डेटाबेस; उच्चतम लागत, उच्चतम अलगाव, सबसे आसान वसूली।
• प्रति किरायेदार एक स्कीमा; अन्य दो, अच्छी अलगाव, काफी आसान वसूली के बीच लागत, लेकिन वसूली आमतौर पर अन्य किरायेदारों के लिए प्रदर्शन को कम कर देता है।
• किरायेदारों के बीच साझा सारणी; सबसे कम लागत, सबसे कम अलगाव (साझा तालिकाओं), मुश्किल आपदा वसूली (वसूली आमतौर पर हर तालिका के लिए कुछ पंक्तियों को पुनर्प्राप्त करने का मतलब है)। रिकवरी आमतौर पर अन्य किरायेदारों के लिए "बहुत" प्रदर्शन को कम कर देती है।

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

एमएसडीएन का एक सभ्य लेख है जो उच्च बिंदुओं को हिट करता है: Multi-Tenant Data Architecture।

लेकिन यदि आप हेरोोक तक सीमित हैं, तो आपको हेरोोकू का एक विकल्प चुनना होगा। मुझे नहीं पता कि ये विकल्प क्या हो सकते हैं, लेकिन मुझे पता है कि आप विकास में SQLite का उपयोग न करने से बेहतर हैं। PostgreSQL पर Heroku तैनाती चलाने जा रहे हैं; आपको PostgreSQL के खिलाफ विकसित करने की आवश्यकता है।

Answer 2

बहुमुखी मणि के लेखक के रूप में, मैं स्पष्ट रूप से पक्षपाती हूं, लेकिन मुझे सच में विश्वास है कि यह एक अच्छा समाधान है! मणि का लक्ष्य इस सामान्य अनुप्रयोग की आवश्यकता को सरल बनाना और इसे लागू करने के लिए तुच्छ बनाना है।

"पुराना स्कूल" विकल्प रेल ऑब्जेक्ट चेनिंग का उपयोग करना है ताकि यह सुनिश्चित किया जा सके कि सभी प्रश्न संबंधित माता-पिता के माध्यम से किए जाते हैं। इस दृष्टिकोण के साथ मुद्दा यह है कि आपकी किरायेदार वस्तु has_many संगठनों के लिए एक डंपिंग ग्राउंड बन जाती है।

class Tenant 
    has_many :users 
end 
# query for users in the current tenant 
current_tenant.users.find params[:id] 

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

पूर्व:

Multitenant.with_tenant current_tenant do 
    # queries within this block are automatically 
    # scoped to the current tenant 
    User.all 

    # records created within this block are 
    # automatically assigned to the current tenant 
    User.create :name => 'Bob' 
end 

Answer 3

के बारे में मैं इस उद्यम (एक छोटे से रेल अनुप्रयोग के लिए बहु किरायेदारी को लागू करने) शुरू करने हूं और जब तक शोध कर मैं इस अतः पोस्ट पर ठोकर खाई।

यह आश्चर्य की बात है कि किसी ने भी पोस्टग्रेएसक्यूएल स्कीमा का उपयोग करके एमटी लागू करने पर रायनब द्वारा महान स्क्रीनकास्ट के बारे में कोई भी उल्लेख नहीं किया है जो हेरोोक द्वारा समर्थित है।

स्क्रीनकास्ट http://railscasts.com/episodes/389-multitenancy-with-postgresql का लिंक यहां दिया गया है।

संकल्पना:

रेल एप्लिकेशन में, हम स्नातकोत्तर कनेक्शन

 connection.schema_search_path = "schema1, schema2, ..." 

अगर यह इसी तालिका वहाँ पाता है बाद में किसी भी कार्रवाई schema1 पर निष्पादित किया जाएगा के लिए एक खोज पथ सेट कर सकते हैं। अन्यथा, यह स्कीमा 2 में टेबल की खोज करता है और इसी तरह। किरायेदार समेत आपकी संपूर्ण ऐप स्कीमा के साथ होने के लिए सार्वजनिक और सामान्य अभ्यास सार्वजनिक स्कीमा में खाली किरायेदार को छोड़कर सभी टेबल बनाना है।

नए किरायेदार पंजीकरण:

अपने किरायेदार मॉडल के लिए एक after_create जोड़ें कार्य नया किरायेदार के लिए एक नया स्कीमा बना सकते हैं और इस नए स्कीमा में सभी (लोड schema.rb) एप्लिकेशन तालिकाओं (किरायेदार को छोड़कर) बनाने के लिए।

उपयोगकर्ता:

है जब उपयोगकर्ता, subdomain1.myapp.com, किरायेदार तालिका से यह उप डोमेन के लिए स्कीमा खोजने के लिए और करने के लिए कनेक्शन खोज पथ सेट 'schema1, सार्वजनिक' और उपयोगकर्ता को प्रमाणित।

कृपया ध्यान दें, मेरा इरादा समाधान के पीछे अवधारणा को कवर करना है। वास्तविक समाधान के लिए RyanB के स्क्रीनकास्ट का संदर्भ लें।