java - استراتيجية بركة اتصال: جيد ، سيء أو قبيح؟




mysql database (4)

إذا كان لديك قاعدة بيانات واحدة ، واثنين من تجمعات الاتصال ، مع كل 5 اتصالات ، لديك 10 اتصالات إلى قاعدة البيانات. إذا كان لديك 5 مسابح اتصال مع كل اتصالين ، لديك 10 اتصالات إلى قاعدة البيانات. في النهاية ، لديك 10 اتصالات إلى قاعدة البيانات. قاعدة البيانات ليس لديها فكرة أن حمام السباحة الخاص بك موجود ، أي الوعي.

ستحدث أي بيانات تعريفية متبادلة بين التجمع وقاعدة البيانات في كل اتصال. عند بدء الاتصال ، عندما يتم قطع الاتصال ، إلخ. لذلك ، إذا كان لديك 10 اتصالات ، فإن هذه الحركة ستحدث 10 مرات (على الأقل ، على افتراض أن جميعهم يتمتعون بصحة جيدة لحياة التجمع). سيحدث هذا سواء كان لديك حمام سباحة أو 10 حمامات سباحة.

بالنسبة لـ "1 DB لكل تطبيق" ، إذا كنت لا تتحدث إلى نسخة منفصلة من قاعدة البيانات لكل DB ، فلا يهم في الأساس.

إذا كان لديك ملقم DB يستضيف 5 قواعد بيانات ، ولديك اتصالات بكل قاعدة بيانات (على سبيل المثال ، 2 اتصال لكل) ، فسيستهلك هذا مقداراً أكبر من الذاكرة والذاكرة من نفس DB الذي يستضيف قاعدة بيانات واحدة. ولكن هذا الارتفاع هامشي في أحسن الأحوال ، ولا يستهان به على الأجهزة الحديثة مع مخازن البيانات ذات حجم GB. وبعيداً عن نقطة معينة ، فإن جميع قواعد البيانات تهتم برسم الخرائط ونسخ صفحات البيانات من القرص إلى ذاكرة الوصول العشوائي والعودة مرة أخرى.

إذا كان لديك جدول كبير احتياطيًا مكررًا عبر DBs ، فمن المحتمل أن يكون ذلك هدرًا.

وأخيرًا ، عندما أستخدم كلمة "قاعدة بيانات" ، أعني الكيان المنطقي الذي يستخدمه الخادم لدمج الجداول. على سبيل المثال ، يحب Oracle حقًا أن يكون لديه "قاعدة بيانات" واحدة لكل خادم ، مقسمًا إلى "schemas". يحتوي Postgres على عدة DBs ، كل منها يمكن أن يكون لديك مخططات. ولكن على أي حال ، فإن جميع الخوادم الحديثة لديها حدود منطقية للبيانات التي يمكن استخدامها. أنا فقط أستخدم كلمة "قاعدة البيانات" هنا.

لذلك ، طالما أنك تصل إلى مثيل واحد من خادم DB لجميع تطبيقاتك ، لا تهمك مسامعات الاتصال et al في الصورة الكبيرة حيث سيشارك الخادم كل الذاكرة والموارد عبر العملاء عند الضرورة.

أنا مسؤول عن تطوير وصيانة مجموعة من تطبيقات الويب التي تتمحور حول بيانات مماثلة. كانت البنية التي قررت في حينها أن يكون لكل تطبيق قاعدة بيانات خاصة به وتطبيق جذر الويب. يحتفظ كل تطبيق تجمع اتصال إلى قاعدة البيانات الخاصة به وقاعدة بيانات مركزية للبيانات المشتركة (تسجيلات الدخول ، وما إلى ذلك)

وقد زعم أحد العاملين أن هذه الاستراتيجية لن تتوسع لأن وجود العديد من مجموعات الاتصال المختلفة لن يكون قابلاً للتحجيم ، وأنه ينبغي لنا إعادة تفكيك قاعدة البيانات بحيث تستخدم جميع التطبيقات المختلفة قاعدة بيانات مركزية واحدة وبأية تعديلات قد تكون يجب أن تنعكس الفريدة على أحد الأنظمة من قاعدة البيانات تلك ثم تستخدم مجموعة واحدة مدعومة من Tomcat. وقد افترض أن هناك الكثير من "بيانات التعريف" التي تذهب ذهابًا وإيابًا عبر الشبكة للحفاظ على تجمع اتصال.

