السبات - ما صامت الدروس حول

مشاكل في تخطيط نموذج كائن في علاقة

المشكلة 1. استفسارات الوراثة وتعدد الأشكال.

1. جميع الورثة في نفس الجدول:
   Inheritance (استراتيجية = InheritanceType.SINGLE_TABLE)
   
   
   
   في هذه الحالة ، الحقول المشتركة وحقول الورثة تقع في جدول واحد. باستخدام هذه الاستراتيجية ، نتجنب الانضمام عند اختيار الكيانات. من السلبيات ، تجدر الإشارة إلى أنه ، أولاً ، لا يمكننا تعيين تقييد "NOT NULL" لعمود "القوة" في النموذج العلائقي ، وثانيًا ، نفقد الشكل العادي الثالث. (تظهر تبعية متعدية للسمات غير الرئيسية: القوة والقرص).
   
   بالمناسبة ، بما في ذلك لهذا السبب ، هناك طريقتان لتحديد قيد حقل غير فارغ - NotNull مسؤول عن التحقق ؛ Column (nullable = true) - مسؤول عن القيد غير الفارغ في قاعدة البيانات.
   
   في رأيي ، هذه هي أفضل طريقة لتعيين نموذج كائن لنموذج علائقي.
   
2. الحقول الخاصة بالكيانات موجودة في جدول منفصل.
   
   Inheritance (Strategy = InheritanceType.JOINED)
   
   
   
   في هذه الحالة ، يتم تخزين الحقول المشتركة في جدول مشترك ، ويتم تخزين الكيانات الفرعية الخاصة في حقول منفصلة. باستخدام هذه الإستراتيجية ، نحصل على JOIN عند اختيار كيان ، ولكننا الآن نحفظ النموذج العادي الثالث ، ويمكننا أيضًا تحديد قيد NOT NULL في قاعدة البيانات.
3. كل كيان لديه جدول خاص به.
   
   @ InheritanceType.TABLE_PER_CLASS
   
   
   
   في هذه الحالة ، ليس لدينا جدول مشترك. باستخدام هذه الاستراتيجية ، نستخدم UNION للاستعلامات متعددة الأشكال. نحن نواجه مشاكل مع مولدات المفاتيح الرئيسية وقيود التكامل الأخرى. هذا النوع من رسم خرائط الميراث لا يشجع بشدة.

المشكلة 2. نسبة التركيب في OOP

مدير الكيان

1. جاري التقاط اتصال قاعدة البيانات
   
   هذه مجرد نقطة مثيرة للاهتمام. لا يلتقط السبات الاتصال في وقت تلقي EM ، ولكن في أول وصول إلى قاعدة البيانات أو فتح المعاملة (على الرغم من أنه يمكن حل هذه المشكلة). يتم ذلك لتقليل وقت الاتصال مشغول. أثناء استلام EM-a ، يتم التحقق من وجود معاملة JTA.
2. الكيانات المستمرة لديها دائما معرف
3. الكيانات التي تصف سطرًا واحدًا في قاعدة البيانات مكافئة حسب المرجع
   كما هو مذكور أعلاه ، يحتوي EM على ذاكرة تخزين مؤقت من المستوى الأول ، ويتم مقارنة الكائنات الموجودة فيه كمرجع. وبناءً على ذلك ، يُطرح السؤال - ما هي الحقول التي يجب استخدامها لإلغاء التساوي ورمز التجزئة؟ فكر في الخيارات التالية:
   
   
   • استخدم جميع المجالات. فكرة سيئة يساوي يمكن أن يؤثر على الحقول LAZY. بالمناسبة ، هذا صحيح أيضًا بالنسبة لطريقة toString.
   • استخدم المعرف فقط. فكرة عادية ، ولكن هناك فروق دقيقة أيضًا. نظرًا لأن معرف الكيانات الجديدة غالبًا ما يضع مولدًا في وقت الإصرار. الحالة التالية ممكنة:
     
     

     Entity foo = new Entity(); //   (id = null) set.put(foo); //   hashset em.persist(foo); // persist  (id = some value) set.contains(foo) == false // .. hashCode    

     
     
   • استخدم مفتاح عمل (بشكل تقريبي ، الحقول الفريدة وغير الفارغة). لكن هذا الخيار ليس مناسبًا دائمًا.
     
     بالمناسبة ، بما أننا نتحدث عن NOT NULL و UNIQUE ، فمن الملائم أحيانًا إنشاء مُنشئ عام باستخدام وسيطات NOT NULL ، ويكون المُنشئ بدون وسيطات محميًا.
   • لا تلغي التساوي ورمز التجزئة على الإطلاق.
