เหตุใดจึงไม่ดีในการอ่านข้อมูลจากฐานข้อมูล“ เป็นเจ้าของ” โดย microservice ที่แตกต่างกัน


64

ฉันเพิ่งอ่านบทความที่ยอดเยี่ยมนี้ในสถาปัตยกรรม microservice: http://www.infoq.com/articles/microservices-intro

มันระบุว่าเมื่อคุณโหลดหน้าเว็บใน Amazon แล้วไมโครไซต์กว่า 100 รายการจะร่วมมือเพื่อให้บริการหน้านั้น

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

ฉันทำอะไรบางอย่างหายไปหรือเปล่า มีเหตุผลอื่นอีกไหมทำไมข้อมูลควรอ่านผ่าน API เท่านั้น?

บริษัท ของฉันเล็กกว่า Amazon อย่างมาก (และจะเป็นเสมอ) และจำนวนผู้ใช้สูงสุดที่เราสามารถมีได้ประมาณ 5 ล้านคน


ปัจจัยทั่วไปอีกข้อหนึ่งที่ไม่ได้กล่าวถึงในคำตอบก็คือเมื่อเขียนไปยังฐานข้อมูลแคชในพื้นที่แม้แต่การทำแผนที่ O / R อย่างง่ายอาจให้ข้อมูลเก่าเมื่อเข้าถึงฐานข้อมูลทันที หากคุณพิจารณาเลี่ยงการใช้ API ของบริการด้วยเหตุผลด้านความเร็วอาจเป็นเพราะการใช้สถาปัตยกรรมของบริการนั้นไกลเกินไป
Joop Eggen

เมื่ออนุญาตให้ฐานข้อมูลอ่านรายละเอียดทั้งหมดของฐานข้อมูลกลายเป็นส่วนหนึ่งของ API สาธารณะ ฉันไม่ต้องการรักษาความเข้ากันได้กับ API ที่ซับซ้อนเช่นนี้
Patrick

แต่ในกรณีนั้นมุมมองไม่ได้เป็นเพียงส่วนหนึ่งของ API อย่างน้อยก็เพื่อจุดประสงค์ทางความหมาย? เป็นเพียงเรื่องของสิ่งที่คุณกำลังเรียก API และสิ่งที่บังคับให้คุณรักษา (โดยปกติเลเยอร์ด้านบนฐานข้อมูลนั้นจะทำให้สอดคล้องกันได้ง่ายขึ้น)
lc

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

คำตอบ:


69

ฐานข้อมูลไม่ค่อยดีในการซ่อนข้อมูลซึ่งเป็นไปได้ค่อนข้างมากเพราะหน้าที่ของพวกเขาคือการเปิดเผยข้อมูล แต่นี่ทำให้พวกมันเป็นเครื่องมือที่น่ารังเกียจเมื่อมันมาถึงการห่อหุ้ม ทำไมคุณถึงต้องการการห่อหุ้ม

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

การคลำหาชั้นจัดเก็บข้อมูลโดยตรงจากชั้นแอปพลิเคชันเป็นสิ่งที่ตรงกันข้ามกับสิ่งที่หลักการผกผันพึ่งพาอาศัยแนะนำให้ทำ


1
นี่เป็นจุดที่ดีมาก! สิ่งหนึ่งที่ทำให้ผมกังวลน้อยคือ Postgres ขณะนี้มีการสนับสนุนทั้งการจัดเก็บเอกสารและการ RDBMS ( withouttheloop.com/articles/2014-09-30-postgresql-nosql ) แม้ว่าจุดของคุณยังคงถูกต้องและฉันจะพิจารณาอย่างรอบคอบ
David

