การมีฟังก์ชั่นใน DB เป็น Roadblock ต่อการขยายขีดความสามารถหรือไม่?


17

ฉันอาจไม่สามารถให้ชื่อที่ถูกต้องกับคำถาม แต่นี่มันคือ

เรากำลังพัฒนาพอร์ทัลการเงินสำหรับการบริหารความมั่งคั่ง เราคาดว่าจะมีลูกค้ามากกว่า 10,000 รายที่จะใช้แอปพลิเคชันนี้ พอร์ทัลจะคำนวณการวิเคราะห์ประสิทธิภาพที่หลากหลายตามการวิเคราะห์ทางเทคนิคของตลาดหุ้น

เราพัฒนาฟังก์ชันการทำงานจำนวนมากผ่านขั้นตอนการจัดเก็บฟังก์ชันที่ผู้ใช้กำหนดเองทริกเกอร์ ฯลฯ ผ่านฐานข้อมูล เราคิดว่าเราสามารถเพิ่มประสิทธิภาพอย่างมากในการทำสิ่งต่างๆโดยตรงในฐานข้อมูลมากกว่าผ่านรหัส C # และเราได้รับการเพิ่มประสิทธิภาพอย่างมาก

เมื่อฉันพยายามคุยโวเกี่ยวกับความสำเร็จของ CTO ของเราเขาตอบโต้การตัดสินใจของฉันในการใช้งานฟังก์ชันในฐานข้อมูลแทนที่จะใช้รหัส ตามที่เขาใช้งานดังกล่าวประสบปัญหาการขยายขีดความสามารถ ในคำพูดของเขา "ทุกวันนี้สิ่งต่าง ๆ ถูกเก็บไว้ในหน่วยความจำ / แคชข้อมูลที่จัดเป็นกลุ่มนั้นยากที่จะจัดการได้ตลอดเวลา Facebook, Google ไม่มีอะไรในฐานข้อมูลมันเป็นยุคของเซิร์ฟเวอร์ที่บางและไคลเอนต์หนาฐานข้อมูลใช้เพื่อเก็บข้อมูลธรรมดาเท่านั้น และฟังก์ชั่นควรแยกออกจากฐานข้อมูลอย่างสมบูรณ์ "

พวกคุณช่วยแนะนำฉันหน่อยได้ไหมว่าเขาพูดถูกไหม จะไปเกี่ยวกับสถาปนิกแอปพลิเคชันเช่นนี้ได้อย่างไร?


3
"และเราได้รับการเพิ่มประสิทธิภาพอย่างมากจริง ๆ " เมื่อเทียบกับอะไร เมื่อคุณไม่เคยใช้ฟังก์ชั่นเดียวกันกับลูกค้าคุณจะรู้ได้อย่างไร?
Doc Brown

3
ฉันคิดว่ามันจะเป็นปกติ - ขึ้นอยู่กับโครงการการใช้ข้อมูลและทักษะของทีม
Daniel Iankov

1
คุณควรถาม CTO ของคุณว่าอะไรทำให้เขาคิดว่าฐานข้อมูลไม่ได้ใช้เทคนิคที่เขาโปรดปรานและเหตุใดขั้นตอนการจัดเก็บจึงไม่ถือว่าเป็น "รหัส"
Blrfl

3
Facebook และ Google มีปัญหาในระดับที่แตกต่างอย่างสิ้นเชิงกับแอพพลิเคชั่นส่วนใหญ่ - อาจมีปัญหาเกี่ยวกับปริมาณข้อมูลที่คุณต้องจัดการในแง่ของข้อมูลจากตลาด แต่ฐานข้อมูล SQL แบบร่วมสมัยถูกสร้างขึ้นเพื่อรับมือกับข้อมูลจำนวนมหาศาล
Murph

