เหตุใดฐานข้อมูล noSQL จึงสามารถปรับขนาดได้มากกว่า SQL

98

เมื่อเร็ว ๆ นี้ฉันอ่านมากเกี่ยวกับ noSQL DBMSs ผมเข้าใจCAP ทฤษฎีบท , กรดกฎBASEกฎและทฤษฎีพื้นฐาน แต่ไม่พบทรัพยากรใด ๆ ว่าทำไม noSQL จึงสามารถปรับขนาดได้ง่ายกว่า RDBMS (เช่นในกรณีของระบบที่ต้องใช้เซิร์ฟเวอร์ DB จำนวนมาก)

ฉันเดาว่าการรักษาข้อ จำกัด และกุญแจต่างประเทศต้องใช้ทรัพยากรและเมื่อมีการกระจาย DBMS มันก็ซับซ้อนกว่ามาก แต่ฉันคาดหวังว่าจะมีมากกว่านี้

ใครช่วยกรุณาอธิบายว่า noSQL / SQL ส่งผลกระทบต่อความสามารถในการปรับขนาดได้หรือไม่?

sql nosql scalability

— ducin
แหล่งที่มา

7

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

— yannis

8

แน่นอนว่าฐานข้อมูล SQL ปรับขนาดได้อย่างดีเยี่ยมในเรคคอร์ดหลายล้านล้านรายการพวกเขาต้องการเพียงความเชี่ยวชาญในการออกแบบและตั้งค่าที่นักพัฒนาแอปพลิเคชันไม่มี และโดยทั่วไปแล้วเป็นชุดของฮาร์ดแวร์และใบอนุญาตที่ค่อนข้างแพง

— HLGEM

ความเป็นไปได้ที่ซ้ำกันของใครบางคนจะใช้ MongoDB (หรือคล้ายกัน) เมื่อเทียบกับ RDMS แบบดั้งเดิม? และของฐานข้อมูล NoSQL จะไปแทนที่ฐานข้อมูลเชิงสัมพันธ์หรือไม่? SQL กำลังจะหายไป?

— ริ้น

6

ในความเห็นของฉันคำถามนี้ไม่ได้ซ้ำกันอย่างใดอย่างหนึ่ง คำถาม mongodb คือ (นอกเหนือจากชื่อที่ไม่ดีทำให้ดูเหมือนเจาะจงมากขึ้น) ถามอย่างอื่นซึ่งอันที่จริงแล้วเป็นเรื่องทั่วไปมากขึ้น โหวตให้เปิดใหม่

— Joeri Sebrechts

77

ฐานข้อมูล noSQL มีจำนวนมากของการทำงานที่ฐานข้อมูล SQL มอบให้คุณเป็นเรื่องปกติ

สิ่งต่าง ๆ เช่นการบังคับใช้ความถูกต้องของการอ้างอิงโดยอัตโนมัติธุรกรรม ฯลฯ สิ่งเหล่านี้เป็นทุกสิ่งที่มีประโยชน์มากสำหรับปัญหาบางอย่างและต้องใช้เทคนิคที่น่าสนใจในการขยายขนาดนอกเซิร์ฟเวอร์เดียว (คิดเกี่ยวกับสิ่งที่เกิดขึ้น ตารางสำหรับธุรกรรมอะตอมมิกและอยู่บนเซิร์ฟเวอร์ที่แตกต่างกัน!)

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

— Michael Kohne
แหล่งที่มา

2

ไม่ทราบว่ามันง่ายขนาดนั้น

— อับดุล

7

คำตอบที่ยอมรับนี้ล้มเหลวอย่างสิ้นเชิงที่จะพูดถึงความสามารถในการแบ่งเศษ NoSQL ซึ่งหายไปจาก SQL Sharding เป็นสิ่งที่ทำให้ NoSQL สามารถปรับขนาดได้ในแนวนอน

— hyankov

8