3
มันไม่ควรทำให้คุณกังวลน้อยลง @David เพียงเพราะเครื่องมือสามารถทำอะไรบางอย่างไม่ได้หมายความว่าการเปลี่ยนแปลงมันจะไม่ทำลายอะไรมากมาย นั่นคือจุดที่มีระดับของการแยก - คุณสามารถเปลี่ยนแปลงข้อมูลเบื้องหลัง API ได้อย่างสมบูรณ์โดยไม่ต้องเปลี่ยนสิ่งที่ผู้ใช้เห็น ฉันกำลังพูดในฐานะ databaser ที่นี่ ... ตราบใดที่ลูกค้าเห็นว่าเป็นสิ่งเดียวกันคุณสามารถเปลี่ยนแบ็กเอนด์ได้มากเท่าที่คุณต้องการ
เบ็น

1
@ David ในขณะที่นี่เป็นข่าวที่น่าสนใจมันค่อนข้างไม่เกี่ยวข้องกับสถานการณ์ที่ฉันอธิบาย หากคุณเปลี่ยน DB schema ของคุณจากความสัมพันธ์เป็นเอกสารที่อ้างอิงมันจะมีผลกระทบเหมือนกันกับสิ่งที่ขึ้นอยู่กับมันคุณจะต้องเขียนแบบสอบถามทั้งหมดอีกครั้ง นอกจากนี้ยังมีฝันร้ายที่ต้องปรับใช้การเปลี่ยนแปลงเหล่านี้ทั้งหมดในครั้งเดียวเพื่อให้ความเข้ากันได้ระหว่างส่วนประกอบต่าง ๆ ทั่วทั้งระบบ
back2dos

1
@David: การ จำกัด การเข้าถึงมุมมองที่กำหนดไว้ไม่กี่รายการนั้นหมายถึงการสร้าง API อื่นด้วยสิทธิประโยชน์บางประการที่มาพร้อมกับมัน ตราบใดที่มันเป็นเพียงการดูคุณจะถูก จำกัด ให้เข้าถึงแบบอ่านอย่างเดียว และการมีส่วนประกอบขึ้นอยู่กับทั้ง API บริการและ API การดูทำให้มันบอบบางมาก ดังนั้นหากคุณสร้างส่วนประกอบขึ้นอยู่กับมุมมองคุณได้กำหนดไว้ล่วงหน้าว่าให้อ่านอย่างเดียวหรือบำรุงรักษาสูง ฉันได้กลิ่นหนี้ทางเทคนิคที่นี่ นอกจากนี้คุณอาจต้องการเพิ่มการแบ่งพาร์ติชันในแนวนอนในลักษณะที่ฐานข้อมูลของคุณไม่อนุญาตให้คุณ
back2dos

2
@David: ในระยะยาวสิ่งสำคัญคือการเปลี่ยนรหัสง่ายกว่าการเขียน สถาปัตยกรรมไม่ได้พูดว่า "คุณไม่ควรเขียนโค้ดในลักษณะเช่นนี้" มันบอกว่า "ถ้าคุณทำคุณจะต้องเจอกับฝันร้ายที่น่ากลัวที่พยายามรักษามันไว้" หากคุณกำลังพูดถึงต้นแบบการบำรุงรักษาไม่ใช่ข้อกำหนด ไปข้างหน้า ต้นแบบควรพิสูจน์จุดได้ง่ายที่สุด แต่เมื่อพยายามที่จะรวมคะแนนที่ได้รับการพิสูจน์แล้วทั้งหมดเข้ากับระบบโดยที่ไม่ต้องตกอยู่ในการทรมานที่เกิดจากตัวเองของ Sisyphean
back2dos

55

อะไรคือสิ่งสำคัญและมีความสำคัญเกี่ยวกับ microservice: API หรือ schema ของฐานข้อมูล API เนื่องจากเป็นสัญญากับส่วนที่เหลือของโลก สคีมาฐานข้อมูลเป็นวิธีที่สะดวกในการจัดเก็บข้อมูลที่จัดการโดยบริการโดยหวังว่าจะจัดระเบียบในวิธีที่ช่วยเพิ่มประสิทธิภาพการทำงานของบริการไมโคร ทีมพัฒนาควรมีอิสระในการจัดระเบียบสคีมานั้นใหม่หรือเปลี่ยนไปใช้โซลูชันดาต้าสโตร์ที่แตกต่างกันโดยสิ้นเชิงได้ทุกเวลา ส่วนที่เหลือของโลกไม่ควรสนใจ ส่วนที่เหลือของโลกใส่ใจเมื่อ API เปลี่ยนแปลงเนื่องจาก API เป็นสัญญา

ทีนี้ถ้าคุณไปที่ฐานข้อมูล

  • คุณเพิ่มการพึ่งพาที่ไม่พึงประสงค์ใน schema ของพวกเขา พวกเขาไม่สามารถเปลี่ยนแปลงได้โดยไม่ส่งผลกระทบต่อบริการของคุณ
  • คุณเพิ่มการโหลดที่ไม่พึงประสงค์และคาดเดาไม่ได้ให้กับ internals ของพวกเขา
  • ประสิทธิภาพของบริการของคุณจะได้รับผลกระทบจากประสิทธิภาพของฐานข้อมูลของพวกเขา (พวกเขาจะพยายามเพิ่มประสิทธิภาพบริการของพวกเขาให้ทำงานได้ดีสำหรับลูกค้าและฐานข้อมูลของพวกเขาเพื่อให้ทำงานได้ดีสำหรับบริการของพวกเขาเท่านั้น)
  • คุณกำลังผูกติดตั้งสคีมาซึ่งอาจไม่ถูกต้องและชัดเจนเป็นตัวแทนทรัพยากรในแหล่งข้อมูลของพวกเขา - มันอาจมีรายละเอียดเพิ่มเติมที่จำเป็นเพียงเพื่อติดตามสถานะภายในหรือตอบสนองการใช้งานเฉพาะของพวกเขา
  • คุณอาจทำลายหรือเสื่อมสภาพสถานะการรับบริการของพวกเขาโดยไม่เจตนา (และพวกเขาจะไม่ทราบว่าคุณกำลังทำสิ่งนี้อยู่)
  • คุณสามารถอัปเดต / ลบ / ลบทรัพยากรออกจากฐานข้อมูลโดยที่พวกเขาไม่ทราบว่าสิ่งนี้เกิดขึ้น

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

มันเป็นเรื่องธรรมดาสำหรับนักพัฒนาที่มีประสบการณ์น้อยกว่า (หรือผู้ที่ไม่ได้เรียนรู้) เพื่อดูฐานข้อมูลที่มีความสำคัญมากกว่าบริการเพื่อดูฐานข้อมูลเป็นของจริงและบริการเป็นเพียงวิธีการเข้าถึง นั่นคือวิธีที่ผิดรอบ


4
โปรดทราบว่าคะแนนทั้งหมดข้างต้นใช้ได้แม้ว่าคุณจะเป็นนักพัฒนาซอฟต์แวร์เพียงคนเดียวที่ทำงานในโครงการทั้งหมด การจัดการโครงการที่ซับซ้อนด้วยตัวคุณเองจะก่อให้เกิดข้อกังวลเหล่านี้ทั้งหมด
itsbruce

15

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

การเขียนและการอ่านจากฐานข้อมูลที่อยู่นอกโดเมนธุรกิจของคอมโพเนนต์ของคุณนั้นขัดกับสถาปัตยกรรมสไตล์นี้

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

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

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

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


4

ในช่วง 20 ปีที่ผ่านมาฉันได้เห็นการออกแบบฐานข้อมูลขนาดใหญ่จำนวนเล็กน้อยและฉันได้เห็นสถานการณ์ที่ David แนะนำมาหลายครั้งในขณะนี้ที่แอปพลิเคชันมีสิทธิ์เขียน schema / ชุดตารางของตนเองและอ่านการเข้าถึง schema อื่น / ชุดโต๊ะ ส่วนใหญ่มักจะข้อมูลนี้ว่าโปรแกรมประยุกต์ / โมดูลได้รับการอ่านอย่างเดียวเข้าถึงสามารถอธิบายได้ว่า"ข้อมูลหลัก"

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

สถานการณ์จำลอง: คุณผูกส่วนประกอบสองส่วนเข้ากับ RDBMS โดยตรงและคุณเห็นส่วนประกอบหนึ่งกลายเป็นคอขวดประสิทธิภาพ

ฉันเห็นด้วยกับความคิดเห็นนี้นอกจากนี้ยังเป็นข้อโต้แย้งที่มีสำเนาของข้อมูลในเครื่องเพื่อให้ microservice อ่าน นั่นคือฐานข้อมูลที่เป็นผู้ใหญ่ส่วนใหญ่รองรับการจำลองแบบและดังนั้นโดยไม่ต้องใช้ความพยายามของนักพัฒนาใด ๆ "ข้อมูลหลัก" สามารถจำลองแบบทางกายภาพไปยังฐานข้อมูล microservice หากต้องการหรือจำเป็น

บางคนอาจจำสิ่งนี้ในหน้ากากเก่าเป็น "ฐานข้อมูลองค์กร" จำลองตารางหลักไปที่ "ฐานข้อมูลแผนก" จุดนี่คือโดยทั่วไปจะดีถ้าฐานข้อมูลทำสิ่งนี้ให้กับเราด้วยการสร้างแบบจำลองของข้อมูลที่เปลี่ยนแปลง (deltas เท่านั้นในรูปแบบไบนารีและค่าใช้จ่ายน้อยที่สุดในฐานข้อมูลแหล่งที่มา)

ในทางกลับกันเมื่อตัวเลือกฐานข้อมูลของเราไม่อนุญาตการสนับสนุนการจำลองแบบ 'ปิดชั้นวาง' เราสามารถเข้าสู่สถานการณ์ที่เราต้องการผลักดัน "ข้อมูลหลัก" ออกไปยังฐานข้อมูล microservice และอาจส่งผลให้นักพัฒนาจำนวนมากพยายาม ยังเป็นกลไกที่มีประสิทธิภาพลดลงอย่างมาก

อาจต้องการทำให้ฐานข้อมูลผิดปกติ แต่คุณไม่สามารถทำได้เนื่องจากส่วนประกอบอื่นทั้งหมดจะได้รับผลกระทบ

สำหรับฉันแล้วข้อความนี้ไม่ถูกต้อง Denormalisation เป็นการเปลี่ยนแปลง "สารเติมแต่ง" ไม่ใช่การเปลี่ยนแปลงแบบ "แตกหัก" และไม่ควรทำลายแอปพลิเคชันเนื่องจากการกระทำผิดปกติ

วิธีเดียวที่จะทำให้แอปพลิเคชันแตกรหัสแอปพลิเคชันที่ใช้บางอย่างเช่น "select * ... " และไม่จัดการคอลัมน์พิเศษ สำหรับฉันแล้วนั่นจะเป็นข้อบกพร่องในแอปพลิเคชันหรือไม่

denormalisation จะทำลายแอปพลิเคชันได้อย่างไร ฟังดูเหมือน FUD สำหรับฉัน

การพึ่งพาสคีมา:

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

ข้อมูลหลัก

สคีมาที่โดยทั่วไปแล้วเราอาจต้องการให้ microservice มีการเข้าถึงแบบอ่านอย่างเดียวเป็นสิ่งที่ฉันอธิบายว่าเป็น " ข้อมูลหลัก " สำหรับองค์กร มีข้อมูลหลักที่จำเป็นต่อองค์กร

ในอดีตนี่หมายถึงสคีมาที่เราเพิ่มการพึ่งพานั้นมีทั้งที่เป็นผู้ใหญ่และมีเสถียรภาพ (ค่อนข้างพื้นฐานสำหรับองค์กรและไม่มีการเปลี่ยนแปลง)

normalization

