ทีมของฉันกลัวฐานข้อมูลเชิงสัมพันธ์ที่มีความสัมพันธ์กับต่างประเทศและฉันไม่เข้าใจว่าทำไม


12

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

ใน microservice db schemas ของเราเอนทิตีมักจะมีมากกว่าหนึ่งตาราง สิ่งใดก็ตามที่คุณต้องการทำให้เป็นปกติในตารางอื่นจะถูกเก็บไว้ในคอลัมน์ json หากภายหลังพบว่าคุณสมบัติอย่างใดอย่างหนึ่งใน json นี้ต้องถูกสอบถามคอลัมน์ใหม่จะถูกเพิ่มและข้อมูลจะถูกเก็บไว้ในทั้งสองแห่ง (ใช่ในคอลัมน์ที่ต่างกันสองแห่งในตารางเดียวกัน)

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

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

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

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

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


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

2
ฉันสงสัยว่า% ของ RDBMS ใดที่พวกเขาสร้างขึ้นในรหัส "แอป"
Caleth

ไม่ว่าวิธีการนั้นจะดีหรือไม่นั้นขึ้นอยู่กับประเภทของแอปพลิเคชันที่คุณกำลังสร้างความต้องการและทิศทางของมัน (ความต้องการข้อ จำกัด ทางสถาปัตยกรรม) - สิ่งที่เราไม่สามารถประเมินได้ที่นี่ สำหรับ NoSQL - สิ่งทั้งหมดนั้นเกี่ยวกับการสนับสนุนความสามารถในการขายในแนวนอนขนาดใหญ่และเกี่ยวกับการยอมรับว่าแอปพลิเคชั่นบางตัวไม่จำเป็นต้องมีข้อ จำกัด ที่เข้มงวดของ RDBMS หากต้องการเรียนรู้เพิ่มเติมให้ใช้คำตอบ 3 อันดับแรกที่นี่เพื่อเป็นจุดเริ่มต้น
Filip Milovanović

2
หากฉันสามารถให้คำแนะนำที่ไม่ใช่ด้านเทคนิคได้ให้ลดระดับลงเล็กน้อย คุณต้องผ่านการตัดสินจำนวนมาก ("ใช่ในสองคอลัมน์ที่แตกต่างกันในตารางเดียวกัน", "design travesty") ในงานที่คุณไม่มีส่วนร่วมในการตัดสินใจออกแบบและทำจากตำแหน่งที่มีประสบการณ์ในโลกแห่งความเป็นจริงน้อยที่สุด . ฉันไม่สามารถบอกได้ว่าคุณถูกหรือผิดเพราะฉันไม่ได้เห็นโครงการ แต่ระบบมักจะมีการประนีประนอมกันเป็นผลทำให้ผลิตภัณฑ์สำเร็จรูปนั้นใช้งานได้ แต่มีความบริสุทธิ์น้อยกว่าแนวคิด สิ่งนี้จะชัดเจนขึ้นเมื่ออาชีพของคุณก้าวหน้าและทำให้การตัดสินใจเหล่านั้นกลายเป็นส่วนหนึ่งของงานของคุณ
Blrfl

@Blrfl ยอดเยี่ยม
Robbie Dee

คำตอบ:


8

คำสำคัญที่นี่เพื่อทำความเข้าใจว่าทีมของคุณมาจากไหนคือ "microservices" มันจะคุ้มค่าที่จะอ่านแนวคิดนี้ก่อนโดยเฉพาะข้อมูลต่อไปนี้:

  • ควรจัดเก็บข้อมูลอย่างไร
  • หลักการออกแบบ?
  • พวกเขาถูกออกแบบมาเพื่อวัดขนาดได้อย่างไร

เช่นเดียวกับวิธีการทำสิ่งต่าง ๆ ที่ค่อนข้างใหม่ (และ 5-10 ปีนั้นค่อนข้างใหม่เมื่อเทียบกับสถาปัตยกรรมซอฟต์แวร์) คุณจะพบว่าอุดมคติและความเป็นจริงนั้นแตกต่างกันเล็กน้อย

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

บรรทัดล่างคือเมื่อคุณกำลังพูดถึงระดับอินเทอร์เน็ตความปลอดภัยและความคุ้นเคยของการทำธุรกรรมกรด (Atomicity, Consistency, Isolation and Durability) ไม่ได้เพิ่มขึ้นเมื่อคุณมีผู้ใช้หลายล้านคนในฐานข้อมูลเดียว ด้วยการถือกำเนิดของ NoSQL กระบวนทัศน์ได้เปลี่ยนไปสู่ ​​BASE มากขึ้น (โดยทั่วไปมีสถานะ Soft state, ความสอดคล้องในที่สุด) ( อ้างอิง )

มีผลกระทบต่อการเปลี่ยนแปลง PH ของวิธีการจัดการข้อมูลของคุณ:

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

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


+1 สิ่งที่ยอดเยี่ยม - มีรายละเอียดปลีกย่อยมากมายรอบ ๆ microservices นั่นหมายความว่าไม่ใช่แค่การแลกเปลี่ยนฐานข้อมูล
Robbie Dee

