บ่อยครั้งที่ปัญหาซ้ำซ้อนของข้อมูลขนาดใหญ่คือฐานข้อมูลเชิงสัมพันธ์ไม่สามารถปรับขนาดเพื่อประมวลผลข้อมูลจำนวนมหาศาลที่ถูกสร้างขึ้นในขณะนี้
แต่ข้อ จำกัด ด้านความสามารถในการปรับขยายเหล่านี้ที่โซลูชั่น Big Data อย่าง Hadoop ไม่ได้ผูกมัดไว้คืออะไร ทำไม Oracle RAC หรือ MySQL sharding หรือ MPP RDBMS เช่น Teradata (ฯลฯ ) ไม่สามารถบรรลุผลสำเร็จเหล่านี้ได้
ฉันสนใจข้อ จำกัด ทางเทคนิค - ฉันทราบว่าค่าใช้จ่ายทางการเงินของการจัดกลุ่ม RDBMS สามารถถูกห้ามได้
คำตอบ:
MS เพิ่งพูดคุยเรื่องเทคโนโลยีในประเทศเนเธอร์แลนด์ซึ่งพวกเขาพูดถึงเรื่องนี้บ้าง มันเริ่มช้าลง แต่เข้าไปในเนื้อของ Hadoop ประมาณ 20 นาที
ส่วนสำคัญของมันคือ "มันขึ้นอยู่กับ" หากคุณมีการจัดเรียงอย่างสมเหตุสมผล (อย่างน้อยค่อนข้าง) พาร์ติชันชุดของข้อมูลที่ (อย่างน้อยค่อนข้าง) เป็นเนื้อเดียวกันมันควรจะง่ายต่อการปรับขนาดของปริมาณข้อมูลที่สูงด้วย RDBMS ขึ้นอยู่กับสิ่งที่คุณทำ .
Hadoop และ MR ดูเหมือนจะเหมาะกับสถานการณ์ที่คุณถูกบังคับให้ทำการสแกนข้อมูลจำนวนมากโดยเฉพาะอย่างยิ่งเมื่อข้อมูลเหล่านั้นไม่จำเป็นต้องเป็นเนื้อเดียวกันหรือมีโครงสร้างเท่าที่เราพบในโลก RDBMS
Big Data Solutions มีข้อ จำกัด อะไรบ้าง? สำหรับฉันข้อ จำกัด ที่ยิ่งใหญ่ที่สุดที่พวกเขาไม่ผูกพันคือต้องทำสคีมาไว้ล่วงหน้า ด้วยโซลูชัน Big Data คุณสามารถผลักข้อมูลจำนวนมหาศาลลงใน "กล่อง" ตอนนี้และเพิ่มตรรกะให้กับแบบสอบถามของคุณในภายหลังเพื่อจัดการกับการขาดความสม่ำเสมอของข้อมูล จากมุมมองของนักพัฒนาการแลกเปลี่ยนนั้นง่ายในการนำไปใช้และความยืดหยุ่นในส่วนหน้าของโครงการเมื่อเทียบกับความซับซ้อนในการสืบค้นและความสอดคล้องของข้อมูลน้อยกว่าในทันที
ผู้บุกเบิกฐานข้อมูลและนักวิจัย Michael Stonebraker ร่วมเขียนบทความที่กล่าวถึงข้อ จำกัด ของสถาปัตยกรรมฐานข้อมูลแบบดั้งเดิม โดยทั่วไปแล้วพวกเขาจะขยายขนาดด้วยฮาร์ดแวร์ที่มีราคาแพงกว่า แต่มีปัญหาในการขยายด้วยฮาร์ดแวร์สินค้าที่มากขึ้นในแบบคู่ขนานและถูก จำกัด ด้วยสถาปัตยกรรมซอฟต์แวร์ดั้งเดิมที่ออกแบบมาสำหรับยุคเก่า เขาเชื่อว่ายุค BigData ต้องการสถาปัตยกรรมฐานข้อมูลใหม่ ๆ ที่ใช้ประโยชน์จากโครงสร้างพื้นฐานที่ทันสมัยและปรับให้เหมาะสมสำหรับปริมาณงานเฉพาะ ตัวอย่างของสิ่งนี้คือโครงการ C-store ซึ่งนำไปสู่ฐานข้อมูลเชิงพาณิชย์ Vertica Systems และโครงการ H-store ที่นำไปสู่ VoltDB ซึ่งเป็นฐานข้อมูล OLTP SQL ในหน่วยความจำที่ออกแบบมาเพื่อภาระงาน BigData ความเร็วสูง (การเปิดเผยแบบเต็มฉันทำงานกับ VoltDB)
คุณอาจพบว่าการสัมมนาผ่านเว็บนี้น่าสนใจในหัวข้อนี้ มันตอบสนองต่อบางส่วนของตำนานที่เกิดขึ้นกับความสำเร็จของฐานข้อมูล NoSQL โดยทั่วไปเขาเชื่อว่า SQL ไม่ใช่ปัญหามันไม่จำเป็นต้องเลิกใช้ฟีเจอร์ฐานข้อมูลแบบเดิมเช่นความสม่ำเสมอเพื่อให้ได้ประสิทธิภาพ
ไม่เป็นความจริงทั้งหมดที่ RDBMS ไม่สามารถปรับขนาดได้ อย่างไรก็ตามความจริงบางส่วนในคำสั่งขึ้นอยู่กับสถาปัตยกรรม ในรายการที่คุณให้ไว้ Oracle RAC นั้นแตกต่างจากส่วนที่เหลือ (MySQL และ Teradata ที่ถูกแบ่งส่วน) ความแตกต่างที่สำคัญคือดิสก์ที่ใช้ร่วมกันและไม่มีอะไรที่แชร์สถาปัตยกรรม
สถาปัตยกรรมดิสก์ที่ใช้ร่วมกันเช่น Oracle RAC ประสบปัญหาการปรับขนาดเนื่องจากในบางจุดหรือทุกเครื่องที่ทำงานอยู่ควรซิงโครไนซ์กับข้อมูลบางส่วน สำหรับเช่นผู้จัดการล็อคระดับโลกเป็นนักฆ่า คุณสามารถปรับจูนต่อไปได้บ้าง แต่ในที่สุดคุณจะชนกำแพง หากคุณไม่สามารถเพิ่มเครื่องจักรได้อย่างง่ายดายคุณควรมีเครื่องจักรที่มีประสิทธิภาพน้อยลง แต่อาจมีประสิทธิภาพมาก ในกรณีที่ไม่มีสถาปัตยกรรมแบบแบ่งใช้ใด ๆ (หรือข้อมูลที่มีเศษ) แต่ละเครื่องจะเป็นเจ้าของข้อมูลบางส่วน ไม่จำเป็นต้องซิงโครไนซ์กับ mahcines อื่นหากต้องการอัปเดตข้อมูลบางอย่าง
จากนั้นสายพันธุ์ของฐานข้อมูล NoSQL มา ฉันจะถือว่าพวกเขาเป็นส่วนหนึ่งของฐานข้อมูล RDBMS แบบดั้งเดิม ไม่ใช่ทุกแอปพลิเคชั่นในโลกนี้ที่จะต้องใช้ฟังก์ชั่นทั้งหมดที่ RDBMS นำเสนอ ถ้าฉันต้องการใช้ฐานข้อมูลเป็นแคชฉันจะไม่สนใจเรื่องความทนทาน อาจเป็นในบางกรณีฉันก็จะไม่สนใจเรื่องความมั่นคง หากการค้นหาข้อมูลทั้งหมดของฉันอ้างอิงจากคีย์ฉันไม่ต้องการการสนับสนุนสำหรับการสอบถามช่วง ฉันอาจไม่ต้องการดัชนีรอง ฉันไม่ต้องการเลเยอร์การประมวลผลการสืบค้น / การเพิ่มประสิทธิภาพการสืบค้นทั้งหมดซึ่งฐานข้อมูลดั้งเดิมทั้งหมดมี