السبات:hbm2ddl.السيارات=تحديث في الإنتاج ؟

https://stackoverflow.com/questions/221379

03-07-2019
|

سؤال

هل يمكن تشغيل السبات التطبيقات تكوين hbm2ddl.auto=update تحديث مخطط قاعدة البيانات في بيئة الإنتاج?

المحلول

لا انها غير آمنة.

على الرغم من أفضل الجهود من السبات الفريق, كنت ببساطة لا يمكن الاعتماد على التحديثات التلقائية في الإنتاج.كتابة بقع الخاصة بك ومراجعتها مع DBA, اختبار لهم ، ثم تطبيقها يدويا.

نظريا, إذا hbm2ddl التحديث عملت في التنمية ، ينبغي أن تعمل في الإنتاج أيضا.ولكن في الواقع هذا ليس الحال دائما.

حتى لو عملت حسنا ، قد يكون دون المستوى الأمثل.دباس وتدفع كثيرا لسبب ما.

نصائح أخرى

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

والتحذير واحدة - في بيئة متفاوت المسافات قد ترغب في تجنب ذلك لتطبيقات متعددة يمكن أن تصل في نفس الوقت ومحاولة لتعديل المخطط الذي يمكن أن يكون سيئا. أو وضعها في بعض آلية التي يسمح فيها حالة واحدة فقط لتحديث المخطط.

والمبدعين السبات تثني عن القيام بذلك في بيئة الإنتاج في كتابهما "جافا مع استمرار السبات ":

<اقتباس فقرة>

تحذير: لقد رأينا المستخدمين السبات محاولة استخدام SchemaUpdate لتحديث مخطط قاعدة بيانات إنتاج تلقائيا. وهذا يمكن أن تنتهي بسرعة في كارثة ولن يسمح به DBA الخاص بك.

تحقق من LiquiBase XML للحفاظ على التغيير من التحديثات. لم يسبق لي أن تستخدم حتى هذا العام، ولكنني وجدت أنه من السهل جدا للتعلم وجعل DB مراجعة مراقبة / الهجرة / إدارة التغيير مضمونة جدا. أنا أعمل على مشروع رائع / الكؤوس المقدسة، والكؤوس المقدسة يستخدم السبات تحت لجميع ORM لها (وتسمى "GORM"). نحن نستخدم Liquibase لإدارة جميع التغييرات المخطط SQL الذي نقوم به في كثير من الأحيان إلى حد ما مع تطور التطبيق لدينا مع ميزات جديدة.

وفي الأساس، عليك أن تبقي ملف XML من changesets أن تستمر في إضافة لمع تطور التطبيق الخاص بك. يتم الاحتفاظ هذا الملف في بوابة (أو أيا كان الذي تستخدمه) مع بقية المشروع. عند نشر التطبيق الخاص بك، Liquibase يتحقق انها طاولة التغيير في DB الذي تحاول الاتصال به لذلك سوف نعرف ما تم تطبيقه بالفعل، فإنه ينطبق بذكاء فقط كل ما لم تطبق changesets بعد من الملف. يعمل كبيرة على الاطلاق من الناحية العملية، وإذا كنت تستخدم لجميع التغييرات المخطط الخاص بك، ثم يمكنك أن تكون 100٪ واثق من أن الرمز الذي الخروج ونشر أن يكون دائما قادرا على الاتصال مخطط قاعدة بيانات متوافقة تماما.

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

وأسهل طريقة للبدء مع أنه ربما يكون لاتخاذ DB الموجودة لديك ثم استخدام Liquibase لإنشاء ملف baseline.xml الأولي. ثم في المستقبل يمكنك إلحاق فقط لانها وترك liquibase تولي إدارة التغييرات المخطط.

http://www.liquibase.org/

والسبات لديها لوضع هذا العقد حول عدم استخدام التحديثات السيارات في همز لتغطية أنفسهم عند الأشخاص الذين لا يعرفون ماذا يفعلون استخدامها في الحالات التي لا ينبغي أن تستخدم.

ومنحت الحالات حيث لا ينبغي استخدامه إلى حد كبير يفوق عدد منها حيث انه موافق.