@ RobbieDee เห็นด้วย มีความซับซ้อนมากมายในโลกนั้นและทุกคนไม่เห็นด้วยกับรายละเอียด
Berin Loritsch

นี่ควรเป็นคำตอบ บิตเกี่ยวกับแต่ละบริการไมโครที่มีแหล่งข้อมูลของตัวเองเป็นปัจจัยที่แตกต่าง มันทำให้เกิดการเปลี่ยนแปลงครั้งใหญ่ในความต้องการและโซลูชั่นด้านการจัดเก็บข้อมูลของคุณและที่เก็บข้อมูลที่เป็นไปตามมาตรฐาน ACID นั้นไม่ได้มีประโยชน์เท่าที่ควร
Greg Burghardt

7
มันเป็นคำตอบที่ดีและฉันก็สนับสนุนมัน ฉันจะชี้ให้เห็นว่าสิ่งที่คุณอ้างถึงเป็น "ระดับอินเทอร์เน็ต" ใช้กับ บริษัท ที่ใหญ่ที่สุดเท่านั้น สำหรับฐานข้อมูลองค์กรและเว็บไซต์ส่วนใหญ่ (ฉันจะบอกว่า 95% ของพวกเขา) ฐานข้อมูล SQL ธรรมดา "แบบธรรมดา" ยังคงทำงานได้อย่างสมบูรณ์
Robert Harvey

@ RobertHarvey ฉันเห็นด้วยใจจริง ฉันอ่านบทความหลายเรื่องเกี่ยวกับไมโครไซต์ที่ระบุสิ่งที่ฉันเขียน ในโครงการของเราเองเราใช้ฐานข้อมูล SQL ที่มีการทำให้เป็นมาตรฐานและข้อ จำกัด ที่เหมาะสม มันจะทำร้ายจิตใจของคนเจ้าระเบียบ แต่ความจริงคือฐานผู้ใช้ของเราค่อนข้างเล็ก (หลายร้อยหรือผู้ใช้) และฐานข้อมูลไม่ได้เป็นปัญหาด้านประสิทธิภาพสำหรับเรา
Berin Loritsch

3

ตกลงไม่ใช่วิศวกรหลักในโครงการที่คุณต้องทำตามคำแนะนำของเขาสำหรับโครงการนี้

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

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

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


+1 แนวคิดที่ยอดเยี่ยม และหากปริมาตรใหญ่เกินไปสำหรับเครื่อง dev หนึ่งในตัวอย่าง N ก็สามารถให้ข้อมูลเชิงลึกที่ยอดเยี่ยมเช่นกัน
Robbie Dee

2

ฉันคิดว่าพวกเขากลัวการสร้าง "การเลียนแบบ" แบบเดิมที่เคยมีมาก่อนหน้านี้มากกว่าที่จะเป็น Referential Integrity

เขาแย้งว่าในสถานที่ที่ฉันต้องการปรมาณูเราไม่ต้องการมัน ...

หากคุณสามารถสร้างเคสที่มั่นคง (หรือที่เรียกว่า Non-Functional Requirement) เพื่อต้องการอะตอมมิกพวกเขาจะต้องมีอาร์กิวเมนต์ที่ดีและมั่นคงเพื่อที่จะไม่ให้มัน

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

Let 's หวังว่าคุณกำลังขวา ฉันขอแนะนำว่าการพึ่งพาข้อมูลที่มีขนาดเล็กพอที่จะยังคงเป็นนักแสดงมีความเสี่ยง

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


1

แนวคิดหลักที่อยู่เบื้องหลัง RDBMS นั้นมีอายุมากกว่า 40 ปี กลับมาแล้วที่เก็บมีราคาแพงมากและความซ้ำซ้อนใด ๆ ก็ขมวดคิ้วอยู่ ในขณะที่แนวคิดที่อยู่เบื้องหลัง RDBMS นั้นยังคงเป็นแนวความคิดของ denormalisation สำหรับประสิทธิภาพ (เพื่อลดการรวม) ได้กลายเป็นที่ยอมรับกันทั่วไปในทศวรรษที่ผ่านมา

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

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

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

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

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


1
ทำไม downvote นี้ นี่คือคำตอบที่สมดุล ลัทธินิยมนิยม +1
Dirk Boer

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

denormalizing ข้อมูลในชื่อของผลการดำเนินงานในช่วงเริ่มต้นของโครงการ ...คำแนะนำ: คุณทำไม่ได้ :)
ร็อบบี้ดี

1
ค่าของ RDBMS ไม่ได้มาจากประสิทธิภาพของดิสก์
TehShrike

0

ขึ้นอยู่กับฐานข้อมูลที่คุณใช้

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

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

สิ่งไหนดีกว่าขึ้นอยู่กับสิ่งที่คุณทำจริง ๆ และสิ่งที่คุณต้องการจริง ๆ

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

แต่พวกเขาจะไม่ หวังว่าคุณจะคิด

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