@HristoYankov และใช้งานได้เพราะระบบ NoSQL ไม่ได้ทำทุกสิ่งที่ไม่ได้เล่นอย่างดีกับการแบ่งส่วน

— immibis

1

@HristoYankov: ฐานข้อมูล SQL สามารถแบ่งออกเป็นแนวนอนได้และไม่ใช่ทุกฐานข้อมูล NoSQL ที่สามารถลบออกในแนวนอนได้อย่างง่ายดาย Sharding ไม่ใช่เหตุผลว่าทำไมคุณถึงต้องการใช้ NoSQL

— Lie Ryan

@HristoYankov คำตอบที่ได้รับการยอมรับนั้นมีระดับที่ลึกกว่าโน้ตของคุณหนึ่งระดับ คำตอบที่ได้รับการยอมรับพูดคุยอย่างถูกต้องเกี่ยวกับสาเหตุที่แนวนอนในแนวดิ่งยากขึ้นด้วยฐานข้อมูล SQL ในความเป็นจริงฉันใช้เวลา 20 นาทีในการค้นหาคำตอบสำหรับเรื่องนี้และทุกคนก็เพิ่งออก "Ohh NoSQL เศษที่ดีกว่า" โดยไม่ต้องพูดถึงเหตุผลใด ๆ การตอบสนองที่ไร้ประโยชน์โดยสิ้นเชิง คำตอบที่ยอมรับได้ที่นี่ตอบคำถามได้อย่างสมบูรณ์แบบ - แม้ว่าจะสั้นมาก ยินดีที่จะมีเหตุผลเพิ่มเติมในรายการด้วย

— Phoeniyx

175

มันไม่เกี่ยวกับ NoSQL vs SQL มันเกี่ยวกับ BASE กับกรด

ปรับขนาดได้จะต้องแบ่งออกเป็นองค์ประกอบของมัน

Read scaling = รองรับปริมาณการอ่านที่สูงขึ้น
Write scaling = จัดการกับปริมาณการเขียนที่สูงขึ้น

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

การเขียนสเกลเป็นสิ่งที่ขนดก มีข้อ จำกัด ต่าง ๆ ที่กำหนดโดยหลักการกรดซึ่งคุณไม่เห็นในสถาปัตยกรรมที่สอดคล้องกันในที่สุด (BASE):

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

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

การปล่อย Atomicity ช่วยให้คุณลดระยะเวลาที่ตาราง (ชุดข้อมูล) ถูกล็อก ตัวอย่าง: MongoDB, CouchDB
ปล่อยความสอดคล้องช่วยให้คุณสามารถขยายการเขียนข้ามโหนดคลัสเตอร์ ตัวอย่าง: riak, cassandra
การปล่อยความทนทานช่วยให้คุณตอบสนองต่อคำสั่งการเขียนโดยไม่ต้องล้างข้อมูลลงดิสก์ ตัวอย่าง: memcache, redis

โดยทั่วไปฐานข้อมูล NoSQL จะเป็นไปตามรูปแบบ BASE แทนที่จะเป็นแบบ ACID พวกเขายกเลิกข้อกำหนด A, C และ / หรือ D และในทางกลับกันพวกเขาปรับปรุงความสามารถในการปรับขยาย บางอย่างเช่นคาสซานดราให้คุณเลือกใช้การรับประกันของกรดเมื่อคุณต้องการ อย่างไรก็ตามไม่ใช่ฐานข้อมูล NoSQL ทั้งหมดที่สามารถปรับขนาดได้ตลอดเวลา

SQL API ไม่มีกลไกในการอธิบายเคียวรีที่ความต้องการของ ACID นั้นผ่อนคลาย นี่คือสาเหตุที่ฐานข้อมูล BASE นั้นเป็น NoSQL ทั้งหมด

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

อัปเดต (2019-09-17):

