เฮ้ ฮาเบอร์.
ฉันชื่อ Misha Butrimov ฉันอยากจะเล่าให้คุณฟังเล็กน้อยเกี่ยวกับคาสซานดรา เรื่องราวของฉันจะเป็นประโยชน์สำหรับผู้ที่ไม่เคยพบฐานข้อมูล NoSQL มาก่อน เนื่องจากมีคุณสมบัติการใช้งานและข้อผิดพลาดมากมายที่คุณจำเป็นต้องรู้ และหากคุณไม่เคยเห็นสิ่งอื่นใดนอกจาก Oracle หรือฐานข้อมูลเชิงสัมพันธ์อื่น ๆ สิ่งเหล่านี้จะช่วยชีวิตคุณได้
แคสแซนดรามีดีอะไร? เป็นฐานข้อมูล NoSQL ที่ออกแบบมาโดยไม่มีจุดล้มเหลวแม้แต่จุดเดียวซึ่งปรับขนาดได้ดี หากคุณต้องการเพิ่มสองสามเทราไบต์สำหรับบางฐานข้อมูล คุณเพียงแค่เพิ่มโหนดเข้ากับวงแหวน ขยายไปยังศูนย์ข้อมูลอื่นหรือไม่? เพิ่มโหนดให้กับคลัสเตอร์ เพิ่ม RPS ที่ประมวลผลหรือไม่ เพิ่มโหนดให้กับคลัสเตอร์ มันทำงานในทิศทางตรงกันข้ามด้วย
เธอเก่งอะไรอีกล่ะ? มันเกี่ยวกับการจัดการคำขอจำนวนมาก แต่มากขนาดไหนล่ะ? 10, 20, 30, 40 คำขอต่อวินาทีนั้นไม่มากนัก 100 คำขอต่อวินาทีสำหรับการบันทึกด้วยเช่นกัน มีบริษัทหลายแห่งที่บอกว่าพวกเขาเก็บคำขอไว้ 2 ล้านคำขอต่อวินาที พวกเขาก็คงจะต้องเชื่อมัน
และโดยหลักการแล้ว Cassandra มีความแตกต่างอย่างมากจากข้อมูลเชิงสัมพันธ์ - มันไม่เหมือนกันเลย และนี่เป็นสิ่งสำคัญมากที่ต้องจำ
ไม่ใช่ทุกสิ่งที่ดูเหมือนกันทำงานเหมือนกัน
เมื่อเพื่อนร่วมงานมาหาฉันแล้วถามว่า: "นี่คือภาษาคิวรี CQL Cassandra และมีคำสั่งแบบเลือก มีที่ไหน มี และ" ฉันเขียนจดหมายแล้วมันไม่ได้ผล ทำไม?". การปฏิบัติต่อแคสแซนดราเหมือนกับฐานข้อมูลเชิงสัมพันธ์เป็นวิธีที่สมบูรณ์แบบในการฆ่าตัวตายอย่างรุนแรง และฉันไม่ได้โปรโมตมัน มันเป็นสิ่งต้องห้ามในรัสเซีย คุณจะออกแบบบางอย่างผิดไป
ตัวอย่างเช่น ลูกค้ามาหาเราแล้วพูดว่า: “มาสร้างฐานข้อมูลสำหรับละครโทรทัศน์หรือฐานข้อมูลสำหรับไดเรกทอรีสูตรอาหารกันเถอะ เราจะมีอาหารที่นั่นหรือรายชื่อละครโทรทัศน์และนักแสดงในนั้น” เราพูดอย่างสนุกสนาน:“ ไปกันเถอะ!” เพียงส่งไบต์ XNUMX เครื่องหมาย XNUMX-XNUMX รายการ เท่านี้ก็เสร็จสิ้น ทุกอย่างจะทำงานได้อย่างรวดเร็วและเชื่อถือได้ และทุกอย่างเรียบร้อยดีจนลูกค้ามาบอกว่าแม่บ้านก็แก้ปัญหาตรงกันข้าม คือ มีรายการสินค้า และอยากรู้ว่าจะทำอาหารเมนูไหน คุณตาย.
เนื่องจาก Cassandra เป็นฐานข้อมูลแบบไฮบริด โดยให้ค่าคีย์และจัดเก็บข้อมูลในคอลัมน์กว้างไปพร้อมๆ กัน ใน Java หรือ Kotlin สามารถอธิบายได้ดังนี้:
Map<RowKey, SortedMap<ColumnKey, ColumnValue>>
นั่นคือแผนที่ที่มีแผนที่ที่เรียงลำดับด้วย คีย์แรกของแผนที่นี้คือคีย์แถวหรือคีย์พาร์ติชัน - คีย์การแบ่งพาร์ติชัน คีย์ที่สองซึ่งเป็นคีย์สำหรับแผนที่ที่เรียงลำดับแล้วคือคีย์การจัดกลุ่ม
เพื่อแสดงให้เห็นการกระจายตัวของฐานข้อมูล เรามาวาดสามโหนดกัน ตอนนี้คุณต้องเข้าใจวิธีแยกย่อยข้อมูลออกเป็นโหนด เพราะถ้าเราอัดทุกอย่างเป็นหนึ่งเดียว (อาจมีเป็นพัน สองพัน ห้าก็ได้ มากเท่าที่คุณต้องการ) นี่ไม่ได้เกี่ยวกับการแจกจ่ายจริงๆ ดังนั้นเราจึงต้องการฟังก์ชันทางคณิตศาสตร์ที่จะส่งคืนตัวเลข ก็แค่ตัวเลข int ยาวๆ ที่จะตกไปอยู่ในบางช่วง และเราจะมีโหนดหนึ่งที่รับผิดชอบหนึ่งช่วง โหนดที่สองสำหรับช่วงที่สอง โหนดที่ n สำหรับช่วงที่ n
หมายเลขนี้ถ่ายโดยใช้ฟังก์ชันแฮช ซึ่งใช้กับสิ่งที่เราเรียกว่าคีย์พาร์ติชั่น นี่คือคอลัมน์ที่ระบุไว้ในคำสั่งคีย์หลัก และนี่คือคอลัมน์ที่จะเป็นคีย์แรกและคีย์พื้นฐานที่สุดของแผนที่ กำหนดว่าโหนดใดจะได้รับข้อมูลใด ตารางถูกสร้างขึ้นใน Cassandra โดยมีไวยากรณ์เกือบจะเหมือนกับใน SQL:
CREATE TABLE users (
user_id uu id,
name text,
year int,
salary float,
PRIMARY KEY(user_id)
)
คีย์หลักในกรณีนี้ประกอบด้วยหนึ่งคอลัมน์ และยังเป็นคีย์การแบ่งพาร์ติชันด้วย
ผู้ใช้ของเราจะดำเนินการอย่างไร? บางส่วนจะไปที่โหนดหนึ่ง บางส่วนไปยังอีกโหนดหนึ่ง และบางส่วนไปยังโหนดที่สาม ผลลัพธ์ที่ได้คือตารางแฮชธรรมดาหรือที่เรียกว่าแผนที่หรือที่เรียกว่าพจนานุกรมใน Python หรือโครงสร้างค่าคีย์แบบง่ายซึ่งเราสามารถอ่านค่าทั้งหมด อ่านและเขียนด้วยคีย์ได้
เลือก: เมื่ออนุญาตให้กรองกลายเป็นการสแกนแบบเต็มหรือสิ่งที่ไม่ควรทำ
มาเขียนคำสั่ง select กัน: select * from users where, userid = . ปรากฎเหมือนใน Oracle: เราเขียน select ระบุเงื่อนไขและทุกอย่างใช้งานได้ ผู้ใช้ก็เข้าใจ แต่หากคุณเลือก เช่น ผู้ใช้ที่มีปีเกิดที่แน่นอน คาสซานดราจะบ่นว่าไม่สามารถดำเนินการตามคำขอได้ เนื่องจากเธอไม่รู้อะไรเลยเกี่ยวกับวิธีที่เรากระจายข้อมูลเกี่ยวกับปีเกิด เธอจึงมีเพียงคอลัมน์เดียวที่ระบุว่าเป็นคีย์ จากนั้นเธอก็พูดว่า “เอาล่ะ ฉันยังคงสามารถตอบสนองคำขอนี้ได้ เพิ่มอนุญาตการกรอง" เราเพิ่มคำสั่ง ทุกอย่างใช้งานได้ และในขณะนี้มีเรื่องเลวร้ายเกิดขึ้น
เมื่อเราเรียกใช้ข้อมูลทดสอบ ทุกอย่างเรียบร้อยดี และเมื่อคุณดำเนินการค้นหาในการผลิตซึ่งเรามีบันทึก 4 ล้านรายการ ทุกอย่างก็ไม่ดีสำหรับเรา เนื่องจากการอนุญาตการกรองเป็นคำสั่งที่ช่วยให้ Cassandra รวบรวมข้อมูลทั้งหมดจากตารางนี้จากโหนดทั้งหมด ศูนย์ข้อมูลทั้งหมด (หากมีจำนวนมากในคลัสเตอร์นี้) จากนั้นกรองเท่านั้น นี่เป็นอะนาล็อกของ Full Scan และแทบไม่มีใครพอใจกับมัน
หากเราต้องการเพียงผู้ใช้ด้วย ID เราก็จะพอใจกับสิ่งนี้ แต่บางครั้งเราจำเป็นต้องเขียนคำสั่งอื่นๆ และกำหนดข้อจำกัดอื่นๆ ในการเลือก ดังนั้นเราจึงจำได้ว่า: นี่คือแผนที่ทั้งหมดที่มีคีย์การแบ่งพาร์ติชัน แต่ภายในนั้นเป็นแผนที่ที่เรียงลำดับ
และเธอยังมีกุญแจอีกดอกหนึ่ง ซึ่งเราเรียกว่า Clustering Key คีย์นี้ซึ่งในทางกลับกันจะประกอบด้วยคอลัมน์ที่เราเลือกด้วยความช่วยเหลือซึ่ง Cassandra เข้าใจวิธีการจัดเรียงข้อมูลทางกายภาพและจะอยู่ที่แต่ละโหนด นั่นคือสำหรับคีย์พาร์ติชั่นบางคีย์ คีย์การจัดกลุ่มจะบอกคุณอย่างชัดเจนว่าจะส่งข้อมูลลงในแผนผังนี้อย่างไร และจะไปที่ใด
นี่คือต้นไม้จริงๆ มีการเรียกตัวเปรียบเทียบง่ายๆ ซึ่งเราส่งชุดคอลัมน์บางชุดในรูปแบบของวัตถุและระบุเป็นรายการคอลัมน์ด้วย
CREATE TABLE users_by_year_salary_id (
user_id uuid,
name text,
year int,
salary float,
PRIMARY KEY((year), salary, user_id)
ให้ความสนใจกับคำสั่งคีย์หลัก อาร์กิวเมนต์แรก (ในกรณีของเราคือปี) จะเป็นคีย์พาร์ติชันเสมอ สามารถประกอบด้วยหนึ่งคอลัมน์ขึ้นไปก็ไม่สำคัญ หากมีหลายคอลัมน์ จะต้องลบออกในวงเล็บอีกครั้งเพื่อให้ตัวประมวลผลล่วงหน้าของภาษาเข้าใจว่านี่คือคีย์หลัก และคอลัมน์อื่นๆ ทั้งหมดที่อยู่ด้านหลังคือคีย์การจัดกลุ่ม ในกรณีนี้ สิ่งเหล่านี้จะถูกส่งไปในตัวเปรียบเทียบตามลำดับที่ปรากฏ นั่นคือคอลัมน์แรกมีความสำคัญมากกว่า คอลัมน์ที่สองมีความสำคัญน้อยกว่า ไปเรื่อยๆ ตัวอย่างเช่น วิธีที่เราเขียน เท่ากับฟิลด์สำหรับคลาสข้อมูล: เราแสดงรายการฟิลด์ และสำหรับฟิลด์เหล่านั้น เราเขียนว่าฟิลด์ไหนใหญ่กว่าและอันไหนเล็กกว่า ในคาสซานดรา สิ่งเหล่านี้คือฟิลด์ของคลาสข้อมูล ซึ่งค่าเท่ากับที่เขียนไว้จะถูกนำไปใช้
เราตั้งค่าการเรียงลำดับและกำหนดข้อจำกัด
คุณต้องจำไว้ว่าลำดับการจัดเรียง (จากมากไปหาน้อย จากน้อยไปหามาก หรืออะไรก็ตาม) จะถูกตั้งค่าในเวลาเดียวกันกับที่คีย์ถูกสร้างขึ้น และไม่สามารถเปลี่ยนแปลงได้ในภายหลัง โดยจะกำหนดทางกายภาพว่าข้อมูลจะถูกจัดเรียงอย่างไรและจะจัดเก็บอย่างไร หากคุณต้องการเปลี่ยนคีย์การทำคลัสเตอร์หรือลำดับการจัดเรียง คุณจะต้องสร้างตารางใหม่และถ่ายโอนข้อมูลลงไป สิ่งนี้จะไม่ทำงานกับอันที่มีอยู่
เราเติมผู้ใช้ในตารางของเราและเห็นว่าพวกเขาตกอยู่ในวงล้อม เริ่มจากปีเกิด จากนั้นจึงเข้าไปข้างในแต่ละโหนดตามเงินเดือนและ ID ผู้ใช้ ตอนนี้เราสามารถเลือกได้โดยกำหนดข้อจำกัด
ผลงานของเราปรากฏขึ้นอีกครั้ง where, andและเราได้รับผู้ใช้ และทุกอย่างก็เรียบร้อยดีอีกครั้ง แต่ถ้าเราพยายามใช้เพียงส่วนหนึ่งของคีย์ Clustering และคีย์ที่มีนัยสำคัญน้อยกว่า Cassandra จะบ่นทันทีว่าไม่พบสถานที่ในแผนที่ของเราที่ซึ่งวัตถุนี้ซึ่งมีฟิลด์เหล่านี้สำหรับตัวเปรียบเทียบค่าว่างและอันนี้ นั่นเพิ่งถูกกำหนดไว้ - ที่ที่เขานอนอยู่ ฉันจะต้องดึงข้อมูลทั้งหมดจากโหนดนี้อีกครั้งและกรอง และนี่คืออะนาล็อกของ Full Scan ภายในโหนด ซึ่งถือว่าแย่
ในสถานการณ์ที่ไม่ชัดเจน ให้สร้างตารางใหม่
หากเราต้องการกำหนดเป้าหมายผู้ใช้ตาม ID หรือตามอายุ หรือตามเงินเดือน เราควรทำอย่างไร? ไม่มีอะไร. ใช้เพียงสองโต๊ะ หากคุณต้องการเข้าถึงผู้ใช้ด้วยสามวิธีที่แตกต่างกัน จะมีสามตาราง หมดยุคที่เราประหยัดพื้นที่บนสกรูแล้ว นี่คือทรัพยากรที่ถูกที่สุด มีค่าใช้จ่ายน้อยกว่าเวลาตอบสนองมากซึ่งอาจเป็นอันตรายต่อผู้ใช้ ผู้ใช้จะได้รับบางสิ่งบางอย่างในไม่กี่วินาทีจะน่าพึงพอใจมากกว่าใน 10 นาที
เราแลกเปลี่ยนพื้นที่ที่ไม่จำเป็นและข้อมูลที่ผิดมาตรฐานเพื่อความสามารถในการปรับขนาดที่ดีและดำเนินการได้อย่างน่าเชื่อถือ ท้ายที่สุดแล้ว ที่จริงแล้ว คลัสเตอร์ที่ประกอบด้วยศูนย์ข้อมูล XNUMX แห่ง ซึ่งแต่ละแห่งมี XNUMX โหนด พร้อมด้วยระดับการรักษาข้อมูลที่ยอมรับได้ (เมื่อไม่มีอะไรสูญหาย) จะสามารถอยู่รอดจากศูนย์ข้อมูลแห่งเดียวได้อย่างสมบูรณ์ และอีกสองโหนดในแต่ละที่เหลืออีกสองโหนด และหลังจากนี้ปัญหาก็เริ่มต้นขึ้นเท่านั้น นี่เป็นการสำรองที่ค่อนข้างดี โดยคุ้มค่ากับไดรฟ์ SSD และโปรเซสเซอร์เพิ่มเติมสองสามตัว ดังนั้นเพื่อที่จะใช้ Cassandra ซึ่งไม่เคยเป็น SQL ซึ่งไม่มีความสัมพันธ์คีย์ต่างประเทศคุณจำเป็นต้องรู้กฎง่ายๆ
เราออกแบบทุกอย่างตามคำขอของคุณ สิ่งสำคัญไม่ใช่ข้อมูล แต่เป็นวิธีการทำงานของแอปพลิเคชัน หากต้องการรับข้อมูลที่แตกต่างกันในลักษณะที่ต่างกันหรือข้อมูลเดียวกันในรูปแบบที่ต่างกันเราจะต้องวางไว้ในลักษณะที่สะดวกต่อการใช้งาน มิฉะนั้น เราจะล้มเหลวในการสแกนแบบเต็ม และคาสซานดราจะไม่ให้ข้อได้เปรียบใดๆ แก่เรา
การทำให้ข้อมูลเป็นปกติเป็นเรื่องปกติ เราลืมรูปแบบปกติไป เราไม่มีฐานข้อมูลเชิงสัมพันธ์อีกต่อไป ถ้าเราวางอะไรลง 100 ครั้ง มันจะนอนลง 100 ครั้ง ยังถูกกว่าหยุดอีก
เราเลือกคีย์สำหรับการแบ่งพาร์ติชันเพื่อให้สามารถกระจายได้ตามปกติ เราไม่ต้องการให้แฮชของคีย์ของเราตกอยู่ในช่วงแคบๆ เดียว กล่าวคือปีเกิดตามตัวอย่างข้างต้นถือเป็นตัวอย่างที่ไม่ดี แม่นยำกว่านั้น เป็นการดีถ้าผู้ใช้ของเรามักจะแจกแจงตามปีเกิด และแย่ถ้าเราพูดถึงนักเรียนชั้นประถมศึกษาปีที่ 5 การแบ่งพาร์ติชันที่นั่นจะไม่ดีนัก
การเรียงลำดับจะถูกเลือกหนึ่งครั้งในขั้นตอนการสร้างคีย์คลัสเตอร์ หากจำเป็นต้องเปลี่ยนแปลง เราจะต้องอัปเดตตารางของเราด้วยคีย์อื่น
และสิ่งที่สำคัญที่สุด: หากเราต้องการดึงข้อมูลเดียวกันด้วยวิธีที่แตกต่างกัน 100 วิธี เราก็จะมีตารางที่แตกต่างกัน 100 ตาราง
ที่มา: will.com