🥕 🍄 🤹🏿 क्लाउड साझा संग्रहण प्रारूप 🏽 👩🏽‍🏭 👰🏻

हमारे दूरस्थ कार्यालय में 30 लोग शामिल हैं। काम विशेष रूप से संयुक्त राज्य अमेरिका के तहत एसईओ से संबंधित है। और यह उस दिन और रात को मानता है - जैसा कि कार्यकर्ता अलग-अलग समय क्षेत्रों में बिखरे हुए हैं - हम सैकड़ों लिंक, संपर्क, विशेषताओं को खोजते हैं और पाते हैं। जानकारी हिमस्खलन की तरह एकत्र की जाती है, एक दिन में, तालिकाओं का विस्तार 1200-3000 कोशिकाओं द्वारा किया जाता है। इसे आधा साल के काम से गुणा करें ... पहले से ही आज, मेरा सिर घूम रहा है।

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

Microsoft Excel

डेढ़ साल पहले फ्लैशबैक बनाते हैं। जब टीम का नेतृत्व एक व्यक्ति (इस मामले में, I) करता है, जो पूरी तरह से सभी जिम्मेदारियों को मानता है, तो वह आसानी से Microsoft Excel के माध्यम से अपने सभी "धन" का प्रबंधन कर सकता है। चाहे वह लिंक, ईमेल एड्रेस, फोन नंबर या अन्य जानकारी हो, अच्छे पुराने एक्सेल को डिजाइन किया गया है ताकि इसके विकास में कोई समस्या न हो। यदि पहली बार में हाथ गलत जगह पर बढ़ते हैं, तो यह ठीक है - समय के साथ, सभी महत्वपूर्ण कार्यों को आवश्यकतानुसार मास्टर किया जाता है।
प्रारंभ में, कोशिकाओं को एक टैब से दूसरे में कॉपी करना इतना मुश्किल नहीं था। इस "बंदर श्रम" ने तनाव नहीं किया और यहां तक कि कुछ हद तक दूर किया। सभी डेटा एक फ़ाइल में फिट होते हैं, जिन्हें टैब में विभाजित किया जाता है। संग्रहित उद्देश्यों के लिए संचित और संग्रहीत की गई जानकारी (अर्थात, उस तक सक्रिय पहुंच नहीं थी) को एक अतिरिक्त फ़ाइल में स्थानांतरित कर दिया गया था। यार्ड में वर्ष 2010 था।

Google डॉक्स

आइए एक नज़र डालते हैं कि एक वर्ष के दौरान डेटा की मात्रा कैसे बढ़ी है।

1 टैब (.xls, एक्सेल) => 10 टैब (.xls, एक्सेल) => 5 फाइलें (.xls, एक्सेल)।

नतीजतन, 3 फाइलें बन गईं, जिनमें से कुल मात्रा 100 हजार भरी हुई कोशिकाओं से अधिक नहीं थी।
जब यह एक काम करने के लिए असहनीय हो गया, तो उन्होंने एक आभासी कार्यालय बनाने का फैसला किया, जहां, जैसा कि उम्मीद थी, हर कोई अपने स्वयं के काम को अंजाम देगा।
वर्ष 2011 आ गया है ... दस्तावेजों के एक साथ संपादन प्रदान करने के लिए तुरंत सभी डेटाबेस को Google डॉक्स में स्थानांतरित करने का निर्णय लिया गया था। ऑनलाइन प्लेटफ़ॉर्म पर स्विच करने के कई मुख्य उद्देश्य नहीं हैं। लेकिन, आप देखते हैं, वे सब कुछ पल्ला झाड़ लेते हैं:

सहयोग का अवसर
भंडारण की विश्वसनीयता
मुक्त

