คู่มือวิศวกรข้อมูลสำหรับการจัดเก็บข้อมูลที่ไม่ใช่แบบดั้งเดิม

วิศวกรรมข้อมูล

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

ในขั้นต้น วัตถุประสงค์ของวิศวกรรมข้อมูลคือการโหลดแหล่งข้อมูลภายนอกและการออกแบบฐานข้อมูล (การออกแบบและพัฒนาไปป์ไลน์เพื่อรวบรวม จัดการ จัดเก็บ และวิเคราะห์ข้อมูล)

นับตั้งแต่นั้นมาก็เติบโตขึ้นเพื่อรองรับปริมาณและความซับซ้อนของข้อมูลขนาดใหญ่ ดังนั้นวิศวกรรมข้อมูลจึงรวบรวมทักษะที่หลากหลาย ตั้งแต่การรวบรวมข้อมูลเว็บ การล้างข้อมูล การคำนวณแบบกระจาย และการจัดเก็บข้อมูลและการดึงข้อมูล

สำหรับวิศวกรรมข้อมูลและวิศวกรข้อมูล การจัดเก็บและดึงข้อมูลเป็นองค์ประกอบที่สำคัญของไปป์ไลน์ร่วมกับวิธีการใช้และวิเคราะห์ข้อมูล

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

วิศวกรส่วนใหญ่คุ้นเคยกับฐานข้อมูล SQL เช่น PostgreSQL, MSSQL และ MySQL ซึ่งมีโครงสร้างอยู่ในตารางข้อมูลเชิงสัมพันธ์พร้อมพื้นที่จัดเก็บเชิงแถว

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

ภายในบริบทของวิศวกรรมข้อมูล เทคโนโลยีเหล่านี้ได้แก่ เสิร์ชเอ็นจิ้น ที่เก็บเอกสาร และที่เก็บแบบเสา

• เครื่องมือค้นหา เก่งในการสืบค้นข้อความ เมื่อเปรียบเทียบกับข้อความที่ตรงกันในฐานข้อมูล SQL เช่น LIKE เครื่องมือค้นหามีความสามารถในการค้นหาที่สูงกว่าและประสิทธิภาพที่ดีขึ้นเมื่อนำออกจากกล่อง
• ที่ เก็บเอกสาร ให้ความสามารถในการปรับเปลี่ยนสคีมาข้อมูลได้ดีกว่าฐานข้อมูลแบบเดิม ด้วยการจัดเก็บข้อมูลเป็นออบเจ็กต์เอกสารแต่ละรายการ ซึ่งมักจะแสดงเป็น JSON นั้นไม่จำเป็นต้องมีการกำหนดสคีมาล่วงหน้า
• ร้านค้า แบบเสามีความเชี่ยวชาญในการสืบค้นคอลัมน์เดียวและการรวมค่า การทำงานของ SQL เช่น SUM และ AVG นั้นเร็วกว่ามากในร้านค้าแบบเสา เนื่องจากข้อมูลของคอลัมน์เดียวกันจะถูกเก็บไว้ใกล้กันบนฮาร์ดไดรฟ์

ในบทความนี้ เราสำรวจเทคโนโลยีทั้งสาม: Elasticsearch เป็นเครื่องมือค้นหา MongoDB เป็นที่เก็บเอกสาร และ Amazon Redshift เป็นที่เก็บแบบเสา

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

เพื่อเปรียบเทียบเทคโนโลยีเหล่านี้ เราจะตรวจสอบว่าเทคโนโลยีเหล่านี้จัดทำดัชนี ชาร์ด และรวบรวมข้อมูลอย่างไร

กลยุทธ์การจัดทำดัชนีข้อมูลแต่ละรายการจะปรับปรุงการสืบค้นข้อมูลบางอย่างในขณะที่ขัดขวางผู้อื่น

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

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

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

ในที่สุด เทคโนโลยีเหล่านี้แต่ละอย่างก็รวบรวมข้อมูลต่างกันมาก