4. كيف يعمل تدفق
   Flush - ينفذ الإضافات المتراكمة ، والتحديثات ، والحذف المتراكم في قاعدة البيانات. بشكل افتراضي ، يتم تنفيذ التدفق في الحالات:
   
   
   • قبل تنفيذ الاستعلام (باستثناء em.get) ، يعد ذلك ضروريًا للالتزام بمبدأ ACID. على سبيل المثال: قمنا بتغيير تاريخ ميلاد الطائرة الهجومية ، ثم أردنا الحصول على عدد الطائرات الهجومية البالغة.
     
     إذا كنا نتحدث عن CriteriaQuery أو JPQL ، فسيتم تنفيذ المسح إذا كان الاستعلام يؤثر على جدول توجد كياناته في ذاكرة التخزين المؤقت للمستوى الأول.
   • عند تنفيذ المعاملة ؛
   • في بعض الأحيان عند الإصرار على كيان جديد - في الحالة التي يمكننا فيها الحصول على معرفها فقط من خلال الإدراج.
   
   والآن القليل من الاختبار. كم عدد عمليات التحديث التي سيتم إجراؤها في هذه الحالة؟
   
   

    val spaceCraft = em.find(SpaceCraft.class, 1L); spaceCraft.setCoords(...); spaceCraft.setCompanion( findNearestSpaceCraft(spacecraft) ); 

   
   تم إخفاء ميزة مثيرة للإسبات تحت عملية التدفق - فهي تحاول تقليل الوقت المستغرق لقفل الصفوف في قاعدة البيانات.
   
   لاحظ أيضًا أن هناك استراتيجيات مختلفة لعملية التدفق. على سبيل المثال ، يمكنك منع "دمج" التغييرات في قاعدة البيانات - يطلق عليها MANUAL (وتعطل أيضًا آلية التحقق القذرة).
   
5. فحص قذر
   
   الفحص القذر هو آلية يتم تنفيذها أثناء عملية التدفق. الغرض منه هو العثور على الكيانات التي قامت بتغييرها وتحديثها. لتطبيق هذه الآلية ، يجب أن يقوم السبات بتخزين النسخة الأصلية من الكائن (ما سيتم مقارنة الكائن الفعلي به). لكي تكون أكثر دقة ، يقوم السبات بتخزين نسخة من حقول الكائن ، وليس الكائن نفسه.
   
   تجدر الإشارة إلى أنه إذا كان الرسم البياني للكيانات كبيرًا ، فقد تكون عملية الفحص القذر مكلفة. لا تنس أن السبات يخزن نسختين من الكيانات (تقريبًا).
   من أجل "تقليل التكلفة" لهذه العملية ، استخدم الميزات التالية:
   
   
   • em.detach / em.clear - فصل الكيانات من EntityManager
   • FlushMode = MANUAL- مفيد في عمليات القراءة
   • غير قابل للتغيير - يتجنب أيضًا عمليات الفحص القذرة
   
   
6. المعاملات
   
   كما تعلم ، يسمح لك السبات بتحديث الكيانات فقط داخل المعاملة. توفر عمليات القراءة المزيد من الحرية - يمكننا تنفيذها دون فتح معاملة صراحة. ولكن هذا هو السؤال بالتحديد: هل يستحق الأمر فتح معاملة صريحة لعمليات القراءة؟
   
   سأذكر بعض الحقائق:
   
   
   • يتم تنفيذ أي بيان في قاعدة البيانات داخل المعاملة. حتى لو من الواضح أننا لم نفتحه. (وضع الالتزام التلقائي).
   • كقاعدة ، نحن لا يقتصر على استعلام واحد لقاعدة البيانات. على سبيل المثال: للحصول على أول 10 سجلات ، ربما تريد إرجاع إجمالي عدد السجلات. وهذا تقريبًا طلبان.
   • إذا كنا نتحدث عن بيانات الربيع ، فإن طرق المستودع هي معاملات بشكل افتراضي ، بينما تكون طرق القراءة للقراءة فقط.
   • يؤثر التعليق التوضيحي لربيع الربيع @ (readOnly = true) أيضًا على FlushMode ، وبشكل أدق ، يضعه الربيع في حالة MANUAL ، وبالتالي لن يقوم السبات بفحص متسخ.
   • ستُظهر الاختبارات الاصطناعية مع استعلام واحد أو اثنين من استعلامات قاعدة البيانات أن الالتزام التلقائي أسرع. ولكن في وضع القتال ، قد لا يكون الأمر كذلك. ( مقال ممتاز في هذا الموضوع ، + انظر التعليقات)
   
   باختصار: من الممارسات الجيدة إجراء أي اتصال بقاعدة البيانات في المعاملة.
   