1
ฉันอาจจะคิดแบบเดียวกับ CTO ของคุณเว้นแต่คุณจะพิสูจน์ได้ว่าโซลูชันของเขาไม่เพียงพอและไม่มีวิธีอื่นในการจัดการ ขั้นตอนการจัดเก็บโดยเฉพาะอย่างยิ่งเมื่อจำนวนของพวกเขามีขนาดใหญ่ก่อให้เกิดอุปสรรคอย่างมากในการย้ายไปยังฐานข้อมูลอื่น ๆ ถ้าจำเป็น ... ไม่สามารถทำนายอนาคต
Rig

คำตอบ:


23

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

ความใกล้เคียงกับข้อมูล: ลองย้อนกลับไปก่อน มีบางเหตุผลที่ดีสำหรับการกดรหัสลงในฐานข้อมูล ฉันจะยืนยันว่าสิ่งที่ยิ่งใหญ่ที่สุดคือความใกล้เคียงกับข้อมูล - ตัวอย่างเช่นหากคุณคาดหวังว่าการคำนวณจะคืนค่าจำนวนหนึ่ง แต่สิ่งเหล่านี้เป็นการรวมตัวกันของเร็กคอร์ดหลายล้านเร็กคอร์ด เครือข่ายที่จะรวมกันที่อื่นนั้นสิ้นเปลืองอย่างมหาศาลและสามารถฆ่าระบบของคุณได้อย่างง่ายดาย เมื่อกล่าวถึงสิ่งนี้คุณสามารถบรรลุความใกล้ชิดของข้อมูลในรูปแบบอื่นโดยใช้แคชหรือฐานข้อมูลการวิเคราะห์ที่มีการรวมกลุ่มบางส่วนเสร็จล่วงหน้า

ประสิทธิภาพของรหัสใน DB:ผลการปฏิบัติงานรองเช่น "แคชแผนการดำเนินการ" นั้นยากที่จะโต้แย้ง บางครั้งแผนปฏิบัติการที่แคชอาจเป็นสิ่งที่เป็นลบมากหากแผนการดำเนินการที่ไม่ถูกต้องถูกแคช ขึ้นอยู่กับ RDBMS ของคุณคุณอาจได้รับประโยชน์สูงสุดจากสิ่งเหล่านี้ แต่คุณจะไม่ได้รับ SQL ที่เกินขอบเขตในกรณีส่วนใหญ่ ฉันจะยืนยันว่าภาษาที่คอมไพล์หรือ JIT ส่วนใหญ่มักจะทำงานได้ดีกว่า SQL เทียบเท่าของพวกเขา (เช่น T-SQL หรือ PL / SQL) สำหรับการดำเนินงานขั้นพื้นฐานและการเขียนโปรแกรมที่ไม่ใช่เชิงสัมพันธ์ (การจัดการสตริง, ลูป ฯลฯ ) ไม่เสียอะไรที่นั่นถ้าคุณใช้บางสิ่งบางอย่างเช่น Java หรือ C # เพื่อทำตัวเลขซ้ำซ้อน การปรับให้เหมาะสมแบบละเอียดนั้นก็ค่อนข้างยากเช่นกันบนฐานข้อมูลคุณ มักจะติดอยู่กับ B-tree ทั่วไป (ดัชนี) เป็นโครงสร้างข้อมูลเดียวของคุณ เพื่อความเป็นธรรมการวิเคราะห์อย่างเต็มรูปแบบรวมถึงสิ่งต่าง ๆ เช่นการทำธุรกรรมที่ยาวนานขึ้นการเพิ่มระดับการล็อก ฯลฯ สามารถเติมหนังสือได้

การบำรุงรักษา: SQL เป็นภาษาที่ยอดเยี่ยมสำหรับสิ่งที่มันถูกออกแบบมาเพื่อทำ ฉันไม่แน่ใจว่ามันเป็นแบบที่ดีสำหรับตรรกะแอปพลิเคชัน เครื่องมือและวิธีปฏิบัติส่วนใหญ่ที่ทำให้ชีวิตของเรานั้นทนทาน (TDD, การเปลี่ยนโครงสร้าง ฯลฯ ) ยากที่จะนำไปใช้กับการเขียนโปรแกรมฐานข้อมูล

