मल्टी-टेनेंट डेटाबेस आर्किटेक्चर में किरायेदारों की बढ़ती संख्या को संभालना

आवेदन के प्रत्येक किरायेदार के उदाहरण के लिए अलग-अलग डेटाबेस के साथ एक आम सर्वर में मामूली संख्या में ग्राहकों (किरायेदारों) को संभालना अपेक्षाकृत सरल है और आमतौर पर ऐसा करने का सही तरीका है। वर्तमान में मैं एक आवेदन के लिए वास्तुकला को देख रहा हूं जहां प्रत्येक किरायेदार का अपना डेटाबेस उदाहरण है।

हालांकि, समस्या यह है कि इस एप्लिकेशन के पास बड़ी संख्या में किरायेदारों (5,000-10,000) होंगे, जिनके उपयोगकर्ताओं की पर्याप्त संख्या, शायद एक ही किराएदार के लिए 2,000 होगी। हमें हर हफ्ते कई किरायेदारों द्वारा प्रणाली को बढ़ाने का समर्थन करने की आवश्यकता होगी।

इसके अलावा, सभी किरायेदारों और उनके उपयोगकर्ताओं को एक सामान्य लॉगिन प्रक्रिया के साथ प्रस्तुत किया जाएगा (अर्थात प्रत्येक किरायेदार का अपना URL नहीं हो सकता है)। ऐसा करने के लिए, मुझे एक केंद्रीकृत लॉगिन प्रक्रिया और सिस्टम में गतिशील रूप से डेटाबेस जोड़ने और उपयोगकर्ताओं को पंजीकृत करने के लिए एक साधन की आवश्यकता है।

पंजीकरण और डेटाबेस निर्माण प्रक्रिया को कैसे मजबूत किया जा सकता है?
सिस्टम पर किरायेदारों के डेटाबेस को बनाने और पंजीकृत करने की प्रक्रिया प्रदर्शन या लॉकिंग मुद्दों के कारण होने की संभावना है। अगर आपको लगता है कि यह एक मुद्दा हो सकता है, तो क्या कोई इसे कम करने के तरीके सुझा सकता है?
मैं ऐसे तरीके से केंद्रीय प्रमाणीकरण कैसे प्रबंधित कर सकता हूं, जहां उपयोगकर्ता क्रेडेंशियल किसी विशेष किरायेदार के डेटाबेस से संबद्ध होंगे, लेकिन उपयोगकर्ता एक सामान्य पृष्ठ (यानी सभी एक ही लॉगिन URL के माध्यम से लॉग इन कर सकता है, लेकिन उनके घर का आवेदन कुछ विशिष्ट किरायेदार के डेटाबेस पर होगा) )। किरायेदारों को अपने स्वयं के लॉगिन और अनुमतियों को बनाए रखने में सक्षम होना चाहिए, लेकिन एक केंद्रीय लॉगिन प्रणाली को इन के बारे में पता होना चाहिए। क्या कोई ऐसा करने का तरीका सुझा सकता है?
यदि मुझे कई डेटाबेस सर्वरों को जोड़कर 'स्केल आउट' करने की आवश्यकता है, तो क्या कोई सुझाव दे सकता है कि सर्वर (प्रतिरूपण इत्यादि) में उपयोगकर्ता की पहचान को प्रबंधित करने के लिए मुझे किन मुद्दों से निपटना पड़ सकता है और उन मुद्दों को कम करने का कोई तरीका है?

sql-server database-design

— coddey
स्रोत

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

— जोएल ब्राउन

क्या आप वाकई 5,000-10,000 के करीब किरायेदार हैं? और आपके सभी किरायेदार 2,000 उपयोगकर्ता रेंज में होंगे? मेरे सिस्टम में मुझे लगता है कि एक एकल किरायेदार के लिए हमारे आवेदन की सबसे बड़ी संख्या लगभग 100 थी। और उनमें से केवल 20 या तो लगातार सक्रिय थे। क्या मैं पूछ सकता हूं कि उद्योग / आवेदन क्या है?

— हारून बर्ट्रेंड

@AaronBertrand इसकी एक लर्निंग मैनेजमेंट सिस्टम है जहाँ सेवाएँ आंशिक रूप से मुफ्त और आंशिक रूप से भुगतान की जाएंगी।

— कोडेय

जवाबों:

निचले सिरे पर (500 किरायेदार / 10000 उपयोगकर्ता) यह है कि मैंने यह कैसे किया। सबसे पहले, आपके पास एक "नियंत्रण" डेटाबेस है जो वैश्विक, केंद्रीय है और इसमें किरायेदारों और उपयोगकर्ताओं के बारे में सभी जानकारी शामिल है (मुझे वास्तव में नहीं लगता है कि आप इनको एसक्यूएल लॉगिन लॉगिन के रूप में प्रबंधित करना चाहते हैं)। तो निम्नलिखित तालिकाओं के साथ "नियंत्रण" नामक एक डेटाबेस की कल्पना करें:

CREATE TABLE dbo.Instances
(
  InstanceID INT PRIMARY KEY,
  Connection VARCHAR(255)
  --, ...
);

INSERT dbo.Instances SELECT 1, 'PROD1\Instance1';
INSERT dbo.Instances SELECT 1, 'PROD2\Instance1';
-- ...

CREATE TABLE dbo.Tenants
(
  TenantID INT PRIMARY KEY,
  Name NVARCHAR(255) NOT NULL UNIQUE,
  InstanceID INT -- Foreign key tells which instance this tenant's DB is on
  --, ...
);

INSERT dbo.Tenants SELECT 1, 'MyTenant', 1;
-- ...

CREATE TABLE dbo.Users
(
  UserID INT PRIMARY KEY,
  Username VARCHAR(320) NOT NULL UNIQUE,
  PasswordHash VARBINARY(64), -- because you never store plain text, right?
  TenantID INT -- foreign key
  --, ...
);

INSERT dbo.Users SELECT 1, 'foo@bar.com', 0x43..., 1;

हमारे मामले में जब हमने एक नया किरायेदार जोड़ा तो हम गतिशील रूप से डेटाबेस का निर्माण करेंगे, लेकिन तब नहीं जब व्यवस्थापक उपयोगकर्ता ने यूआई में ओके पर क्लिक किया ... हमारे पास एक पृष्ठभूमि का काम था जो हर 5 मिनट में नए डेटाबेस को एक कतार से खींचता था, मॉडल को one_user पर सेट करता था। , और फिर प्रत्येक नए डेटाबेस को क्रमिक रूप से बनाया। हमने ऐसा (ए) व्यवस्थापक उपयोगकर्ता को डेटाबेस निर्माण की प्रतीक्षा करने से रोका और (बी) दो व्यवस्थापक उपयोगकर्ताओं को एक ही समय में डेटाबेस बनाने की कोशिश करने से बचने के लिए या अन्यथा मॉडल को लॉक करने की क्षमता से वंचित किया जा रहा है (नया डेटाबेस बनाते समय आवश्यक है )।

डेटाबेस को नाम योजना के साथ बनाया गया था Tenant000000xxजहाँ xxप्रतिनिधित्व किया गया था Tenants.TenantID। यह, रखरखाव नौकरियों बनाया बजाय नामित डेटाबेस के सभी प्रकार के होने का काफी आसान BurgerKing, McDonalds, KFCकि एक उदाहरण के रूप में सिर्फ का उपयोग कर आदि ऐसा नहीं है कि हम फास्ट फूड में थे,।

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

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

हमारे पास ऐसे सलाहकार थे जो हमारे एक से अधिक ग्राहकों के लिए काम करते थे, और उन्हें कई तक पहुँच की आवश्यकता थी
हमारे पास किरायेदार थे जो वास्तव में कई किरायेदारों में शामिल थे

इसलिए, हमने एक TenantUsersतालिका के साथ समाप्त किया जिसने एक उपयोगकर्ता को कई किरायेदारों के साथ जुड़े रहने की अनुमति दी।

प्रारंभ में जब कोई उपयोगकर्ता लॉग इन करता है, तो एप्लिकेशन को केवल नियंत्रण डेटाबेस के लिए कनेक्शन स्ट्रिंग पता होगा। जब कोई लॉगिन सफल होता है, तो यह मिली जानकारी के आधार पर एक कनेक्शन स्ट्रिंग का निर्माण कर सकता है। उदाहरण के लिए

SELECT i.Connection
  FROM dbo.Instances AS i
  INNER JOIN dbo.Tenants AS t
  ON i.InstanceID = t.InstanceID
  INNER JOIN dbo.TenantUsers AS u
  ON i.TenantID = u.TenantID
  WHERE u.UserID = @UserID;

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

