জিরো ডাউনটাইম মোতায়েন - ট্রানজিশনাল ডিবি স্কিমা


14

জিরো ডাউনটাইম ডিপ্লোয়মেন্ট অর্জন একই সমস্যাটি স্পর্শ করেছে তবে আমি যে কৌশলটি বিবেচনা করছি তাতে আমার কিছু পরামর্শের প্রয়োজন।

প্রসঙ্গ

সার্ভার-সাইড প্রসেসিংয়ের জন্য অ্যাপাচি / পিএইচপি এবং অধ্যবসায়ের জন্য মাইএসকিউএল ডিবি / ফাইল সিস্টেমের সাথে একটি ওয়েব-ভিত্তিক অ্যাপ্লিকেশন।

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

এটি আমার উদ্দেশ্য যে আমরা কোনও ডাউন-টাইম ছাড়াই অ্যাপ্লিকেশনটিতে আপডেটগুলি প্রয়োগ করতে সক্ষম। আমি 100% আপ-টাইম সরবরাহ করতে পারি তা নিশ্চিত করার জন্য অবকাঠামোগত নকশা করার সময় আমি প্রচণ্ড ব্যথা পেয়েছি; এটি ততবার হতাশ হবে যে প্রতিবার আপডেট প্রয়োগের সময় 10-15 মিনিট ডাউনটাইম থাকবে। এটি খুব তাড়াতাড়ি তাত্পর্যপূর্ণ কারণ আমরা খুব দ্রুত প্রকাশের চক্র রাখার ইচ্ছা করি (কখনও কখনও এটি প্রতিদিন এক বা একাধিক প্রকাশে পৌঁছতে পারে)।

নেটওয়ার্ক টপোলজি

এটি নেটওয়ার্কের সংক্ষিপ্তসার:

                      Load Balancer
             |----------------------------|
              /       /         \       \  
             /       /           \       \ 
 | Web Server |  DB Server | Web Server |  DB Server |
 |-------------------------|-------------------------|
 |   Host-1   |   Host-2   |   Host-1   |   Host-2   |
 |-------------------------|-------------------------|
            Node A        \ /        Node B
              |            /            |
              |           / \           |
   |---------------------|   |---------------------|
           Switch 1                  Switch 2

   And onward to VRRP enabled routers and the internet

দ্রষ্টব্য: ডিবি সার্ভারগুলি মাস্টার-মাস্টার প্রতিলিপি ব্যবহার করে

প্রস্তাবিত কৌশল

এটি অর্জনের জন্য, আমি বর্তমানে ডিবি স্কিমা আপগ্রেড স্ক্রিপ্টগুলি দুটি ভাগে ভাঙ্গার কথা ভাবছি। আপগ্রেডটি দেখতে এটির মতো হবে:

  1. নোড এ ওয়েব-সার্ভারটি অফ-লাইন নেওয়া হয়েছে; নোড বি-তে ওয়েব-সার্ভার দ্বারা ট্রাফিক প্রক্রিয়াজাতকরণ অব্যাহত রয়েছে B.
  2. ট্রানজিশনাল স্কিমা পরিবর্তনগুলি ডিবি সার্ভারগুলিতে প্রয়োগ করা হয়
  3. ওয়েব-সার্ভার একটি কোড-বেস আপডেট হয়েছে, ক্যাশে সাফ হয়ে গেছে এবং অন্য কোনও আপগ্রেড পদক্ষেপ নেওয়া হয়েছে।
  4. ওয়েব-সার্ভার এ অনলাইনে আনা হয় এবং ওয়েব-সার্ভার বি অফলাইনে নেওয়া হয়।
  5. ওয়েব-সার্ভার বি কোড-বেস আপডেট হয়েছে, ক্যাশে সাফ করা হয়েছে এবং অন্য কোনও আপগ্রেড পদক্ষেপ নেওয়া হয়েছে।
  6. ওয়েব সার্ভার বি অনলাইন আনা হয়।
  7. চূড়ান্ত স্কিমা পরিবর্তনগুলি ডিবিতে প্রয়োগ করা হয়

