একাধিক ডাটাবেস / সার্ভার ব্যবহার করে ডেটা দিয়ে ইন্টারেক্ট করা


18

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

এই ক্ষেত্রে:

  • একাধিক ডাটাবেসে দুটি টেবিলের মধ্যে কীভাবে যুক্ত হয়? (এখানে একটি কোড উদাহরণ সহায়ক হবে)।
  • কোন ডাটাবেসে কোন সারণী রয়েছে তা ট্র্যাক করার জন্য কোনও বিশেষ কৌশল আছে?
  • এক বা একাধিক ডাটাবেস একাধিক সার্ভারে ছড়িয়ে রয়েছে তা কি অ্যাপ্লিকেশন কোডটি জানতে হবে? যদি তা না হয় তবে অনুরোধগুলি কোন স্তরে ফিল্টার করা হয়?
  • 1 টি ডাটাবেস / 1 সার্ভার সেটআপের বাইরে চলে যাওয়ার সময় কখন? এটি করা কতটা সাধারণ?

এই প্রশ্নের ডেটাবেস প্রশাসকগুলিতে আরও ভাল উত্তর দেওয়া যেতে পারে । যদিও এখানে এটির সাথে সত্যিই কোনও ভুল নেই, তাই আমি কেবল ডিবিএ মোডগুলি দিয়ে পরীক্ষা করব। যদি এটি উপযুক্ত হয়, আপনি কি এই স্থানান্তরিত করতে চান?
অ্যাডাম শিখুন

@ আন্নলায়ার - আমার ধারণা এটি উত্তরগুলির উপর নির্ভর করে। এই মুহুর্তে, আমি ইস্যুটির অ্যাপ্লিকেশন দিকটি সম্পর্কে আরও আগ্রহী, সুতরাং আপাতত, আমি মনে করি এটি এখানে আরও ভাল হতে পারে।
ভার্চুসিমিডিয়া

@ আন্নলায়ার এসি, ওপিতে সম্মত হন যদি তারা অ্যাপ নির্দিষ্ট কোড চান।
jcolebrand

উত্তর:


13

ঠিক আছে, আসুন এটি ভেঙে দিন:

  • একাধিক ডাটাবেসে দুটি টেবিলের মধ্যে কীভাবে যুক্ত হয়? (এখানে একটি কোড উদাহরণ সহায়ক হবে)।

এই বেশ সহজ. এসকিউএল অবজেক্টগুলির এক থেকে চার অংশের নামকরণ কনভেনশন থেকে যে কোনও জায়গায় থাকতে পারে:

Servername.databasename.schemaname.tablename

যদি আপনার সমস্ত টেবিল একই ডেটাবেসে একই সার্ভারে থাকে, একই মালিক / স্কিমা সহ, আপনি কেবল প্রথম তিনটি অংশ উপেক্ষা করতে পারেন এবং আপনি যা ব্যবহার করতে চান তা ব্যবহার করতে পারেন:

Select a.*,b.* from 
tableA a inner join 
tableB b on a.col1=b.col1

যদি আপনার টেবিলগুলির মধ্যে একটি আলাদা ডাটাবেসে থাকে এবং উভয়ই তাদের ডাটাবেসের জন্য ডিফল্ট স্কিমা ব্যবহার করেন, তবে আপনি কেবল দ্বিতীয় টেবিলে ডাটাবেস যুক্ত করুন:

Select a.*,b.* from 
tableA a inner join 
databaseC..tableB b on a.col1 = b.col1

আপনি যদি জিজ্ঞাসা করছেন তার যে কোনও একটি থেকে আপনি যদি কোনও তৃতীয় ডাটাবেসে আলাদা হয়ে থাকেন তবে আপনি উভয় ডাটাবেসের নাম স্পষ্টভাবে ব্যবহার করেন:

Select a.*,b.* from 
databaseD..tableA a inner join 
databaseC..tableB b on a.col1 = b.col1

যদি আপনি বিভিন্ন স্কিমা এবং / বা মালিক ব্যবহার করে শেষ করেন তবে আপনি এগুলিকে যুক্ত করতে পারেন:

Select a.*,b.* from 
databaseD.john.tableA a inner join 
databaseC.accounting.tableB b on a.col1 = b.col1