ประสิทธิภาพเทียบกับความสามารถในการปรับขยาย:ในการชี้แจงข้อกำหนดเหล่านี้ฉันหมายถึงสิ่งนี้: ประสิทธิภาพคือความรวดเร็วในการที่คุณคาดหวังว่าคำขอเดียวจะต้องผ่านระบบของคุณ (และกลับสู่ผู้ใช้) ในขณะที่สมมติว่าโหลดต่ำ สิ่งนี้มักจะถูก จำกัด ด้วยสิ่งต่าง ๆ เช่นจำนวนของเลเยอร์ทางกายภาพที่ผ่านไปการเพิ่มประสิทธิภาพของเลเยอร์เหล่านั้นเป็นอย่างไร ฯลฯ ความสามารถในการปรับขนาดคือการเปลี่ยนแปลงประสิทธิภาพเมื่อเพิ่มจำนวนผู้ใช้ / โหลด คุณอาจมีประสิทธิภาพปานกลาง / ต่ำ (กล่าวคือ 5 วินาที + สำหรับการร้องขอ) แต่ความสามารถในการปรับขยายที่ยอดเยี่ยม (สามารถรองรับผู้ใช้หลายล้านคน) ในกรณีของคุณคุณอาจจะประสบกับประสิทธิภาพที่ดี แต่ความสามารถในการปรับขนาดของคุณจะถูก จำกัด โดยเซิร์ฟเวอร์ขนาดใหญ่ที่คุณสามารถสร้างได้ เมื่อถึงจุดหนึ่งคุณจะถึงขีด จำกัด นั้นและถูกบังคับให้หันไปหาสิ่งต่าง ๆ เช่นการเรียงลำดับซึ่งอาจไม่สามารถทำได้ขึ้นอยู่กับลักษณะของแอปพลิเคชัน

การเพิ่มประสิทธิภาพก่อนวัย: ในที่สุดฉันคิดว่าคุณทำผิดพลาดในการปรับให้เหมาะสมก่อนเวลาอันควร ในขณะที่คนอื่น ๆ ชี้ให้เห็นคุณไม่ได้มีการวัดจริง ๆ แสดงให้เห็นว่าวิธีการอื่น ๆ จะทำงานอย่างไร เราไม่สามารถสร้างต้นแบบเต็มรูปแบบเพื่อพิสูจน์หรือหักล้างทฤษฎีได้เสมอ ... แต่โดยทั่วไปฉันมักลังเลที่จะเลือกวิธีที่ใช้ในการแลกเปลี่ยนความสามารถในการบำรุงรักษา .

แก้ไข: ในแง่บวกการปรับขนาดแนวตั้งสามารถยืดได้ค่อนข้างไกลในบางกรณี เท่าที่ฉันรู้ดังนั้นทำงานบนเซิร์ฟเวอร์เดียวสำหรับบางครั้ง ฉันไม่แน่ใจว่ามันตรงกับผู้ใช้ 10,000 คนของคุณอย่างไร (ฉันเดาว่ามันขึ้นอยู่กับลักษณะของสิ่งที่พวกเขากำลังทำในระบบของคุณ) แต่มันให้ความคิดว่าคุณสามารถทำอะไรได้บ้าง ตัวอย่างที่น่าประทับใจยิ่งขึ้นสิ่งนี้เพิ่งได้รับความนิยมอย่างที่คนคนหนึ่งเข้าใจได้ง่าย)

