ডিবিতে কার্যকারিতা কি স্কেলিবিলিটির জন্য কোনও রোড ব্লক?


17

আমি প্রশ্নের সঠিক শিরোনাম দিতে সক্ষম নাও হতে পারি। তবে এটি এখানে,

আমরা সম্পদ পরিচালনার জন্য আর্থিক পোর্টাল বিকাশ করছি। আমরা আশা করছি 10000 এর বেশি ক্লায়েন্ট অ্যাপ্লিকেশনটি ব্যবহার করবে। স্টক মার্কেটের প্রযুক্তিগত বিশ্লেষণের ভিত্তিতে পোর্টালটি বিভিন্ন পারফরম্যান্স অ্যানালিটিকগুলি গণনা করে।

আমরা স্টোরেজ পদ্ধতি, ব্যবহারকারীর সংজ্ঞায়িত ফাংশন, ট্রিগার ইত্যাদির মাধ্যমে ডেটাবেসের মাধ্যমে প্রচুর কার্যকারিতা বিকাশ করেছি। আমরা ভেবেছিলাম আমরা সি # কোডের চেয়ে সরাসরি ডাটাবেসে স্টাফ তৈরি করে প্রচুর কর্মক্ষমতা বাড়িয়ে তুলতে পারি। এবং আমরা আসলে একটি বিশাল পারফরম্যান্স উত্সাহ পেয়েছি।

আমি যখন আমাদের সিটিও-তে এই কৃতিত্বের বিষয়ে বড়াই করার চেষ্টা করেছি, তখন কোডের পরিবর্তে ডাটাবেসে কার্যকারিতা কার্যকর করার বিষয়ে আমার সিদ্ধান্তকে তিনি পাল্টা প্রশ্ন করেছিলেন। তাঁর মতে এ জাতীয় অ্যাপ্লিকেশনগুলি স্কেল্যাবিলিটি সমস্যা ভোগ করে। তাঁর কথায় "এই দিনগুলিকে মেমরি / ক্যাশে রাখা হয়েছে। সময়ের সাথে সাথে ক্লাস্টার করা ডেটা পরিচালনা করা কঠিন Facebook এবং কার্যকারিতা সম্পূর্ণরূপে ডাটাবেস থেকে decoupled করা উচিত। "

আপনি কি দয়া করে আমাকে যা বলছেন সেগুলি সঠিক কিনা তা সম্পর্কে কিছু পরামর্শ দিন। স্থপতি যেমন একটি অ্যাপ্লিকেশন সম্পর্কে যেতে কিভাবে?


3
"এবং আমরা আসলে একটি বিশাল পারফরম্যান্স উত্সাহ পেয়েছি" কিসের তুলনায়? আপনি যখন কখনই কোনও ক্লায়েন্টের উপর একই কার্যকারিতা প্রয়োগ করেন না, আপনি কীভাবে জানেন?
ডক ব্রাউন

3
আমি মনে করি এটি স্বাভাবিক হবে - এটি প্রকল্পের উপর নির্ভর করে, দলের বাস্তবায়ন এবং ডেটা বাস্তবায়ন।
ড্যানিয়েল ইয়ানকভ

1
আপনার সিটিওকে জিজ্ঞাসা করা উচিত যে কী কারণে তাকে মনে হয় যে ডেটাবেসগুলি তার অনুকূল কৌশলগুলি ব্যবহার করছে না এবং কেন সঞ্চিত পদ্ধতিগুলি "কোড" হিসাবে যোগ্যতা অর্জন করে না।
blrfl

3
ফেসবুক এবং গুগলের বেশিরভাগ অ্যাপ্লিকেশনগুলির কাছে সম্পূর্ণ আলাদা স্কেলে সমস্যা রয়েছে - বাজার থেকে প্রাপ্ত তথ্যের ক্ষেত্রে আপনাকে যে পরিমাণ ডেটা মোকাবেলা করতে হবে তা নিয়ে সমস্যা হতে পারে তবে সমসাময়িক এসকিউএল ডাটাবেসগুলি স্তম্ভিত পরিমাণে ডেটা মোকাবেলায় তৈরি করা হয়।
মার্ফ