ولقد استخدمت لسنوات على الكثير من المشاريع المختلفة ولم يكن لديه قضية واحدة. هذا ليس الجواب عرجاء، وانها ليست الترميز رعاة البقر. انها حقيقة تاريخية.

والشخص الذي يقول "لم تفعل ذلك في إنتاج" يفكر في مجموعة محددة من نشر الإنتاج، وهي تلك التي كان على دراية (شركته، صناعته، الخ).

والكون من "نشر الإنتاج" واسع ومتنوع.

وهناك السبات المطور من ذوي الخبرة يعرف بالضبط ما DDL سوف تنجم عن تكوين خرائط معينة. طالما يمكنك اختبار والتحقق من أن ما كنت تتوقع ينتهي في DDL (في ديف، سؤال وجواب، التدريج، الخ)، وكنت على ما يرام.

وعند إضافة الكثير من الميزات، يمكن تحديثات المخطط السيارات يكون الوقت المدخر الحقيقي.

وقائمة التحديثات الاشياء السيارات سوف يتم معالجة لا نهاية لها، ولكن بعض الأمثلة توجد بيانات الهجرة، إضافة الأعمدة غير قيم الفارغة، يتغير اسم العمود، الخ، الخ.

وكما تحتاج إلى رعاية في بيئات متفاوت المسافات.

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

وأود أن التصويت لا. لا يبدو السبات لفهم عندما أنواع البيانات للأعمدة قد تغيرت. أمثلة (باستخدام الخلية):

String with @Column(length=50)  ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)

@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed

وربما يكون هناك أمثلة أخرى أيضا، مثل دفع طول عمود سلسلة على مدى 255 ورؤيتها لتحويل النص، mediumtext، الخ الخ.

ومنح، وأنا لا أعتقد أن هناك حقا وسيلة ل"تحويل أنواع البيانات" مع دون إنشاء عمود جديد، نسخ البيانات وتهب بعيدا العمود القديم. لكن الدقيقة قاعدة البيانات لديها الأعمدة التي لا تعكس تعيين السبات الحالي الذي نعيش خطير جدا ...

وجويا هو خيار جيد للتعامل مع هذه المشكلة:

http://flywaydb.org

كما شرحت في هذه المادة, انها ليست فكرة جيدة لاستخدام hbm2ddl.auto في الإنتاج.

الطريقة الوحيدة لإدارة مخطط قاعدة البيانات هو استخدام تدريجي الهجرة النصوص لأن:

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

حتى السبات دليل المستخدم أنصح لك تجنب استخدام hbm2ddl أداة بيئات الإنتاج.

وأود أن لا خطر عليه لأنك قد ينتهي فقدان البيانات التي كان ينبغي أن يتم الحفاظ عليها. hbm2ddl.auto = التحديث هو محض وسيلة سهلة للحفاظ على قاعدة بيانات ديف الخاص بك حتى الآن.

ونحن نفعل ذلك في مشروع يعمل في الإنتاج منذ شهور ولم يكن هناك مشكلة حتى الآن.نضع في اعتبارنا 2 المكونات اللازمة لهذه الوصفة:

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

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

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

شخصيا, أنا لن أعود إلى كتابة النصوص من جهة عن تقديم أي نوع من المخطط ، ولكن هذا مجرد رأيي.و بعد البدء في اعتماد NoSQL مخطط أقل قواعد البيانات في الآونة الأخيرة ، أستطيع أن أرى أن أكثر من وقت قريب ، كل هذه المخططات على أساس العمليات سوف تنتمي إلى الماضي ، لذا من الأفضل أن نبدأ في تغيير المنظور الخاص بك ونتطلع إلى الأمام.

في حالتي (السبات 3.5.2, كيو, أوبونتو) ، ووضع hibernate.hbm2ddl.auto=update فقط إنشاء جداول جديدة و إنشاء أعمدة جديدة في القائمة جداول.
لم لا إسقاط الجداول ولا وإسقاط الأعمدة ، ولا تغيير الأعمدة.يمكن أن يطلق عليه خيار آمن, ولكن شيئا من هذا القبيل hibernate.hbm2ddl.auto=create_tables add_columns سيكون أكثر وضوحا.