หากนักออกแบบฐานข้อมูล 3 คนไปและออกแบบ db schema ที่ทำให้เป็นมาตรฐานพวกเขาจะสิ้นสุดที่การออกแบบเดียวกัน ตกลงอาจมีรูปแบบ 4NF / 5NF บางอย่าง แต่ไม่มาก มีคำถามอีกหลายข้อที่ผู้ออกแบบสามารถถามเพื่อตรวจสอบความถูกต้องของแบบจำลองเพื่อให้ผู้ออกแบบสามารถมั่นใจได้ว่าพวกเขามาถึง 4NF (ฉันเป็นคนมองโลกในแง่ดีเกินไปหรือไม่?

อัปเดต:โดย4NFที่นี่ฉันหมายถึงตารางทั้งหมดในสคีมามีรูปแบบปกติสูงสุดถึง 4NF (ตารางทั้งหมดได้รับการทำให้เป็นมาตรฐานอย่างเหมาะสมสูงสุดถึง 4NF)

ฉันเชื่อว่ากระบวนการออกแบบการทำให้เป็นมาตรฐานคือสาเหตุที่ผู้ออกแบบฐานข้อมูลมักรู้สึกสบายใจกับแนวคิดที่ขึ้นอยู่กับสคีมาฐานข้อมูลที่ทำให้เป็นมาตรฐาน

กระบวนการของการทำให้เป็นมาตรฐานได้รับการออกแบบ DB ไปสู่การออกแบบ "ถูกต้อง" ที่เป็นที่รู้จักและความแปรปรวนจากที่นั่นควรจะเป็น

  1. อาจมีรูปแบบที่แตกต่างกันไปตามประเภทฐานข้อมูลที่รองรับ (JSON, ARRAY, ประเภทสนับสนุนทางภูมิศาสตร์ ฯลฯ )
  2. บางคนอาจโต้แย้งสำหรับการเปลี่ยนแปลงตาม 4NF / 5NF
  3. เราไม่รวมการเปลี่ยนแปลงทางกายภาพ (เพราะนั่นไม่สำคัญ)
  4. เรา จำกัด สิ่งนี้ไว้สำหรับการออกแบบ OLTP ไม่ใช่การออกแบบ DW เนื่องจากเป็นแบบแผนที่เราต้องการให้สิทธิ์การเข้าถึงแบบอ่านอย่างเดียว

ถ้า 3 โปรแกรมเมอร์ที่ได้รับการออกแบบเพื่อนำไปใช้ (เป็นรหัส) ความคาดหวังจะเป็น 3 การใช้งานที่แตกต่างกัน (อาจแตกต่างกันมาก)

สำหรับฉันอาจมีคำถามของ "ศรัทธาในการฟื้นฟู"

ทำลายสคีมาเปลี่ยนแปลงหรือไม่

Denormalisation การเพิ่มคอลัมน์แก้ไขคอลัมน์สำหรับพื้นที่เก็บข้อมูลขนาดใหญ่การขยายการออกแบบด้วยตารางใหม่และอื่น ๆ ล้วนเป็นการเปลี่ยนแปลงแบบไม่ทำลายและนักออกแบบฐานข้อมูลที่เข้าสู่รูปแบบที่ 4 จะมั่นใจได้ว่า

เห็นได้ชัดว่าการเปลี่ยนแปลงแบบแบ่งย่อยทำได้โดยการวางคอลัมน์ / ตารางหรือทำการเปลี่ยนแปลงแบบแบ่ง เป็นไปได้ใช่ แต่ในแง่ปฏิบัติฉันไม่เคยพบปัญหาใด ๆ เลย อาจเป็นเพราะมันเป็นที่เข้าใจกันว่าการเปลี่ยนแปลงที่เกิดขึ้นเป็นอย่างไรและสิ่งเหล่านี้มีการจัดการที่ดี?

ฉันสนใจที่จะรับฟังกรณีที่มีการเปลี่ยนแปลงสคีมาในบริบทของสคีมาแบบอ่านอย่างเดียว

อะไรคือสิ่งสำคัญและมีความสำคัญเกี่ยวกับ microservice: API หรือ schema ของฐานข้อมูล API เนื่องจากเป็นสัญญากับส่วนที่เหลือของโลก

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

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

มีปัญหากับ API หรือไม่

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

What motivates people to desire local read-only access?

การเพิ่มประสิทธิภาพ API:

LinkedInมีงานนำเสนอที่น่าสนใจ (ตั้งแต่ปี 2009) ในเรื่องของการเพิ่มประสิทธิภาพ API ของพวกเขาและสาเหตุที่สำคัญสำหรับพวกเขาในระดับของพวกเขา http://www.slideshare.net/linkedin/building-consistent-restful-apis-in-a-highperformance-environment

กล่าวโดยย่อเมื่อ API ต้องสนับสนุนกรณีการใช้งานที่แตกต่างกันหลายอย่างมันสามารถเข้าสู่สถานการณ์ที่รองรับกรณีการใช้งานหนึ่งครั้งได้อย่างดีที่สุดและส่วนที่เหลือค่อนข้างแย่จากมุมมองเครือข่ายและมุมมองฐานข้อมูล

หาก API ไม่มีความซับซ้อนเช่นเดียวกับ LinkedIn คุณสามารถรับสถานการณ์โดยที่:

  • API ดึงข้อมูลมากกว่าที่คุณต้องการ (สิ้นเปลือง)
  • API ของ Chatty ที่คุณต้องเรียก API หลายครั้ง

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

ฉันสงสัยว่าจะมีกลุ่มคนจำนวนหนึ่งออกมาที่นั่นซึ่งอาจรวมเป็น:

  • การจำลองแบบต้นทุนต่ำของข้อมูลหลักไปยังฐานข้อมูล microservice (ไม่มีค่าใช้จ่ายในการพัฒนาและมีประสิทธิภาพทางเทคนิค)
  • ศรัทธาในการทำให้เป็นมาตรฐานและความยืดหยุ่นของแอปพลิเคชันต่อการเปลี่ยนแปลงของสคีมา
  • ความสามารถในการปรับให้เหมาะสมทุกกรณีการใช้งานและอาจหลีกเลี่ยงการโทรระยะไกล API แบบไร้สาระ / ไร้ประโยชน์ / ไร้ประสิทธิภาพ
  • บวกกับผลประโยชน์อื่น ๆ ในแง่ของข้อ จำกัด และการออกแบบที่สอดคล้องกัน

คำตอบนี้มีวิธียาวเกินไป ขอโทษ!!


โดยทั่วไปการเพิ่มคอลัมน์จะทำให้แอปพลิเคชันหยุดทำงาน หากคุณมี "เงินเดือน" แอปพลิเคชันที่จะสรุปจำนวนเงินเดือนทั้งหมดจะแตกเมื่อเปิดตัวคอลัมน์ใหม่ "Salary_currency"
kubanczyk

จริงๆ? ขึ้นอยู่กับคำจำกัดความของคุณว่า "หยุด" ฉันคิดว่า หากแอปอยู่ในการผลิตและทำงานตามที่คาดไว้โดยไม่มี "Salary_currency" ทำไมคุณถึงคิดว่าแอปพลิเคชันนั้นพัง?
Rob Bygrave

แอปพลิเคชั่นทำงานโดยไม่มีข้อผิดพลาดและแสดงหมายเลขบางส่วน แต่มันไร้ประโยชน์ เมื่อซีอีโอเห็นว่าจำนวนเงินเดือนในเดือนที่ผ่านมาคือ 6 ล้านคนแทนที่จะเป็น 50,000 คน (เนื่องจากพนักงานใหม่ที่จ่ายเงินวอนเกาหลีใต้) คำจำกัดความของผลลัพธ์ที่มีประโยชน์ / ไร้ประโยชน์นั้นไม่ได้กล่าวถึงมากนัก
kubanczyk

0

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

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