เมื่อเรากำลังจัดการกับข้อมูลกิกะไบต์และเทราไบต์ กลยุทธ์การรวมที่ไม่ถูกต้องสามารถจำกัดประเภทและประสิทธิภาพของรายงานที่เราสร้างขึ้นได้

ในฐานะวิศวกรข้อมูล เราต้องพิจารณาทั้งสามด้านเมื่อประเมินการจัดเก็บข้อมูลที่แตกต่างกัน

ผู้เข้าแข่งขัน

เครื่องมือค้นหา: Elasticsearch

Elasticsearch ได้รับความนิยมในหมู่คู่แข่งอย่างรวดเร็วเนื่องจากความสามารถในการปรับขนาดและความง่ายในการรวมเข้าด้วยกัน สร้างขึ้นบน Apache Lucene มีฟังก์ชันการค้นหาข้อความและจัดทำดัชนีที่มีประสิทธิภาพและพร้อมใช้งานทันที นอกเหนือจากงานเครื่องมือค้นหาแบบดั้งเดิม การค้นหาข้อความ และการค้นหาค่าที่แน่นอนแล้ว Elasticsearch ยังมีความสามารถในการรวมชั้นอีกด้วย

ที่เก็บเอกสาร: MongoDB

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

ร้านเสา: Amazon Redshift

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

การจัดทำดัชนี

ความสามารถในการจัดทำดัชนีของ Elasticsearch

ในหลาย ๆ ด้าน เสิร์ชเอ็นจิ้นคือที่เก็บข้อมูลที่เชี่ยวชาญในการจัดทำดัชนีข้อความ

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

โดยค่าเริ่มต้น การดึงข้อมูลนี้จะดำเนินการโดยอัตโนมัติสำหรับทุกฟิลด์ผ่านตัววิเคราะห์

เครื่องวิเคราะห์ คือโมดูลที่สร้างคีย์ดัชนีหลายคีย์โดยการประเมินค่าฟิลด์และแบ่งออกเป็นค่าที่น้อยกว่า

ตัวอย่างเช่น เครื่องวิเคราะห์พื้นฐานอาจตรวจสอบคำว่า "จิ้งจอกสีน้ำตาลกระโดดข้ามสุนัขขี้เกียจ" เป็นคำเช่น "the" "quick" "brown" "fox" เป็นต้น

วิธีนี้ทำให้ผู้ใช้สามารถค้นหาข้อมูลโดยการค้นหาส่วนย่อยภายในผลลัพธ์ จัดอันดับตามจำนวนชิ้นส่วนที่ตรงกับข้อมูลเอกสารเดียวกัน

เครื่องวิเคราะห์ที่ซับซ้อนมากขึ้นสามารถใช้ระยะการแก้ไข n-grams และกรองตามคำหยุด เพื่อสร้างดัชนีการดึงข้อมูลที่ครอบคลุม

ความสามารถในการจัดทำดัชนีของ MongoDB

ในฐานะที่เก็บข้อมูลทั่วไป MongoDB มีความยืดหยุ่นมากในการจัดทำดัชนีข้อมูล

ต่างจาก Elasticsearch โดยจะทำดัชนีเฉพาะฟิลด์ _id โดยค่าเริ่มต้น และเราจำเป็นต้องสร้างดัชนีสำหรับฟิลด์ที่สืบค้นโดยทั่วไปด้วยตนเอง

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

ความสามารถในการจัดทำดัชนีของ Redshift

ไม่เหมือนกับ Elasticsearch, MongoDB หรือแม้แต่ฐานข้อมูลแบบเดิม รวมถึง PostgreSQL Amazon Redshift ไม่รองรับวิธีการจัดทำดัชนี

แต่จะลดเวลาในการสืบค้นด้วยการรักษาการเรียงลำดับที่สอดคล้องกันบนดิสก์

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

ชาร์ดิง

ความสามารถในการชาร์ดของ Elasticsearch

Elasticsearch สร้างขึ้นบน Lucene เพื่อปรับขนาดในแนวนอนและพร้อมสำหรับการผลิต