Google डॉक्स के लिए एक और ऑनलाइन विकल्प खोजने के लिए यह आवश्यक था, लेकिन आवश्यक नहीं (जीभ-बंध के लिए खेद)। कुछ भी बेहतर नहीं था, और नहीं। हम यहां उन सभी संभावित विकल्पों पर चर्चा नहीं करेंगे जिनका हमने परीक्षण किया ताकि वैकल्पिक मुफ्त सेवाओं पर छाया न डाली जा सके। केवल एक ही निष्कर्ष है: उनमें से कई नहीं हैं, उनमें से सभी Google डॉक्स के पीछे कार्यात्मक रूप से हैं। यदि कोई सहमत नहीं है, तो कृपया टिप्पणियों में लिखें। लेखक गलत हो सकता है।
हालांकि, मरहम में एक मक्खी मिली, और एक नहीं, बल्कि एक पूरी स्कूप। बहुत जल्दी, Google डॉक्स ने एक्सेल के संबंध में कमियों को प्रकट करना शुरू कर दिया, और उससे आगे। अधिक से अधिक दस्तावेज थे जिनके साथ हमने सक्रिय रूप से काम किया, समय के साथ, उनमें से लगभग 10 थे। हर दिन दस्तावेजों को 500-1000 लाइनों द्वारा फिर से भर दिया गया था, और यह अभी भी भरे हुए कोशिकाओं की संख्या प्राप्त करने के लिए 2 से गुणा करने की आवश्यकता है। और फिर Google डॉक्स की सीमाओं ने खुद को महसूस किया। 400 हजार कोशिकाओं, सज्जनों, और नहीं।

दुर्भाग्य से, यह सब असुविधा नहीं है। और क्या?

कई आवश्यक विकल्प नहीं हैं (डुप्लिकेट को हटाते हुए, आप कक्षों में पाठ और समान महत्वपूर्ण छोटी चीज़ों के भाग का चयन नहीं कर सकते हैं)
एक्सेल की तुलना में, कोशिकाओं की प्रतिलिपि बनाने और एक दस्तावेज़ से दूसरे में स्विच करने की गति 2 के कारक से कम हो गई है।
इंटरनेट की लत (शाब्दिक) और यातायात की खपत। कोई इंटरनेट नहीं - डेटा तक कोई पहुंच नहीं।
चूंकि हम यूआरएल के साथ काम करते हैं, इसलिए हमें हाइपरलिंक्स से दस्तावेजों को साफ करना होगा।

निराधार न होने के लिए, मैं अपने सहयोगियों को मंजिल प्रदान करूंगा। यहाँ वे क्या शिकायत करते हैं:
आर्थर:
400,000 कोशिकाओं की कष्टप्रद सीमा
ब्रेक, आज आम तौर पर डॉक का उपयोग करना असंभव है, वे सिर्फ लोड नहीं करते हैं
पाशा:
हाँ मुझे भी वेज करता है। मैं डॉक में 1000 से अधिक लिंक नहीं जोड़ सकता
इगोर:
डॉक पर, लैग और इरोरस हमेशा शर्मनाक और कष्टप्रद होते हैं! + एक बार में 1000 से अधिक कोशिकाओं को स्थानांतरित न करें।
ओल्गा:
फिलहाल, Google डॉक्स असुविधाजनक है:
1. गोदी से गोदी में स्थानांतरण - आपको इसे हटाना होगा, यह केवल टैब द्वारा स्थानांतरित किया जाता है।
2. खोज करते समय, यदि यह एक दस्तावेज़ में नहीं मिला है, या सुरक्षा कारणों से, आपको 3 से 4 दस्तावेज़ों में वैकल्पिक रूप से खोजना होगा। यदि SQL में संक्रमण सभी डेटा को एक डेटाबेस में संयोजित करना संभव बनाता है, तो यह खोज को गति देगा और डुप्लिकेट से बचने में मदद करेगा !!!

खैर, आज 13.00 के बाद Google डॉक्स ने बस काम करने से इनकार कर दिया। लाडा: "एक बार में 1000 से अधिक कोशिकाओं को स्थानांतरित न करें।" कल मैं छह कोशिकाओं को भी हस्तांतरित नहीं कर सका) मिठाई के लिए - दो सामान्य समस्याएं:
और समय ...

और दो ...

हम क्या करने आए हैं, या एक मध्यजीव संकट