यदि आप इस 10MM उपयोगकर्ता क्षेत्र में आते हैं, तो आप निश्चित रूप से बेहतर संतुलित होने के लिए इसकी आवश्यकता होगी। आप एप्लिकेशन को फ़ेडरेट करना चाह सकते हैं ताकि उनके पास अलग-अलग नियंत्रण डेटाबेस से जुड़ने वाले प्रवेश के विभिन्न बिंदु हों। यदि आप प्रत्येक किरायेदार को एक उपडोमेन (उदाहरण के लिए TenantName.YourApplicationDomain.com) देते हैं, तो आप इसे डीएनएस / मार्ग के साथ पर्दे के पीछे कर सकते हैं, जब आपको आगे स्केल करने की आवश्यकता नहीं होती है।

इसमें और भी बहुत कुछ है - जैसे @ डारिन मैं केवल यहाँ की सतह को खुरच रहा हूँ। मुझे पता है अगर आप एक गैर मुक्त परामर्श की जरूरत है। :-)

— आरोन बर्ट्रेंड
स्रोत

अपना अनुभव साझा करने के लिए धन्यवाद। और इसके ज्ञानवर्धक मुझे बताएं। लेकिन यू ने पहले से ही नॉन-फ्री लिखा है। :(

— कोडडी

मेरा कहना यह था कि मेरे पास केवल मुफ्त सलाह देने के लिए इतना समय है। :-)

— हारून बर्ट्रेंड

+1 - जैसा कि मैंने पहले प्रयोग किया है वैसा ही बहुत अधिक वैसा ही दृष्टिकोण। ~ किरायेदारों की एक ही संख्या, वास्तव में अच्छी तरह से काम किया।

— AdaTheDev

मास्टर डेटाबेस और किरायेदार डेटाबेस के बीच संबंध कैसे संभालें? (ट्रिगर्स आदि के उपयोग के बिना)

— जितेन्द्र पंचोली

@ जितेंद्र के पास वास्तव में कई विकल्प नहीं हैं - आपके पास वास्तव में एक किरायेदार डेटाबेस में कितना डेटा है जो मास्टर डेटाबेस में डेटा से संबंधित होना चाहिए? मुझे यकीन नहीं है कि मैं ट्रिगर्स के लोकप्रिय डर को समझता हूं - एक ठीक से लिखा ट्रिगर डरने की कोई बात नहीं है ...

— एरॉन बर्ट्रेंड

आपके पास खुद एक काफी दिलचस्प प्रोजेक्ट है। मैंने कभी नहीं देखा कि किसी ने भी कुछ को लागू करने की कोशिश की हो, जो कि कम से कम SQL सर्वर पर हो। जितना अधिक मैं आपकी पोस्ट को पढ़ता हूँ, उतने ही अधिक प्रश्न मेरे साथ आते हैं ...

सबसे खराब स्थिति परिदृश्य इन्फ्रास्ट्रक्चर-वार (जो वास्तव में सबसे अच्छा मामला है, व्यापार-वार), आपको 10K डेटाबेस 2k उपयोगकर्ताओं की आवश्यकता है। वह 20,000,000 उपयोगकर्ता हैं। आप 20 M SQL सर्वर लॉगिन को प्रबंधित करने के प्रयास में सफल नहीं होंगे। IMO। बस उनमें से सरासर संख्या, उन्हें सर्वर से सर्वर तक ले जाने के लिए, आईडी टकराव और बेमेल आईडी के लिए बाहर देखने के साथ-साथ, मुझे यकीन नहीं है कि SQL सर्वर sys.server_principals में 20 M पंक्तियों के साथ कैसे व्यवहार करेगा। इसके अतिरिक्त, आपका वेब ऐप संभवतः एकल, या बहुत कम उपयोगकर्ताओं के रूप में कनेक्ट करना चाहता है। जब तक उनके DSN तार समान नहीं हैं, IIS कनेक्शन को पूल नहीं कर सकता। DSN स्ट्रिंग की विशेषताओं में से एक उपयोगकर्ता नाम है। विभिन्न उपयोगकर्ताओं का अर्थ है कोई पूलिंग नहीं।

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

त्वरित प्रश्न: क्या दो अलग-अलग उपयोगकर्ता, जो दो अलग-अलग किरायेदारों से संबंधित हैं, को एक ही उपयोगकर्ता नाम की अनुमति दी जानी चाहिए?