แก้ไข 2: เพื่อชี้แจงและแสดงความคิดเห็นในบางสิ่งที่ยกมาที่อื่น:

  • เรื่องความสอดคล้องของอะตอม - ความสอดคล้องของกรดอาจเป็นข้อกำหนดของระบบ ข้างต้นไม่ได้โต้แย้งกับสิ่งนั้นจริง ๆ และคุณควรตระหนักว่าความสอดคล้องของกรดไม่ต้องการให้คุณใช้ตรรกะทางธุรกิจทั้งหมดของคุณภายในฐานข้อมูล ด้วยการย้ายรหัสซึ่งไม่จำเป็นต้องอยู่ในฐานข้อมูลคุณกำลังบังคับให้มันทำงานในสภาพแวดล้อมทางกายภาพของส่วนที่เหลือของฐานข้อมูล - มันเป็นการแข่งขันสำหรับทรัพยากรฮาร์ดแวร์เดียวกันกับส่วนการจัดการข้อมูลจริงของฐานข้อมูลของคุณ สำหรับการปรับขนาดรหัสออกไปยังเซิร์ฟเวอร์ฐานข้อมูลอื่น ๆ (แต่ไม่ใช่ข้อมูลจริง) - แน่นอนว่าอาจเป็นไปได้แต่สิ่งที่คุณได้รับตรงนี้นอกเหนือจากค่าลิขสิทธิ์เพิ่มเติมในกรณีส่วนใหญ่ เก็บสิ่งที่ไม่จำเป็นต้องอยู่บนฐานข้อมูลออกจากฐานข้อมูล
  • Re: ประสิทธิภาพของ SQL / C # - เนื่องจากนี่เป็นหัวข้อที่น่าสนใจเรามาเพิ่มการสนทนากันสักหน่อย คุณสามารถเรียกใช้โค้ดเนทีฟ / Java / C # ในฐานข้อมูลได้ แต่เท่าที่ฉันรู้นั่นไม่ใช่สิ่งที่ถูกกล่าวถึงที่นี่ - เรากำลังเปรียบเทียบการใช้โค้ดแอปพลิเคชันทั่วไปในบางสิ่งเช่น T-SQL กับ C # มีปัญหาหลายอย่างที่แก้ไขได้ยากด้วยรหัสเชิงสัมพันธ์ในอดีต - พิจารณาปัญหา "การลงชื่อเข้าใช้พร้อมกันสูงสุด" ซึ่งคุณมีบันทึกที่ระบุการเข้าสู่ระบบหรือการออกจากระบบและเวลาและคุณต้องคิดออกว่า จำนวนผู้ใช้สูงสุดที่เข้าสู่ระบบในแต่ละครั้งคือ ทางออกที่ง่ายที่สุดที่เป็นไปได้คือการวนซ้ำระเบียนและเพิ่ม / ลดจำนวนตัวนับในขณะที่คุณพบการเข้าสู่ระบบ / ออกจากระบบและการติดตามสูงสุดของค่านี้อาจฉันไม่รู้) สิ่งที่ดีที่สุดที่คุณสามารถทำได้คือเคอร์เซอร์ (โซลูชันเชิงสัมพันธ์ล้วนมีความซับซ้อนแตกต่างกันและพยายามที่จะแก้ปัญหาโดยใช้ขณะที่ลูปส่งผลให้ประสิทธิภาพแย่ลง) ในกรณีนี้ใช่แล้วโซลูชัน C # นั้นเร็วกว่าสิ่งที่คุณสามารถทำได้ใน T-SQL, ช่วงเวลา ที่อาจดูไกล แต่ปัญหานี้สามารถประจักษ์เองได้อย่างง่ายดายในระบบการเงินถ้าคุณกำลังทำงานกับแถวที่แสดงถึงการเปลี่ยนแปลงที่เกี่ยวข้องและจำเป็นต้องคำนวณการรวมตัวกันของหน้าต่าง การเรียกใช้ proc ที่จัดเก็บมีแนวโน้มที่จะมีราคาแพงกว่า - เรียกใช้ SP เล็กน้อยเป็นล้านครั้งและดูว่าการเปรียบเทียบกับการเรียกใช้ฟังก์ชัน C # ได้อย่างไร ฉันพูดถึงตัวอย่างอื่น ๆ ด้านบน - ฉันยังไม่พบใครใช้ตารางแฮชที่เหมาะสมใน T-SQL (อันที่ให้ประโยชน์บางอย่าง) ในขณะที่มันค่อนข้างง่ายที่จะทำใน C # อีกครั้งมีสิ่งที่ดีเลิศที่น่ากลัวและสิ่งที่พวกเขาไม่น่ากลัว เช่นเดียวกับที่ฉันไม่ต้องการเข้าร่วม SUMs และ GROUP BYs ใน C # ฉันไม่ต้องการเขียนอะไรโดยเฉพาะอย่างยิ่ง CPU ที่เข้มข้นใน T-SQL