'ট্রানজিশনাল স্কিমা' ক্রস সংস্করণে সামঞ্জস্যপূর্ণ ডিবি তৈরির জন্য ডিজাইন করা হবে। এটি বেশিরভাগ টেবিলের মতামত ব্যবহার করবে যা পুরানো সংস্করণ স্কিমা অনুকরণ করে টেবিলটি নিজেই নতুন স্কিমাতে পরিবর্তিত হবে। এটি পুরানো সংস্করণটিকে ডিবি হিসাবে স্বাভাবিক হিসাবে ইন্টারঅ্যাক্ট করতে দেয়। টেবিলের নামগুলিতে স্কিমা সংস্করণ নম্বর অন্তর্ভুক্ত থাকবে তা নিশ্চিত করার জন্য কোন টেবিলটি লিখতে হবে তাতে কোনও বিভ্রান্তি সৃষ্টি হবে না।

'ফাইনাল স্কিমা' পিছনের সামঞ্জস্যতা সরিয়ে স্কিমাকে পরিপাটি করে।

প্রশ্ন

সংক্ষেপে, এই কাজ করবে?

আরো নির্দিষ্টভাবে:

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

  2. এমন কি সহজ পদ্ধতি আছে যা এই ডিগ্রি স্থিতিশীলতা সরবরাহ করে যখন ডাউন-টাইম ছাড়াই আপডেটগুলিও অনুমতি দেয়? আমি 'বিবর্তনীয়' স্কিমা কৌশল এড়াতেও পছন্দ করি কারণ আমি পিছনে স্কিমা সামঞ্জস্যের মধ্যে আবদ্ধ হতে চাই না।

উত্তর:


4

মনে হচ্ছে আপনি যা খুঁজছেন তা তেমন উচ্চ উপলব্ধতা নয় কারণ আপনার অবিচ্ছিন্ন প্রাপ্যতা প্রয়োজন ।

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

প্রোডাকশন ওয়ান

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

প্রোডাকশন টু

এটি মূলত মঞ্চে পরিবেশ প্রকাশ করে যা একের প্রোডাকশনের অনুরূপ। আপনি এখানে আপনার রিলিজ আপগ্রেডগুলি সম্পাদন করতে পারেন এবং আপনার যাওয়ার সরাসরি ইভেন্টের আগে নিজের স্যানিটি পরীক্ষা করতে পারেন। এটি আপনাকে এই পরিবেশে আপনার ডাটাবেস পরিবর্তনগুলি নিরাপদে সম্পাদন করতে সহায়তা করে। লোড ব্যালান্সার বর্তমানে এই পরিবেশের দিকে ইঙ্গিত করে না।

প্রোডাকশন ডি

এটি পৃথক তথ্য কেন্দ্রে অন্য একটি নকল যা বিশ্বের বিভিন্ন অঞ্চলে অবস্থিত। এটি আপনাকে লোড ব্যালেন্সারে ডিএনএস স্যুইচ করে বিপর্যয়কর ইভেন্টে ব্যর্থ হতে দেয়।

সরাসরি যাও

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

তথ্য স্থানান্তর

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

উপসংহার

একবার আপনি আপনার প্রকাশের ইভেন্ট সম্পূর্ণরূপে শেষ করার পরে, প্রোডাকশন টু এখন আপনার প্রাথমিক এবং আপনি পরবর্তী স্থাপনার চক্রের জন্য পরবর্তী প্রকাশের প্রোডাকশন ওনে ইনস্টল করার কাজ শুরু করবেন।

অপূর্ণতা

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


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

@ পিটারস্কট আপনি এটি পেয়েছেন কেবল মনে রাখবেন যে আপনি পুরানো সিস্টেমে সমস্ত সক্রিয় সেশন শেষ হয়ে গেছে এবং আপনার ডিএনএসের সমস্ত ক্যাশে নতুন সিএনএল বা আইপি ঠিকানায় আপডেট হয়েছে এমনটি নিশ্চিত হওয়া পর্যন্ত আপনি স্ক্রিপ্টটি চালাতে চান না।
maple_shaft

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

2

আপনার কৌশলটি দৃ is়। আমি কেবল "ট্রানজিশনাল স্কিমা "টিকে" লেনদেন সারণী "এর সম্পূর্ণ সেটে বিস্তৃত করার বিষয়ে বিবেচনা করার প্রস্তাব দেব।

লেনদেনের টেবিলগুলির সাথে, নির্ভুলতা নিশ্চিত করার জন্য SELECTs (কোয়েরিগুলি) সাধারণীকৃত টেবিলগুলির বিরুদ্ধে করা হয়। তবে সমস্ত ডাটাবেস INSERTs, আপডেট এবং ডিলিটগুলি সর্বদা অস্বীকৃত লেনদেনের টেবিলগুলিতে লেখা থাকে।