এবং সর্বশেষে, আপনি যদি এটি সম্পর্কে খুব সাবধান হন এবং খুব ভাল কারণ থাকে তবে আপনি অন্য সার্ভারের একটি (সাধারণত ছোট) টেবিলে যোগ দিতে পারেন:

Select a.* from 
databaseD.john.TableA a inner join 
ATLANTA.databaseC.accounting.tableB b on a.col1 = b.col1
  • 1 টি ডাটাবেস / 1 সার্ভার সেটআপের বাইরে চলে যাওয়ার সময় কখন? এটি করা কতটা সাধারণ? কোন ডাটাবেসে কোন সারণী রয়েছে তা ট্র্যাক করার জন্য কোনও বিশেষ কৌশল আছে?

আমি এই দুটি একত্রিত করব কারণ তারা একসাথে যায়। আপনার নকশা / ব্যবসায় / প্রযুক্তিগত সীমাবদ্ধতা আপনাকে আরও ব্যবহার করতে বাধ্য না করা অবধি আপনার এক ডেটাবেস এক সার্ভারই ​​যথেষ্ট বলে ধরে নেওয়া শুরু করার জন্য প্রায় সর্বদা সাধারণ fine

প্রথমে আপনার দ্বিতীয় প্রশ্নের উত্তর দেওয়ার জন্য, যেহেতু আপনার কাছে সাধারণত পৃথক ডাটাবেস থাকার কারণ থাকে তাই এটি আপনার সিস্টেমের নকশাটি যেখানে কিছু রয়েছে তা জানা থেকে মোটামুটি স্পষ্ট হওয়া উচিত।

কখন / কেন এটি একটি একক ডাটাবেসের বাইরে যাওয়ার প্রয়োজন। সাধারণত এটি ব্যবসায়িক বিধি, রাজনীতি এবং / বা প্রযুক্তিগত কারণে মিশ্রিত হয়।

উদাহরণস্বরূপ, আমি যেখানে কাজ করি সেখানে আমাদের 4 টি সার্ভারে 16 টি ডাটাবেস ছড়িয়ে আছে। আমাদের একটি মেইনডিবি, ইমেজডিবি, রেফারেন্সেবল ডিবি, হাইভলিউম ট্রান্সজেকশনডিবি, রিপোর্টিংডিবি, স্টেজিংডিবি, প্রসেসিংডিবি, আর্কাইভডিবি, ফিনান্সিয়ালডিবি রয়েছে। এগুলি কেন আলাদা তার কয়েকটি উদাহরণ দেওয়া:

  • ফিনান্সিয়ালডিবি, সংবেদনশীল তথ্য
  • চিত্র ডিবি, নির্দিষ্ট বিভিন্ন স্টোরেজ এবং পুনরুদ্ধারের প্রয়োজনীয়তা
  • রেফারেন্সডিবি, কম লেনদেন, উচ্চ পঠিত
  • रिपोर्टিংডিবি, খুব উচ্চ পঠিত, অন্যান্য অন্যান্য তথ্যের থেকে ভিন্ন ভিন্ন অন্যান্য পরিবেশে পুনরুদ্ধার / পুনরুদ্ধার করা দরকার
  • স্টেজিংডিবি, স্থায়ী কিছুই নয়, কেবলমাত্র একটি বিফ আপ আপ টেম্পডিবি যা আমাদের আরও নিয়ন্ত্রণ করে
  • মেইনডিবি, অন্যান্য সমস্ত ডিবি'র সাথে ইন্টারফেস রয়েছে তবে ডিফারেনশিয়াল ব্যাকআপ প্রয়োজন তাই ... আমরা বিভক্ত হয়ে যাই
  • হাইভোলিউম ট্রান্সজেকশন টেবিলগুলি (যা তুলনামূলকভাবে ক্ষণস্থায়ী হয়) তাদের নিজস্ব ডিবিতে যাতে ব্যাকআপটি যুক্তিযুক্ত আকার রাখতে পারে।
  • সংরক্ষণাগারভুক্ত, মেইন এবং রিপোর্টিং থেকে একই তথ্য প্রচুর, তবে দীর্ঘতর ধরে রাখার সময়সীমা এবং ডেটা আরও গভীরভাবে খনন করা শক্ততর মারধর অনুসন্ধানগুলি। যদি এখনও এটি মেইন / রিপোর্টিংয়ের সাথে একত্রিত করা হয় তবে এটি আমাদের সিস্টেমটিকে নষ্ট করবে।

জানতে দেয় আবেদন কোড প্রয়োজন যা এক বা একাধিক ডাটাবেস একাধিক সার্ভার জুড়ে ছড়িয়ে আছেন? যদি তা না হয় তবে অনুরোধগুলি কোন স্তরে ফিল্টার করা হয়?

একটি বিস্তৃত অর্থে, তারা সম্ভবত। ডেটাবেস সংযোগ স্ট্রিংয়ে তারা কোন সার্ভারের দিকে ইশারা করছে তা ন্যূনতমভাবে তাদের জানতে হবে। প্রসেসিং, রিপোর্টিং, মেইন, ইত্যাদি

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

স্বাভাবিক, (বা কমপক্ষে, আমার স্বাভাবিক) সাধারণত পন্থা হ'ল সর্বদা এক বা দুটি প্রধান ডাটাবেসের মাধ্যমে অ্যাক্সেস করা।

তারপরে সঞ্চিত প্রক্রিয়াগুলির মাধ্যমে ডাটাবেসের সাথে ইন্টারফেসিংয়ের সাথে মিলিয়ে প্রয়োজনীয় অন্যান্য ডেটাবেজে ভিউ তৈরি করুন।

সুতরাং উদাহরণস্বরূপ:

ধরা যাক আপনি কোনও ক্লায়েন্টের ডেমোগ্রাফিক তথ্য, বিক্রয় ডেটা এবং ক্রেডিট ব্যালেন্স পেতে চান এবং এটি মূলত তিনটি টেবিল জুড়ে মেইনডিবিতে ছড়িয়ে পড়ে।

সুতরাং আপনি আপনার অ্যাপ্লিকেশন থেকে একটি কল লিখুন:

Select c.ClientName, c.ClientAddress, s.totalSales,f.CreditBlance from
Clients c join Sales s on c.clientid = s.clientid inner join AccountReceivable f on 
c.clientid=f.clientid where c.clientid = @clientid

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

Use MainDB
GO
Create view v_Clients as select * from Clients
Create view v_Sales as select * from Sales
Create view v_AccountReceivable as select * from AccountReceivable
Go

তারপরে আমরা একটি সঞ্চিত পদ্ধতিও তৈরি করব, spGetClientSalesAR

Create proc spGetClientSalesAR @clientID int
as
Select c.ClientName as ClientName, 
       c.ClientAddress as ClientAddress, 
       s.totalSales as TotalSales, 
       f.CreditBlance as CreditBalance 
from
v_Clients c join v_Sales s 
    on c.clientid = s.clientid 
inner join v_AccountReceivable f 
    on c.clientid=f.clientid 
where c.clientid = @clientid

এবং আপনার অ্যাপ্লিকেশন কল যে।

এখন যতক্ষণ না আমি সেই সঞ্চিত প্রকল্পের ইন্টারফেসটি পরিবর্তন করি না, আমি ব্যাকএন্ড ডাটাবেসে স্কেল আপ বা আউট করার জন্য আমার যা কিছু করতে হবে তা করতে পারি।

চূড়ান্তভাবে, আমি এমনকি আমার পুরানো মেইনডিবিটিকে কেবল সেলের মতো সঞ্চিত পদ্ধতি এবং এমন মতামত তৈরি করতে পেরেছিলাম যা আমাদের তৈরি করা মতামতের নীচে এর মতো দেখাচ্ছিল:

Create view v_Clients as select * from ServerX.DatabaseY.dbo.Clients
Create view v_Sales as select * from ServerQ.DatabaseP.dbo.Sales
Create view v_AccountReceivable as select * from ServerJ.DatabaseK.dbo.AccountReceivable

এবং আপনার অ্যাপ্লিকেশনটি কখনই পার্থক্যটি জানতে পারে না, (দ্রুত পাইপ এবং অন্যান্য জিনিসের মধ্যে ভাল স্টেজযুক্ত ডেটা ধরে)।

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


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

ওহ ধন্যবাদ. আমি ওটার তারিফ করি. প্রশ্নের উত্তর দিয়ে খুব মজা লাগছিল।
টেটনসিগ

