تتميز النظم المحاسبية للشركات بزيادة تدريجية في حجم قواعد البيانات بسبب تراكم المعلومات التاريخية. بمرور الوقت ، يمكن أن يصل حجم قاعدة البيانات إلى أبعاد تثير عددًا من المشكلات في الأداء والصيانة ومساحة القرص المتوفرة والمزيد. نعتبر اليوم طريقتين لحل هذه المشكلة: زيادة موارد الأجهزة وطي البيانات التاريخية.
مقدمة
تتناول هذه المقالة مشكلة طي قواعد البيانات الكبيرة خاصة على النظام الأساسي MS SQL Server. يوصف الحل لهذه المشكلة باستخدام تقنية النسخ المتماثل DBREPLICATION من Softpoint.
العدد
قد يبدأ كل نوع من أنظمة المحاسبة في إظهار ميزاته الخاصة. على سبيل المثال ، في الأنظمة القائمة على منصة 1C ، تنشأ مشاكل في العمليات الروتينية مثل تحديث التكوين وتحديث النظام الأساسي 1C. مع نمو قاعدة البيانات ، يزداد الوضع سوءًا تدريجيًا ؛ عاجلاً أم آجلاً ، يجب اتخاذ تدابير.
النهج رقم 1: الأجهزة
الحل الأكثر وضوحًا وشفافية تقنيًا هو زيادة موارد الأجهزة. يمكن أن يكون هذا إما شراء خوادم أكثر إنتاجية أو تخزين أقراص أو ما إلى ذلك أو استئجار معدات أكثر قوة في مركز بيانات تابع لجهة خارجية أو في مجموعة النظراء.
إذا ذهبت بهذه الطريقة ، فإن الخيار الجيد هو وضع قاعدة البيانات في سحابة Microsoft Azure. يوفر Azure العديد من خيارات البنية لاستضافة قاعدة البيانات: MS SQL على الجهاز الظاهري Azure ، وثلاثة خيارات لقاعدة بيانات SQL Azure في السحابة. لذلك ، من الممكن اختيار أفضل خيار تحديد موضع وفقًا لخصائص قاعدة بيانات معينة وظروف التشغيل الخاصة بها.
يتمتع Azure بعدد من المزايا مقارنة بشراء المعدات الخاصة بك. واحدة من أهمها قدرات الأجهزة الضخمة التي يمكن أن توفرها أزور. وكذلك اتباع نهج مرن في استخدام هذه القدرات حسب الحمل الفعلي. على سبيل المثال ، يمكنك شراء إمكانات إضافية لفترة "موسم الذروة" لعملك ، أو في نهاية فترة إعداد التقرير ، بحيث يمكن أن تمر القمم دون مشاكل. وبقية الوقت ، استخدم تكوينًا أكبر للموارد في الميزانية. وبالتالي ، فمن ناحية ، في الوقت المناسب ، يمكنك الوصول إلى الإمكانيات الهائلة للموارد من Azure (والتي ، بالمناسبة ، تنمو طوال الوقت) ، ومن ناحية أخرى ، لا يمكنك دفع مبالغ زائدة مقابل السعة الزائدة عندما لا تحتاج إليها.
ومع ذلك ، على الرغم من بساطته النسبية ، فإن زيادة موارد الأجهزة ليس حلاً عالميًا. أولاً ، التأثير الإيجابي غالبًا ما يكون بعيدًا عن الاستثمارات المالية (هناك العديد من الاستثمارات - هناك تأثير ضئيل). ثانياً ، التأثير مؤقت ، حيث تستمر القاعدة في النمو وتتطلب المزيد من الموارد والمزيد من الاستثمارات المالية.
في أي حال ، فإن هذا النهج له الحق في الحياة ، ويستخدم على نطاق واسع. لكننا لن نتطرق إليها بعد الآن ، لأن الهدف الرئيسي من المقال ليس نهج "الأجهزة" ، بل هو نهج "البرمجيات" ، الموضح أدناه.
النهج رقم 2: الإلتفاف من القاعدة
والحل الأكثر جذرية هو الإلتفاف في قاعدة البيانات ، أي إزالة البيانات التاريخية غير ذات الصلة منها. تحتوي قاعدة البيانات المنهارة على بيانات فقط لفترة تشغيلية قصيرة نسبيا ، وعادة ما لا تزيد عن 1-2 سنوات. من الواضح أن درجة الخفض في كل حالة مختلفة ، ومن الصعب تسمية أي أرقام محددة. ومع ذلك ، بالنسبة للمبدأ التوجيهي ، سنتخذ مؤشرا على انخفاض في الأساس بنسبة 50-70 ٪ ، أي حوالي 2-3 مرات ، تقريبا بنفس المقدار في معظم الأحيان ، ويظهر ذلك في الممارسة العملية ، أقل أو العكس بالعكس - إنه أمر نادر الحدوث.
لن نتناول المكاسب الناتجة. من الواضح ، إذا تم تخفيض القاعدة بمقدار 2-3 مرات أو أكثر ، فسيكون تأثير الأداء قويًا وطويل الأجل ، ويمكن تجنب استثمارات إضافية في مكون الجهاز. وآلية الالتواء ، بمجرد تطويرها وتشغيلها ، يمكن إعادة استخدامها في المستقبل. بشكل عام ، هذا هو حل فعال كبير مع نتائج مضمونة.
تعقيد تنفيذ الإلتواء
لكن على الرغم من فعاليته ، فإن الإلتواء لديه مشكلة كبيرة للغاية. وهي ليست مسألة تطوير آلية الالتواء نفسها. نعم ، هذا التطور هو أيضًا مهمة صعبة ، لكن تم حلها بطريقة أو بأخرى. الشيء مختلف. عندما يكون حجم قاعدة البيانات عدة مئات غيغا بايت أو عبرت خط تيرابايت ، اتضح أنه من الصعب فعليًا للغاية تنفيذ عملية الطي. حتما ، تنشأ مجموعة كاملة من الصعوبات المترابطة ، دعونا ننظر فيها.
- كثافة موارد عمليات الطي - يتم تحميل المعدات بكثافة.
- عند التحويل ، لا يتم حذف مجموعة كبيرة من البيانات فعليًا فحسب ، بل يتم أيضًا تنفيذ الكثير من العمليات كثيفة الاستخدام للموارد: تحديدات متعددة ، وفحوصات ، وتجمعات ، وفهرسة ، وتسجيل ، ونقل البيانات بين الجداول وما إلى ذلك. هذه الحقيقة مهمة بشكل خاص لأن قاعدة البيانات القابلة للطي ، كقاعدة عامة ، تم تحميلها بالفعل بشكل كبير ، وليس لديها سعة زائدة.
- تدخل للمستخدمين.
- من الصعب للغاية أو المستحيل إجراء عملية التحويل مباشرة في قاعدة بيانات العمل بالتوازي مع عمل المستخدم نظرًا للارتفاع الكبير في الحمل والأقفال التي أنشأتها عملية الالتفاف.
- لا يوجد نافذة التكنولوجية.
- النافذة التكنولوجية ذات المدة الكافية ، عندما لا يعمل المستخدمون ، ليست متاحة ببساطة للتلف. بعد كل شيء ، فإن عملية طي قواعد البيانات بهذا الحجم عادة ما تكون عشرات الساعات أو عدة أيام.
- مخاطر عالية عند الطي مباشرة إلى قاعدة العمل.
- النهج ، عندما يتم تطبيق خوارزمية الالتواء مباشرة على قاعدة العمل ، هو في حد ذاته مخاطرة كبيرة لعدة أسباب. واحد منهم - احتمالات التحقق النهائي لنتائج الالتواء محدودة للغاية (لا يوجد وقت).
- مدة غير مقبولة للنهج التكراري.
- يمكنك محاولة تجنب عنق الزجاجة - نافذة تكنولوجية ، والوقوع مباشرة في قاعدة الإنتاج بأجزاء صغيرة تكرارية ، واختيار حجم كل جزء بحيث يلائم النوافذ التكنولوجية الحالية. لكن هذا المسار غير قابل للتطبيق في أغلب الأحيان ، لأنه أولاً ، تمتد عملية التشذيب لفترة طويلة غير مقبولة (عدة أسابيع أو أشهر) ، وثانياً ، يزيد تعقيد آلية الطي ، والتكلفة الإجمالية لضمان عملية تشذيب غير متقطعة لفترة طويلة ، مخاطر المشروع ككل تتزايد بشكل كبير.
- كيفية ضغط الفراغات في ملف البيانات!؟
- أثناء إزالة المعلومات التاريخية من قاعدة البيانات ، لا ينقص ملف البيانات الخاص بها فعليًا (بل ويزيد قليلاً في كثير من الأحيان) ، بل إنه ينشئ فراغات كبيرة بداخله. وتحتاج إلى التخلص منها بطريقة أو بأخرى بحيث يتم تقليل ملف البيانات. خلاف ذلك ، يتم فقد الربح من حيث مساحة القرص. خيار واحد هو تنفيذ SHRINK نموذجي. وعلى مثل هذه المجلدات يعد هذا الإجراء طويلًا جدًا (عدة ساعات أو حتى عشرات الساعات).
وهكذا ، الإلتواء هو مهمة غير تافهة للغاية. لا يكفي تطوير آلية الإلتواء ، بل يجب أيضًا تطبيقها. وعلاوة على ذلك ، فإن التطبيق غالبا ما يصبح عنق الزجاجة.
ملاحظة: بعد ذلك ، نترك وراء تطوير الأقواس تطور آلية الإلتفاف نفسها (بمعنى آخر ، خوارزمية حذف البيانات التاريخية) ، بغض النظر عن معنى إنشائها. ونحن نركز فقط على تطبيق الآلية المنفذة بالفعل في المعركة.
الحل باستخدام DBREPLICATION
قد يبدو طريق مسدود. ولكن لا تزال هناك حلول. هناك تقنية فعالة تتيح لك كشف تشابك الصعوبات بأكمله وإزالة المخاطر ومضمونة لتحقيق الهدف. أنها تنطوي على استخدام تقنية تبادل البيانات DBREPLICATION. الحل مناسب لكل من خيار البنية التحتية التقليدية و Microsoft Azure المستند إلى مجموعة النظراء. باختصار ، جوهر هو على النحو التالي.
- يتم إنشاء استنساخ من قاعدة البيانات ، يتم تكوين تبادل البيانات في اتجاه واحد بين استنساخ وقاعدة البيانات الرئيسية باستخدام DBREPLICATION. يُسمح بتحديد قاعدة البيانات الرئيسية و / أو استنساخها (كليهما أو أحدهما) في سحابة Microsoft Azure.
- في استنساخ ، لا يعمل المستخدمون ، هناك تبدأ عملية الالتواء. نظرًا لأن عملية الطي لا تزعج أي شخص ، يمكن أن تستمر هناك طوال اليوم دون انقطاع طالما استغرق الأمر. وهكذا ، يختفي الرابط إلى مدة النافذة التكنولوجية!
- المستخدمين دون تدخل العمل في قاعدة البيانات الرئيسية. وتقوم تقنية DBREPLICATION بنقل جميع التغييرات تلقائيًا من قاعدة البيانات الرئيسية إلى قاعدة قابلة للطي بسرعة عالية. وبالتالي ، فإن استنساخ محدثة من حيث البيانات التشغيلية.
- بعد الانتهاء من الإلتفاف ، كقاعدة عامة ، يتم إجراء تحقق تفصيلي للنتيجة بمشاركة متخصصين تقنيين ومستخدمي الأعمال من العميل. وهذه العملية يمكن أن تستمر لفترة طويلة (عدة ساعات أو أيام). في المنهجية قيد النظر ، لا يوجد عمليا أي حد زمني ، لذلك ، يمكن تخصيص التحقق من الوقت بقدر ما هو مطلوب.
- بعد الانتهاء من الإكمال والتحقق ، ينتقل جميع المستخدمين إلى clone clone ، ومن تلك اللحظة يصبحون الأساس الرئيسي. والقاعدة الأصلية غير المختونين بمثابة أرشيف للبيانات التاريخية.
- ميزة إضافية هي القدرة على تبديل النسخ المتماثل في الاتجاه المعاكس عندما يتحول المستخدمون إلى قاعدة بيانات صغيرة. يوفر هذا أمانًا إضافيًا ، لأنه إذا حدث "خطأ ما" ، فيمكنك التبديل بين المستخدمين بسرعة إلى قاعدة البيانات غير المختصرة دون فقد البيانات المدخلة.
- إذا كانت هناك حاجة إلى تحديث قاعدة بيانات الأرشيف ، فيمكنك تبديل النسخ المتماثل في الاتجاه المعاكس ونقل التغييرات من قاعدة البيانات المصغرة إلى الأرشيف.
الشكل 1. رسم تخطيطي لقاعدة بيانات التشذيب باستخدام تقنية DBREPLICATION.
الشكل 2. الخيار لاستضافة قواعد البيانات القابلة للطي في سحابة MS Azure.
وبالتالي ، فإن تقنية الالتفاف الموصوفة في قاعدة بيانات النسخ توسع كل الاختناقات. يزيل الاعتماد على النافذة التكنولوجية. في الاستنساخ ، الحزمة لا تزعج أي شخص ، ولا أحد يزعجها. يمكنك استخدام الحد الأقصى من موارد الاستنساخ بأمان ، وكذلك الاهتمام الكافي بالتحقق النهائي.
يبقى أن نفهم أي تكنولوجيا التبادل يمكن استخدامها في هذا المخطط؟ لماذا DBReplication؟
لماذا DBReplication؟
في المنهجية الموصوفة ، فإن العنصر الأساسي هو تقنية التبادل ، والتي تضمن تزامن قاعدة البيانات المشذبة مع القاعدة الرئيسية. من حيث المبدأ ، يمكن أن تكون تقنية التبادل قائمة إذا استوفت ثلاثة شروط أساسية أساسية:
- التوافق مع منصة تطبيق الأعمال ، التي تنهار قاعدتها.
مثال: في حالة انهيار قاعدة البيانات 1C ، فلن تكون كل تقنية التبادل متوافقة مع الهيكل الأساسي 1C ، على وجه الخصوص ، MS Transaction Replication الكلاسيكية غير متوافق ، حيث أنه يجري تغييرات على بنية الجدول.
- الأداء. يجب ضمان تكنولوجيا التبادل للتعامل مع تدفق التغييرات التي تحدث في قاعدة العمل أثناء الالتواء.
Explanation: في هذه المقالة ، نعني في المقام الأول قواعد البيانات المحملة بدرجة عالية مع معدل تغيير كبير للبيانات. سيستمر الالتواء عشرات الساعات ، وربما عدة أيام ، وربما حتى يكون هناك أكثر من تكرار للتلف. خلال هذا الوقت ، سيقوم المستخدمون بإجراء تغييرات ضخمة. العديد من تقنيات المشاركة لا تستطيع التعامل معها. وتحتاج ليس فقط للتعامل ، فمن المستحسن التعامل مع العرض.
- قابلية التطبيق الرئيسية لظروف المشكلة.
Explanation: ربما تبدو هذه النقطة بديهية ، لكن مع ذلك يمكننا استبعادها. وهي: لا تنس أن البيانات الموجودة في قاعدة البيانات المصدر وفي الاستنساخ ليست متساوية مع بعضها البعض! هذه الحقيقة تكتسح تلقائيًا مجموعة كاملة من التقنيات القوية والإنتاجية القائمة على مزامنة سجلات المعاملات - دائمًا ، تسجيل الشحن ، النسخ المتطابق ، إلخ.
بالإضافة إلى ذلك ، يجب أن تكون تقنية التبادل فعالة من حيث المؤشرات الأخرى:
- الموثوقية والاستقلالية في العمل. نظرًا لأننا نتحدث عن نقل كميات هائلة من البيانات ، ولفترة طويلة إلى حد ما ، فلن يتمتع فريق المشروع ببساطة بالقدرة المادية على التعامل يدويًا مع مشكلات التبادل والتصادمات والفشل ، والتحقق من جودة البيانات ، إلخ. لذلك ، يجب أن تكون تقنية التبادل موثوقة قدر الإمكان من حيث جودة البيانات المرسلة ، بحيث تكون مستقلة وآلية قدر الإمكان.
- جودة واجهات المستخدم للتحكم والإدارة.
- من السهل نشر وتكوين. لا ينبغي أن تفرض تكنولوجيا التبادل متطلبات عالية بشكل مفرط على مؤهلات المتخصصين لتعديلها.
بدون هذه الصفات ، تهدد تقنية التبادل بالانتقال من عنصر توفير رئيسي في المنهجية إلى "رابطه الضعيف" ، ويقدم مخاطر جدية ويهدد المشروع بأكمله. ثم تفقد الفكرة الأصلية معناها.
ومع ذلك ، فإن تقنية DBReplication تلبي بالتأكيد جميع المتطلبات وتضمن نجاح مشروع مجموعة التحديثات.
لاحظ العوامل الرئيسية بسبب نجاح DBReplication في هذه المهمة:
- سعر صرف مرتفع جدا. لاحظ بعض الميزات التي توفر السرعة:
- DBReplication عبارة عن نسخة متماثلة للمعاملات ، يبدأ كل تغيير في إرساله مباشرة بعد الالتزام بالمعاملة ؛
- في البنية الداخلية للنظام الفرعي للنقل ، يتم استخدام حلول مثل معالجة قائمة الانتظار المتوازية ذات مؤشرات الترابط المتعددة ، والنهج المعتمد على خطوط الأنابيب ، وضغط الدفق ، ومعالجة المعاملات الدفعية ، واستخدام Bulk Insert وغيرها.
- النقل يتم على أساس خدمات ويندوز ، ومجهزة بالعديد من الميزات لضمان التشغيل السلس. وتشمل هذه: الاسترداد التلقائي للتبادل بعد انقطاع الاتصال ، والعمل على قنوات الاتصال غير المستقرة الضعيفة ، والمعالجة التلقائية لتعارضات الإصدار (للتبادل ثنائي الاتجاه) ، والتكيف التلقائي في حالة حدوث تغييرات في بنية جداول تطبيق الأعمال ، وغيرها.
- آلية تسليم البيانات مضمونة. التقيد الصارم بسلامة المعاملات والاتساق في نقل التغييرات.
- لا يعدل هيكل جدول تطبيق الأعمال. لذلك ، على وجه الخصوص ، يمكن استخدامه بنجاح عند طي قواعد بيانات 1C.
- واجهة مستخدم مطورة تسمح لك بإدارة نظام التبادل مركزياً "من نافذة واحدة" ، يتم جمع جميع معلومات الخدمة وعرضها على الإنترنت.
- من السهل نشر وتكوين.
- تتكيف مع منصة 1C. لا يعمل المستخدم مع الجداول ، ولكن مع كائنات بيانات تعريف 1C مألوفة.
- أي إصدار من MS SQL ، بدءًا من 2005 ، من Standard إلى Enterprise ، يتم نشره محليًا في سحابة MS Azure ؛ من وجهة نظر Azure ، يُسمح بخيارات استضافة الجهاز الظاهري وخيارات استضافة Azure SQL DB ، بما في ذلك مثيل مُدار لقاعدة بيانات SQL Azure ( مثيل مُدار ).
- DBReplication هو حل موثوق جاهز تم اختباره من قبل العديد من المشاريع في مجموعة متنوعة من الظروف والمهام.
- إذا تم استخدام DBREPLICATION في وضع التبادل أحادي الاتجاه ، فيمكن تبديل اتجاه التبادل.
بالإضافة إلى ذلك ، نلاحظ ميزة واحدة أكثر أهمية:
- يمكن أن تعمل DBREPLICATION في وضع تبادل ثنائي الاتجاه ، عندما يكون من الممكن إدخال / تغيير البيانات في وقت واحد في جميع قواعد البيانات المشاركة في التبادل. عدد القواعد التي يمكن تضمينها في دائرة التبادل ليست محدودة.
مثال التطبيق العملي
شركة روسية كبيرة لديها نظام محاسبة التطبيقات على أساس منصة 1C 8 + MS SQL Server. تخطت القاعدة التشغيلية الرئيسية منذ فترة طويلة 2 تيرابايت وتستمر في النمو. في الوقت نفسه ، يزداد الحمل أكثر فأكثر: معاملات وتحليلية. في النهاية ، تم تشكيل عدد من الأسباب لإلتفاف القاعدة. تقرر خفض البيانات التاريخية لبداية عام 2017. تم تحديد التقنية الموضحة هنا باستخدام DBReplication.
في حد ذاته ، تم تحديد خوارزمية الالتواء ليتم تنفيذها بشكل رئيسي من خلال TSQL مع ادراج صغير لأدوات 1C النموذجية. كانت المهمة معقدة بسبب حقيقة أنه لا يمكن طي جميع الكائنات المطبقة (الجداول) بحلول الموعد المحدد ، حيث أن ميزات العمل تتطلب أن تكون البيانات التاريخية موجودة في عدد من أكبر النظم الفرعية بالكامل في عمق 5-7 سنوات. لذلك ، من وجهة نظر حجم قاعدة البيانات ، لم يكن تأثير الالتواء كبيرًا كما نود. تم إجراء تحليل أولي ، أظهر أنه مع مراعاة القيود الموضوعية ، سيتم قطع حوالي 33٪ من الحجم الأولي. ولكن تم تقييم هذا من قبل العميل كنتيجة جيدة ، لأن المكسب ليس فقط في حجم قاعدة البيانات على هذا النحو ، ولكن أيضًا في سرعة الجداول الفردية ، كما انخفضت جداول النظم الفرعية المنهارة في الحجم بأكثر من 33٪ - من 46٪ إلى 77٪ (في 2 - 3 مرات).
دعونا نلقي نظرة فاحصة على بعض المؤشرات والحقائق من الاستخدام الفعلي للالتواء. كانت مدة الالتواء المباشر للبيانات حوالي 12 ساعة. استغرق تزامن التغييرات المتراكمة باستخدام DBREPLICATION حوالي 1 ساعة. إحدى النقاط الرئيسية في المشروع هي التحقق النهائي من القاعدة المصغرة ، والتي قام بها متخصصو العميل. تجدر الإشارة خاصة إلى مدتها - استغرقت هذه العملية حوالي أسبوع. ترجع هذه المدة إلى أن التحقق كان عميقًا وشاملًا للغاية ، بمشاركة متخصصين من مختلف الملفات الشخصية ، بما في ذلك إنشاء نموذج بيانات في نظام خارجي. طوال هذا الوقت ، تمت مزامنة القاعدة المصغرة تلقائيًا مع قاعدة البيانات القتالية الحالية من خلال DBREPLICATION. تم التحقق بنجاح. وتم تبديل المستخدمين إلى قاعدة بيانات مطوية. تم نقل قاعدة البيانات السابقة إلى حالة الأرشفة ، مع وصول للقراءة فقط. ليست هناك حاجة لمزامنة لاحقة ، لذلك تم تعطيل النسخ المتماثل.
ملخص المشروع:
- تم تطبيق التقنية المطبقة بالكامل ، وبفضلها كان هناك ما يكفي من الوقت لإكمال عملية الالتواء نفسها ، بالإضافة إلى التحقق الشامل من البيانات ، مما قلل إلى حد كبير مخاطر تخطي بعض الأخطاء والتحول إلى قاعدة بيانات مطوية.
- الانتهاء من الإلتفاف بنجاح:
- انخفض إجمالي حجم قاعدة البيانات التشغيلية بنسبة 33 ٪. لم يكن من الممكن تحقيق تأثير أكبر على حجم قاعدة البيانات لأسباب موضوعية ، بسبب القيود المفروضة على طي بعض الأنظمة الفرعية الكبيرة.
- انخفض حجم الجداول المستخدمة بنشاط من النظم الفرعية المنهارة بنسبة 46-77 ٪ (2-3 مرات).
الخاتمة
DBReplication هو حل موثوق به جاهز موجود في السوق لسنوات عديدة ، تم اختباره من قبل العديد من المشاريع في مجموعة متنوعة من الظروف. في تقنية الالتفاف قيد النظر ، تأخذ DBReplication تمامًا إحدى المهام الفرعية الرئيسية - تزامن قاعدة البيانات. في حالة قواعد البيانات الكبيرة على وجه الخصوص ، يتم فرض متطلبات صارمة للغاية على نظام التبادل ، وتفي DBReplication بها تمامًا. إنه يحل مهمته بشكل موثوق وفعال ، وبالتالي ضمان نجاح المشروع ككل.
لأي مهام أخرى يمكنك استخدام DBREPLICATION
تتيح مجموعة من الميزات والمزايا التنافسية استخدام DBReplication لحل عدد من المشكلات. للرجوع اليها ، نحن قائمة لهم.
- قاعدة البيانات التكرار والتسامح مع الخطأ.
- موازنة التحميل: إعادة توزيعها بين مثلي أو أكثر من مثيلات قاعدة البيانات المتزامنة.
- الانتقال المتحكم فيه إلى إصدارات البرامج الجديدة (MS SQL، 1C) ، هذه التقنية تشبه تقنية الالتواء.
- بناء نظام معلومات موزع مع تبادل عالي السرعة يعتمد على DBReplication. على وجه الخصوص ، استبدال تقنية تبادل الشركة الحالية بمزيد من الإنتاجية والكفاءة - DBREPLICATION.