ภูมิทัศน์ของฐานข้อมูลมีวิวัฒนาการตั้งแต่โพสต์คำตอบนี้ ในขณะที่ยังคงมีขั้วสองขั้วระหว่างโลก RDBMS ACID และ NoSQL BASE โลกสายกลายเป็นคลุมเครือ ฐานข้อมูล NoSQL ได้เพิ่มคุณสมบัติจากโลก RDBMS เช่นการสนับสนุน SQL API และการทำธุรกรรม ขณะนี้ยังมีฐานข้อมูลที่รับประกัน SQL, ACID และการปรับสเกลเช่น Google Cloud Spanner, YugabyteDB หรือ CockroachDB โดยทั่วไปแล้วมารจะอยู่ในรายละเอียด แต่สำหรับวัตถุประสงค์ส่วนใหญ่แล้วสิ่งเหล่านี้คือ "กรดเพียงพอ" สำหรับการดำน้ำลึกลงไปในเทคโนโลยีฐานข้อมูลและวิธีการที่มีการพัฒนาคุณสามารถดูที่ดาดฟ้าสไลด์นี้ (บันทึกย่อของสไลด์มีคำอธิบายประกอบ)

— Joeri Sebrechts
แหล่งที่มา

ในขณะที่ฉันยอมรับว่าร้านค้า NoSQL บางแห่งแทนที่ ACID ด้วย BASE แต่ก็ยังไม่ใช่คุณสมบัติทั่วไปสำหรับร้านค้าทั้งหมดที่อยู่ภายใต้หมวดหมู่ NoSQL ซึ่งเป็นคำนิยามที่ไม่ดีในตอนแรก หลังจากที่ในขณะที่การตีความคำเปลี่ยนจาก "No SQL" เป็น "ไม่เพียง SQL" แต่เป็นฐานข้อมูลจำนวนมากยังคงเข้าร่วมหรือได้เริ่มใช้ภาษาถิ่น SQLesque, Mark Madsen ได้ประกาศเกียรติคุณคำอื่นในประวัติฐานข้อมูลของเขาในแบบไม่มีการกำหนด : "ไม่, SQL" ;-)

— Lukas Eder

2

เพื่อหลีกเลี่ยงการรวมเราจะมีข้อมูลที่ไม่ทำให้เป็นมาตรฐานใน NoSQL ซึ่งนำไปสู่การทำซ้ำและการจัดเก็บที่มากขึ้น แต่ก็สามารถทำได้ใน RDBMS หากเราตกลงด้วยการทำให้เป็นปกติ ดังนั้น "Joins" หรือ "no Joins" จึงขึ้นอยู่กับ DBA และไม่ใช่ประเภทฐานข้อมูล ถูกต้องหรือไม่

— Kaushik Lele

2

@dynamic เว็บไซต์เหล่านั้นอาจใช้การแคชหนัก การออกแบบเหล่านั้นมีความซับซ้อนในการปรับขนาดข้อมูลนอกฐานข้อมูล คุณอาจใช้ nosql ในกรณีเช่นนี้เพราะนั่นคือสิ่งที่ทำให้ nosql ได้รับผลกระทบ

— Joeri Sebrechts

1

"SQL API ขาดกลไกในการอธิบายข้อความค้นหาที่ข้อกำหนดของ ACID นั้นผ่อนคลาย" จริงทางเทคนิค แต่เซิร์ฟเวอร์ SQL ได้ดำเนินการขั้นตอนที่ขี้อายในทิศทางนั้น SQL 2014 ขอแนะนำ Delayed Durability ซึ่งเป็นการผ่อนคลาย D ใน ACID เพื่อแลกกับการลดความดันล็อกการเขียน

— EBarr

3

นี่ควรเป็นคำตอบที่ได้รับการยอมรับ มันชัดเจนมากกับตัวอย่าง แต่จัดการให้กระชับ

— Olshansk

4

