คุณควรละทิ้งกรอบงาน ORM เมื่อคุณต้องการใช้การดำเนินการแบบกลุ่ม?

นี่เป็นสถานการณ์ทั่วไป:

• คุณต้องใช้การดำเนินการเป็นกลุ่มในแอปพลิเคชันที่ใช้กรอบ ORM
• หลังจากผ่านไปครั้งแรกคุณสังเกตเห็นปัญหาด้านประสิทธิภาพที่สำคัญ

นี่คือคำถามของฉัน:

• ในสถานการณ์เช่นนี้คุณควรสนับสนุนโซลูชันที่มี SQL ดิบหรือไม่
• หรือมีรูปแบบการออกแบบที่รู้จักกันดีซึ่งสามารถช่วยคุณลดปัญหาที่มักเกี่ยวข้องกับการดำเนินงานจำนวนมากด้วยกรอบ ORM หรือไม่

แก้ไข:

• ฉันไม่ได้ถามว่าคุณควรลบ ORM framework ออกจากแอพพลิเคชันทั้งหมดหรือไม่
• ฉันกำลังถาม: คุณควรละทิ้งกรอบ ORM สำหรับแอปพลิเคชั่นเล็ก ๆ นี้หรือไม่?

ORM ไม่ได้มีไว้เพื่อให้สามารถเข้าถึงฐานข้อมูลของคุณได้อย่างสมบูรณ์ ใช้รหัส 80% ของรหัสนั่นคือ CRUD สิ่งที่น่าเบื่อเกินกว่าจะเขียนด้วยตัวคุณเอง ใช้โพรซีเดอร์ที่เก็บไว้, SQL แบบไดนามิก, หรืออะไรก็ตามที่คุณต้องการในส่วนที่เหลืออีก 20% ที่ต้องได้รับการปรับให้เหมาะสม

ฉันใช้ ORM (nHibernate) ในแอปพลิเคชันที่ต้องการประสิทธิภาพสูงและจัดการบันทึกนับพันล้านรายการ เมื่อเวลาผ่านไปเราสังเกตเห็นว่าปัญหาด้านประสิทธิภาพที่สำคัญที่สุดนั้นเกี่ยวข้องกับวิธีการใช้ ORM ของเราเองแทนที่จะเป็นเพราะ ORM เพียงอย่างเดียว

ORM ไม่ควรแทนที่ความรู้ฐานข้อมูลบังคับของคุณ มันเป็นเครื่องมือที่คุณใช้ในการเพิ่มผลผลิตและความยืดหยุ่นในโค้ดของคุณ แต่คุณจะต้องรู้กระบวนการพื้นฐานเพื่อเพิ่มประสิทธิภาพของคุณ

คุณไม่ได้ระบุ ORM เฉพาะดังนั้นนี่คือสิ่งที่เราทำเพื่อปรับปรุงประสิทธิภาพ:

• เราใช้เครื่องมือสร้างโปรไฟล์ ORM (เราใช้ nhprof)
• เราใช้ผู้สร้างโปรไฟล์ฐานข้อมูล (เราใช้ SQL Server Profiler)
• เราอ่านบทความให้มากที่สุดเท่าที่จะทำได้ในเรื่อง (หลายคนพร้อมใช้งานสำหรับ nHibernate นอกเหนือจากบททั้งหมดในหัวข้อในเอกสารประกอบ)
• เราซื้อหนังสือเฉพาะเรื่องประสิทธิภาพและความสามารถในการปรับขนาด
• เราสร้างระบบเปรียบเทียบเพื่อทดสอบการเพิ่มประสิทธิภาพของเราเอง
• และที่สำคัญกว่านั้นเราสามารถทดสอบรหัสของเรากับลูกค้าที่ใช้งานจริงด้วยข้อมูลจำนวนมาก สิ่งสุดท้ายที่อยู่คนเดียวช่วยให้เราเห็นปัญหาส่วนใหญ่ในการสมัคร

เราจัดการกับ Entity Framework ได้ แต่แอปพลิเคชันของเรามีการดำเนินการตามแบทช์ (เราจะเขียนเร็กคอร์ดจำนวนมากในแต่ละตาราง) ดังนั้นมันจึงเหมาะสมอย่างยิ่ง ฉันจะดูว่าเป็นไปได้หรือไม่ที่จะรักษากรอบ ORM หากเป็นไปได้เพียงเพื่อลดจำนวนรหัสวัตถุประสงค์พิเศษในแอปของคุณ เป็นไปได้ไหมที่บัฟเฟอร์การเขียนจากนั้นเรียกใช้งานเป็นกลุ่ม? คุณสูญเสียความหมายของการทำธุรกรรม แต่ถ้าคุณจะไปกับการดำเนินการจำนวนมากฉันคิดว่าคุณได้ตกลงกับสิ่งนั้นแล้ว

ออมไม่ทำอะไรเลยที่มีมนต์ขลัง พวกเขาแปลวิธีการเข้าถึงวัตถุเป็น SQL คำสั่ง SQL ที่รันจะไม่ช้ากว่า SQL ที่คุณเขียนด้วยตนเอง ต้องบอกว่ามีบางประเด็นที่คุณอาจสะดุดเมื่อ:

1. ธุรกรรม: การดำเนินการเป็นกลุ่มขนาดใหญ่หนึ่งครั้งนั้นเร็วกว่าธุรกรรมขนาดเล็กจำนวนมากที่ทำสิ่งเดียวกันให้สำเร็จ ดังนั้นหากการเรียกใช้เมธอด ORM ของคุณใช้การทำธุรกรรมแบบละเอียด (วิธีการบันทึกสไตล์ที่ใช้งานในเอนทิตี Spring Roo จะถูกเพิ่มความคิดเห็นเป็น @Transactional ตามค่าเริ่มต้น) การดำเนินงานจำนวนมากจะช้า หากเป็นกรณีนี้ในใบสมัครของคุณคุณควรดูตรรกะการทำธุรกรรมของคุณ
2. การแคช: ในโหมดไฮเบอร์เนตแคชระดับแรกอนุญาตให้ตัวจัดการเอนทิตีของคุณหลีกเลี่ยงการไปกลับไปยังฐานข้อมูลโดยไม่จำเป็น โดยทั่วไปสิ่งที่ดี แต่ไม่ดีสำหรับการแทรกจำนวนมากซึ่งจะนำไปสู่การอุดตันแคชที่ไม่จำเป็นซึ่งส่งผลให้ประสิทธิภาพการทำงานของแอปพลิเคชันลดลง หากนั่นเป็นปัญหาของคุณคุณควรดูรูปแบบการจับคู่ที่แนะนำข้างต้นโดย ChrisAnnODell เราใช้มันในผู้นำเข้าของเราและเพิ่มความเร็วในการแทรกจำนวนมาก

ไม่มีอะไรผิดปกติกับการใช้ SQL ดั้งเดิมเพื่อปรับปรุงประสิทธิภาพ แต่ก่อนอื่นให้แน่ใจว่าคุณเข้าใจสิ่งที่ทำให้คุณช้าลง

ข้าม ORM ไม่เพียงเท่านั้น แต่ยังบายพาส "ปกติ" ด้วย ใช้ยูทิลิตี้ขนาดใหญ่ของฐานข้อมูลของคุณเพื่อแทรกชุดข้อมูลที่มีขนาดใหญ่มากไปยังตารางการจัดเตรียม จากนั้นใช้ sql เพื่อดำเนินกิจกรรมการแสดงละครของคุณ

ORM "flavor-of-the-blog" ของคุณอาจไม่สามารถใช้งานได้ในทุกสถานการณ์

เคยอยู่ในสถานการณ์นั้น บางครั้งคุณต้อง

ORM บางตัวอนุญาตให้ผู้พัฒนาข้ามโมเดลวัตถุและไปที่เลเยอร์ฐานข้อมูลโดยตรง

นอกจากนี้ยังมี ORM ที่ใช้การดำเนินการจำนวนมากห่อหุ้มเป็น Object Oriented

ตามที่กล่าวไว้โดยumlcatมีORMบางอย่างที่จะช่วยให้คุณใช้การดำเนินงานจำนวนมาก

ยิ่งไปกว่านั้น ORM จำนวนมากสามารถขยายได้ดังนั้นคุณสามารถเขียนวิธีการของคุณเองสำหรับการใช้งานการดำเนินการจำนวนมากหากยังไม่รองรับ หากการดำเนินการจำนวนมากในแอปพลิเคชันของคุณเป็นสิ่งที่คุณสามารถแยกออกได้ฉันจะเพิ่มมันเป็นเลเยอร์ใน ORM (หากต้องการทำเช่นนั้นคุณอาจต้องเขียน SQL ดิบ) แต่ในแอปพลิเคชันให้ใช้ ORM วิธีการที่คุณใช้

สิ่งนี้ยังทำให้การทดสอบหน่วยและการดีบักง่ายขึ้น เมื่อคุณมีการทดสอบที่ดีสำหรับวิธี ORM ของคุณคุณสามารถใช้งานได้ฟรีในแอพของคุณ มิฉะนั้นการดีบัก SQL แบบดิบ (โดยเฉพาะอย่างยิ่งอันที่มีธุรกรรมและ JOIN จำนวนมาก) อาจเป็นเรื่องที่เจ็บปวด

ฉันใช้เวลาเกือบหนึ่งวันในการตรวจพบข้อผิดพลาดในการโทร SQL แบบดิบที่เกือบ 100 LOC และข้อผิดพลาดเป็นเพียงตัวละครเดียว! ตั้งแต่นั้นมาฉันพยายามหลีกเลี่ยง SQL ดิบในแอพและมีขั้นตอน SQL ทั้งหมดแยกจากกันโดยผ่านการทดสอบหน่วย

ไม่มีการออกแบบใด ๆ ที่ฉันรู้ ฉันเดาว่าคุณตัดสินใจ ORM ด้วยเหตุผลดังนั้นการละทิ้ง ORM นั้นไม่ใช่สิ่งที่คุณต้องการ อย่างไรก็ตามในกรณีเหล่านี้ฉันคิดว่ามีพื้นที่สำหรับผสมทั้งสองโซลูชัน ตราบใดที่คุณทำมันอย่างตั้งใจและจัดทำเอกสารว่าทำไมคุณถึงเบี่ยงเบนจากการใช้ ORM เริ่มต้นในซอฟต์แวร์ของคุณ ถัดจากนั้นกรอบ ORM บางตัวมีสิ่งอำนวยความสะดวกบางอย่างสำหรับการดำเนินการแบบกลุ่ม ฉันรู้ว่า nHibernate (ORM สำหรับ. NET Framework) มี socalled StatelessSessions ซึ่งมีค่าใช้จ่ายน้อยกว่ามาก ในกรณีนั้นให้ใช้ raw SQL