مولدات

• GenerationType.AUTO - يعتمد اختيار المولد على اللهجة. ليس الخيار الأفضل ، حيث إن قاعدة "الصريح أفضل من القاعدة الضمنية" تنطبق هنا فقط.
• GenerationType.IDENTITY هي أسهل طريقة لتكوين مولد. يعتمد على عمود الزيادة التلقائية في الجدول. لذلك ، للحصول على معرف مع استمرار نحتاج إلى إدراج. هذا هو السبب في أنه يلغي إمكانية استمرار المؤجل وبالتالي الخلط.
• GenerationType.SEQUENCE هي الحالة الأكثر ملاءمة عندما نحصل على معرف من التسلسل.
• GenerationType.TABLE - في هذه الحالة يحاكي السبات تسلسلًا من خلال جدول إضافي. ليس الخيار الأفضل ، لأنه في مثل هذا الحل ، يجب على السبات استخدام معاملة منفصلة وقفل لكل سطر.

• بلا - لا يوجد تحسينات. لكل معرف نسحب تسلسل.
• pooled and pooled-lo - في هذه الحالة ، يجب أن يزيد التسلسل لدينا بفاصل زمني معين - N في قاعدة البيانات (SequenceGenerator.allocationSize). وفي التطبيق ، لدينا مجموعة معينة ، والقيم التي يمكننا من خلالها تعيين كيانات جديدة دون الوصول إلى قاعدة البيانات ..
• hilo - لإنشاء معرف ، تستخدم خوارزمية hilo رقمين: hi (مخزنة في قاعدة البيانات - القيمة التي تم الحصول عليها من استدعاء التسلسل) و lo (مخزنة فقط في التطبيق - SequenceGenerator.allocationSize). بناءً على هذه الأرقام ، يتم حساب الفاصل الزمني لإنشاء المعرّف كما يلي: [(hi - 1) * lo + 1، hi * lo + 1). لأسباب واضحة ، تعتبر هذه الخوارزمية قديمة ولا يوصى باستخدامها.

• SequenceHiLoGenerator هو مولد قديم يستخدم محسّن hilo. يتم تحديده افتراضيًا إذا كان لدينا hibernate.id.new_generator_mappings == خاصية خاطئة.
• SequenceStyleGenerator - يُستخدم افتراضيًا (إذا كانت hibernate.id.new_generator_mappings == خاصية حقيقية). يدعم هذا المولد عدة محسنات ، ولكن يتم تجميع الافتراضي.

طريق مسدود

 Thread #1: update entity(id = 3) update entity(id = 2) update entity(id = 1) Thread #2: update entity(id = 1) update entity(id = 2) update entity(id = 3) 

مجموعة ، حقيبة ، قائمة

• Set - مجموعة غير مرتبة من الكيانات دون تكرار ؛
• حقيبة - مجموعة غير منظمة من الكيانات ؛
• القائمة عبارة عن مجموعة مرتبة من الكيانات.

• إذا كان إصدار السبات الخاص بك أقل من 5.0.8 ، فهناك خطأ خطير إلى حد ما - HHH-5855 - عند إدخال كيان فرعي ، يمكن تكراره (في حالة cascadType = MERGE و PERSIST) ؛
• إذا كنت تستخدم حقيبة لعلاقة ManyToMany ، فإن السبات يولد استعلامات غير مناسبة للغاية عند حذف كيان من المجموعة - يقوم أولاً بإزالة جميع الصفوف من جدول الربط ، ثم يقوم بإدراج ؛
• لا يستطيع السبات جلب حقائب متعددة لنفس الكيان في نفس الوقت.

 //  bag spaceCraft.getCrew().add( luke ); //       //  set spaceCraft.getCrew().put( luke ); //      //        .     ManyToOne   : luke.setCurrentSpaceCraft( spaceCraft ); 

