नोड

Question

में फ़ाइल बनाम डेटाबेस से सामग्री की सेवा करता है मैं एक पुरानी स्थैतिक वेबसाइट का एक नया संस्करण बना रहा हूं जो 50+ स्थिर पृष्ठों तक बढ़ी है।

इसलिए मैंने पुरानी सामग्री के साथ एक JSON फ़ाइल बनाई ताकि नई वेबसाइट अधिक सीएमएस (सामान्य पृष्ठों के लिए टेम्पलेट्स के साथ) हो और बैकएंड अधिक DRY हो।

मुझे आश्चर्य है कि क्या मैं JSON से अपने विचारों को उस सामग्री की सेवा कर सकता हूं या यदि मुझे इसे MySQL डेटाबेस में रखना चाहिए?

मैं नोड.जेएस का उपयोग कर रहा हूं, और नोड में मैं उस JSON फ़ाइल को स्मृति में संग्रहीत कर सकता हूं ताकि उपयोगकर्ता डेटा के लिए पूछे जाने पर कोई फ़ाइल रीडिंग न हो।

क्या इसके लिए कोई सही अभ्यास है? क्या उनके बीच कैश किए गए JSON फ़ाइल या MySQL के माध्यम से प्रदर्शन अंतर हैं?

प्रश्न में फ़ाइल लगभग 400 केबी है। यदि फाइलसाइज दूसरे पर एक टेक्नोलॉजी की पसंद के लिए प्रासंगिक है?

Answer 1

आम तौर पर, डेटाबेस गतिशील सामग्री है कि अक्सर बदलती की सेवा के लिए प्रयोग किया जाता है, रिकॉर्ड एक-से-कई या कई-से-अनेक संबंध है, और आप विभिन्न मानदंडों के आधार पर डेटा क्वेरी करने के लिए की जरूरत है।

मामले आप वर्णित में, यह लगता है कि सर्वर स्मृति में कैश JSON फ़ाइल के साथ ठीक हो जाएगा। बस सुनिश्चित करें कि जब भी फ़ाइल की सामग्री बदलती है, तो आप कैश को अपडेट करते हैं, यानी सर्वर को पुनरारंभ करके, http अनुरोध के माध्यम से कैश अपडेट ट्रिगर करना या फ़ाइल सिस्टम स्तर पर फ़ाइल की निगरानी करना।

कि के अलावा, आप सर्वर पर और स्टार्टअप पर बेहतर प्रदर्शन

1. कैश और सर्वर स्मृति में Gzip स्थिर फ़ाइलें (एचटीएमएल, जे एस, सीएसएस, JPG) के लिए ब्राउज़र पर स्थिर फ़ाइलों की कैशिंग पर विचार करना चाहिए । इसे आसानी से connect-static
2. उचित प्रतिक्रिया शीर्षलेख सेट करके क्लाइंट के ब्राउज़र कैश का उपयोग करके आसानी से किया जा सकता है।

app.use "/ बोवर", express.static: एक तरह से यह, एक्सप्रेस मार्ग परिभाषा पर maxAge हेडर को जोड़े है यानी ऐसा करने के लिए ("बोवर-घटक", {maxAge: 31,536,000})

Here ब्राउज़र कैशिंग के बारे में एक अच्छा लेख

Answer 2

संकेत की एक और परत क्यों जोड़ें? बस जेएसओएन से सीधे विचारों की सेवा करें।

Answer 3

यदि आपका डेटा आकार भविष्य में नहीं बढ़ेगा तो सीधे जेएस की सेवा करने के लिए यह एक अच्छा अभ्यास है। लेकिन अगर भविष्य में डेटा बढ़ने जा रहा है तो यह सबसे खराब आवेदन मामला बन जाएगा।

Answer 4

400 केबी छोटा है। सभी डेटा रैम में रहेंगे, इसलिए I/O कोई मुद्दा नहीं होगा।

गतिशील रूप से पृष्ठों का निर्माण करना - सभी भारी हिटर्स ऐसा करते हैं, यदि विज्ञापन डालने से कोई अन्य कारण नहीं है। (मैं ऐसी कंपनी के आंतों में काम करता था। लाखों पेज हर समय रहते थे; केवल कुछ ही "स्थिर" थे।)

कौन सी सीएमएस - से चुनने के लिए बहुत सारे हैं। एक जोड़े को चुनें जो आसान लगता है; तो देखें कि क्या आप उनके साथ सहज महसूस कर सकते हैं। फिर उनके बीच उठाओ।

लिनक्स/विंडोज; अपाचे/बिलाव/nginx; PHP/पर्ल/जावा/वीबी। फिर, इस छोटे से वेब साइट में आपका आराम स्तर एक महत्वपूर्ण मानदंड है; उनमें से कोई भी कार्य कर सकता है।

यह गलत कहां हो सकता है? मुझे यकीन है कि आपने वेब पेजों को मारा है जो प्रस्तुत करने में बुरी तरह धीमी हैं। तो, गलत दिशा में जाना संभव है। आप पहले ही गियर बदल रहे हैं; यदि आपका निर्णय सही से कम हो जाता है तो अब से एक या दो साल गियर स्विच करने के लिए तैयार रहें।

किसी भी सीएमएस से बचें जो ईएवी (कुंजी-मूल्य) स्कीमा में बहुत भारी है। वे 400 केबी डेटा के लिए ठीक काम कर सकते हैं, लेकिन वे पैमाने पर बदसूरत हैं।

Answer 5

आप पहले से ही JSON के रूप में अपने विचार भंडारण और नोड का उपयोग कर रहे हैं, तो यह (MongoDB, एक्सप्रेस, कोणीय, नोड) एक मतलब ढेर का उपयोग कर पर विचार लायक हो सकता है:

• http://meanjs.org/
• http://mean.io/

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

MySQL जेएसओएन को कोई समस्या स्टोर और सेवा नहीं कर सकता है, लेकिन क्योंकि यह इसे पार्स नहीं करता है, यह बहुत ही लचीला है जब तक कि आप इसे घटक में विभाजित नहीं करते हैं और दस्तावेज़ के भीतर अनुक्रमण करना असंभव है।

आप इस आपके व्यक्तिगत परियोजना पर पूरी तरह से निर्भर है और क्या यह है/यह कैसे विकसित करने के लिए की संभावना है कर 'चाहिए' है या नहीं।

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

मैं हमारी परियोजनाओं के लिए MySQL में JSON संग्रहीत किया है से पहले, और सभी लेकिन कुछ आला मामलों में विभाजित घटक डेटा समाप्त हो गया।

Answer 6

आप (एम) किसी भी नए पृष्ठ जोड़ने के लिए उम्मीद नहीं कर रहे हैं, मैं सबसे सरल समाधान के लिए जाना चाहते हैं:, स्मृति में एक बार JSON पढ़ा तो स्मृति से काम करते हैं। 400 केबी बहुत कम स्मृति है।

डेटाबेस को शामिल करने की कोई आवश्यकता नहीं है। निश्चित रूप से, आप इसे कर सकते हैं, लेकिन यह यहां अधिक है।

Answer 7

मैं बिल्ड समय पर स्थिर एचटीएमएल सामग्री उत्पन्न करने की सिफारिश करता हूं (ग्रंट या .. का उपयोग करें)। यदि आप परिवर्तनों को लागू करना चाहते हैं, तो निर्माण को ट्रिगर करें और स्थिर सामग्री उत्पन्न करें और इसे तैनात करें।