11 โอเพนซอร์สฐานข้อมูลสำหรับโครงการถัดไปของคุณ

ข้อมูลคือทุกสิ่ง และโดยส่วนขยายดังนั้นฐานข้อมูล นี่คือตัวเลือกโอเพนซอร์ซที่ยอดเยี่ยมสำหรับโปรเจ็กต์ kick-ass ครั้งต่อไปของคุณ.


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

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

ผลลัพธ์?

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

ฉันรู้ว่ามันทำให้ฉันกลัวด้วย มีตัวเลือกมากเกินไป – เอกสารมากเกินกว่าจะผ่านได้ – และชีวิตที่สั้นมาก ��

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

ไม่มี MySQL

โปรดทราบ: รายการนี้จะไม่มี MySQL แม้ว่าจะเป็นโซลูชันฐานข้อมูลโอเพ่นซอร์สที่ได้รับความนิยมมากที่สุด.

ทำไม? เพียงเพราะ MySQL มีอยู่ทุกที่ – เป็นสิ่งที่ทุกคนเรียนรู้ก่อนได้รับการสนับสนุนจาก CMS หรือกรอบงานแทบทุกประเภทและมันก็ดีมากสำหรับกรณีใช้งานส่วนใหญ่ กล่าวอีกนัยหนึ่ง MySQL ไม่จำเป็นต้อง “ค้นพบ” ��

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

หมายเหตุพิเศษ: ความเข้ากันได้

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

ตัวอย่างเช่นหากคุณใช้งาน WordPress บทความนี้ไม่มีประโยชน์สำหรับคุณ ��ในทำนองเดียวกันผู้ที่ใช้งานเว็บไซต์แบบคงที่บน JAMStack จะไม่ได้รับอะไรเลยโดยมองหาทางเลือกอื่น ๆ อย่างจริงจัง.

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

PostgreSQL

หากคุณมาจากดินแดน PHP (WordPress, Magento, Drupal และอื่น ๆ ) PostgreSQL จะฟังคุณต่างประเทศ อย่างไรก็ตามโซลูชันฐานข้อมูลเชิงสัมพันธ์นี้มีมาตั้งแต่ปี 1997 และเป็นตัวเลือกอันดับต้น ๆ ในชุมชนเช่น Ruby, Python, Go และอื่น ๆ.

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

มีไคลเอนต์ SQL ที่ดีมากมายที่สามารถเชื่อมต่อกับฐานข้อมูล PostgreSQL สำหรับการบริหารและการพัฒนา.

คุณสมบัติพิเศษ

PostgreSQL มีคุณสมบัติที่น่าสนใจมากมายเมื่อเทียบกับฐานข้อมูลเชิงสัมพันธ์อื่น ๆ (โดยเฉพาะ, MySQL) เช่น:

  • ชนิดข้อมูลในตัวสำหรับ Array, Range, UUID, Geolocation เป็นต้น.
  • การสนับสนุนดั้งเดิมสำหรับที่เก็บเอกสาร (สไตล์ JSON), XML และที่เก็บคีย์ – ค่า (Hstore)
  • การจำลองแบบซิงโครนัสและแบบอะซิงโครนัส
  • สคริปต์ใน PL, Perl, Python และอื่น ๆ
  • ค้นหาข้อความแบบเต็ม

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

ควรใช้ PostgreSQL เมื่อใด

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

PostgreSQL ยังมีข้อได้เปรียบที่ชัดเจนหากคุณต้องการสิ่งอำนวยความสะดวก NoSQL บางส่วนสำหรับโมเดลข้อมูลแบบไฮบริด เนื่องจากการจัดเก็บเอกสารและคีย์ – ค่าได้รับการสนับสนุนเป็นอย่างดีคุณไม่จำเป็นต้องไปหาติดตั้งเรียนรู้และบำรุงรักษาโซลูชันฐานข้อมูลอื่น.

เมื่อไม่ใช้ PostgreSQL

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

