PHP में सबसे विश्वसनीय सत्र भंडारण क्या है: मेमेचे, डेटाबेस या फाइलें? [बन्द है]


10

PHP सत्रों को संभालने के लिए सबसे अच्छा और सबसे सुरक्षित तरीका क्या है। सत्रों को संग्रहीत करने का सबसे अच्छा तरीका है:

  1. डेटाबेस (अधिक विश्वसनीय, लेकिन उच्च अड़चन, धीमी गति, उच्च डेटाबेस उपयोग वेबसाइटों के लिए अच्छा नहीं है)?

  2. Memcache (सुपर फास्ट, लेकिन अधिक सुरक्षा समस्याओं को वितरित किया, जब सर्वर फिर से शुरू होता है और कैश के पूर्ण होने पर डेटा खोने की संभावना), डेटा खोने की संभावना?

  3. फ़ाइलें (डिफ़ॉल्ट विकल्प, मुझे लगता है कि यह धीमी गति से पढ़ता है और फ़ाइल I / O से लिखता है, कम सुरक्षा, आदि)।

कौन सा तरीका सबसे अच्छा है? उन दृष्टिकोणों में से प्रत्येक की समस्याएं और अच्छी बातें क्या हैं?


2
मेरा मानना ​​है कि आपको निर्दिष्ट करना चाहिए कि क्या आप केवल एक मशीन का उपयोग कर रहे हैं, या यदि आवेदन वितरित किया गया है, क्योंकि यह उत्तरों को भारी रूप से प्रभावित करेगा।
आर्सेनी मौरज़ेंको

1
@haylem इस सवाल को पूछने के लिए सबसे उपयुक्त जगह है, इसकी प्रोग्रामिंग नहीं इसकी प्रोग्रामिंग वैचारिक समस्या,
user1179459

3
यह वास्तव में एक खराब सवाल है क्योंकि 'सर्वश्रेष्ठ' आपकी विशिष्ट परिस्थिति पर निर्भर करता है। फेसबुक के लिए 'सर्वश्रेष्ठ' शायद आपके निजी होम पेज के लिए समान 'सर्वश्रेष्ठ' नहीं है।
ग्रैंडमास्टरबी

1
@GrandmasterB मुझे पता है कि क्यों मैं स्पष्ट रूप से पूछा "उन समस्याओं में से प्रत्येक की समस्याओं और अच्छी चीजें क्या हैं?" यह जानने के लिए कि कौन सा मेरे लिए सबसे अच्छा है।
user1179459

जवाबों:


6

Memcached पर स्टोर करना सबसे अच्छा है क्योंकि हम आसानी से अन्य मुद्दों (कैश आकार, सुरक्षा, आदि) को हल कर सकते हैं।

फेसबुक है # 1 memcached के उपभोक्ता। कृपया पढ़ें अगर दिलचस्पी है: http://www.facebook.com/note.php?note_id=39391378919

अन्य मुद्दों को कैसे हल करें?


4

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

फ़ाइल सिस्टम - मैंने ऐसा करने की आवश्यकता कभी नहीं देखी है। मैं हजारों छोटी फाइलों के बजाय तालिकाओं में पंक्तियों के प्रबंधन की सादगी पसंद करता हूं। यदि आप सत्र के आँकड़ों में खुदाई करना चाहते हैं, तो आप फ़ाइलों में क्वेरी नहीं कर सकते।

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


4

MySQL में MEMORY स्टोरेज इंजन का उपयोग करने के बारे में क्या?

यह Memcache जितना तेज़ नहीं है, लेकिन इसका फायदा यह है कि आप सादे SQL का उपयोग कर सकते हैं, और आप सामान्य स्टोरेज इंजन का उपयोग भी कर सकते हैं जब इसकी आवश्यकता नहीं होगी और उपयोगकर्ताओं की संख्या / अनुरोध बढ़ने पर MEMORY पर स्विच कर सकते हैं।

मैं इसे वेब ऐप में बड़ी मात्रा में सांख्यिकीय डेटा संग्रहीत करने के लिए उपयोग कर रहा हूं, जो अक्सर बदलता रहता है इसलिए इसका उपयोग सत्रों को संभालने के लिए नहीं किया जाता है, लेकिन मुझे लगता है कि इस उद्देश्य के लिए इसे अच्छी तरह से अनुकूल होना चाहिए।


3

यह ब्लॉग पोस्ट मैगेंटो के साथ विभिन्न सत्र भंडारण इंजनों के प्रदर्शन की तुलना के परिणामों को दिखाता है और उन्होंने निष्कर्ष निकाला है कि लगभग 75 समवर्ती उपयोगकर्ताओं तक उनके बीच वास्तव में प्रदर्शन अंतर नहीं है।