5 फाइलें (.xls, एक्सेल) => 20 Google डॉक्स फाइलें => ??? :(

2011 वर्ष, जून। तालिकाओं में डेटा संग्रहीत करना कठिन होता जा रहा है। इसके अलावा, Google डॉक्स की सीमाएं कड़ी होती जा रही हैं: हमें नए दस्तावेज़ बनाने होंगे, और मेल के साथ काम करने वालों को एक गोदी से दूसरे में कूदना होगा। कल, लगातार दो दिन, व्यक्तिगत कर्मचारी स्वर्ग तक नहीं पहुंच सके।
दस्तावेजों को छोटे लोगों में विभाजित करना सबसे अच्छा समाधान नहीं है: आपको कई दस्तावेज खोलने होंगे और उनमें से प्रत्येक में आवश्यक जानकारी तलाशनी होगी। और अगर डुप्लिकेट हैं? आप प्रत्येक लिंक की 2 बार जांच नहीं कर सकते।

Olya:
मैं अब प्रत्येक लिंक को "कंट्रोल मेल", "कंट्रोल" के माध्यम से चला रहा हूं। मेल 2 द्वारा "और" दूसरा रन ", कभी-कभी सत्यापन के लिए" कॉलिंग और पत्र "भी, सामान्य तौर पर, एक संयुक्त दस्तावेज़ के लिए कई सेकंड में खोजने के बजाय, कुछ मिनट लगते हैं।
कल्पना कीजिए कि, आदर्श रूप से, दस्तावेज़ में एक मैनुअल खोज अनुरोध (URL, ईमेल) में 10 सेकंड लगते हैं (इस तथ्य को ध्यान में रखते हुए कि खोज विंडो नियमित रूप से खोली जाती है)। यह इस बात पर ध्यान दिए बिना है कि वह खोज के साथ आगे बढ़ने से पहले अपनी पीठ और जम्हाई को भी खरोंच देगा।
यहां तक कि प्रति दिन 10 मिनट की बचत प्रति माह 4 घंटे का समय है (हम 10 मिनट 22 कार्य दिवसों से गुणा करते हैं)। यदि आप उन सेकंड्स को सहेजे बिना, एक और 10 (Google डॉक्स में खोज का उपयोग करते हुए सक्रिय रूप से कर्मचारियों की संख्या) से गुणा करते हैं, तो 40 कार्य घंटे चिमनी से उड़ जाएंगे। और हमारे साथ भुगतान, वास्तव में, प्रति घंटा है।

हम कहां जा रहे हैं?

उपरोक्त सभी इस विचार की ओर ले जाते हैं कि सभी जानकारी के लिए आपको फ़ाइलों में नहीं, बल्कि श्रेणियों में एक एकल डेटाबेस की आवश्यकता है। मेरा क्या मतलब है? श्रेणी में परिवर्तन दो क्लिकों से किया जाना चाहिए, न कि इशारों के साथ जैसे: सेल की प्रतिलिपि बनाएँ (अभी भी वांछित क्षेत्र में पहली बार प्रयास करें), किसी अन्य दस्तावेज़ में पेस्ट करें, पुराने से हटा दें। हां, जब तक Google डॉक्स ने केवल एक ही पुस्तक के भीतर एक टैब से दूसरे में जानकारी को काटना सीखा। और हाइपरलिंक्स की बेवकूफी सक्रियण सक्रिय URL से दस्तावेजों को नियमित रूप से साफ करने के लिए मजबूर करती है। सामान्य तौर पर, कोई भी ट्रिफ़ल उल्लंघन करना शुरू कर देता है। या यहाँ एक और उदाहरण है।

हमें उनकी Exel और GDocs संस्थाओं में तालिकाओं को छोड़ देना चाहिए।

मैंने लंबे समय से बॉस को एक्सेल या गूगल डॉक्स में नहीं, बल्कि एसक्यूएल में डेटा स्टोर करने के लिए सुझाव दिया है। अब हमारे पास विभिन्न डेटा के साथ दसियों हज़ार पंक्तियाँ हैं। यह सब कमोबेश एक ही प्रारूप में कम हो गया है: दिनांक, URL, टिप्पणी, आदि। इसलिए, हम उन सभी चीज़ों को रक्तहीन रूप से स्थानांतरित कर सकते हैं जो हमने एक एकल SQL डेटाबेस में जमा किए हैं।
लेकिन समस्या क्या है? आप नोटपैड में डेटाबेस के रूप में एसक्यूएल नहीं खोल सकते हैं, आपने मैन्युअल रूप से संपादन शुरू नहीं किया है। एक ओर, डेटाबेस को मास्टर करना अधिक कठिन होगा, दूसरी तरफ, डेटा भंडारण को सरल और सुलभ कैसे बनाया जाए। हमें अपनी आवश्यकताओं के लिए "मानव" शेल, UI, इसके अलावा, "तेज" की आवश्यकता है। दरअसल, यहां वे हैं, हमारी आवश्यकताएं:

खोज के माध्यम से हमें वह सब कुछ मिल सकता है जिसकी हमें आवश्यकता है: ब्लैकलिस्ट (ब्लैकलिस्ट) में लिंक की उपस्थिति से लेकर रिपोर्ट्स (श्वेतसूची) में लिंक तक। यह ग्राहक को पत्र फिर से भेजने और क्रमशः डुप्लिकेट करने की संभावना को कम करता है। खोज फ़िल्टर का उपयोग करके, हम एक निर्दिष्ट मानदंड के अनुसार डेटाबेस में लिंक को फ़िल्टर कर सकते हैं।
स्तंभों में, हम जो कुछ भी चाहते हैं उसे इंगित कर सकते हैं, और लाइनें पूर्ण स्क्रीन में रेंगना नहीं करेंगी। श्रमिक SQL प्रारूप में डेटा निर्यात / आयात कर सकेंगे,
तालिका की पंक्तियों को "अंकित किया जाएगा": एक रिकॉर्ड है कि यह इवानोव था जिसने जानकारी प्राप्त की थी जो प्रवेश किया (संयुक्त राष्ट्र) सुखदता। इस प्रकार, हम प्रत्येक लिंक के भाग्य का पता लगा सकते हैं।
क्रोन शेड्यूलर की मदद से प्रबंधन, जो हम एक अनुसूची पर लिंक के साथ जो कुछ भी करना चाहते हैं, वह कर पाएंगे: पीआर और एक्सट को रीचेक करें। लिंक। वास्तव में, Google डॉक्स स्क्रिप्ट की कोई आवश्यकता नहीं है।
SQL में ऐसी कोई सीमा नहीं है जैसी Google डॉक्स में है। आधार हमारे लिए जीवन के लिए पर्याप्त है।
क्लिक के एक जोड़े में सुविधाजनक बैकअप।
एक पंक्ति को दूसरे उदाहरण से स्थानांतरित करने के लिए, हमें फ़ाइलों के बीच कूदने की आवश्यकता नहीं होगी। लिंक के लिए श्रेणी बदलें (आप चेकबॉक्स का उपयोग कर सकते हैं) - और आपका काम हो गया। एक उदाहरण? हमने लिंक पर काम किया - श्रेणी को "XXX" में बदल दिया। डायलर अपनी श्रेणी XXX खोलते हैं (उनकी श्रेणियों की एक सूची प्रदर्शित की जाती है)। यदि लिंक में कोई दिलचस्पी नहीं है, तो श्रेणी को ब्लैकलिस्ट में बदलें और नोट को संपादित करें। और इसी तरह।
तेजी से आयात / निर्यात। उदाहरण के लिए, हम आवश्यक मापदंडों द्वारा डेटा को माउस क्लिक के एक जोड़े में, सीएसवी को तालिकाओं को निर्यात कर सकते हैं, बस आइकन पर क्लिक करके।

बेशक, यह सभी आवश्यकताएं नहीं हैं, लेकिन आज उसी Google डॉक्स में इसकी कमी है।
संभवतः, SQL डेटाबेस CMS Drupal के अंतर्गत चल सकता है। द्रुपाल क्यों उसके लिए, एक निश्चित संख्या में मॉड्यूल को लिखा गया है कि हम अपनी आवश्यकताओं पर लागू कर सकते हैं (कम से कम एक जोड़ी, बाकी सभी को लिखा जाएगा)। इस सीएमएस में एक बड़ा समुदाय है, जिसमें रूसी वक्ता भी शामिल हैं। भार और अन्य बन्स की मापनीयता जुड़ी हुई है।

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

कौन सी DBMS 10 मिलियन कोशिकाओं या अधिक के क्षेत्र में, बड़ी मात्रा में जानकारी संग्रहीत करने के लिए सबसे उपयुक्त है। MySQL? ओरेकल!
Drupal के माध्यम से डेटाबेस प्रबंधन - यह कितना प्रभावी है?
क्या समाधान, डेटाबेस के अलावा, एक अपेक्षाकृत छोटी कंपनी में इस्तेमाल किया जा सकता है?
क्या ड्रुपल प्रोग्रामर को निरंतर आधार पर रखना समझदारी है? सबसे पहले, हम केवल SQL में डेटा का हिस्सा स्थानांतरित कर सकते हैं, और GDocs में कुछ स्टोर कर सकते हैं, उदाहरण के लिए, रिपोर्ट।

किसी भी सलाह के लिए अग्रिम धन्यवाद।

क्लाउड साझा संग्रहण प्रारूप