กล่าวอีกนัยหนึ่งให้ใช้ PostgreSQL เว้นเสียแต่ว่าคุณจะรู้ 100% ว่าคุณทำอะไรอยู่! ��

ลองดูสิ SQL & PostgreSQL สำหรับผู้เริ่มต้น หากสนใจเรียนรู้เพิ่มเติม.

MariaDB

MariaDB ถูกสร้างขึ้นแทน MySQL โดยบุคคลเดียวกันกับผู้พัฒนา MySQL.

สับสน?

ที่จริงแล้วหลังจากที่ Oracle ถูกยึดครองโดย Oracle ในปี 2010 (โดยการซื้อ Sun Microsystems ซึ่งบังเอิญเป็นวิธีที่ Oracle มาควบคุม Java) ผู้สร้าง MySQL เริ่มโครงการโอเพนซอร์สใหม่ที่เรียกว่า MariaDB.

ทำไมคุณถึงถามรายละเอียดที่น่าเบื่อนี้ เป็นเพราะ MariaDB ถูกสร้างขึ้นจากฐานรหัสเดียวกันกับ MySQL (ในโลกโอเพนซอร์ซนี่เป็นที่รู้จักกันในนาม “ฟอร์ก” โครงการที่มีอยู่) เป็นผลให้ MariaDB ถูกนำเสนอแทน “หล่นใน” สำหรับ MySQL.

นั่นคือหากคุณใช้ MySQL และต้องการย้ายไปยัง MariaDB กระบวนการนั้นง่ายมากจนคุณไม่เชื่อ.

น่าเสียดายที่การโยกย้ายดังกล่าวเป็นถนนเดินรถทางเดียว การย้อนกลับจาก MariaDB ไปยัง MySQL นั้นเป็นไปไม่ได้และหากคุณพยายามที่จะใช้ความพยายาม!

คุณสมบัติพิเศษ

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

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

. . . และอื่น ๆ อีกมากมาย มันเหนื่อยมากที่จะติดตามคุณลักษณะทั้งหมดของ MariaDB ��

ควรใช้ MariaDB เมื่อใด

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

เมื่อไม่ใช้ MariaDB

ความเข้ากันได้กับ MySQL เป็นข้อกังวลเดียวที่นี่ ดังกล่าวได้กลายเป็นปัญหาน้อยลงเนื่องจากโครงการเช่น WordPress, Joomla, Magento และอื่น ๆ ได้เริ่มสนับสนุน MariaDB คำแนะนำของฉันจะไม่ใช้ MariaDB เพื่อหลอกลวง CMS ที่ไม่สนับสนุนเนื่องจากมีเทคนิคเฉพาะฐานข้อมูลจำนวนมากที่จะทำให้ระบบพังได้ง่าย.

CockroachDB

ทีมที่อยู่เบื้องหลัง CockroachDB ดูเหมือนจะประกอบด้วยนักทำโทษตนเอง ด้วยชื่อผลิตภัณฑ์เช่นนั้นแน่นอนว่าพวกเขาต้องการเปลี่ยนราคาทั้งหมดต่อพวกเขาและยังคงชนะ?

ก็ไม่มาก.

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

แนวคิดคือทีมที่อยู่เบื้องหลัง CockroachDB (ซึ่งประกอบด้วยอดีตวิศวกรของ Google) รู้สึกผิดหวังกับข้อ จำกัด ของโซลูชัน SQL แบบดั้งเดิมเมื่อมาถึงขนาดใหญ่ นั่นเป็นเพราะโซลูชั่น SQL ในอดีตควรถูกโฮสต์ไว้ในเครื่องเดียว (ข้อมูลไม่ใหญ่มาก) เป็นเวลานานไม่มีวิธีสร้างคลัสเตอร์ของฐานข้อมูลที่รัน SQL ซึ่งเป็นเหตุผลที่ MongoDB ได้รับความสนใจอย่างมาก.

แม้ว่าการทำซ้ำและการจัดกลุ่มออกมาใน MySQL, PostgreSQL และ MariaDB มันก็เจ็บปวดที่สุด CoackroachDB ต้องการเปลี่ยนสิ่งนั้นนำมาซึ่งการแบ่งอย่างง่ายดายการจัดกลุ่มและความพร้อมใช้งานสูงสู่โลกของ SQL.

เมื่อใดควรใช้ CockroachDB

CockroachDB เป็นความฝันของสถาปนิกระบบที่เป็นจริง หากคุณสาบานด้วย SQL และรู้สึกเดือดดาลกับความสามารถในการปรับขนาดของ MongoDB คุณจะรัก CockroachDB ตอนนี้คุณสามารถตั้งค่าคลัสเตอร์ได้อย่างรวดเร็วโยนการสืบค้นและนอนหลับอย่างสงบในเวลากลางคืน ��

เมื่อไม่ใช้ CockroachDB

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

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

Neo4j

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

เครือข่ายสังคมเป็นตัวอย่างที่ดีและการสร้างแบบจำลองข้อมูลที่คล้ายกันโดยใช้ SQL หรือแม้แต่ฐานข้อมูลที่ใช้เอกสารก็เป็นฝันร้าย.

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

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

คุณสมบัติพิเศษ

ฐานข้อมูลกราฟนั้นไม่เหมือนใครและ Neo4j นั้นเป็นตัวเลือกเดียวสำหรับการทำงานกับกราฟ เป็นผลให้คุณสมบัติใด ๆ ที่มันมีเอกลักษณ์ ��

  • รองรับแอพพลิเคชั่นการทำธุรกรรมและการวิเคราะห์กราฟ.
  • ความสามารถในการแปลงข้อมูลสำหรับการย่อยข้อมูลตารางขนาดใหญ่ลงในกราฟ.
  • ภาษาคิวรีแบบพิเศษ (Cypher) สำหรับการสืบค้นฐานข้อมูลกราฟ
  • คุณสมบัติการสร้างภาพและการค้นพบ

เป็นจุดที่สงสัยในการพูดคุยว่าควรใช้ Neo4j เมื่อใดและเมื่อใด หากคุณต้องการความสัมพันธ์แบบกราฟระหว่างข้อมูลของคุณคุณต้องมี Neo4j ��

MongoDB

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

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

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

คุณสมบัติพิเศษ

MongoDB มีบางอย่างที่รุนแรง (ฉันเกือบอยากจะเขียนคำว่า“ kick-ass” เพื่อสื่อถึงผลกระทบ แต่มันอาจไม่เหมาะสมกับเว็บไซต์สาธารณะบางที) คุณสมบัติที่ทำให้สถาปนิกที่มีประสบการณ์หลายคนต้องละทิ้งดินแดนเชิงสัมพันธ์ตลอดไป:

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

หากฉันฟังดูเหมือนโฆษกของ MongoDB ฉันต้องขออภัย แต่ก็ยากที่จะตรวจสอบข้อดีของ MongoDB แน่นอนว่าการสร้างแบบจำลองข้อมูล NoSQL นั้นแปลกในตอนแรกและบางคนก็ไม่เคยพลาดมัน แต่สำหรับสถาปนิกหลาย ๆ คนมันจะเป็นผู้ชนะในโครงสร้างของตาราง.

เมื่อใดควรใช้ MongoDB

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

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

เมื่อไม่ใช้ MongoDB

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

หากคุณเป็นนักพัฒนาซอฟต์แวร์คุณจะพบ มีประโยชน์นี้.

RethinkDB

ตามชื่อของมัน, RethinkDB “ คิดใหม่” แนวคิดและความสามารถของฐานข้อมูลเมื่อมาถึงแอพตามเวลาจริง.

เมื่อฐานข้อมูลได้รับการอัปเดตแอปพลิเคชันจะไม่สามารถรู้ได้ วิธีการที่ได้รับการยอมรับสำหรับแอปจะปิดการแจ้งเตือนทันทีที่มีการอัปเดตซึ่งจะถูกส่งไปยังส่วนหน้าผ่านสะพานที่ซับซ้อน (PHP -> Redis -> ปม -> Socket.io เป็นตัวอย่างหนึ่ง).

แต่จะเกิดอะไรขึ้นถ้าการอัปเดตสามารถส่งโดยตรงจากฐานข้อมูลไปยังส่วนหน้า?!

ใช่นั่นคือสัญญาของ RethinkDB ดังนั้นหากคุณต้องการสร้างแอปพลิเคชันตามเวลาจริงอย่างแท้จริง (เกม, ตลาด, การวิเคราะห์ ฯลฯ ) Rethink DB นั้นน่าสนใจ.

Redis

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

เรียนรู้ฐานข้อมูลนี้ เป็นงานสิบนาที (ตามตัวอักษร!) และเป็นที่เก็บคีย์ – ค่าอย่างง่ายที่เก็บสตริงด้วยเวลาหมดอายุ (ซึ่งสามารถตั้งค่าเป็นอินฟินิตี้แน่นอน) สิ่งที่ Redis สูญเสียไปในคุณสมบัติที่ใช้ในยูทิลิตี้และประสิทธิภาพ เนื่องจากมันใช้งาน RAM ทั้งหมดการอ่านและการเขียนจึงรวดเร็วอย่างไม่น่าเชื่อ (การทำงานสองสามแสนครั้งต่อวินาทีนั้นไม่เคยได้ยินมาก่อน).

Redis ยังมีความซับซ้อน ระบบ pub-sub, ซึ่งทำให้ “ฐานข้อมูล” นี้น่าสนใจเป็นสองเท่า.

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

SQLite

ใช่ฉันสัญญาว่าเราทำกับฐานข้อมูลเชิงสัมพันธ์ แต่ SQLite น่ารักเกินกว่าจะเพิกเฉย.

SQLite เป็นไลบรารี่ C ที่มีน้ำหนักเบาซึ่งจัดเตรียมเอ็นจินการจัดเก็บฐานข้อมูลเชิงสัมพันธ์ ทุกสิ่งในฐานข้อมูลนี้อาศัยอยู่ในไฟล์เดียว (พร้อมด้วยนามสกุล. sqlite) ที่คุณสามารถวางไว้ที่ใดก็ได้ในระบบไฟล์ของคุณ และนั่นคือทั้งหมดที่คุณต้องใช้! ใช่ไม่ต้องติดตั้งซอฟต์แวร์“ เซิร์ฟเวอร์” และไม่มีบริการเชื่อมต่อ.

คุณสมบัติที่มีประโยชน์

แม้ว่า SQLite จะเป็นทางเลือกที่มีน้ำหนักเบาไปยังฐานข้อมูลเช่น MySQL แต่มันก็อัดแน่นไปด้วย คุณลักษณะบางอย่างที่น่าตกใจคือ:

  • รองรับการทำธุรกรรมด้วย COMMIT, ROLLBACK และ BEGIN.
  • รองรับ 32,000 คอลัมน์ต่อตาราง
  • การสนับสนุน JSON
  • รองรับการเข้าร่วม 64 ทาง
  • ข้อความค้นหาย่อย, การค้นหาข้อความแบบเต็ม ฯลฯ.
  • ขนาดฐานข้อมูลสูงสุด 140 เทราไบต์!
  • ขนาดแถวสูงสุด 1 กิกะไบต์!
  • เร็วกว่าไฟล์ I / O 35%

ควรใช้ SQLite เมื่อใด

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

เมื่อไม่ใช้ SQLite

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

คาสซานดรา

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

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

คุณสมบัติพิเศษ

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

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

เมื่อใดควรใช้ Cassandra

การบันทึกและการวิเคราะห์เป็นสองกรณีที่ดีที่สุดสำหรับ Cassandra แต่นั่นไม่ใช่ทั้งหมด – จุดที่น่าสนใจคือเมื่อคุณต้องการจัดการกับข้อมูลขนาดใหญ่จริง ๆ (Apple มีการปรับใช้ Cassandra ที่จัดการข้อมูลกว่า 400 เพตาไบต์ในขณะที่ Netflix นั้นจัดการได้ 1 ล้านล้านคำขอต่อวัน) โดยไม่มีการหยุดทำงาน ความพร้อมใช้งานสูงเป็นหนึ่งในเครื่องหมายรับรองคุณภาพของคาสซานดรา.

เมื่อไม่ใช้ Cassandra

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

ระยะเวลา

การพัฒนาใหม่ต้องการฐานข้อมูลประเภทใหม่และ Internet of Things (IoT) เป็นปรากฏการณ์เช่นนี้ หนึ่งในฐานข้อมูลโอเพนซอร์ซที่ดีที่สุดคือ ระยะเวลา.

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

ทำไมไม่ใช้ฐานข้อมูลดั้งเดิมที่มีเขตเวลาบันทึกเท่านั้น มีสองเหตุผลหลักที่:

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

คุณสมบัติพิเศษ

Timescale DB มีคุณสมบัติที่น่าสนใจซึ่งแยกออกจากฐานข้อมูลอื่น ๆ ในหมวดหมู่เดียวกัน:

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

ไม่เหมาะสมที่จะพูดคุยเกี่ยวกับเวลาที่จะใช้หรือไม่ใช้ Timescale DB หาก IoT เป็นโดเมนของคุณหรือคุณมีลักษณะฐานข้อมูลที่คล้ายคลึงกันอยู่แล้ว Timescale นั้นควรค่าแก่การดู.

CouchDB

CouchDB เป็นโซลูชันฐานข้อมูลขนาดเล็กที่เรียบร้อยซึ่งตั้งอยู่ในมุมเงียบ ๆ มันถูกสร้างขึ้นเพื่อจัดการกับปัญหาของการสูญเสียเครือข่ายและการแก้ไขข้อมูลในที่สุดซึ่งเกิดขึ้นเป็นปัญหาดังนั้นยุ่งที่นักพัฒนาจะเปลี่ยนงานแทนที่จะจัดการกับมัน.

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

คุณสมบัติที่เป็นเอกลักษณ์

CouchDB เป็นสายพันธุ์ที่มีเอกลักษณ์เมื่อมันมาถึงฐานข้อมูล.

  • ความสามารถในการซิงค์ข้อมูลออฟไลน์แรก
  • รุ่นพิเศษสำหรับมือถือและเว็บเบราว์เซอร์ (PouchDB, CouchDB Lite ฯลฯ )
  • ความน่าเชื่อถือที่ทนต่อการชนและทดสอบการสู้รบ
  • จัดกลุ่มได้ง่ายด้วยการจัดเก็บข้อมูลซ้ำซ้อน

ควรใช้ CouchDB เมื่อใด

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

เมื่อไม่ใช้ CouchDB

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

ข้อสรุป

ฉันต้องละทิ้งผู้สมัครที่น่าสนใจมากมายเช่น Riak ดังนั้นรายการนี้จะถูกนำไปเป็นแนวทางมากกว่าบัญญัติ ฉันหวังว่าฉันจะสามารถบรรลุเป้าหมายของฉันได้ด้วยบทความนี้ – ไม่ใช่เพียงแค่ชุดของคำแนะนำฐานข้อมูล แต่ยังพูดคุยสั้น ๆ เกี่ยวกับสถานที่และวิธีการใช้งาน (และหลีกเลี่ยง!).

หากคุณสงสัยที่จะเรียนรู้ฐานข้อมูลจากนั้นตรวจสอบ Udemy สำหรับหลักสูตรออนไลน์ที่ยอดเยี่ยมบางหลักสูตร.

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