তারপরে একটি পৃথক, সমবর্তী প্রক্রিয়া ব্যবসায়ের নিয়ম এবং স্কিমা প্রয়োজনীয়তা প্রতিষ্ঠিত অনুযায়ী সাধারণ পরিবর্তনসমূহ (সম্ভবত সঞ্চিত পদ্ধতি ব্যবহার করে) প্রয়োগ করে changes

বেশিরভাগ সময়, এটি কার্যত তাত্ক্ষণিক হবে। তবে ক্রিয়াগুলি পৃথক করা সিস্টেমকে অতিরিক্ত ক্রিয়াকলাপ এবং স্কিমা আপডেটের বিলম্বকে সামঞ্জস্য করতে দেয়।

ডাটাবেস (বি) এ স্কিমা পরিবর্তনের সময়, সক্রিয় ডাটাবেস (এ) এর ডেটা আপডেটগুলি তার লেনদেনের টেবিলগুলিতে চলে যায় এবং তাত্ক্ষণিকভাবে তার সাধারণ টেবিলগুলিতে প্রয়োগ করা হত।

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

কোনও লেনদেনের টেবিল সারিতে এমন কিছু লাগতে পারে ...

| ROWID | TRANSNR | DB | TABLE | SQL STATEMENT
    0        0       A    Name   INSERT INTO Name ...
    1        0       A    Addr   INSERT INTO Addr ...
    2        0       A    Phone  INSERT INTO Phone ...
    3        1       A    Stats   UPDATE Stats SET NrOfUsers=...

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

ধারণাটি ডাবল-এন্ট্রি বুককিপিং এবং একই কারণে একই নীতি অনুসরণ করে।

লেনদেনের টেবিলগুলি বুককিপিং "জার্নাল" এর সাথে সাদৃশ্যপূর্ণ। সম্পূর্ণরূপে সাধারণীকরণযোগ্য টেবিলগুলি বুককিপিং "খাতা" এর সাথে সাদৃশ্যযুক্ত এবং প্রতিটি টেবিল কিছুটা বুককিপিং "অ্যাকাউন্ট" এর মতো হয়।

বুককিপিংয়ে প্রতিটি লেনদেন জার্নালে দুটি এন্ট্রি পায়। একটি "ডেবিটেড" খাত্তরের অ্যাকাউন্টের জন্য এবং অন্যটি "জমা দেওয়া" অ্যাকাউন্টের জন্য।

আরডিবিএমএসে, একটি "জার্নাল" (লেনদেনের টেবিল) প্রতিটি লেনদেনের পরিবর্তে প্রতিটি সাধারণ টেবিলের জন্য একটি প্রবেশিকা পায়।

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


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

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

পুরানো স্কিমাটি নতুন স্কিমাতে প্রয়োগ করার জন্য আপনি কীভাবে নির্বাচিত অনুসন্ধানগুলি রোধ করবেন? আমি একটি টেবিল ভিউ তৈরি করতে এবং স্কিমা টেবিলটির নামকরণ (স্কিমা সংস্করণ নম্বর সহ) ব্যবহার করতে পারতাম তবে স্কিমার পরিবর্তনগুলি প্রয়োগ করা হচ্ছে যখনই তারা সাধারণীকরণের টেবিলটিতে সরাসরি প্রয়োগ করে তবে এটি সমস্যাযুক্ত হবে।
মারভিন

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

ধন্যবাদ। আমি এই সম্পর্কে চিন্তা করা প্রয়োজন। আমি অ্যাপ্লিকেশনটিতে একটি ওআরএম স্তর তৈরি করছি যা মূল ডোমেন থেকে সমস্ত রাজ্যের দৃistence়তা যুক্তিটিকে সম্পূর্ণভাবে সরিয়ে দেয়; সার্ভার-সাইড প্রোগ্রামিংয়ের উপর ভিত্তি করে আমি ডিবি প্রশাসনের পক্ষের চেয়ে সেই দিক থেকে সমস্যাগুলি আরও সমাধান করার প্রবণতা রাখি। আমার বর্তমান কৌশলটি ব্যবহার করে, ডিবি ORM সক্রিয়ভাবে কাঁচা টেবিলগুলি পরিচালনা করার সাথে যথেষ্ট সমতল হবে। সারণী দর্শন যোগ করা এবং সম্ভবত, একটি লেনদেন লগ ওআরএম-তে আরও বেশি জটিলতা যুক্ত করে তবে এটি একাধিক স্কিমা সংস্করণকে ডেটা স্প্লিন্টিং ছাড়াই সমর্থন করার জন্য সহায়তা করে।
মারভিন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.