การปรับขนาดทำได้โดยการสร้างอินสแตนซ์ Lucene หลายรายการ (ชาร์ด) และกระจายไปยังโหนดต่างๆ (เซิร์ฟเวอร์) ภายในคลัสเตอร์

ตามค่าเริ่มต้น เอกสารแต่ละฉบับจะถูกส่งไปยังชาร์ดตามลำดับผ่านฟิลด์ _id

ในระหว่างการดึงข้อมูล โหนดหลักจะส่งสำเนาของแบบสอบถามแต่ละชาร์ดก่อนที่จะรวบรวมและจัดอันดับผลลัพธ์สำหรับผลลัพธ์

ความสามารถในการชาร์ดของ MongoDB

ภายในคลัสเตอร์ MongoDB มีเซิร์ฟเวอร์สามประเภท: เราเตอร์ config และชาร์ด

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

เช่นเดียวกับ Elasticsearch เอกสาร MongoDB ถูกกำหนดเส้นทาง (โดยค่าเริ่มต้น) ผ่าน _id ไปยังชาร์ดตามลำดับ ในเวลาสืบค้น เซิร์ฟเวอร์กำหนดค่าจะแจ้งเราเตอร์ ซึ่งจะแยกส่วนการสืบค้น จากนั้นเซิร์ฟเวอร์เราเตอร์จะกระจายการสืบค้นข้อมูลและรวบรวมผลลัพธ์

ความสามารถในการชาร์ดของ Redshift

คลัสเตอร์ Amazon Redshift ประกอบด้วยโหนดผู้นำหนึ่งโหนดและโหนดประมวลผลหลายโหนด

โหนดผู้นำจะจัดการกับการรวบรวมและการกระจายของแบบสอบถามตลอดจนการรวมผลลัพธ์ระดับกลาง

ไม่เหมือนกับเซิร์ฟเวอร์เราเตอร์ของ MongoDB โหนดผู้นำมีความสอดคล้องกันและไม่สามารถปรับขนาดในแนวนอนได้

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

การรวบรวม

ความสามารถในการรวมของ Elasticsearch

เอกสารภายใน Elasticsearch สามารถรวมเข้าด้วยกันตามค่าที่แน่นอน เป็นช่วง หรือแม้แต่ค่าเวลาและตำแหน่งทางภูมิศาสตร์

บัคเก็ตเหล่านี้สามารถจัดกลุ่มเพิ่มเติมเป็นรายละเอียดปลีกย่อยผ่านการรวมที่ซ้อนกัน

สามารถคำนวณเมตริก ซึ่งรวมถึงค่าเฉลี่ยและค่าเบี่ยงเบนมาตรฐานสำหรับแต่ละเลเยอร์ ซึ่งให้ความสามารถในการคำนวณลำดับชั้นของการวิเคราะห์ภายในการสืบค้นข้อมูลเดียว

เนื่องจากเป็นการจัดเก็บแบบเอกสาร จึงมีข้อจำกัดในการเปรียบเทียบฟิลด์ภายในเอกสาร

ตัวอย่างเช่น ในขณะที่เป็นการดีในการกรองว่า ผู้ติดตาม ฟิลด์มากกว่า 10 เราไม่สามารถตรวจสอบได้ว่า ผู้ติดตาม มากกว่าฟิลด์อื่นที่ ตาม มาหรือไม่

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

ความสามารถในการรวมของ MongoDB

Aggregation Pipeline มีประสิทธิภาพและรวดเร็ว

ตามชื่อของมัน มันทำงานกับข้อมูลที่ส่งคืนในลักษณะที่ชาญฉลาด

แต่ละขั้นตอนสามารถกรอง รวม และแปลงเอกสาร แนะนำตัวชี้วัดใหม่ หรือคลายกลุ่มที่รวมก่อนหน้านี้

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

แม้จะมีความสามารถในการปรับตัว MongoDB ก็ประสบปัญหาขาดการเปรียบเทียบฟิลด์ภายในเอกสารเช่นเดียวกับ Elasticsearch

นอกจากนี้ การดำเนินการบางอย่าง รวมถึง $group ต้องส่งผลลัพธ์ไปยังโหนดหลัก