انها ليست آمنة, لا ينصح به, لكنه ممكن.

لدي خبرة في تطبيق باستخدام خيار التحديث التلقائي في الإنتاج.

حسنا, المشاكل الرئيسية والمخاطر الموجودة في هذا الحل هي:

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

لذا أنا لن يوصي استخدام التحديث التلقائي في الإنتاج.

إذا كنت تريد حقا أن استخدام التحديث التلقائي في الإنتاج ، أوصي بما يلي:

فصل الشبكات.الاختبار البيئة لا يمكن الوصول إلى وhomolog البيئة.هذا يساعد على منع النشر التي كان من المفترض أن يكون في بيئة اختبار تغيير تجانس البيانات الخاصة بنا.
إدارة البرامج النصية من أجل.تحتاج إلى تنظيم البرامج النصية الخاصة بك على المدى قبل نشر (هيكل الجدول التغيير إسقاط الجدول/أعمدة) و السيناريو بعد نشر (ملء المعلومات عن أعمدة جديدة/الجداول).

و مختلفة من آخر المشاركات, لا أعتقد التحديث التلقائي تمكين انها ذات صلة مع "المدفوعة بشكل جيد جدا" دباس (كما ذكر في الوظائف الأخرى)...دباس لدي أشياء أكثر أهمية من كتابة البيانات SQL إنشاء/تغيير/حذف الجداول والأعمدة.هذه المهام اليومية البسيطة يمكن أن يتم الآلي من قبل المطورين فقط مرت على DBA فريق الاستعراض لا تحتاج إلى السبات دباس "المدفوعة بشكل جيد جدا" أن يكتب لهم.

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

عادة التطبيقات المؤسسية في المنظمات الكبيرة تشغيل مع تخفيض امتيازات.
اسم مستخدم قاعدة البيانات قد لا يكون DDL امتياز إضافة الأعمدة التي hbm2ddl.auto=update يتطلب.

وأنا أتفق مع فلاديمير بوتين. إن الإداريين في الشركة التي أعمل بها بالتأكيد لا نقدر ذلك حتى لو كنت اقترح مثل هذا المسار.

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

وأجد مقارنة مخطط الإنتاج مع مخطط جديد يتيح لك رؤية أفضل لوات قمت بتغييرها في نموذج البيانات. أنت تعرف، بطبيعة الحال، لأنك جعلت، ولكن الآن أنت ترى كل التغييرات دفعة واحدة. حتى تلك التي تجعلك تذهب مثل "ما هيك؟!".

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

التطبيقات المخطط قد تتطور في الوقت المناسب ؛ إذا كان لديك العديد من المنشآت التي قد تكون في إصدارات مختلفة ، يجب أن يكون بعض طريقة للتأكد من أن التطبيق الخاص بك, نوع من أداة أو برنامج نصي قادر على الهجرة مخطط البيانات من إصدار واحد متدرج أي بعد واحد.

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

يجب عليك أن تنظر أن تطور مخطط له العديد من الجوانب التي يتعين النظر فيها:

تطور مخطط قاعدة البيانات في إضافة المزيد من الأعمدة والجداول
إسقاط الأعمدة القديمة والجداول العلاقات
ملء الأعمدة الجديدة مع التخلف

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

3 نقطة حساسة جدا في حال كنت تستخدم السبات ، كما في حال كنت جديدا منطقية قيمة الممتلكات أو رقمي واحد ، إذا كان السبات سوف تجد أي قيمة فارغة في مثل هذه الأعمدة ، إذا رفع استثناء.

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

هكذا على سبيل المثال إذا كان إصدار التحديث يتكون ببساطة في إضافة varchar قيمة الممتلكات (ومن ثم عمود) ، والتي قد الافتراضية إلى null, مع التحديث التلقائي وسوف يتعين القيام به.حيث المزيد من التعقيد هو ضروري ، سوف يكون من الضروري.

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

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow