SQL กับ NoSQL – คุณควรใช้โครงการไหนต่อไป

หนึ่งในคำถามที่พบบ่อย – ฉันควรใช้ฐานข้อมูลใด …


SQL ย่อมาจาก Structured Query Language มันได้รับการพัฒนาครั้งแรกในปี 1970 โดยทีมนักวิจัยของ IBM ฐานข้อมูล NoSQL ถูกใช้เป็นครั้งแรกในปี 1998 โดย Carlo Strozzi.

ความแตกต่างที่พบบ่อยที่สุดระหว่างระบบฐานข้อมูลทั้งสองนี้คือ SQL นั้นสัมพันธ์กันและ NoSQL นั้นไม่สัมพันธ์กัน.

มาดำดิ่งลงในฐานข้อมูลทั้งสองนี้เพื่อแจ้งการตัดสินใจของคุณให้ดีขึ้นเมื่อคุณกำลังพิจารณาฐานข้อมูลสำหรับโครงการของคุณ.

โครงสร้างฐานข้อมูล

พูดคุยเกี่ยวกับโครงสร้าง.

SQL

SQL ฐานข้อมูลมีโครงสร้างสคีมาที่แน่นอน.

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

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

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

ในฐานข้อมูลของเราเราอาจมีตารางผู้ใช้ซึ่งมีโครงสร้างดังต่อไปนี้,

users_table
—————————————————-
id | ชื่อ | อีเมล
—————————————————–
1 ไอดริส [email protected]

นอกจากนี้เราอาจมีตารางคำสั่งซื้อ

orders_table
———————————————————————————
id | user_id | ORDER_NUMBER
———————————————————————————
1 1 20000001

user_id บนตารางคำสั่งซื้อทำให้ง่ายต่อการจับคู่แต่ละคำสั่งบนตารางคำสั่งกับผู้ใช้ที่เป็นสมาชิก ในกรณีของความสัมพันธ์แบบหนึ่งต่อหนึ่งเราอาจมี order_id อยู่ใน users_table ด้วยหากเราตัดสินใจรับผู้ใช้ตามรหัสคำสั่งที่เกี่ยวข้อง.

สำหรับหลาย ๆ สถานการณ์มักจะมีการเพิ่มตารางพิเศษที่เรียกว่าตาราง Pivot สิ่งนี้ช่วยให้สามารถแมปหลายระเบียนเข้าด้วยกัน ใช้ตัวอย่างข้างต้น เราน่าจะมี,

users_table
————————————————————————————-
id | ชื่อ | อีเมล
————————————————————————————-
1 ไอดริส [email protected]

และตารางการสั่งซื้อจะเป็น

orders_table
———————————————————
id | ORDER_NUMBER
———————————————————
1 2000001

จากนั้นตาราง Pivot จะถือ ID ทั้งสองเป็นคีย์ต่างประเทศ.

users_orders_table
——————————————————————————
id | order_id | user_id
——————————————————————————
1 1 1

ขึ้นอยู่กับโครงสร้างนี้ที่จัดทำโดย SQL คุณสามารถเขียน Joins ระหว่างตารางที่จะให้ข้อมูลจากตารางที่แตกต่างกันรวมเข้าด้วยกันในแบบสอบถามเดียว.

NoSQL

NoSQL ฐานข้อมูลถูกสร้างขึ้นเพื่อให้มีความยืดหยุ่นมากกว่า SQL DBs รวมถึงข้อมูลจำนวนมาก.

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

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

กลับไปที่ตัวอย่างที่เรากำหนดไว้ก่อนหน้านี้ของ บริษัท ที่มีผู้ใช้และคำสั่งซื้อ.

การรวบรวมผู้ใช้สามารถกำหนดเป็น,

{id: 1, ชื่อ: ‘idris’, อีเมล: ‘[email protected]‘}

และคอลเลกชันคำสั่งซื้อสามารถกำหนดเป็น,

{id: 1, order_number: 2000001, user_id: 1}

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

{id: 1, order_number: 200001, ผู้ใช้ {id: 1, ชื่อ: ‘idris’, อีเมล: ‘[email protected]‘}}

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

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

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

ขูดหินปูน

มาสำรวจวิธีการปรับขนาด.

SQL

SQL DBs ไม่สามารถปรับขนาดในแนวนอน แต่เป็นแนวตั้งเท่านั้น สิ่งนี้หมายความว่าอะไร?

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

การปรับสเกลแนวนอน

การปรับสเกลแนวตั้ง


NoSQL

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

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

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

Sharding คืออะไร?

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

ตัวอย่างฐานข้อมูล

SQL

  • MySQL – ฐานข้อมูลโอเพนซอร์สที่นิยมมาก อย่างไรก็ตามฐานข้อมูลที่เป็นทางเลือกสำหรับนักพัฒนา PHP จำนวนมากสามารถใช้กับ Node.js, C #, C ++, Java, Perl, Ruby และ Python ได้.
  • MSSQL – Microsoft SQL ให้ความเสถียรมากเนื่องจากการพัฒนานั้นมาจาก Microsoft โดยตรงซึ่งยังให้การสนับสนุนในแง่ของการกู้คืนความเสียหาย.
  • MariaDB – สิ่งนี้สร้างขึ้นบน MySQL โดยผู้สร้าง MySQL ตั้งใจที่จะทำให้ MariaDB เป็นรุ่นฟรีตลอดไป.
  • PostgresSQL – ฐานข้อมูลโอเพนซอร์สที่นิยมมาก ภูมิใจในตนเองเป็นฐานข้อมูลโอเพ่นซอร์สที่ทันสมัยที่สุดในโลก
  • Oracle – โดยปกติจะปรับให้เข้ากับโซลูชันระดับองค์กรของ Oracle โดยมีข้อ จำกัด บางประการเกี่ยวกับเวอร์ชันฟรี.

NoSQL

  • MongoDB – อาจเป็น NoSQL DB ที่เป็นที่รู้จักมากที่สุดซึ่งพบได้ทั่วไปในหมู่นักพัฒนาแอปพลิเคชันที่ทำงานกับ MERN stack (MongoDB, Express, React, Node) หรือ MEAN stack (MongoDB, Express, Angular, Node).
  • Firebase – เปิดตัวในปี 2554 และได้รับโดย Google ในปี 2557 กำลังถูกใช้อย่างกว้างขวางโดยนักพัฒนาเว็บและแอปพลิเคชั่นมือถือ.
  • Apache Couch DB – NoSQL DB ซึ่งเป็นเอกสารซึ่งเก็บข้อมูลเป็น JSON.
  • Redis: นี่คือ NoSQL DB ซึ่งเป็นที่รู้จักกันดีที่สุดสำหรับการใช้ในการจัดเก็บข้อมูลด้วยเวลาที่ไม่จำเป็น เป็นที่รู้จักกันดีในเรื่องความเร็ว.

ข้อสรุป

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

Tags:

  • ฐานข้อมูล

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map