By Felipe Cardeneti Mendes ในปี 2008 Apache Cassandra ก่อตั้งมาตรฐานใหม่สําหรับการปรับขนาดของฐานข้อมูล ที่เกิดมาเพื่อสนับสนุนการค้นหากล่องจดหมายของ Facebook ตั้งแต่วันนี้มันได้รับการยอมรับโดยผู้ใหญ่ทางเทคโนโลยีเช่น Uber, Netflix และ Apple - ซึ่งมีการดําเนินงานโดยผู้เชี่ยวชาญที่ยังทําหน้าที่เป็นผู้มีส่วนร่วมของ Cassandra (พร้อมกับ DataStax / IBM) และในขณะที่ adoption ของมันเพิ่มขึ้น Cassandra ยังคงอยู่กับภารกิจหลักของตนคือการปรับขนาดบนฮาร์ดแวร์วัตถุดิบที่มีความพร้อมใช้งานสูง แต่อะไรเกี่ยวกับประสิทธิภาพ ความเรียบง่าย ประสิทธิภาพ ความยืดหยุ่น? ในปี 2015 ScyllaDB ใหม่จากการสร้าง KVM และสับแกน Linux ผู้ก่อตั้งเชื่อว่าพวกเขา สามารถบีบอัดพลังงานได้มากขึ้นจากโครงสร้างพื้นฐาน ระยะเวลาที่เหมาะสม: เพียงหนึ่งปีที่ผ่านมา Netflix ได้เผยแพร่ตัวเลขของพวกเขาแสดงวิธีการกด นี้เป็นความสําเร็จที่น่าประทับใจ แต่หนึ่งที่ต้องใช้การลงทุนในโครงสร้างพื้นฐานอย่างมีนัยสําคัญและความพยายามในการปรับแต่ง เกิดขึ้นเพื่อไปเหนือกว่าการใช้ทรัพยากรที่ต่ําสุดของ Cassandra วิธีการวิศวกรรมระดับต่ํา Apache Cassandra ไปยัง 1 ล้านเขียน RPS ความคิดนั้นค่อนข้างเรียบง่าย (ในทฤษฎีอย่างน้อย): ใช้สถาปัตยกรรมที่สามารถปรับขนาดได้ของ Apache Cassandra และนําไปใช้ใหม่ใกล้กับโลหะในขณะที่รักษาความเข้ากันได้ของโปรโตคอลลวด ไม่พึ่งพา Java หมายความว่ามีการเปลี่ยนแปลงความล่าช้าน้อยลง (บวกไม่มีการหยุดชะงักของโลก) ในขณะที่การหยุดชะงักที่ไม่ซ้ํากัน การเพิ่มประสิทธิภาพการไหลของเซิร์ฟเวอร์แม้ภายใต้การโหลดระบบที่หนัก เพื่อหลีกเลี่ยงความขัดแย้งทุกอย่างจะถูกทํา asynchronous และการเพิ่มประสิทธิภาพเหล่านี้ทั้งหมดจะมีการเชื่อมโยงกับตารางเวลาภายในที่เป็นอิสระเพื่อให้สามารถทํางานได้น้อยที่สุด อาคาร Shard-per-Core นี่คือ 10 ปีที่ผ่านมา ในขณะที่ฉันไม่สามารถพูดคุยกับทิศทางปัจจุบันของ Cassandra แต่ ScyllaDB มีการพัฒนาอย่างมีนัยสําคัญตั้งแต่นั้น ” การประยุกต์ใช้ Cassandra ที่เร็วขึ้นไปยังฐานข้อมูลที่มีเอกลักษณ์ของตัวเองและชุดคุณสมบัติที่ไม่ซ้ํากัน เพียงแค่ Spoiler: ในวิดีโอนี้ฉันจะนําคุณผ่านความแตกต่างที่สําคัญระหว่าง ScyllaDB และวิธีการที่แตกต่างจาก Apache Cassandra ฉันพูดถึงความแตกต่างในประสิทธิภาพความยืดหยุ่นและความสามารถเช่นการกําหนดค่าความสําคัญของภาระงาน คุณสามารถเห็นว่า ScyllaDB แผนผังข้อมูลตามแกน CPU ปกติและลดความเสี่ยงการเปลี่ยนแปลง topology - ช่วยให้สามารถจัดการกับล้าน OPS ด้วยความล่าช้าต่ําที่คาดการณ์ได้ (และไม่มีการปรับแต่งและดูแลเด็กอย่างต่อเนื่อง) การพัฒนาของ ScyllaDB นี่คือเมื่อเราแนะนําสถาปัตยกรรม asynchronous shard-per-core, cache ขึ้นอยู่กับแถวและตารางขั้นสูงที่ให้ความล่าช้าต่ําที่คาดการณ์ได้ รุ่นที่สองของ ScyllaDB มีวัตถุประสงค์เพื่อให้มีความเท่าเทียมกันกับ Cassandra แต่เราได้ไปไกลกว่านั้น ตัวอย่างเช่นเราได้แนะนํา (บางสิ่งที่ Cassandra ). เช่นเดียวกับ ScyllaDB ยังแนะนํา ในปีเดียวกัน; เหล่านี้ถูกนําเสนอใน Cassandra 5 (หลังจากที่อย่างน้อย ) นอกจากนี้การใช้งาน Paxos ของเราสําหรับธุรกรรมน้ําหนักเบาจะถูกกําจัด ในการใช้งานทางเลือกของ Cassandra ครั้งที่เข้าดูที่เกิดขึ้นและดัชนีระดับโลกที่สองพร้อมที่จะผลิต ยังคง flag เป็นการทดลอง การสนับสนุนสําหรับดัชนีที่สองในท้องถิ่น 3 การประยุกต์ใช้การดัชนีต่าง ๆ ส่วนใหญ่ของ overhead และข้อ จํากัด รุ่นที่สามหมายถึงการเปลี่ยนแปลงของเราไปยังระบบคลาวด์พร้อมกับนวัตกรรมอย่างต่อเนื่อง นี่คือเมื่อ ScyllaDB Alternator – API ที่เข้ากันได้กับ DynamoDB ของเรา – ถูกนํามาใช้ เราเพิ่มการสนับสนุนสําหรับ ในปี 2020 (บางอย่าง ) ในช่วงเวลานี้เราได้ปรับปรุงความเร็วในการซ่อมแซมอย่างมากด้วยการซ่อมแซมระดับลําดับและแนะนําการกําหนดความสําคัญของภาระงาน (เพิ่มเติมเกี่ยวกับเรื่องนี้ในส่วนถัดไป) การบีบอัด ZSTD Cassandra ได้รับการยอมรับเมื่อปลายปี 2021 ScyllaDB รุ่นที่สี่ปรากฏขึ้นเมื่อ AWS ประกาศครอบครัวตัวอย่าง i3en ของพวกเขาด้วย nodes ความหนาแน่นสูงที่เก็บข้อมูลได้ถึง 60TB ( ในช่วงเวลานี้เราได้แนะนํากลยุทธ์การบีบอัดเพิ่ม (ICS) ซึ่งช่วยให้ผู้ใช้สามารถใช้ได้ถึง 70% ของพื้นที่เก็บข้อมูลของพวกเขาก่อนที่จะขยายขนาด ซึ่งในภายหลังพัฒนาเป็นกลยุทธ์การบีบอัดไฮบริด (และตอนนี้เราสนับสนุนการใช้พื้นที่เก็บข้อมูล 90%) สิ่งที่ Cassandra ยังคงพยายามที่จะจัดการได้อย่างมีประสิทธิภาพ นอกจากนี้เรายังแนะนํา ด้วยวิธีการที่แตกต่างจาก Cassandra และเรามากขึ้น ด้วยแนวคิดเช่น , CACHE BYPASS, TIMEOUTs ที่สามารถกําหนดค่าได้ตามคําถามและอื่น ๆ อีกมากมาย Change Data Capture (CDC) ขยายโปรโตคอล CQL ความตระหนัก สุดท้ายเรามาถึงรุ่นที่ห้าของ ScyllaDB ซึ่งยังคงมีการพัฒนา ขั้นตอนนี้แสดงให้เห็นถึงเส้นทางของเราไปยังความสม่ําเสมอและความยืดหยุ่นที่แข็งแกร่งกับ Raft และ Tablets สําหรับข้อมูลเพิ่มเติมเกี่ยวกับความสําคัญของสิ่งนี้โปรดอ่านที่... ความสามารถที่แยกแยะ ScyllaDB วิศวกรของเราได้แนะนําคุณสมบัติที่น่าสนใจมากมายในช่วงทศวรรษที่ผ่านมา จากการโต้ตอบของฉันกับผู้ใช้ Cassandra ก่อนหน้านี้ฉันคิดว่านี่คือคุณสมบัติที่น่าสนใจที่สุดที่จะพูดคุยที่นี่ Tablets Data Distribution แต่ละตาราง ScyllaDB จะถูกแบ่งออกเป็นชิ้นส่วนเล็ก ๆ (“แท็บเล็ต”) เพื่อกระจายข้อมูลและโหลดอย่างสม่ําเสมอทั่วระบบ แท็บเล็ตจะนําความยืดหยุ่นไปยัง ScyllaDB ซึ่งช่วยให้คุณสามารถเพิ่มขนาดคลับของคุณได้สองเท่าหรือสามเท่าหรือแม้แต่ 10 เท่าเพื่อรองรับการเพิ่มขึ้นของการจราจรที่ไม่คาดการณ์ได้ พวกเขายังช่วยให้สามารถใช้พื้นที่เก็บข้อมูลได้อย่างมีประสิทธิภาพมากขึ้นได้ถึง 90% การใช้งาน เนื่องจากทีมสามารถขยายขนาดได้อย่างรวดเร็วในการตอบสนองต่อการเพิ่มขึ้นของการจราจรพวกเขาสามารถตอบสนองข้อตกลง SLA ของความล่าช้าได้โดยไม่จําเป็นต้องเกินไป “เพียงในกรณีเดียว” Raft-Based: ความสม่ําเสมอที่แข็งแกร่งสําหรับข้อมูลเมตา Raft นําเสนอความสอดคล้องที่แข็งแกร่งกับข้อมูลเมตาของ ScyllaDB ได้หายไปเมื่อการเปลี่ยนแปลงแผนภูมิอาจทําให้คลัสเตอร์ของคุณไม่เห็นด้วยกันหรือคุณจะสูญเสียการเข้าถึงเพราะคุณลืมที่จะอัปเดตปัจจัยการทําซ้ําของพื้นที่กุญแจการรับรอง (ปัญหาที่ยังคงทรมาน Cassandra) Workload Prioritization ช่วยให้คุณสามารถรวบรวมภาระงานหลายครั้งภายใต้คลัสเตอร์เดียว แต่ละคนมี SLA ของตัวเอง โดยทั่วไปแล้วมันควบคุมว่าภาระงานที่แตกต่างกันจะแข่งขันกับทรัพยากรระบบอย่างไร ทีมใช้มันเพื่อให้ความสําคัญกับคําขอแอปพลิเคชันที่จําเป็นต้องตอบสนองทันทีเมื่อเทียบกับคําขออื่น ๆ ที่สามารถทนต่อความล่าช้าเล็กน้อย (เช่นการสแกนขนาดใหญ่) กรณีการใช้งานทั่วไปรวมถึงการสมดุลเวลาจริง vs การประมวลผลแบทช์การแยกการเขียนจากการอ่านและการรวบรวมภาระงาน / โครงสร้างพื้นฐาน ความสําคัญในการทํางาน Repair-based Operations การดําเนินการตามการซ่อมแซมให้แน่ใจว่าข้อมูลคลัสเตอร์ของคุณยังคงซิงค์แม้ในระหว่างการเปลี่ยนแปลง topology ที่การดําเนินการเช่นการแทนที่ nodes ที่ล้มเหลวสามารถ ScyllaDB ยังกําจัดปัญหาการฟื้นฟูข้อมูลอย่างสมบูรณ์ด้วย . ข้อบกพร่องความสม่ําเสมอของข้อมูลในระยะยาวใน Apache Cassandra result in data loss การซ่อมแซมถังขยะบนพื้นฐาน Incremental Compaction การบีบอัดที่เพิ่มขึ้น (ICS) เป็นกลยุทธ์การบีบอัดเริ่มต้นใน ScyllaDB มากกว่าห้าปี ICS ลดการขยายตัวพื้นที่ชั่วคราวอย่างมากซึ่งส่งผลให้มีพื้นที่ดิสก์มากขึ้นสําหรับการจัดเก็บข้อมูลของผู้ใช้ - และสิ่งนี้กําจัดความต้องการทั่วไปของพื้นที่ว่าง 50% ในไดรฟ์ของคุณ ไม่มีคุณลักษณะ Cassandra ที่เปรียบเทียบได้ Cassandra ได้แนะนํา Unified Compaction เมื่อเร็ว ๆ นี้ซึ่งยังไม่ได้พิสูจน์ตัวเอง Row-based Cache แคชตามลําดับของ ScyllaDB ยังเป็นเอกลักษณ์ มันเปิดใช้งานโดยค่าเริ่มต้นและไม่จําเป็นต้องปรับแต่งด้วยตนเอง ด้วย การขยายตัวคุณสามารถป้องกันการปนเปื้อนแคชได้โดยการป้องกันไม่ให้รายการที่สําคัญถูกยกเลิกได้ นอกจากนี้ ลดเวลาการเข้าถึง I / O อย่างมีนัยสําคัญเมื่อรับข้อมูลจากดิสก์ อะไหล่ Cache SSTABLE Index Caching Per-shard Concurrency Limits and Rate Limiters ScyllaDB รวมถึงขีด จํากัด คู่ต่อชิ้นส่วนและขีด จํากัด อัตราต่อพาร์ทิชันเพื่อป้องกันการเพิ่มขึ้นอย่างไม่คาดคิด ไม่ว่าคุณจะจัดการกับลูกค้าที่มีพฤติกรรมผิดหรือการร้องขอจํานวนมากไปยังคีย์ที่เฉพาะเจาะจง ScyllaDB ให้ความยืดหยุ่นที่ Cassandra มักจะขาด DynamoDB Compatibility ScyllaDB ยังมีชั้นที่เข้ากันได้กับ DynamoDB ซึ่งจะแยกออกจากแหล่งกําเนิดของ Apache Cassandra ซึ่งช่วยให้ทีมทํางาน DynamoDB ของพวกเขาทํางานบนคลาวด์ใด ๆ หรือบนพื้นฐานโดยไม่ต้องเปลี่ยนแปลงรหัสและมีค่าใช้จ่ายลดลง 50% สิ่งนี้ได้ช่วยให้ทีมงานไม่กี่ทีมรวมค่าใช้จ่ายหลายครั้งบน ScyllaDB ถัดไปคืออะไร ที่ Monster SCALE Summit เมื่อเร็ว ๆ นี้ CEO / co-founder Dor Laor ได้แบ่งปันมุมมองเกี่ยวกับสิ่งที่จะเกิดขึ้นต่อไปสําหรับ ScyllaDB... พร้อมแล้วตอนนี้ (ดูนี้ และ สําหรับรายละเอียด): การเขียนบล็อก หน้าผลิตภัณฑ์ ความสามารถในการทํางานได้อย่างปลอดภัยที่ 90% การใช้การจัดเก็บ สนับสนุนคูลเลอร์ที่มีปุ่มประเภทตัวอย่างผสม การจัดหาแบบไดนามิกและเครดิตแบบยืดหยุ่น ค้นหาเวคเตอร์ ระยะสั้น: ตารางที่สอดคล้องกันอย่างมาก บริการฉีดผิดพลาด การซ่อมแซมที่โปร่งใส การจัดเก็บวัตถุและระดับ Raft สําหรับโต๊ะที่สอดคล้องกันอย่างเข้มงวด ระยะยาว การทําธุรกรรมหลายกุญแจ การวิเคราะห์และการเปลี่ยนแปลงด้วย UDFs การสมดุลส่วนแบ่งขนาดใหญ่อัตโนมัติ โครงสร้างพื้นฐานที่คงที่เพื่อความเสถียรและความน่าเชื่อถือที่ดีขึ้น โหมดการทําซ้ําสําหรับการเปลี่ยนแปลงโครงสร้างพื้นฐานที่ยืดหยุ่นและมีประสิทธิภาพมากขึ้น สําหรับรายละเอียดโปรดดูบทสนทนาที่สมบูรณ์ที่นี่: ปิด ScyllaDB เร็วกว่า Cassandra (ฉันจะแบ่งปันผลการเปรียบเทียบล่าสุดของฉันที่นี่เร็ว ๆ นี้) แต่ทั้ง ScyllaDB และ Cassandra ได้พัฒนาไปจนถึงจุดที่ ScyllaDB ไม่ใช่ “เพียง” Cassandra ที่เร็วกว่าอีกต่อไป เราได้พัฒนาไปไกลกว่า Cassandra หากโครงการของคุณต้องการประสิทธิภาพที่คาดการณ์ได้มากขึ้น - และ / หรืออาจได้รับประโยชน์จากการเพิ่มความยืดหยุ่นประสิทธิภาพและความเรียบง่ายที่เรามุ่งเน้นไปที่มานานหลายปีแล้ว - คุณอาจต้องการพิจารณาการพัฒนาไปไกลกว่า Cassandra เป็น สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ ScyllaDB เยี่ยมชม https://www.scylladb.com/ คุณสามารถเข้าถึงหนังสือฐานข้อมูลฟรีหลักสูตรและอื่น ๆ ที่ https://resources.scylladb.com/ https://www.scylladb.com/ https://resources.scylladb.com/
