ในช่วง 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 ไปสู่การออกแบบ "ถูกต้อง" ที่เป็นที่รู้จักและความแปรปรวนจากที่นั่นควรจะเป็น
- อาจมีรูปแบบที่แตกต่างกันไปตามประเภทฐานข้อมูลที่รองรับ (JSON, ARRAY, ประเภทสนับสนุนทางภูมิศาสตร์ ฯลฯ )
- บางคนอาจโต้แย้งสำหรับการเปลี่ยนแปลงตาม 4NF / 5NF
- เราไม่รวมการเปลี่ยนแปลงทางกายภาพ (เพราะนั่นไม่สำคัญ)
- เรา จำกัด สิ่งนี้ไว้สำหรับการออกแบบ 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 แบบไร้สาระ / ไร้ประโยชน์ / ไร้ประสิทธิภาพ
- บวกกับผลประโยชน์อื่น ๆ ในแง่ของข้อ จำกัด และการออกแบบที่สอดคล้องกัน
คำตอบนี้มีวิธียาวเกินไป ขอโทษ!!