NoSQL: ข้อมูลที่ไม่มีโครงสร้างคืออะไร

ขณะนี้เรากำลังใช้ทรัพยากรที่มีอยู่ด้วยโซลูชั่น mssql เซิร์ฟเวอร์ของเรา

ขณะนี้เรามีตัวเลือกแบบดั้งเดิมมากมายเกี่ยวกับการย้ายครั้งต่อไปเพื่อรับมือกับโหลด:

• ซื้อ CPU และ IO เร็วขึ้น
• แยกลูกค้าบางรายออกเป็นเซิร์ฟเวอร์แยกต่างหาก
• ย้าย db ไปยังคลัสเตอร์

ทั้งหมดมีราคาแพงทั้งในแง่ของลิขสิทธิ์และฮาร์ดแวร์หรือเวลา ดังนั้นฉันต้องการเพิ่มตัวเลือกอื่นโดยการย้ายทั้งระบบไปยังโซลูชันที่ปรับขนาดได้ซึ่งสัญญาของคาสซานดราเครื่องยนต์ nosql

แต่ฉันไม่แน่ใจและไม่มีประสบการณ์กับฐานข้อมูล noSQL ดังนั้นฉันต้องเข้าใจโครงสร้างของข้อมูล "ที่ไม่มีโครงสร้าง"

ในแอปพลิเคชันของเราเราจะจัดเก็บข้อมูลที่ผู้ใช้ป้อนในรูปแบบต่างๆเป็นรายการ "คีย์ - ค่า" มีตารางหลักที่มีองค์ประกอบส่วนหัว (เช่นคำสั่งซื้อ) และมีตารางลูกที่มีคู่ค่าคีย์ประกอบไปด้วยเนื้อหาของคำสั่งซื้อ (เช่น Order_Lines)

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

ในระหว่างการดำเนินการบางครั้งเราเลือกที่จะโหลดเฉพาะส่วนบน แต่ส่วนใหญ่เราโหลดแถวหลัก + KVP บางส่วนเพื่อแสดงข้อมูลที่เป็นประโยชน์

ตัวอย่างเช่นในรายการภาพรวมเราจะแสดงตัวระบุส่วนหัว + ค่าบางค่าในคอลัมน์สำหรับแต่ละแถว

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

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

"พจนานุกรม" ประเภทนี้เช่นชุดข้อมูลจะถูกเก็บไว้ในฐานข้อมูล noSQL ดีกว่าหรือไม่ และเราจะได้ประโยชน์จากการทำงานนี้หรือไม่? คาสซานดราจำลองหัว + KVP เหล่านี้เป็นชุดข้อมูลเดียวหรือไม่ เมื่อดูที่หน้าเว็บคาสซานดราและบทเรียนบางอย่างฉันมีความประทับใจว่า RDBMS และคาสซานดราของเราแตกต่างกันมากในแง่ของการจัดระเบียบข้อมูลทำให้เรามีจำนวนผู้เข้าร่วมมากหากคุณต้องการเลือก 5 KVP สำหรับรายการสำหรับแต่ละแถว

ยินดีต้อนรับการตรัสรู้ก็ชี้ไปที่เอกสารที่อธิบายปัญหาก็โอเค

มีแนวคิดสองสามข้อที่ต้องแยกแยะ หนึ่งคือเกี่ยวกับโครงสร้างและอื่น ๆ เกี่ยวกับสคี

ข้อมูลที่มีโครงสร้างเป็นข้อมูลที่แอปพลิเคชันทราบล่วงหน้าถึงความหมายของแต่ละไบต์ที่ได้รับ ตัวอย่างที่ดีคือการวัดจากเซ็นเซอร์ ในทางตรงกันข้ามกระแส Twitter ไม่มีโครงสร้าง สคีมาเป็นเรื่องเกี่ยวกับโครงสร้างการสื่อสารกับ DBMS มากน้อยเพียงใดเมื่อมีการขอให้บังคับใช้สิ่งนี้ มันควบคุมว่า DBMS แยกวิเคราะห์ข้อมูลที่เก็บ DBMS ที่จำเป็นต้องใช้ schema เช่น SQL Server สามารถเก็บข้อมูลที่ไม่ได้แยกวิเคราะห์ (varbinary) หรือแยกวิเคราะห์ข้อมูล (xml) และแยกวิเคราะห์ข้อมูลอย่างสมบูรณ์ (คอลัมน์)

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

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

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

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

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

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

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

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

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