مراجع القوة

 //  bag spaceCraft.getCrew().add( em.getReference( User.class, 1L ) ); //      ,      

التاريخ والوقت

 setTimestamp(int i, Timestamp t, java.util.Calendar cal) 

• اضبط المنطقة الزمنية JVM المطلوبة
• استخدام معلمة السبات - hibernate.jdbc.time_zone (تمت إضافتها في 5.2) - سيتم إصلاح ZonedDateTime و OffsetDateTime فقط
• استخدم النوع TIMESTAMP مع TIMEZONE

 // LocalDateTime LocalDateTime.ofInstant( ts.toInstant(), ZoneId.systemDefault() ); // Instant ts.toInstant(); 

الخلط

• تمكين التجميع وتعيين الحد الأقصى لعدد العبارات:
  hibernate.jdbc.batch_size (يوصى بـ 5 إلى 30)
• تمكين فرز الإدراج والتحديث:
  السبات
  الإسبات. order_updates
  
• إذا كنا نستخدم الإصدارات ، فنحن بحاجة أيضًا إلى تمكينها
  hibernate.jdbc.batch_versioned_data - كن حذرًا هنا ، فأنت بحاجة إلى برنامج تشغيل jdbc حتى تتمكن من تحديد عدد الأسطر التي تأثرت أثناء التحديث.

مشكلة N + 1

• ترقيم الصفحات. في حالة علاقات OneToMany ، لن يتمكن السبات من تحديد الإزاحة والحد. لذلك ، سيحدث ترقيم الصفحات في الذاكرة.
• مشكلة المنتج الديكارتي هي حالة عندما تقوم قاعدة البيانات بإرجاع صفوف N * M * K لاختيار كتب N مع فصول M ومؤلفي K.

• FetchMode - يسمح لك بتغيير خوارزمية التحميل للكيانات الفرعية. في حالتنا ، نحن مهتمون بما يلي:
  • FetchType.SUBSELECT - تحميل السجلات التابعة في طلب منفصل. الجانب السلبي هو أن كل تعقيد الطلب الرئيسي يتكرر في الاختيار الفرعي.
  • BATCH (FetchType.SELECT + BatchSize التعليقات التوضيحية) - يتم أيضًا تحميل السجلات كطلب منفصل ، ولكن جنبًا إلى جنب مع الاستعلام الفرعي ، فإنه يجعل حالة مثل WHERE parent_id IN (؟،؟،؟، ...، N)
  تجدر الإشارة إلى أنه عند استخدام الجلب في Criteria API ، يتم تجاهل FetchType - يتم دائمًا استخدام JOIN
• JPA EntityGraph و Hibernate FetchProfile - تسمح لك بجعل قواعد تحميل الكيان في تجريد منفصل - في رأيي كلا التنفيذين غير ملائمين.

الاختبار

• تسجيل الدخول
  • org.hibernate.SQL: تصحيح الأخطاء
  • org.hibernate.type.descriptor.sql: أثر
• الإحصائيات
  • إحصائيات توليد

• DBUnit - يسمح لك بوصف حالة قاعدة البيانات بتنسيق XML. في بعض الأحيان يكون الأمر مناسبًا. ولكن من الأفضل التفكير مرة أخرى ما إذا كنت بحاجة إليها.
• وكيل مصدر البيانات
  • يعد p6spy أحد أقدم الحلول. يقدم تسجيل استعلام متقدم ووقت تشغيل وما إلى ذلك.
  • com.vladmihalcea: db-util: 0.0.1 أداة مفيدة لإيجاد مشاكل N + 1. كما يسمح لك بتسجيل الاستعلامات. تشتمل التركيبة على تعليق توضيحي مثير للاهتمام لإعادة المحاولة ، والذي يعيد محاولة المعاملة في حالة OptimisticLockException.
  • Sniffy - يتيح لك التأكيد على عدد الطلبات من خلال التعليق التوضيحي. في بعض النواحي ، أكثر أناقة من قرار فلاد.

الأدب

• تقرير نيكولاي أليمنكوف - دعونا نجعل السبات سريعًا مرة أخرى - كان هذا التقرير هو الذي ألهمني بدراسة السبات بشكل أكثر عمقًا. فيما يلي الموارد التي استخدمتها.
• كتاب "Java Persistent API and Hibernate"
• التوثيق الرسمي
• مدونة فلاد م
• Java Weakly Digest - Daily Digest (متعلق بشكل غير مباشر بالموضوع)