5

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


3

একাধিক ডাটাবেসে দুটি টেবিলের মধ্যে কীভাবে যুক্ত হয়? (এখানে একটি কোড উদাহরণ সহায়ক হবে)।

তারা না. নোএসকিউএল ডাটাবেসগুলি একেবারে "যোগ দেয়" না, এবং আপনি আরডিবিএমএস সার্ভার জুড়ে কোনও এসকিউএল যোগ দিতে পারলেও , আপনি যদি পারফরম্যান্সকে ( ডিস্ট্রিবিউটেড কম্পিউটিংয়ের সিএফ ফলসেসি ) মূল্য দেন তবে আপনি চাইবেন না ।

কোন ডাটাবেসে কোন সারণী রয়েছে তা ট্র্যাক করার জন্য কোনও বিশেষ কৌশল আছে?

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

যদি আপনি আসলে শারীরিকভাবেই নয়, লজিকালভাবে ডেটাবেস বিভক্ত করেন তবে আপনার ডাল বা ওআরএম-এ সংজ্ঞায়িত ম্যাপিংগুলি ঘোষণা করবে যে কোন ডাটাবেসে টেবিল রয়েছে।

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

এটি অবশ্যই ধরে নেওয়া যায় যে আপনি প্রকৃতপক্ষে শার্পিং বৈশিষ্ট্যগুলি ব্যবহার করছেন এবং কেবল বিভিন্ন ডেটাবেস তৈরি করছেন না। আপনি যদি পরে কাজটি করে থাকেন তবে আপনি নিজেরাই।

এক বা একাধিক ডাটাবেস একাধিক সার্ভারে ছড়িয়ে রয়েছে তা কি অ্যাপ্লিকেশন কোডটি জানতে হবে? যদি তা না হয় তবে অনুরোধগুলি কোন স্তরে ফিল্টার করা হয়?

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

1 টি ডাটাবেস / 1 সার্ভার সেটআপের বাইরে চলে যাওয়ার সময় কখন? এটি করা কতটা সাধারণ?

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

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

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


+1 - আমি আসলেই নোএসকিউএল বিবেচনা করছিলাম না, তবে এটি সমস্ত ক্ষেত্রে সহায়ক। ধন্যবাদ।
ভার্চুসিমিডিয়া

1

ডাটাবেসগুলির জন্য তিনটি বড় ধরণের প্রতিলিপি কনফিগারেশন রয়েছে:

  • মনিব গোলাম
  • মাস্টার-মাস্টার
  • ঐক্য

মাস্টার-স্লেভ উদাহরণ: মাইএসকিউএল মাস্টার + মাইএসকিউএল ক্রীতদাস, মঙ্গোডিবি

মাস্টার-মাস্টার উদাহরণ: কাউচডিবি, ক্যাসান্দ্রা, রিয়াক

Sensকমত্যের উদাহরণ: স্কালিয়েনডিবি

... কয়েক নাম রাখা।

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

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

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

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

আমি আশা করি আমি ভাবনার জন্য কিছু খাবার দিয়েছি :)। আপনি এই জিনিসগুলি সম্পর্কে টুইটগুলি দেখতে চাইলে আপনি টুইটার @henrikfeldt এ আমাকে অনুসরণ করতে পারেন।


1

ঠিক আছে, সুতরাং এখানে স্কেলাবিলিটি সম্পর্কিত আরও একটি দৃষ্টিভঙ্গি।

আসুন আমরা আলোচ্য বিষয়গুলিকে ডেটা হওয়ার কী বোঝায়, আচরণ করা কী বোঝায় এবং অ্যাপ্লিকেশন যুক্তি রাখার অর্থ কী।

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

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

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

এর মূল ক্ষেত্রে, ধারণাটি হ'ল স্তরগুলি বিনিময়যোগ্য; কিন্তু তারা না! কেন? সমস্ত কল-সাইট কাপলিংয়ের কারণে।

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

ডেটা প্যাকেজটি নীচে ইথারনেট এবং কাঁচা বৈদ্যুতিক সংকেতের দিকে চলার সাথে সাথে এটি ধারাবাহিকভাবে স্তরগুলি মুড়িয়ে যায় যা কেবল তার নিজস্ব নির্দিষ্ট বার্তা খামের, তার নিজস্ব নির্দিষ্ট 'বাইটের ব্যাচ' যা এটি প্রেরণ করতে পারে তা জানে; এবং আর কিছুনা. প্যাকেজের সামগ্রীর উপর নির্ভর করে কল-পাথগুলি পরিবর্তন করার দরকার নেই।

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

এটি কোনও কম্পিউটিং দৃষ্টিকোণ থেকে স্কেলযোগ্য বা সর্বোত্তম নয়।

কেন এটি স্কেলেবল নয়? কারণ আর্কিটেকচারটি মিলিত হয়েছে, এবং তারপরে আপনি এখনও একই পুরাতন ডিবি-র অভ্যন্তরে রয়েছেন যা আপনি অনেকগুলি নোডকে স্কেল করার চেষ্টা করছেন! তবে, কারণ এর জন্য আপনার এসিডি দরকার, এটি এবং একটি তৃতীয় সত্তা (ডেটা অবজেক্ট) আপনার তাদের একটি একক ডাটাবেসে রাখতে হবে যা লেনদেন করে!

পরাক্রমশালী, তাই পথের বাইরে ছড়িয়ে পড়ে; আর কোন উপায় আছে?

ঠিক আছে, 'এসওএ' নামক ঘৃণ্য সংক্ষিপ্ত বিবরণ আছে, অর্থাত্ পরিষেবামুখী আর্কিটেকচার অবশ্যই, বিশ্বের টমাস এরলস, আপনি আপনার সমস্ত স্তরগুলি প্রয়োগ করতে পারবেন তবে পরিবর্তে এক্সএমএল এবং এসওএপি দিয়ে।

উপরের সমস্ত কারণে, এটি যাওয়ার ভুল উপায়, কারণ আপনি এই এক্সএমএল প্রক্সিগুলির সাথে নিজেকে সংযুক্ত করছেন, ঠিক যেমন আপনি উপরে বর্ণিত অ্যাপ্লিকেশন স্তরগুলিতে নিজেকে জুড়ি দিয়েছিলেন।

পরিবর্তে, মেসেজিং ব্যবহার করুন এবং যা কিছু কার্যকর করে তাদের জন্য কার্যকারিতা দিন, তাদের শুনুন। আপনার পরিষেবা পৃষ্ঠ তখন আপনার বার্তাগুলির একটি তালিকা হয়ে যায় যা আপনি প্রেরণ করতে পারেন এবং আপনি আপনার পরিষেবাটি আপনার পরিষেবাটির সম্মুখভাগে মিশ্রিত করেন নি; এবং আপনাকে কী অ্যাপ্লিকেশন বা শেষ পয়েন্টগুলি এই ক্রিয়াকলাপগুলি বাস্তবায়িত করে তাও জানতে হবে না, কারণ আপনি যা করছেন তা অন্য কোনও রাউটিং মেকানিজম সঠিক গ্রাহকের দিকে যাত্রা করবে এমন বার্তা প্রকাশ করছে!

আপনি যে কার্য সম্পাদন করতে চান সেগুলি থেকে পরিষেবাটি সম্মুখের দিকে ডিক্লোল করে দেওয়ার কারণে, আপনি এখন একাধিক পরিষেবা যুক্ত করতে পারেন; আসলে নেটফ্লিক্স এটি এটি করে। এই উপস্থাপনাগুলি একবার দেখুন: http://www.slideshare.net/adrianco/global-netflix-platformhttp://www.slideshare.net/adrianco/global-netflix-platform । তারা ভালো!


0

বিটাতে একটি নতুন এসকিউএল (এসিডি) ডাটাবেস রয়েছে যা দাবি করে যে স্থিতিস্থাপক স্কেলিং বৈশিষ্ট্য রয়েছে। এখানে এখন একটি নিখরচায় বিটা প্রোগ্রাম চলছে এবং আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি এটি দেখতে পারেন, একে নুওডিবি বলে।

স্পষ্টতই এটি সহজেই একক থ্রেডেড মেশিনে মাইএসকিউএলকে ছাড়িয়ে যায়, তবে নির্দিষ্ট বেঞ্চমার্কগুলিতে খুশির সাথে স্কেল করে 70+ দৃষ্টান্তে।


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