หนึ่งในเหตุผลที่ฉันมักจะผลักดันการทำงานไปยังฐานข้อมูลนั้นเป็นรถที่น้อยกว่ารหัสระดับแอปพลิเคชัน SQL เป็นสิ่งที่ประกาศและไม่ได้รับความเดือดร้อนจากปัญหามากมายที่ภาษาที่จำเป็นต้องทำ
wobbily_col

เกี่ยวกับการบำรุงรักษาการใช้การบำรุงรักษาเครื่องมือ SQL Server Data Tools เป็นของแน่นอน ในความเป็นจริงสำหรับฐานข้อมูลใด ๆ ที่ไม่น่าสนใจ (หนึ่งที่มีมากกว่า 5 ตาราง) ฉันจะพิจารณาความต้องการ
Jon49

4

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

ฉันไม่แน่ใจว่า CTO ของคุณกำลังรับข้อมูลของเขาเกี่ยวกับปัญหาความสามารถในการปรับขนาดได้ แต่จากสิ่งที่คุณพูดมามันไม่ได้ดูเหมือนว่าเขามีเหตุผลที่แท้จริงสำหรับการตั้งคำถามเกี่ยวกับการตัดสินใจทางสถาปัตยกรรมในปัจจุบันนอกเหนือจากแนวโน้มแฟชั่นซอฟต์แวร์ การอ้างอิงการตัดสินใจทางสถาปัตยกรรมเกี่ยวกับแนวโน้มดังกล่าวมักเป็นความคิดที่ไม่ดี


1
+1 สำหรับScalability is all about how you manage global state and data inter-dependence.
Estefany Velez

2

และเราได้รับการเพิ่มประสิทธิภาพอย่างมาก

ฉันคิดว่าคุณต้องกำหนดเกณฑ์มาตรฐานประสิทธิภาพและเริ่มสร้างต้นแบบของคุณก่อน การรักษาตรรกะทั้งหมดใน DB เป็นโรงเรียนเก่า (ฉันไม่ได้ทำอะไรเลย) ในการจัดการกับสถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์ แม้ว่าจะมีข้อดีคือมีจำนวนข้อเสียเปรียบที่ต้องพิจารณา

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

คุณได้พูดถึงทริกเกอร์ด้วย การใช้ทริกเกอร์อาจกลายเป็น gotchas ขนาดใหญ่ในภายหลังในวงจรชีวิตของแอปพลิเคชันฉันจะต้องระมัดระวังเป็นสองเท่ากับมันและพยายามข้ามการใช้งานไป


2

CTO ของคุณผิด 100%

หมายเลขทางการเงินของคุณต้องเพิ่มขึ้นตลอดเวลา นั่นหมายความว่าคุณต้องการACIDและ DB สัมพันธ์เป็นสถานที่ที่ดีที่สุดในการรับประกัน ประสิทธิภาพที่เพิ่มขึ้นของ NoSql DB มักจะเป็นค่าใช้จ่ายของกรดและนั่นก็โอเคสำหรับ Google และ Facebook แต่ไม่ใช่สำหรับระบบที่มีการเงิน

