একক ভি / গুলি একাধিক ডাটাবেস

Question

আমি এই ওয়েব অ্যাপটি তৈরি করেছি (পিএইচপি এবং মাইএসকিএল) যা বিভিন্ন সংস্থার (বর্তমানে প্রায় 20 ক্লায়েন্ট) তথ্য সরবরাহ করে।

বর্তমান পরিস্থিতি পৃথক ডাটাবেসে ক্লায়েন্ট সম্পর্কিত তথ্য সংরক্ষণ করে, তাই সেখানে 20 ক্লায়েন্ট ডাটাবেস এবং 1 টি মাস্টার ডাটাবেস রয়েছে।

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

প্রতিটি ডিবিতে প্রায় 15 টি টেবিল থাকে এবং একটি সারণীর সর্বাধিক সারি প্রায় 2000 হয় This এটিকে সর্বাধিক 5000 রেকর্ড পর্যন্ত ছাঁটাই করা হবে বলে আশা করা হচ্ছে।

একটি একক ডিবি-স্তরের পরিবর্তন পরিচালনার অর্থ 20 টি ডাটাবেস পরিবর্তন করা, তবে বিরল ইভেন্টে আমার এই ধরনের পরিবর্তন আনা দরকার, আমি এমন একটি স্ক্রিপ্ট ব্যবহার করি যা একক ফাংশন কলে এটি করে।

আমরা একটি শেয়ার্ড হোস্টিংয়ের ব্যবস্থা করছি এবং আমাদের আইএসপি আমাদের সীমাবদ্ধ নং সরবরাহ করে। ডাটাবেসের; এবং এটিই আমাকে ডাটাবেসকে কেন্দ্রীকরণের দিক দিয়ে ভাবতে পরিচালিত করেছিল; যাতে সমস্ত ক্লায়েন্টের ডেটা মাস্টার ডাটাবেসে সংরক্ষণ করা যায়।

অবশ্যই, কিছু গুরুত্বপূর্ণ সমস্যা যা ক্রপ হয়:

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

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

আপনি কি মনে করেন যে কেন্দ্রীভূত ডাটাবেসে স্থানান্তরিত হওয়া আমাদের মতো (স্বতন্ত্র ডাটাবেসে) থাকার চেয়ে আরও বেশি অর্থবোধ করে?

আপনার উপদেশের জন্য ধন্যবাদ.

Comments

এটি আমার কাছে ওয়েবমাস্টারদের ইস্যুর চেয়ে স্ট্যাকওভারফ্লো প্রশ্নের মতোই বেশি অনুভব করে?

— কান্দার

এটি স্ট্যাকওভারফ্লো ডট কমের জন্য।

— vmarquez

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

— বেনাম কাপুরুষ 21

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

— মারিও

Answer 1

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

একক ডিবি'র প্রো:

1. সফ্টওয়্যার আপডেট এবং বাগ ফিক্সগুলি আরও সহজ।
2. সমস্ত ক্লায়েন্টের ডেটা পরিচালনা এবং প্রতিবেদন করা সহজ।
3. ডেটা আপডেট করা সহজ হয়ে যায়।
4. 1 ক্লায়েন্ট চায় এমন মডুলার কার্যকারিতা তৈরি করা সহজ, অন্য ক্লায়েন্টদের জন্য বন্ধ করুন এবং ভবিষ্যতে যখন তারা এটি চান তখন এটিকে ঘুরিয়ে দিন।

একক ডিবি এর কন:

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

একাধিক ডিবি'র প্রো:

1. ক্রস ক্লায়েন্টের ডেটা দূষণ বা লঙ্ঘনের কোনও উদ্বেগ নেই
2. ক্লায়েন্টের ডেটা রফতানি করা সহজ dead

একাধিক ডিবি'র কন:

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

শেষ পর্যন্ত আমার সুপারিশটি উভয়ই দেখেছি এবং করেছে তা হচ্ছে "শৃঙ্খলা" থাকা! আমি মনে করি মাল্টি-ডিবি পছন্দটি কিছুটা ভাল কারণ এটি আপনাকে রক্ষা করে তবে আপনি ক্লায়েন্টদের এমন কোনও পছন্দ করতে পারবেন না যার ফলে আপনি কেবল তাদের সাথে কার্যকারিতা যুক্ত করতে পারেন বা আপনি নিজেকে ব্যর্থতার পথে রাখবেন।

