2012-11-30 19 views
5

मैं एक PostgreSQL डेटाबेस जो इस संरचना है के साथ एक रूबी ऑन रेल्स अनुप्रयोग है:क्षैतिज डेटाबेस स्केलिंग

class A < ActiveRecord::Base 
    has_many :B 
end 
class B < ActiveRecord::Base 
    has_many :C 
end 
class C < ActiveRecord::Base 
    attr_accessible :x, :y :z 
end 

केवल हैं कुछ एक के, और वे धीरे धीरे बढ़ता है (जैसे कि 5 एक महीने) । प्रत्येक ए में हजारों बी हैं, और प्रत्येक बी में हजारों सी है (इसलिए प्रत्येक ए में लाखों सी हैं)।

ए स्वतंत्र हैं और अलग-अलग ए की बी और सी के साथ कभी भी आवश्यकता नहीं होगी (यानी एक ही प्रश्न में)।

मेरी समस्या यह है कि अब मेरे पास केवल कुछ जोड़े हैं, ActiveRecord प्रश्नों में काफी लंबा समय लगता है। जब सी के लिए तालिका में लाखों पंक्तियां होती हैं, तो प्रश्न हमेशा के लिए लेते हैं।

मैं क्षैतिज डेटाबेस को स्केल करने के बारे में सोच रहा हूं (यानी ए के लिए एक टेबल, बी की एक तालिका और प्रत्येक ए के लिए सी की एक तालिका)। लेकिन मुझे नहीं पता कि यह कैसे करना है। यह मुझे लगता है कि यह एक प्रकार का शेरिंग है, लेकिन मैं यह नहीं समझ सकता कि डीबी टेबल को गतिशील रूप से कैसे बनाया जाए और डेटा तक पहुंचने के लिए ActiveRecord का उपयोग करें यदि टेबल निर्भर करता है कि किस ए के साथ काम कर रहा है।

बहुत बहुत धन्यवाद।

+1

आप ऐसा करते हैं, तो आप अलग अलग स्कीमा में विभाजन तो आप में एक kajillion टेबल नहीं बनाते हैं चाहते हो सकता है 'सार्वजनिक' एक। – tadman

+0

धन्यवाद, मुझे स्कीमा के बारे में पता नहीं था। हालांकि मैं गतिशील रूप से ऐसा कैसे करूं? – Nicolas

+0

यदि मैं आप थे तो मैं किसी प्रकार का ऐड-ऑन या प्लगइन ढूंढूंगा जो आपको शुरू करने के लिए एक जगह देता है। मैं पोस्टग्रेस स्पेस से परिचित नहीं हूं, लेकिन ऐसी चीजें हैं जो [ऑक्टोपस] (https://github.com/tchandy/octopus) हैं जो एक कूदते बिंदु के रूप में काम कर सकती हैं। – tadman

उत्तर

2

यदि आपके पास केवल कुछ पंक्तियों के साथ प्रदर्शन चिंताएं हैं, या यहां तक ​​कि कई मिलियन पंक्तियों के साथ, आपको वायुमंडल अभियंता को समाधान देने से पहले एक कदम वापस लेने की आवश्यकता है। जिस समस्या का आप वर्णन कर रहे हैं वह अनुक्रमण द्वारा बहुत आसानी से सुलझाया जाता है; अतिरिक्त भौतिक तालिकाओं को बनाने का कोई फायदा नहीं है और आप अविश्वसनीय जटिलता पेश करेंगे।

जैसा कि @ mu-is-too-short पहले से ही कहा गया है: अपनी क्वेरी योजनाओं पर ध्यान दें। प्रदर्शन का विश्लेषण करने के लिए अपने टूल्स का प्रयोग करें।

कहा जा रहा है कि आप table partitioning का उपयोग शारीरिक रूप से और पारदर्शी रूप से डेटा के भंडारण को अलग-अलग sharded तालिकाओं में घर पर रख सकते हैं जो विशेष रूप से डेटा के लिए उपयोगी होता है जो बहुत तेजी से बढ़ता है लेकिन केवल एक दिए गए समय बॉक्स (एक महीने की तरह) में उपयोगी होता है। आप तेजी से भंडारण (जैसे एसएसडी की RAID) पर सक्रिय रिकॉर्ड रखते हुए पुराने धीमे भंडारण (कहते हैं, कताई जंग के मानक RAID) पर पुरानी या हटाए गए रिकॉर्ड को शटल करने के लिए एक संग्रह बिट फ्लैग कॉलम के साथ भी ऐसा कर सकते हैं।

+0

धन्यवाद। जब आप कहते हैं कि समस्या अनुक्रमणित करके हल हो जाती है तो आपका क्या मतलब है? वर्तमान में सी के पास उन्हें बी से जोड़ने के लिए एक इंडेक्स है, और वे बी के लिए उनके ए के संबंध में भी जाते हैं। – Nicolas

+0

यदि आपके पास अपनी टेबल पर इंडेक्स हैं तो कुछ मिलियन पंक्तियों को अपेक्षाकृत तेज़ी से वापस लौटना चाहिए, जब तक आप पुराने हार्डवेयर का उपयोग नहीं कर लेते, तब तक "बहुत लंबा" कभी नहीं। एक प्रयोग के रूप में Navicat जैसे टूल को SQL कथन चलाने के लिए उपयोग करें जो आपको लगता है कि ActiveRecord द्वारा निष्पादित किया जाता है - अक्सर यह नहीं लगता कि आप क्या सोचते हैं - और देखें कि यह एआर के प्रदर्शन से तुलना करता है। अपने लॉग/development.log को टेल करें और देखें कि क्या आप एन + 1 क्वेरी प्रदर्शन (अनजाने में शामिल होने को छोड़कर) का शिकार कर रहे हैं। मुझे यह जानकर उत्सुकता है कि किस प्रकार की प्रक्रिया की आवश्यकता पर काम करने के लिए लाखों पंक्तियों की आवश्यकता है; एमएम + पंक्ति संचालन आम तौर पर proc से बाहर होते हैं। – cfeduke

0

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

http://www.mongodb.org/

आप देख रहे हैं एक ORM के लिए, जाँच

http://mongoid.org/en/mongoid/index.html

+0

धन्यवाद! मैंने नोएसक्यूएल के बारे में सोचा नहीं था, हो सकता है कि मैं – Nicolas

+1

की तलाश कर रहा हूं, यदि आप मोंगो का उपयोग करते हैं तो उचित तरीके से योजना बनाने के लिए लेखन-प्रदर्शन चिंताओं हैं, हालांकि 2.2 से वैश्विक लॉक चला गया है (मैंने 2.0 के बाद इसका उपयोग नहीं किया है) तो शायद यह उतना बुरा नहीं जितना कि यह एक बार था। आपको अनावश्यकता पर विचार करने की भी आवश्यकता होगी - 10gen एक स्केल किए गए और अनावश्यक वातावरण के लिए न्यूनतम छह वीएम (विभिन्न भौतिक मेजबानों पर) की सिफारिश करता है। अपने डेटा को denormalize करने के लिए डरो मत - अपने अंतर्निहित डेटा भंडारण को बदलने से पहले - ऐसा करने के लिए आपके पास एक अच्छा मामला है। इसके अतिरिक्त PostgreSQL में हैस्टोर है जो एक नोएसक्यूएल विकल्प है, हालांकि इसके लागू होने पर यह देखने के लिए और अधिक शोध की आवश्यकता है। – cfeduke

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