ในการบอกว่า C # ทำงานได้ดีกว่ารหัส SQL ก็เป็นเรื่องงี่เง่า ...


ถ้าจะบอกว่า C # ทำงานได้ดีกว่าโค้ด SQL ก็เป็นเรื่องงี่เง่า ... - แต่คุณไม่ปฏิเสธว่าโค้ด C # นั้นสามารถปรับขนาดได้มากกว่าใช่ไหม?
Jim G.

ไม่มีความสามารถในการปรับขนาดได้อีกต่อไปเนื่องจากไม่ได้อยู่ที่ตำแหน่งคอขวดฉันสามารถปรับขนาดรหัส Sql (ไม่ใช่ข้อมูล) ในแนวนอนได้อย่างง่ายดายเช่นเดียวกับที่ฉันสามารถปรับขนาดรหัส C # ในแนวนอนได้
Morons

@JimG เพื่อความชัดเจน "ฉันสามารถปรับขนาดรหัส Sql (ไม่ใช่ข้อมูล) ในแนวนอนได้อย่างง่ายดายเช่นเดียวกับที่ฉันสามารถปรับขนาดรหัส C # ในแนวนอน" ถ้ามันถูกออกแบบมาให้ทำ ... เช่นเดียวกับ C # คุณไม่สามารถบอกได้ว่าเครื่องชั่ง C # ดีกว่ามันเป็นเรื่องของการวางแผนไม่ใช่ภาษา
Morons

@JimG: ซอฟต์แวร์ที่ไม่มีขนาดสามารถเขียนได้ในภาษาใด ๆ รวมถึง C # ฐานข้อมูลใด ๆ ที่คุ้มค่าสามารถมีขั้นตอนการจัดเก็บที่เขียนในภาษาอื่นนอกเหนือจากการใช้ SQL-ish ดั้งเดิมของพวกเขาและผู้ที่ออกไปสู่จุดสุดยอดด้วย NoSQL ในสถานการณ์ที่ต้องการ ACID มักจะจบลงด้วยการประดิษฐ์ล้อส่วนใหญ่ ดำเนินการโดย DBMS
Blrfl

@ Morons: ฉันคิดว่าเราเห็นด้วย ในความเป็นจริงฉันกำลังสับสนข้อมูลด้วย "SQL" มันมีราคาแพงกว่ามากในการขยายฐานข้อมูล
Jim G.

2

เมื่อใดก็ตามที่ทุกคนพูดถึงความยืดหยุ่นและ Google / Facebook / Twitter / ฯลฯ มันเป็นปลาเฮอริ่งแดง หากคุณไม่ได้ให้บริการเดียวกันเป็นหลักสิ่งที่ได้ผลสำหรับพวกเขาอาจไม่เหมาะสมสำหรับคุณ โดยทั่วไปหากคุณสามารถปรับขนาดจากเครื่องเดียวเป็นคลัสเตอร์แปดเครื่องคุณอาจครอบคลุมฐานทั้งหมดของคุณ หากคุณไม่มีความต้องการทางธุรกิจอย่างหนักในการให้บริการการดูหน้าเว็บ 20M ต่อวันไม่ต้องกังวลกับการปรับขนาดไฮเปอร์ ทำสิ่งที่สมเหตุสมผลสำหรับความต้องการที่แท้จริงของแอปพลิเคชันของคุณและกังวลเกี่ยวกับการเพิ่มขนาดเมื่อเห็นได้ชัดว่าคุณต้องการ และอย่าลืมว่าเซิร์ฟเวอร์ฐานข้อมูลส่วนใหญ่สามารถทำคลัสเตอร์ด้วยเช่นกันเพียงเพราะทุกอย่างในฐานข้อมูลเดียวไม่ได้หมายความว่าอยู่ในเซิร์ฟเวอร์เดียว

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.