मुझे लगता है कि इन स्तरों पर (उनके पास एक दूसरे के बारे में 5 लेनदेन थे, जो कि 12 घंटे की अवधि में लगभग 430k हिट होंगे) फ़ाइल या DB / Memcache / Redis के बाद से आपके द्वारा देखे जाने वाले प्रदर्शन संख्याओं में ओवरहेड सब कुछ खुशी से संभाल लेंगे यदि ठीक से उपयोग किया जाता है तो एक पसीने को तोड़ने के बिना यातायात।

यह अन्य कारकों जैसे कि स्केलेबिलिटी, विश्वसनीयता और सुरक्षा को छोड़ देता है।

मैं सबसे पहले यह कहना चाहूंगा कि आपकी फ़ाइल भंडारण से समझौता करने वाली कोई भी चीज़ किसी अन्य चीज़ से समझौता करने की संभावना बनाएगी क्योंकि एक हमलावर तब आपके आवेदन कोड को संशोधित कर सकता है या कम से कम खोज कुंजियों और भंडारण पहुंच प्रोटोकॉल / क्रेडेंशियल्स पर भी पढ़ सकता है, भले ही वे केवल-पढ़े हों पहुंच। फ़ाइल संग्रहण कम वॉल्यूम साइट के लिए अच्छा काम करेगा, सेट अप करना आसान है और इसके बारे में तर्क करना आसान है। जितना आप कहते हैं कि आप डिस्क को हिट करते हैं, एक डीबी रीड डिस्क को भी हिट करेगा और अगर डीबी इसे कैश कर सकता है, तो आपके ओएस में भी सत्र फ़ाइल को कैश किया जाएगा। इसके अलावा, इसकी एक फ़ाइल पढ़ी जाती है, और यदि आप पहले से ही इसका नाम जानते हैं, तो आपकी फ़ाइल प्रणाली शानदार है। यदि आप PHP का उपयोग कर रहे हैं, तो क्या आप जानते हैं कि आपके एप्लिकेशन को सेवा देने के लिए सिस्टम को कितनी फ़ाइल पढ़नी है? नकारात्मक पक्ष यह है कि आप कर सकते हैं '

Memcache अपेक्षाकृत तेज़ है और यदि आप Memcache वर्ग के समाधानों पर अधिक मोटे तौर पर (Redis, etc) विचार कर रहे हैं, तो कुछ ऐसे भी हैं जो गति के लिए मेमोरी रीड्स के साथ दृढ़ता का भी वादा करेंगे ताकि आपको दोनों दुनिया में सबसे अधिक मिलें। वे कारण के बारे में अपेक्षाकृत सरल हैं और सत्रों की कुंजी-मूल्य प्रकृति वास्तव में यही है जो ये करने के लिए डिज़ाइन किए गए हैं। क्या आप जानते हैं कि इनमें से एक को भरने के लिए आपको कितना सत्र लगाना होगा? किसी भी तरह से, आपके सभी विकल्प आपको अपनी क्षमता तक पहुंचने के लिए समझौता करने के लिए मजबूर करेंगे। डिस्क फ़ाइलों (संख्या और आकार कारक यहाँ) के साथ भरते हैं, कैश स्टोर क्षमता में भरते हैं और डेटाबेस में पंक्तियों की सीमित संख्या और फ़ाइल दृष्टिकोण के समान डिस्क क्षमता सीमा होती है। इसके अलावा, इन प्रणालियों को केवल वितरित किया जाता है यदि आप उन्हें वितरित फैशन में चलाते हैं। अधिकांश एकल सर्वर सेटअप के साथ ठीक काम करते हैं। यदि आप उन्हें वितरित करते हैं तो आप शायद पहले से ही वेब सर्वर / डेटाबेस सर्वर आदि को वितरित कर चुके हैं, इसलिए आपकी वितरित सिस्टम समस्याएं निश्चित रूप से आपके सत्र भंडारण विकल्प से प्रकट नहीं होंगी। हालाँकि, जब आप 10x ट्रैफ़िक / क्षमता आदि चाहते हैं, तो फ़ाइल संग्रहण योजना के साथ होने के साथ-साथ इसमें बहुत अधिक स्वाभाविक है। कुछ कुंजी / मूल्य भंडार आपको सत्र डेटा के सरल विश्लेषणों को अपेक्षाकृत आसानी से संचालित करने की अनुमति देंगे, लेकिन अधिकांश आपको SQL के पास कहीं भी नहीं मिलेगा।

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

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


0

यह आपकी आवश्यकताओं पर निर्भर करता है।

फ़ाइलों और डेटाबेस स्टोरेज के बीच कुछ अंतर हैं। इस प्रश्न को देखें ।

हालाँकि, आप डिफ़ॉल्ट रूप से रेल 3 में क्या कर सकते हैं, और अपने सत्र के लिए केवल एन्क्रिप्टेड कुकीज़ का उपयोग कर सकते हैं। इसलिए आप सभी मानों को इस तरह एन्क्रिप्ट करते हैं कि केवल बाद में आप इसे डिक्रिप्ट कर सकते हैं (जैसे निजी / सार्वजनिक कुंजी), और आप ग्राहक को आपके लिए रखने की स्थिति में करते हैं।

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