เป็นความจริงที่ว่าฐานข้อมูล NoSQL (MongoDB, Redis, Riak, Memcached ฯลฯ ) ไม่รักษาข้อ จำกัด คีย์ต่างประเทศและการดำเนินการปรมาณูจะต้องระบุไว้อย่างชัดเจนยิ่งขึ้น เป็นความจริงที่ว่าฐานข้อมูล SQL (SQL Server, Oracle, PostgreSQL ฯลฯ ) สามารถปรับขนาดเพื่อรองรับความต้องการด้านประสิทธิภาพที่มีขนาดใหญ่มากโดย DBA ที่มีประสบการณ์

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

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

— RandomProgrammer
แหล่งที่มา

2

ฉันไม่แน่ใจว่าฉันเห็นด้วยกับส่วนที่เกี่ยวกับการทำธุรกรรมปรมาณูในความรู้สึกกรด (แม้ว่ามันจะยากที่จะแสดงความคิดเห็นใน "NoSQL" เพราะมันขึ้นอยู่กับการอภิปรายสิ่งที่เราหมายถึง) ประสิทธิภาพส่วนใหญ่จะได้รับใน NoSQL DB ทั่วไปโดยการคลายการรับประกันความสอดคล้อง (ดู: ความสอดคล้องท้ายที่สุด , ACID vs. BASE) หากความสอดคล้องในที่สุดนั้นดีพอสำหรับแอปพลิเคชัน (และบ่อยครั้งก็คือ) สิ่งนี้จะช่วยให้การปรับสเกลแนวนอนมีประสิทธิภาพมากขึ้น

— Daniel B

4

จาก IBM developerWorks: จัดหาความสามารถในการขยายข้อมูลระดับคลาวด์ด้วยฐานข้อมูล NoSQL

Scalabilityเป็นระบบที่สามารถรองรับฐานข้อมูลขนาดใหญ่มากที่มีอัตราการร้องขอสูงมากในเวลาแฝงที่ต่ำมาก

ระบบ NoSQL มีคุณสมบัติการออกแบบที่เหมือนกัน:

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

เหตุใดฐานข้อมูลเชิงสัมพันธ์อาจไม่เหมาะสำหรับการปรับขนาด

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

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

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

มากกว่าใน DBA.SE: การปรับสเกลในแนวนอนหมายถึงอะไร

การขยายในแนวนอนเป็นสิ่งที่จำเป็นแทนที่จะสร้างขึ้นมา คุณไม่ต้องไปซื้อเซิร์ฟเวอร์ beefier ที่ใหญ่กว่าและย้ายภาระทั้งหมดของคุณลงไปแทนคุณซื้อเซิร์ฟเวอร์เพิ่มเติม 1+ ตัวและกระจายภาระของคุณไปยังเซิร์ฟเวอร์เหล่านั้น

การปรับสเกลแนวนอนจะใช้เมื่อคุณมีความสามารถในการเรียกใช้หลายอินสแตนซ์บนเซิร์ฟเวอร์พร้อมกัน โดยทั่วไปแล้วมันจะยากกว่ามากในการเปลี่ยนจากเซิร์ฟเวอร์ 1 เซิร์ฟเวอร์เป็นเซิร์ฟเวอร์ 2 เซิร์ฟเวอร์จากนั้นเป็นเซิร์ฟเวอร์ 2 ถึง 5, 10, 50 และอื่น ๆ

เมื่อคุณได้แก้ไขปัญหาของการเรียกใช้อินสแตนซ์แบบขนานคุณสามารถใช้ประโยชน์จากสภาพแวดล้อมเช่น Amazon EC2, Cloud Service ของ Rackspace, GoGrid, ฯลฯ เนื่องจากคุณสามารถนำอินสแตนซ์ขึ้นและลงตามความต้องการลดความต้องการจ่ายพลังงานเซิร์ฟเวอร์ คุณไม่ได้ใช้เพียงเพื่อให้ครอบคลุมการโหลดสูงสุดเหล่านั้น

ฐานข้อมูลเชิงสัมพันธ์เป็นหนึ่งในรายการที่ยากต่อการรันอ่าน / เขียนแบบเต็มในแบบคู่ขนาน

— Md Mahbubur Rahman
แหล่งที่มา