बिलियंस पंक्तियां mysql तालिका/कैसंद्रा मॉडल - (और जीवविज्ञान का थोड़ा सा :))

Question

मैं जीवविज्ञान प्रयोगशाला पर काम कर रहा हूं और मुझे कई डीएनए माइक्रोएरे प्रयोग परिणामों को स्टोर करने के लिए डेटाबेस तैयार करना है।

प्रत्येक प्रयोग कई सूक्ष्मजीवों (लगभग दस में औसत) से जुड़ा होता है और प्रत्येक माइक्रोएरे में 5 मिलियन से अधिक जांच होती है। प्रत्येक जांच को एक विशेष जीन आईडी में मैप किया जाता है, बेशक एक ही जांच सभी प्रयोगों में एक ही जीन_आईडी से मेल खाती है। एक विशेष प्रयोग में किसी विशेष जीन आईडी की जांच के तीव्रता मूल्यों को त्वरित रूप से पुनर्प्राप्त करने में सक्षम होने के लिए प्रत्येक माइक्रोएरे के तीव्रता मानों को संग्रहीत करना है।

वास्तव में एक सरल mysql तालिका पर्याप्त होगा, यह ऐसा दिखेगा:

तीव्रता तालिका: | probe_id | EXPERIMENT_ID | microarray_id | gene_id | intensity_value

से बना एक प्राथमिक कुंजी के साथ

(probe_id , exper_id, microarray_id, gene_id)

यहां समस्या है: प्रत्येक प्रयोग में कई माइक्रोएरे होते हैं जिनमें 5 मिलियन से अधिक जांच होती है। 1000 प्रयोगों के साथ, औसत पर 10 सूक्ष्मजीव (जो कम अनुमान है, कुछ में सैकड़ों हैं), इसकी 1000 * 10 * 5 एम = 50 बिलियन पंक्तियां। मुझे लगता है कि यह धीमा होगा। और मुझे अरबों पंक्तियों mysql तालिका को संभालने के तरीके के बारे में बिल्कुल कोई जानकारी नहीं है। क्या यह संभव है ? कोई सुझाव ?

मैं भी noSQL डेटाबेस के बारे में उत्सुक हूं। मैंने कभी कैसंद्रा का इस्तेमाल नहीं किया लेकिन मुझे ऐसा लगता है कि यह इस काम के लिए सही होगा, क्या मैं सही हूँ?

{ 
experiment_id_1:{ <- thats a super collumnFamilly ? 
    gene_id_1:{ <- thats a collumnFamilly ? 
     probe_id_1:{ value_microarray_1, value_microarray_2, ... }, <- thats a superCollumn ? 
     probe_id_2:{ value_microarray_1, value_microarray_2, ... }, 
     probe_id_3:{ value_microarray_1, value_microarray_2, ... }, 
     ... 
    }, 
    gene_id_2:{ 
     probe_id_1:{ value_microarray_1, value_microarray_2, ... }, 
     probe_id_2:{ value_microarray_1, value_microarray_2, ... }, 
     probe_id_3:{ value_microarray_1, value_microarray_2, ... }, 
     ... 
    } 
} 
experiment_id_2{ 
    ... 
} 
... 
} 

Am मैं rigth: मैं इस तरह एक शेमा कल्पना कर सकते हैं? क्या यह कैसंद्रा मॉडल फिट होगा? क्या यह कुशल होगा? आपको क्या लगता है नोएसक्यूएल गुरु :)

धन्यवाद।

Answer 1

शायद मैं कुछ याद कर रहा हूँ, लेकिन आप एक प्रणाली की तरह यह है लगता है कि है:

• सजातीय: डेटाबेस में प्रत्येक प्रविष्टि एक प्रयोग आईडी, एक जीन आईडी, एक जांच आईडी, एक मूल्य है चयनकर्ता आईडी (माइक्रोएरे का यह तत्व कौन सा है), और एक मान।
• लिखिए-एक बार, पढ़िए-कई: आप जानकारी रिकॉर्ड करने जा रहे हैं और एक बार रिकॉर्ड होने के बाद, आप कभी भी इसे फिर से बदलना नहीं चाहते हैं।

यह और अधिक लगता है यह एक संबंधपरक डेटाबेस (MySQL या PostreSQL) के बजाय एक NoSQL डेटाबेस के लिए एक अच्छे उम्मीदवार है जैसे - NoSQL डेटाबेस ज्यादा विषम डेटाबेस से निपटने में बेहतर कर रहे हैं।

Answer 2

इस पर विचार करें:

प्रत्येक प्रयोग है, जो कॉलम (probe_id, gene_id, array_of_values) है के लिए एक मेज है। अगर मैं आपको सही ढंग से समझता हूं, प्राथमिक कुंजी prob_id पर होगी (लेकिन यदि आप इस कॉलम से क्वेरी नहीं करते हैं, तो आपके पास प्राथमिक कुंजी नहीं हो सकती है)। इसके अलावा, आपको gene_id पर एक अनुक्रमणिका की आवश्यकता है।

इस प्रकार, आपके पास 1000 टेबल प्रबंधित करने योग्य 5 एम पंक्तियां हैं। ठीक है या नहीं? क्या यह आपके प्रश्न पैटर्न फिट है? इस योजना की एक साफ संपत्ति यह है कि पुराने डेटा को छोड़ना आसान बनाता है।

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

वैसे भी, यह परीक्षण करना आसान होना चाहिए।

Answer 3

एक आरडीबीएमएस को उस वॉल्यूम के साथ बिल्कुल नहीं दबाया जाना चाहिए। आपका डेटा पर्याप्त रूप से संरचित है कि यह संबंधों में शामिल होने के लिए पर्याप्त समझ में आता है।

MySQL आपके संग्रहण के आधार पर इसे संभाल सकता है। मैं तालिका विभाजन को केवल भंडारण मैनेजमेंट स्थिति से अलग टेबल में डालकर अनुशंसा कर सकता हूं।

संबंधित How many rows in a database are TOO MANY?

Answer 4

मैं इस दृष्टिकोण भी एक NoSQL डेटाबेस से अधिक एक संबंधपरक में विचार करेंगे। आप कुछ बातों को बनाने हैं, तो आप यदि आप डेटा को संभालने में सक्षम हैं की जाँच करने में सक्षम हो जाएगा:

1. क्या तालिका के expectet आकार है, मोटा अनुमान लगा एक डाटा संग्रह के आकार की जांच प्राप्त करने के लिए और डेटासेट की कुल एक्सपेसेट संख्या के साथ इसे गुणा करके समग्र आकार की गणना करें।
2. अपनी अनुक्रमणिका के आकार की गणना करें
3. अब जांचें, यदि आपका सर्वर रैम या बेहतर में उन इंडेक्स को संभालने में सक्षम है, तो संपूर्ण तालिका को रैम में संभाल लें।
4. इस तालिका पर डीएमएल/चयन संचालन के बीच अनुपात क्या है
5. सुनिश्चित करें कि आपके पास बैकअप, ऑप्टिमाइज़िंग, उन प्रकार की तालिकाओं को बदलने जैसे सामान्य कार्यों से निपटने के तरीके हैं।

यदि मुझे ऐसी स्थितियों का सामना करना पड़ता है, तो मैं आमतौर पर कुछ परीक्षण डेटा उत्पन्न करता हूं जो कि मेरी तालिका में होने की अपेक्षा करता है और विभिन्न सर्वर पैरामीटर के साथ घूमता है। इसके अलावा मैं इस मामले में partitioning of tables का उपयोग करने पर विचार करता हूं (उदाहरण के लिए प्रयोग_आईडी पर विभाजन। इसके परिणामस्वरूप तालिका को छोटे सबसेट में विभाजित किया जाएगा, जिसे मौजूदा हार्डवेयर सीमाओं के माध्यम से कॉपी किया जा सकता है। क्या आप इसे स्वयं से बनाने की हिम्मत नहीं करते हैं, MySQL यह आपके लिए कर सकता है और तालिका को उपयोगकर्ता को एकल तालिका के रूप में प्रस्तुत किया जाएगा। लेकिन मशीन को केवल उस भाग से निपटना होगा, जहां किसी दिए गए प्रयोग_आईडी के लिए डेटासेट संग्रहीत किए जाते हैं। इसका परिणाम बहुत तेजी से I/O आदि होता है

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

(मैं इस क्षेत्र में मेरी पहली अनुभवों बनाया अपने अध्ययन काल के दौरान EMBL डेटा साथ काम करते हुए, और यह मेरा जुनून बन गया;))

Answer 5

MySQL या Postgres ठीक बाहर काम कर सकते हैं आप के लिए, और अन्य जवाब आपको यह करने के तरीके पर कुछ अच्छी टिप्स दी गईं। लेकिन, चूंकि आपने विशेष रूप से कैसंद्रा के बारे में भी पूछा है, यहां मेरे विचार हैं:

कैसंद्रा इसके लिए अच्छा काम करेगा। यदि आप एक प्रयोग/जीन_आईडी संयोजन के लिए सभी तीव्रता मानों को कुशलतापूर्वक देखने में सक्षम होना चाहते हैं, तो मैं आपके द्वारा आने वाली चीज़ों से थोड़ा अलग सुझाव देता हूं। यदि आप इसे सरल रखना चाहते हैं तो (<experiment_id>, <gene_id>) (या केवल "<experiment_id>:<gene_id>" जैसे स्ट्रिंग) की एक समग्र कुंजी का उपयोग करें, और इस पंक्ति में प्रति तीव्रता मान प्रति कॉलम का उपयोग करें। यह आपको उन सभी तीव्रता मानों को लाने देगा जो आपको बहुत कुशलता से चाहिए; आम तौर पर एक या दो डिस्क एक ठंड लुकअप के लिए खोजता है।

Answer 6

मैं मॉडल से परिचित हूं क्योंकि यह 2010 में मेरे पीएचडी के प्रस्ताव में से एक था।हालांकि, मैं ~ 80000 प्रयोगों को देख रहा था (जो केवल जीन अभिव्यक्ति Omnibus डेटाबेस का एक अंश है)।

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

यदि कोई प्रश्न प्रयोग या जांच द्वारा जाता है तो NoSQL काम करेगा। इसका मतलब है, एक जांच के लिए सभी मूल्य प्राप्त करना (सभी प्रयोगों में) एक प्रयोग की सभी जांच प्राप्त करने के साथ पारस्परिक रूप से अनन्य है। यदि आप किसी भी नोएसक्यूएल टूल (कैसंद्रा शामिल) के साथ जाना चाहते हैं तो आपको डेटा को दो बार स्टोर करना होगा।

दूसरी ओर, वॉल्यूम एक एकल नोड पर संग्रहीत करने से रोकने के लिए इतना बड़ा नहीं है। उदाहरण के लिए, 80k प्रयोग एक्स 5 एम प्रति रिकॉर्ड = 100 टीबी की जांच करता है जो आप 12x6GTB = 60TB (2 डिस्क रिडंडेंसी के लिए घटाए गए डिस्क) के RAID6 सिस्टम के द्वारा कवर कर सकते हैं।

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