Comments

সাথী ধন্যবাদ, আপনার সহায়তার প্রশংসা করুন। আমি সম্মত হই যে এটি শৃঙ্খলাবদ্ধ পদ্ধতির সাথে এ জাতীয় যে কোনও সমস্যা মোকাবেলা করতে এবং সিস্টেমটি কীভাবে প্রসারিত হবে তা নিয়ে কঠোর তদারকি করার জন্য এটি উত্সাহিত হয়।

— নারায়ণ

Answer 2

আমি পৃথক ক্লায়েন্টদের জন্য পৃথক ডাটাবেস চাই। কোনও ক্লায়েন্ট সুরক্ষার কারণে এই দাবি করতে পারে - যেমন কেবল তাদের সাইটের তাদের ডেটাতে অ্যাক্সেস রয়েছে। এর অর্থ হ'ল কোনও ক্লায়েন্ট যদি তাদের ডেটা সরিয়ে নিতে চান তবে এটি পরিচালনা করা আরও সহজ হতে চলেছে ।

এর অর্থ হ'ল যদি কোনও ক্লায়েন্টের ডাটাবেসে কোনও সমস্যা হয় তবে এটি অন্য সকলকে প্রভাবিত করে না।

আপনি যদি ক্লায়েন্টদের মধ্যে ডেটা তুলনা করতে চান তবে আপনার এটি আলাদাভাবে করা উচিত।

যদি আপনার কাছে থাকা ডাটাবেসগুলি শেষ হয়ে যায় তবে সম্ভবত আপনার হোস্ট সরবরাহকারীর পরিবর্তনের কথা বিবেচনা করা উচিত।

Comments

ক্লায়েন্টদের তাদের ডেটা জিজ্ঞাসা করার জন্য +1। পৃথক ডাটাবেসগুলির জন্য অর্থ প্রদানের চেয়ে ক্লায়েন্টের ডেটা কেবল বের করার জন্য কিছু লিখতে এটি দ্রুত ব্যয়বহুল হয়ে উঠতে পারে।

— কারসন

কেবল তা-ই নয়, এটি পৃথক হারগুলিতে পৃথক ক্লায়েন্টকে 'স্কেল' দেয়, যা একটি প্রধান প্লাস।

— টিম পোস্ট

@ টিম - ভাল পয়েন্ট

— ক্রিসএফ

ওহে, upvote করতে ভুলে গেছেন। +1 :)

— টিম পোস্ট

@ টিম এবং @ ক্রিসকে ধন্যবাদ, আপনার অন্তর্দৃষ্টি সহায়ক হয়েছে।

— নারায়ণ

Answer 3

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

তবে এই মামলাটি বাদ দিয়ে আমি মনে করি একাধিক ডাটাবেসই ভাল।

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

এছাড়াও, একাধিক ডাটাবেসগুলি এই টেবিলগুলিতেও পিতা-মাতার রেকর্ড আইডির প্রয়োজনীয়তা ছাড়াই সাব টেবিলগুলিকে (যেমন ফোনের ধরণের) সহজেই ক্লায়েন্ট প্রতি কাস্টমাইজ করতে সক্ষম হয়।

Answer 4

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

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

রাস্তাটির নিচে, 100 টি ডাটাবেসের জন্য একই কাজ করার চেয়ে একক ডাটাবেস স্কেল করা (পার্টিশন, হার্ডওয়্যার, শারডিং ইত্যাদি) সহজ easier

আমি মনে করি অন্যান্য পোস্টারগুলি কিছু দুর্দান্ত পয়েন্ট তৈরি করেছে তাই আমি সেগুলির উপরে যেতে চাই না।

Answer 5

এখন পর্যন্ত তালিকাভুক্ত প্রো / কনসের সাথে যুক্ত করতে:

প্রো একাধিক ডাটাবেস:

1. লকিংয়ের বিষয়গুলি এড়ানো হয়; আমাদের এমন ডাটাবেস রয়েছে যেখানে ক্লায়েন্টরা কয়েকটি টেবিলে ডিডিএল-পরিবর্তনগুলি ট্রিগার করতে পারে। বৃহত্তর টেবিলগুলির জন্য (> 2 মি রেকর্ড) এটি যথেষ্ট পরিমাণের জন্য টেবিলটিকে লক করে দেয়। অসুবিধায় কেবল লোকেরা তাদের নিজস্ব ব্যবহারকারী, সুতরাং এটি ধরণের গ্রহণযোগ্য।

2. নমনীয়তা - কিছু ক্লায়েন্টদের তারা সংরক্ষণ করতে চান ডেটা সম্পর্কিত নির্দিষ্ট ইচ্ছা আছে; মাল্টি-ডাটাবেস আমাদের অন্যান্য ক্লায়েন্টদের জন্য ডেটা মডেলকে বিশৃঙ্খলা না করে বিশেষত তাদের ডেটাবেসগুলিতে পরিবর্তন আনতে নমনীয়তা দেয়।

কনস:

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

ভাগ্য ভালো!

Answer 6

আমি জানি আপনি ইতিমধ্যে একটি উত্তর চয়ন করেছেন, তবে দেখে মনে হচ্ছে এমন আরও একটি সমাধান রয়েছে যা প্রস্তাবিত হয়নি:

সবকিছুকে একটি ডাটাবেসে স্থানান্তরিত করুন, তবে প্রতিটি গ্রাহকের জন্য একটি উপসর্গ ব্যবহার করে টেবিল তৈরি করুন:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

এটি উভয় বিশ্বের সেরা ধরনের।

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

Comments

আমি নিশ্চিত যে এই পদ্ধতির কথা ভাবেনি। এটি বেশ কার্যকর বলে মনে হচ্ছে, তবে তারপরে আবার কী কী এটি সীমাবদ্ধ করে তা স্কেলিংয়ের সময় জটিলতা ফ্যাক্টর। প্রদত্ত প্রতি ক্লায়েন্টে আমার কমপক্ষে 18 টি টেবিল থাকবে, একটি 20-ক্লায়েন্ট সেটআপের অর্থ ডাটাবেসের মধ্যে 360 টি সারণী শুরু হবে। এবং যদি আমরা আমাদের বিক্রয় অনুমানের কাছাকাছি পৌঁছে যাই, 1800 টেবিলের ডেটাবেস পরিচালনা করা বেদনাদায়ক হবে। তুলনামূলকভাবে, 18 টি টেবিল সহ 100 টি ডাটাবেস পরিচালনা করা ভাল। তোমার মন্তব্যের জন্য ধন্যবাদ.

— নারায়ণ

@ নারায়ণ: আপনাকে স্বাগতম এটা অনেক টেবিল। অন্য প্রান্তে, এই সমস্ত টেবিল ক্রিয়াকলাপগুলি সহজেই অটোমেটেড হতে পারে, সুতরাং এটি যতটা বড় দেখায় তেমন বড় বিষয় নয়। আপনার কেবলমাত্র গ্রাহকের টেবিলের নাম তালিকাভুক্ত তালিকা রয়েছে। আসলে বিভিন্ন 100 টি ডাটাবেসে সংযোগ / সংযোগ বিচ্ছিন্ন করার চেয়ে সহজ করে তোলে। যাইহোক, এটি কেবল একটি পরামর্শ ছিল। সেই বিড়ালের চামড়ার অনেক উপায় রয়েছে ways

— সিলভার

PS: আপনার কাছে থাকা টেবিলের সংখ্যার একমাত্র আসল সীমাটি আপনার ওএসে একসাথে খোলার মতো ফাইলের সংখ্যা। একটি সাধারণ লিনাক্স মেশিনের জন্য, এটি ডিফল্টরূপে 75,000। অন্যথায়, Ms এসকিউএল সার্ভার 2 বিএন টেবিল পর্যন্ত অনুমতি দেবে।

— সিলভার