1
আমি সম্ভবত আপনার সিটিওর মতোই ভাবব যদি না আপনি তার সমাধানের পারফরম্যান্স অপর্যাপ্ত প্রমাণ করতে না পারতেন এবং এটি পরিচালনা করার অন্যান্য উপায় না থাকতেন। সঞ্চিত পদ্ধতিগুলি, বিশেষত যখন তাদের সংখ্যা বড় হয়, প্রয়োজনে অন্যান্য ডিবিতে যাওয়ার জন্য একটি দুর্দান্ত বাধা সৃষ্টি করে ... ভবিষ্যতের ভবিষ্যদ্বাণী করতে পারে না।
রিগ

উত্তর:


23

সংক্ষেপে, আমি আপনার সিটিওর সাথে একমত হব। আপনি স্কেলাবিলিটি ব্যয়ে সম্ভবত কিছু কর্মক্ষমতা অর্জন করেছেন (যদি এই শর্তগুলি বিভ্রান্তিকর হয় তবে আমি নীচে পরিষ্কার করব)। আমার দুটি সবচেয়ে বড় উদ্বেগ হ'ল আনুভূমিকভাবে স্কেল করার জন্য রক্ষণাবেক্ষণযোগ্যতা এবং বিকল্পগুলির অভাব (ধরে নিবেন যে আপনার এটির প্রয়োজন হবে)।

ডেটাতে সান্নিধ্য: আসুন একটি পদক্ষেপ পিছনে নেওয়া যাক। কোডটিকে কোনও ডিবিতে ঠেলে দেওয়ার কয়েকটি ভাল কারণ রয়েছে। আমি যুক্তি দিয়ে বলব যে সবচেয়ে বড়টি হ'ল ডেটাটির সান্নিধ্য - উদাহরণস্বরূপ, আপনি যদি গণনাটি কয়েক মুঠো মান ফিরিয়ে দেওয়ার প্রত্যাশা করছেন তবে এই মিলিয়ন মিলিয়ন রেকর্ডের সমষ্টি, মিলিয়ন মিলিয়ন রেকর্ড প্রেরণ (অন-চাহিদা) অন্য কোথাও একত্রিত হওয়ার নেটওয়ার্কটি অত্যন্ত ব্যর্থ, এবং সহজেই আপনার সিস্টেমকে হত্যা করতে পারে। এটি বলার পরে, আপনি অন্যান্য উপায়ে ডেটাগুলির এই সান্নিধ্য অর্জন করতে পারেন, মূলত ক্যাশে বা বিশ্লেষণ ডিবি ব্যবহার করে যেখানে কিছু সংহতকরণ সামনে করা হয়।

ডিবিতে কোডের সম্পাদনা:"কার্যনির্বাহী পরিকল্পনার ক্যাশে" এর মতো গৌণ পারফরম্যান্সের প্রভাবগুলি যুক্তিযুক্ত হওয়া আরও বেশি কঠিন difficult কখনও কখনও, ক্যাশেড এক্সিকিউশন প্ল্যানগুলি একটি খুব নেতিবাচক জিনিস হতে পারে, যদি ভুল এক্সিকিউশন প্ল্যান ক্যাশে হয়। আপনার আরডিবিএমএসের উপর নির্ভর করে আপনি এগুলির মধ্যে সবচেয়ে বেশি কিছু পেতে পারেন তবে বেশিরভাগ ক্ষেত্রে প্যারামেট্রিসড এসকিউএল এর চেয়ে বেশি কিছু পাবেন না (সেই পরিকল্পনাগুলি সাধারণত ক্যাশেও হয়ে যায়)। আমি আরও যুক্তি দিয়ে বলব যে বেশিরভাগ সংকলিত বা জেআইটি'র ভাষা সাধারণত তাদের এসকিউএল সমতুল্য (যেমন টি-এসকিউএল বা পিএল / এসকিউএল) বুনিয়াদি ক্রিয়াকলাপ এবং অ-সম্পর্কযুক্ত প্রোগ্রামিংয়ের (স্ট্রিং ম্যানিপুলেশন, লুপস ইত্যাদির) চেয়ে ভাল সম্পাদন করে, তাই আপনি নম্বর ক্রাঞ্চিংয়ের জন্য আপনি যদি জাভা বা সি # এর মতো কিছু ব্যবহার করেন তবে সেখানে কিছুই হারাবেন না। সূক্ষ্ম দানাযুক্ত অপ্টিমাইজেশনটিও বেশ কঠিন - ডিবিতে, আপনি ' আপনার একমাত্র ডেটা স্ট্রাকচার হিসাবে প্রায়শই জেনেরিক বি-ট্রি (সূচক) দিয়ে আটকে থাকেন। সুস্পষ্টভাবে বলতে গেলে, দীর্ঘমেয়াদি লেনদেন হওয়া, লক বাড়ানো ইত্যাদির মতো সামগ্রীর একটি সম্পূর্ণ বিশ্লেষণ বই ভরাতে পারে।