एक और त्वरित प्रश्न: अगर मैं आपको बताता हूं कि मैं फ़्यूबर, इंक। के लिए काम करता हूं, तो आप कैसे जानते हैं? क्या फ़्यूबर आपको उपयोगकर्ताओं की एक सूची देने जा रहा है और आप उन्हें उपयोगकर्ता नामों की एक सूची वापस दे रहे हैं, या वे स्वयं-प्रावधान पर जा रहे हैं?

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

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

आपको डेटाबेस को स्थानांतरित करने के लिए एक तरीका चाहिए, जो ओवरलोडेड सर्वरों से हल्के से लोड किए गए (या नए) सर्वरों तक ले जाए। आपको डाउनटाइम की विंडो मिल सकती है या नहीं यह आपके SLA पर निर्भर करेगा।

क्या आप SalesForce की तरह एक विशिष्ट एप्लिकेशन प्रदान कर रहे हैं, या ये डेटाबेस केवल आपके किरायेदारों के लिए जो कुछ भी डालना चाहते हैं उसके लिए कंटेनर हैं?

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

यदि यह आपका अपना ऐप है, तो आप स्कीमा में अपडेट कैसे संभालेंगे? यदि आप डेटाबेस के संस्करणों को कोड के संस्करणों के साथ सीधे रखने जा रहे हैं, यदि आप एक एकल URL का उपयोग कर रहे हैं जो आपके वेब ऐप पर जाता है?

आप उन डेटाबेस का कैसे पता लगा सकते हैं और नष्ट कर सकते हैं जो अब उपयोग में नहीं हैं? क्या आप तब तक इंतजार करते हैं जब तक कि आपका ए / आर समूह यह नहीं कहता कि किसी ने तीन महीने के लिए अपने बिल का भुगतान नहीं किया है?

यदि किरायेदार अनुमतियाँ प्रबंधित कर रहे हैं, तो इसका अर्थ है कि उन्हें ऐप के आंतरिक कामकाज की कुछ समझ है, या आपके ऐप में बहुत ही सरल रोल संरचना है। ब्लॉगर जैसी किसी चीज़ का एक मोटे उदाहरण के रूप में उपयोग करना, उपयोगकर्ता कर सकते हैं (पोस्ट पढ़ें), (पोस्ट पढ़ें और टिप्पणी करें), (... और पोस्ट बनाएं), (... और अन्य पोस्ट संपादित करें), (... और रीसेट कर सकते हैं अन्य उपयोगकर्ता पासवर्ड), या (... और जो भी हो)। अधिकारों के उन विभिन्न सेटों में से प्रत्येक के लिए एक भूमिका होना और एक उपयोगकर्ता को एक भूमिका या किसी अन्य को सौंपना बहुत कठिन नहीं होना चाहिए, लेकिन आप अपने ऐप को 'GRANT' स्टेटमेंट नहीं चलाना चाहते हैं। उन भूमिकाओं के लिए देखें जिनमें एक पदानुक्रम है और विरासत पर निर्भर है, यह भ्रमित हो सकता है। यदि आप किसी उपयोगकर्ता का प्रचार कर रहे हैं या उसे डिमोट कर रहे हैं, तो मैं कहूंगा कि उन्हें सभी संबद्ध भूमिकाओं से हटा दें और फिर उन्हें वापस उसी भूमिका में जोड़ें, जिसकी उन्हें आवश्यकता है। ओह,

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

— डारिन स्ट्रेट
स्रोत

टिप्पणियों के लिए धन्यवाद। और परियोजना दिलचस्प है। शब्द सीमा के कारण I vl टिप्पणी को बहुत सटीक रखते हैं। यह एक लर्निंग मैनेजमेंट सिस्टम है, जहां प्रत्येक किरायेदार के पास लगभग 120-150 टेबल होंगे। किसी भी उपयोगकर्ता के पास किरायेदार के समान उपयोगकर्ता नाम नहीं होगा। जटिलता को कम करने के लिए DNS CNAME मैपिंग का उपयोग tenant1.abc.com उदाहरण के रूप में किया जाएगा। अब क्वथनांक है - इसे सही तरीके से डिजाइन करना ताकि यह आपके द्वारा साझा किए गए सभी सुझावों को पूरा कर सके और मैं इसके लिए चिंतित हूं। व्हाइटपैपर प्राप्त करना सराहनीय होगा लेकिन यह आसान नहीं है, शायद। यदि आप कर सकते हैं तो अधिक इनपुट प्राप्त करना। !!!!

— कोडेय