ما أفهمه هو أنه باستخدام الضبط المناسب لاستخدام عدد كبير من الاتصالات حسب الضرورة عبر مختلف المجمعات (مثل التطبيقات ذات الحجم المنخفض التي تحصل على اتصالات أقل ، والتطبيقات ذات الحجم الكبير التي تحصل على المزيد ، وما إلى ذلك) ، فإن عدد البرك لا يهم مقارنة بعدد اتصالات أو أكثر رسمية أن الفرق في النفقات العامة اللازمة للحفاظ على 3 حمامات من 10 اتصالات لا يكاد يذكر مقارنة مع تجمع واحد من 30 اتصالات.

كان السبب وراء تقسيم الأنظمة في البداية إلى تصميم قاعدة بيانات واحدة هو أنه من المرجح أن تكون هناك اختلافات بين التطبيقات وأن كل نظام يمكنه إجراء تعديلات على المخطط حسب الحاجة. وبالمثل ، فقد أزال احتمال حدوث نزيف بيانات النظام إلى تطبيقات أخرى.

للأسف ليس هناك قيادة قوية في الشركة لاتخاذ قرار صعب. على الرغم من أن زملائي في العمل يتراجع عن مخاوفه فقط مع الغموض ، أريد أن أتأكد من فهم عواقب قواعد بيانات / اتصالات متعددة متعددة مقابل تجمع قاعدة بيانات / اتصال واحد كبير.


التصميم والهندسة المعمارية والخطط والأفكار العظيمة يختفي عندما لا يكون هناك إحساس عادي أو رياضيات بسيطة وراء. بعض مزيد من الممارسة و / أو الخبرة يساعد ... هنا هو الرياضيات البسيطة لماذا لا تجمع 10 حمامات مع 5 اتصالات نفس تجمع 1 مع اتصال 50: تم تكوين كل تجمع مع اتصالات مفتوحة min & max ، حقيقة أنه سوف عادة ما تستخدم (99 ٪ من الوقت) 50 ٪ من عدد قليل (2-3 في حالة 5 دقائق) إذا كان يستخدم أكثر من أن هذا التجمع هو سوء تكوينه لأنه فتح وإغلاق الاتصالات طوال الوقت (مكلفة ) ... لذلك نحن 10 حمامات مع وصلات 5 دقائق لكل = 50 اتصال مفتوح ... يعني 50 اتصال TCP ؛ 50 توصيلة JDBC في أعلىها ... (هل قمت بتصحيح اتصال JDBC؟ ستفاجئ كمية البيانات الوصفية التي تتدفق بطريقتين ...) إذا كان لدينا تجمع واحد (يخدم نفس البنية التحتية أعلاه) يمكننا ضبط الحد الأدنى إلى 30 بسيطة لأنها سوف تكون قادرة على تحقيق التوازن بين الإضافات بشكل أكثر كفاءة ... وهذا يعني 20 أقل اتصالات JDBS. أنا لا أعرف عنك ولكن بالنسبة لي هذا كثير ... الشيطان في التفاصيل - اتصالات 2-3 التي تركتها في كل تجمع للتأكد من أنه لا يفتح / إغلاق طوال الوقت .. لا تريد حتى الذهاب في النفقات العامة لإدارة حمام السباحة 10 ... (لا أريد الحفاظ على 10 حمامات كل واحد منهم مختلف عن الآخر ، هل أنت؟) الآن بعد أن بدأت في هذا إذا كان كان لي أن "التفاف" DB (مصدر البيانات) مع تطبيق واحد (طبقة خدمة أي شخص؟) من شأنه أن يوفر خدمات فرق (REST / SOAP / WS / JSON - اختيار السم الخاص بك) وتطبيقاتي لن تعرف حتى حول JDBC ، TCP إلخ. الخ أوه ، انتظر جوجل ذلك - GAE ...


سؤال ممتاز. لا أعرف الطريقة الأفضل ، ولكن هل فكرت في تصميم الشفرة بطريقة تجعلك تنتقل من استراتيجية إلى أخرى مع أقل قدر ممكن من الألم؟ ربما يمكن استخدام بعض كائنات وكيل قاعدة البيانات خفيفة الوزن لإخفاء قرار التصميم هذا من التعليمات البرمجية ذات المستوى الأعلى. فقط في حالة.


قاعدة البيانات والحجم العلوي ، 1 تجمع مع 30 اتصالات و 3 حمامات مع 10 وصلات هي نفسها إلى حد كبير على افتراض الحمل هو نفسه في كلتا الحالتين.

من حيث التطبيق ، قد يكون الفرق بين أن جميع البيانات تمر عبر نقطة واحدة (مثل طبقة الخدمة) مقابل نقطة الوصول لكل تطبيق قد يكون شديد القسوة ؛ من حيث الأداء وسهولة التنفيذ / الصيانة (ضع في اعتبارك الحاجة إلى استخدام ذاكرة التخزين المؤقت الموزعة ، على سبيل المثال).





connection-pooling