ดังนั้นพวกเขาจึงไม่ใช้ประโยชน์จากการคำนวณแบบกระจาย

ผู้ที่ไม่คุ้นเคยกับการคำนวณไปป์ไลน์ตามขั้นตอนจะพบว่างานบางอย่างไม่ได้ใช้งาน ตัวอย่างเช่น การสรุปจำนวนองค์ประกอบในฟิลด์อาร์เรย์จะต้องมีสองขั้นตอน: ขั้นแรก $unwind จากนั้นดำเนินการ $group

ความสามารถในการรวมของ Redshift

ประโยชน์ของ Amazon Redshift ไม่สามารถอธิบายได้

การรวมที่ช้าอย่างน่าผิดหวังบน MongoDB ในขณะที่การวิเคราะห์ปริมาณการใช้มือถือจะได้รับการแก้ไขอย่างรวดเร็วโดย Amazon Redshift

การสนับสนุน SQL วิศวกรฐานข้อมูลแบบดั้งเดิมจะมีเวลาที่สะดวกในการย้ายข้อความค้นหาไปยัง Redshift

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

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

เพื่อรักษาเวลาในการอ่านที่ดีที่สุด แถวต่างๆ จะต้องได้รับการจัดเรียง และเพิ่มความพยายามในการปฏิบัติงานเป็นพิเศษ

ปรับให้เหมาะกับผู้ที่มีปัญหาขนาดเพทาไบต์ ไม่ถูกและไม่น่าจะคุ้มกับการลงทุน เว้นแต่จะมีปัญหาเรื่องการปรับขนาดกับฐานข้อมูลอื่น

คัดเลือกผู้ชนะ

ในบทความนี้ เราตรวจสอบเทคโนโลยีที่แตกต่างกันสามอย่าง – Elasticsearch, MongoDB และ Amazon Redshift – ภายในบริบทของวิศวกรรมข้อมูล อย่างไรก็ตาม ไม่มีผู้ชนะที่ชัดเจนเนื่องจากแต่ละเทคโนโลยีเหล่านี้เป็นผู้นำในประเภทการจัดเก็บ

สำหรับวิศวกรรมข้อมูล บางตัวเลือกก็ดีกว่าตัวเลือกอื่นๆ ขึ้นอยู่กับกรณีการใช้งาน

• MongoDB เป็นฐานข้อมูลเริ่มต้นที่ยอดเยี่ยม ซึ่งให้ความยืดหยุ่นที่เราต้องการเมื่อยังคงต้องกำหนดสคีมาข้อมูล ที่กล่าวว่า MongoDB ไม่ได้มีประสิทธิภาพเหนือกว่ากรณีการใช้งานเฉพาะที่ฐานข้อมูลอื่นเชี่ยวชาญ
• แม้ว่า Elasticsearch จะนำเสนอสคีมาของไหลที่คล้ายคลึงกันกับ MongoDB แต่ก็ได้รับการปรับให้เหมาะสมสำหรับดัชนีและการสืบค้นข้อความหลายรายการ โดยเสียประสิทธิภาพในการเขียนและขนาดพื้นที่จัดเก็บ ดังนั้น เราควรพิจารณาย้ายไปที่ Elasticsearch เมื่อเราพบว่าตนเองยังคงรักษาดัชนีจำนวนมากใน MongoDB
• Redshift ต้องการ data schema ที่กำหนดไว้ล่วงหน้า และขาดความสามารถในการปรับตัวที่ MongoDB มีให้ ในทางกลับกัน ฐานข้อมูลนี้จะจัดกลุ่มฐานข้อมูลอื่นๆ สำหรับการสืบค้นที่เกี่ยวข้องกับคอลัมน์เดียว (หรือสองสามคอลัมน์) เท่านั้น เมื่องบประมาณเอื้ออำนวย Amazon Redshift เป็นอาวุธลับที่ยอดเยี่ยมเมื่อผู้อื่นไม่สามารถจัดการปริมาณข้อมูลได้