রক্ষণাবেক্ষণযোগ্যতা: এসকিউএল হ'ল এটি করার জন্য ডিজাইন করা একটি দুর্দান্ত ভাষা। আমি নিশ্চিত নই যে এটি প্রয়োগের যুক্তির জন্য দুর্দান্ত। আমাদের জীবনকে বহনযোগ্য করে তোলা (টিডিডি, রিফ্যাক্টরিং, ইত্যাদি) তৈরি করার বেশিরভাগ সরঞ্জামাদি এবং অনুশীলনগুলি ডাটাবেস প্রোগ্রামিংয়ে প্রয়োগ করা কঠিন।

পারফরম্যান্স বনাম স্কেলাবিলিটি:এই শর্তাদি স্পষ্ট করার জন্য, আমি এর অর্থ: পারফরম্যান্স হ'ল কম লোড ধরে নিয়ে মুহুর্তে আপনি আপনার সিস্টেমে (এবং ব্যবহারকারীর কাছে ফিরে) একক অনুরোধের আশা করতে চেয়েছিলেন quick এটি প্রায়শই শারীরিক স্তরগুলির মধ্য দিয়ে যায় এমন স্তরগুলির দ্বারা সীমাবদ্ধ থাকবে those স্তরগুলি কতটা অনুকূলিত হয়েছে ইত্যাদি Sc আপনার মাঝারি / নিম্ন পারফরম্যান্স থাকতে পারে (বলুন, একটি অনুরোধের জন্য 5 সেকেন্ড +), তবে দুর্দান্ত স্কেলাবিলিটি (কয়েক মিলিয়ন ব্যবহারকারীকে সমর্থন করতে সক্ষম)। আপনার ক্ষেত্রে, আপনি সম্ভবত ভাল পারফরম্যান্সের অভিজ্ঞতা অর্জন করতে পারেন, তবে আপনার স্কেলাবিলিটিটি শারীরিকভাবে আপনি কত বড় সার্ভার তৈরি করতে পারবেন তার দ্বারা সীমাবদ্ধ থাকবে। এক পর্যায়ে, আপনি সেই সীমাটি হিট করবেন এবং শারডিংয়ের মতো জিনিসগুলির দিকে ফিরে যেতে বাধ্য হবেন যা অ্যাপ্লিকেশনটির প্রকৃতির উপর নির্ভর করে সম্ভব হবে না।

অকালে অপ্টিমাইজেশন: শেষ পর্যন্ত, আমি মনে করি আপনি অকালে অপ্টিমাইজ করার ভুল করেছেন। অন্যরা যেমন উল্লেখ করেছে, আপনার কাছে অন্যান্য মীমাংসাগুলি কীভাবে কাজ করবে তা দেখানোর মতো পরিমাপের সত্যিই নেই। ঠিক আছে, আমরা কোনও তত্ত্বকে প্রমাণ বা অস্বীকার করার জন্য সর্বদা পূর্ণ-স্কেল প্রোটোটাইপগুলি তৈরি করতে পারি না ... তবে সাধারণভাবে, আমি সর্বদা পারফরম্যান্সের জন্য রক্ষণাবেক্ষণের (সম্ভবত কোনও অ্যাপ্লিকেশনটির সবচেয়ে গুরুত্বপূর্ণ গুণ) ব্যবসায়ের জন্য একটি পদ্ধতিকে বেছে নিতে দ্বিধা বোধ করব ।

সম্পাদনা: একটি ইতিবাচক নোটে, উল্লম্ব স্কেলিং বেশ কয়েকটি ক্ষেত্রে প্রসারিত হতে পারে। যতদূর আমি জানি, এসও বেশ কিছু সময়ের জন্য একটি একক সার্ভারে ছুটেছিল। আমি নিশ্চিত না যে এটি আপনার 10,000 ব্যবহারকারীর সাথে কীভাবে মেলে (আমার ধারণা এটি আপনার সিস্টেমে কী করছে তার প্রকৃতির উপর নির্ভর করবে) তবে এটি আপনাকে কী করা যায় তার একটি ধারণা দেয় (আসলে, অনেকদূর আছে) আরও চিত্তাকর্ষক উদাহরণ, এটি কেবল এমন জনপ্রিয় হিসাবে ঘটে যা সহজেই লোকেরা বুঝতে পারে।

সম্পাদনা 2: অন্যত্র উত্থাপিত কয়েকটি বিষয় সম্পর্কে স্পষ্ট করে মন্তব্য করতে:

  • পুনরায়: পারমাণবিক ধারাবাহিকতা - এসিডি ধারাবাহিকতা সিস্টেমের প্রয়োজনীয়তাও হতে পারে। উপরেরটি সত্যই এর বিরুদ্ধে তর্ক করে না, এবং আপনার বুঝতে হবে যে এসিডি ধারাবাহিকতার জন্য আপনার সমস্ত ব্যবসায়িক যুক্তি ডিবি-র মধ্যে চালানো দরকার না। কোড যা নেই সরিয়ে প্রয়োজন ডিবি মধ্যে সেখানে হতে, আপনি এটি ডিবি বাকি ভৌত পরিবেশের চালানোর জন্য constraining করছি - আপনার ডিবি প্রকৃত ডেটা ম্যানেজমেন্ট অংশ হিসাবে একই হার্ডওয়্যার সম্পদের জন্য প্রতিদ্বন্দ্বী নেই। অন্যান্য ডিবি সার্ভারগুলিতে কেবল কোড স্কেলিংয়ের জন্য (তবে আসল তথ্য নয়) - অবশ্যই, এটি সম্ভব হতে পারে তবে বেশিরভাগ ক্ষেত্রে অতিরিক্ত লাইসেন্স ব্যতীত আপনি এখানে কী অর্জন করছেন? ডিবি থেকে দূরে থাকা জিনিসগুলি ডিবিতে রাখবেন না।
  • পুনরায়: এসকিউএল / সি # পারফরম্যান্স - যেহেতু এটি আগ্রহের বিষয় বলে মনে হচ্ছে, তাই আলোচনায় কিছুটা যুক্ত করা যাক। আপনি অবশ্যই ডিবিগুলির মধ্যে নেটিভ / জাভা / সি # কোড চালাতে পারেন, তবে যতদূর আমি জানি, এটি এখানে আলোচনা করা হয়নি - আমরা টি-এসকিউএল বনাম সি # এর মতো কিছুতে সাধারণ অ্যাপ্লিকেশন কোডটি প্রয়োগের সাথে তুলনা করছি। অতীতে আপেক্ষিক কোডের সাথে সমাধান করা বেশ কয়েকটি সমস্যা ছিল - যেমন "সর্বাধিক সমবর্তী লগিনগুলি" সমস্যাটি বিবেচনা করুন, যেখানে আপনার লগইন বা লগআউট এবং আপনার সময়কে চিহ্নিত করার রেকর্ড রয়েছে এবং আপনার কী কাজ করা দরকার যে কোনও সময়ে লগ ইন করা সর্বাধিক সংখ্যক ব্যবহারকারী ছিল। সহজতম সমাধান হ'ল রেকর্ডগুলির মাধ্যমে পুনরাবৃত্তি করা এবং লগইন / লগআউটগুলির মুখোমুখি হওয়ার সাথে সাথে একটি কাউন্টার বাড়ানো / হ্রাস করা এবং এই মানটির সর্বোচ্চ সন্ধান করা।may, আমি জানি না), সেরা আপনি যা করতে পারেন তা কর্সর (খাঁটি সম্পর্কযুক্ত সমাধানগুলি সমস্ত জটিলতার বিভিন্ন আদেশে রয়েছে, এবং কিছুক্ষণ লুপ ব্যবহার করে এটি সমাধানের চেষ্টা করা খারাপ ফলাফলের ফলে)। এই ক্ষেত্রে, হ্যাঁ, সি # সমাধানটি টি-এসকিউএল, পিরিয়ডে আপনি যা অর্জন করতে পারবেন তার চেয়ে আসলে দ্রুত। এটি সুদূরপ্রসারী বলে মনে হতে পারে, তবে আপনি যদি সমস্যাগুলি তুলনামূলকভাবে পরিবর্তনের প্রতিনিধিত্ব করে সারিগুলির সাথে কাজ করে থাকেন এবং সেগুলির জন্য উইন্ডোড সমষ্টিগুলি গণনা করার প্রয়োজন হয় তবে এই সমস্যাটি সহজেই আর্থিক ব্যবস্থায় নিজেকে প্রকাশ করতে পারে। সঞ্চিত প্রকল্পের অনুরোধগুলি আরও ব্যয়বহুল হতে থাকে - একটি তুচ্ছ স্পিকে এক মিলিয়ন বার আবেদন করে দেখুন কীভাবে এটি সি # ফাংশন কল করার সাথে তুলনা করে। আমি উপরোক্ত কয়েকটি অন্যান্য উদাহরণে ইঙ্গিত দিয়েছিলাম - টি-এসকিউএল-তে সঠিক হ্যাশ টেবিল প্রয়োগ করার জন্য আমি এখনও কারও মুখোমুখি হইনি (এটি আসলে কিছুটা সুবিধা দেয়), যদিও সি # তে করা খুব সহজ is আবার, এমন কিছু জিনিস রয়েছে যেগুলিতে ডিবিগুলি দুর্দান্ত হয় এবং এগুলিতে এগুলি এত ভয়াবহ নয়। আমি সি # তে যোগ, এসইউএমস এবং গ্রোপ বিওয়াইস করতে চাই না, আমি টি-এসকিউএল বিশেষত সিপিইউ নিবিড় কিছু লিখতে চাই না।

আমি ডাটাবেসে কার্যকারিতা ঠেকানোর যে কারণগুলির মধ্যে একটি হ'ল এটি অ্যাপ্লিকেশন স্তরের কোডের তুলনায় বগী much এসকিউএল হ'ল ঘোষিত এবং এটি অত্যাবশ্যক ভাষাগুলি যে সমস্যাগুলি করে তার অনেকগুলিই ভোগ করে না।
wobbily_col

রক্ষণাবেক্ষণযোগ্যতার বিষয়ে, এসকিউএল সার্ভার ডেটা সরঞ্জামগুলির রক্ষণাবেক্ষণযোগ্যতাটি একটি শিবির। আসলে কোনও অনানুষ্ঠানিক ডাটাবেসের জন্য (৫ টিরও বেশি টেবিল সহ একটি) আমি এটিকে একটি প্রয়োজনীয়তা হিসাবে বিবেচনা করব।
49

4

ডেটা বসেছে বা গণনাটি কীভাবে ঘটে তার সাথে স্কেলাবিলিটির কোনও সম্পর্ক নেই। স্কেলাবিলিটি হ'ল আপনি কীভাবে বিশ্বব্যাপী রাষ্ট্র এবং ডেটা আন্ত-নির্ভরতা পরিচালনা করেন সে সম্পর্কে about যদি আপনার আর্কিটেকচারটি সব ধরণের ডেটা আন্তঃনির্ভরশীলতার সাথে সংশ্লেষিত হয় তবে আপনি সেই ডেটাটি রূপান্তর করার জন্য কোডটি কোথায় রেখেছেন তাতে কিছু যায় আসে না। আন্তঃনির্ভরতাগুলি আপনার হাতকে চাপ দিতে চলেছে এবং জিনিসগুলি স্কেলিংয়ের কোনও সম্ভাবনা হ্রাস করবে। অন্যদিকে যদি আপনার ডেটা আলগাভাবে মিলিত হয় এবং কোনও বিশ্বব্যাপী রাষ্ট্রের খুব সামান্য পরিমাণ থাকে তবে আবার কোথায় এটি গণনা হয় তা বিবেচনা করে না। জিনিস স্কেলিং অনেক সহজ হতে চলেছে।

আমি নিশ্চিত নই যে আপনার সিটিও কোথায় স্কেলিবিলিটি সম্পর্কিত সমস্যাগুলি সম্পর্কে তার তথ্য পাচ্ছে তবে আপনি যা বলেছেন তা শুনে মনে হচ্ছে না সফ্টওয়্যার ফ্যাশন প্রবণতা বাদে বর্তমান স্থাপত্য সংক্রান্ত সিদ্ধান্ত নিয়ে প্রশ্ন করার কোনও বাস্তব কারণ তাঁর আছে। এই জাতীয় প্রবণতাগুলির বিষয়ে স্থাপত্য সংক্রান্ত সিদ্ধান্তগুলি মজাই দেওয়া সাধারণত একটি খারাপ ধারণা।


1
+1 এর জন্যScalability is all about how you manage global state and data inter-dependence.
এস্তেফানি ভেলিজ

2

এবং আমরা আসলে একটি বিশাল পারফরম্যান্স উত্সাহ পেয়েছি।

আমি মনে করি আপনাকে প্রথমে একটি পারফরম্যান্স বেঞ্চমার্ক সেট করা এবং আপনার প্রোটোটাইপ তৈরি শুরু করা দরকার। ক্লায়েন্ট-সার্ভার আর্কিটেকচারের সাথে ডিলের সমস্ত যুক্তি রাখা একটি পুরানো স্কুল (তবে, এর বিরুদ্ধে আমার কিছু নেই)। যদিও এর এর সুবিধাগুলি রয়েছে, এমন অনেকগুলি অপূর্ণতা রয়েছে যা বিবেচনা করা দরকার।

এই ধরণের বিক্রয়যোগ্য অ্যাপ্লিকেশনগুলির জন্য সাধারণ পদ্ধতি এসওএর মাধ্যমে করা হয় । কারণ দীর্ঘমেয়াদে, এটি আপনার প্রকল্পে নতুন ক্লায়েন্ট অ্যাপ্লিকেশন যুক্ত করার সহজতম উপায়।

আপনি ট্রিগারগুলিও উল্লেখ করেছেন। ট্রিগার ব্যবহারটি অ্যাপ্লিকেশনটির সাপোর্ট লাইফ-চক্রের পরে বড় গটচে পরিণত হতে পারে, আমি এটির সাথে দ্বিগুণ সাবধানতা অবলম্বন করব এবং এমনকি এর ব্যবহার এড়িয়ে যাওয়ার চেষ্টা করব।


2

আপনার সিটিও 100% ভুল।

আপনার আর্থিক সংখ্যার হবে সব সময়ে আপ যোগ করুন। তার অর্থ আপনার এসিআইডি দরকার এবং এটির বীমা করার জন্য রিলেশনাল ডিবিই সেরা জায়গা। NoSql ডিবি এর কার্য সম্পাদনে লাভ ব্যয় সাধারণত ACID এবং Google এবং ফেসবুক জন্য কিন্তু না একটি সিস্টেম অর্থনৈতিক ধারণকারী জন্য ঠিক আছে।

এটি বলতে যে এসকিউএল কোডের চেয়ে সি # আরও ভাল পারফর্ম করে তাও বোকামি…


এটি বলতে যে এসকিউএল কোডের চেয়ে সি # আরও ভাল পারফর্ম করে তাও মূর্খতা… - তবে আপনি কি অস্বীকার করছেন না যে সি # কোডটি আরও স্কেলযোগ্য, সঠিক?
জিম জি।

এটি এর চেয়ে বেশি স্কেলযোগ্য নয়, কারণ বোতল ঘাড় যেখানে নেই, আমি স্কেল কোডটি (ডেটা নয়) ঠিক তত সহজেই সি # কোডটি অনুভূমিকভাবে স্কেল করতে পারি ont
মরনস

@JimG। কেবল স্পষ্ট করে বলার জন্য, "আমি স্কেল কোডটি (ডেটা নয়) ঠিক তত সহজেই স্কেল করতে পারি যতই আমি আনুভূমিকভাবে সি # কোড স্কেল করতে পারি" যদি এটি করার জন্য ডিজাইন করা হয়েছিল ... সি # এর মতোই এটি অবশ্যই স্কেল করার জন্য ডিজাইন করা উচিত। আপনি কেবল সি # স্কেল আরও ভাল বলতে পারবেন না, এটি ভাষা নয় পরিকল্পনার বিষয়।
মরনস

@ জিমজি .: সফ্টওয়্যার যা স্কেল করে না সেগুলিকে সি # সহ যে কোনও ভাষায় লেখা যেতে পারে। এর নুনের মূল্যবান যে কোনও ডাটাবেসে তাদের স্থানীয় এসকিউএল-ইশ বাস্তবায়ন ব্যতীত অন্য ভাষায় লিখিত পদ্ধতি সংরক্ষণ করা যেতে পারে এবং নোএসকিউএল-এর গভীর অবস্থার বাইরে যাওয়া লোকেরা এমন পরিস্থিতিতে যেটি এসিডের প্রয়োজন হয় সাধারণত বেশিরভাগ চাকা পুনরায় উদ্ভাবন করতে পারে যা বেশিরভাগ চাকা ছিল nice DBMS দ্বারা বাস্তবায়িত।
blrfl

@ মরনস: আমি মনে করি আমরা একমত হই। আমি ছিল আসলে "এসকিউএল" সঙ্গে ডেটা conflating হবে। ডাটাবেস স্কেল করা অনেক বেশি ব্যয়বহুল।
জিম জি।

2

যে কোনও সময় স্কেলাবিলিটি এবং গুগল / ফেসবুক / টুইটার / ইত্যাদি উল্লেখ করে, এটি একটি লাল রঙের উত্তাপ ring আপনি যদি একইভাবে পরিষেবা সরবরাহ না করেন তবে তাদের জন্য যা কাজ করে তা আপনার পক্ষে উপযুক্ত নাও হতে পারে। সাধারণভাবে, আপনি যদি একটি একক মেশিন থেকে আট-মেশিনের ক্লাস্টারে স্কেল করতে পারেন তবে আপনি সম্ভবত আপনার সমস্ত ঘাঁটি coveredেকে রেখেছেন। আপনার যদি দিনে 20 এম পৃষ্ঠাগুলি দেখাতে কঠোর ব্যবসায়ের প্রয়োজন না হয় তবে হাইপার-স্কেলিং সম্পর্কে চিন্তা করবেন না। আপনার অ্যাপ্লিকেশনটির আসল প্রয়োজনীয়তার জন্য যা বোঝায় তা করুন এবং আপনার যখন প্রয়োজনীয় হওয়া প্রাসঙ্গিক হবে তখন তা বাড়ানোর বিষয়ে চিন্তা করুন। এবং ভুলে যাবেন না, বেশিরভাগ ডাটাবেস সার্ভারগুলিকেও ক্লাস্টার করা যায়, তাই কেবলমাত্র এটি সমস্ত ডাটাবেসে থাকা অর্থ এটি কোনও একটি সার্ভারে নয়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.