2
जब तक आप अपने कुकी पथ से बाहर होने के लिए अपने स्थैतिक संसाधनों को अलग नहीं करते हैं, कुकीज़ एक निश्चित कर हैं जो आपको हर अनुरोध पर भुगतान करना होगा।
जोएरी सेब्रैच्ट्स

jQuery और बूटस्ट्रैप संयुक्त 150kb के आसपास हैं, और यह अन्य पुस्तकालयों के बिना है। कुकी अधिकतम 4kb है, और आमतौर पर 1Kb से नीचे। जब तक ओपी चरम परिस्थितियों के बारे में नहीं पूछ रहा है - उस तरह के कराधान की परवाह कौन करता है?
यम मार्कोविच

@YamMarcovic में कुछ समस्याएं हैं 1) कुकीज़ सर्वर पर भी जा रही हैं (उपयोगकर्ताओं के पास आमतौर पर तेज़ डाउनलोड है तो अपलोड करें) 2) आमतौर पर पृष्ठों में स्थैतिक फ़ाइलों (छवियों, जेएस, सीएसएस) के लिए 100 अनुरोध होते हैं, इसलिए यह प्रत्येक अनुरोध पर 100kb में मिल सकता है। ऊपर जा रहा है
Miro Svrtan

@MiroSvrtan यदि आप अपने उपयोगकर्ताओं को प्रति पृष्ठ सैकड़ों अनुरोध भेज रहे हैं (जहां कभी ऐसा हुआ?), अनुकूलन स्पष्ट रूप से आपके लिए कोई समस्या नहीं है।
यम मारकोविच

मेरे पास एक ग्राहक था जिसकी साइट गति अनुकूलन के लिए मुझसे परामर्श करने से पहले फ्रंट पेज को लोड करने के लिए ~ 170 HTTP अनुरोध कर रही थी, इसलिए ऐसा होता है, मुझ पर भरोसा करें। Btw, निजी / सार्वजनिक कुंजी असममित क्रिप्टोग्राफी से एक अवधारणा है, जिसे आम तौर पर इस परिदृश्य में लागू नहीं किया जाएगा जहां इसके सममित सिफर के बराबर, लागू करने के लिए केवल अधिक जटिल। इसके अलावा, अधिकांश सत्र भंडारण कार्यान्वयन ग्राहक द्वारा प्रबंधित कुछ कुकी पर निर्भर करते हैं, इसलिए उत्तर के अंतिम पैराग्राफ में वर्णित लाभ उन सभी पर लागू होता है।
जेटी

0

मेरी विशेष स्थिति के लिए, मैं आपको बता सकता हूं कि एक डेटाबेस में सत्र हमारे सर्वर हैंग-अप का एक अच्छा कारण है। हमारी सत्र तालिका बार-बार दूषित हो जाती है जिसे हमने पूर्व-खाली करने के लिए छोटा कर दिया है।

memcache आकर्षक लगता है, लेकिन हमारे पास बहुत सारी प्रक्रियाएँ हैं जो पूरे मेमेक को साफ़ करती हैं, इसलिए उपयोगकर्ता सत्र बहुत बार कट जाएंगे। और पुराने सत्रों को मंजूरी दे दी जाएगी क्योंकि स्मृति पूर्ण हो गई ... इसलिए कोई और स्थायी लॉगिन नहीं।

हम जल्द ही डिफ़ॉल्ट फ़ाइल-आधारित सत्रों की कोशिश करेंगे।

यदि आप अपने सत्र डेटा की सुरक्षा के बारे में चिंतित हैं, तो आपको उस डेटा को सत्र में नहीं रखना चाहिए - और सत्र पर भरोसा न करें - प्रत्येक अनुरोध पर उपयोगकर्ता को मान्य करें।


0

आप अपने सत्र को Redis पर सहेजने का प्रयास कर सकते हैं । Redis, Memcached की तरह तेज़ है लेकिन इसमें कई डेटा-दृढ़ता के विकल्प भी हैं। इसके अलावा, विभिन्न PHP क्लाइंट समर्थित हैं।

इसके अलावा, आप 3 पार्टी सेवाओं की कोशिश कर सकते हैं जैसे मेम्च्च्ड क्लाउड जो अंतर्निहित प्रतिकृति और भंडारण इंजन क्षमताओं के साथ है

प्रकटीकरण, मैं सह-संस्थापक और गोरेंटिया डेटा का सीटीओ हूं।


2
खुलासे के लिए धन्यवाद! सुनिश्चित करें कि आप इस साइट पर उन पदों से आगे भाग लेते हैं जहां आप अपने उत्पादों का उल्लेख कर सकते हैं, हालांकि, हम चाहते हैं कि आप एक व्यक्ति के रूप में योगदान करें, आपकी कंपनी नहीं।
मार्टिज़न पीटरर्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.