พวกเขาบอกว่าทุกสิ่งในชีวิตคุ้มค่าที่จะลองอย่างน้อยหนึ่งครั้ง และหากคุณคุ้นเคยกับการทำงานกับ DBMS เชิงสัมพันธ์ ก็คุ้มค่าที่จะทำความคุ้นเคยกับ NoSQL ในทางปฏิบัติ ประการแรก อย่างน้อยก็เพื่อการพัฒนาทั่วไป ขณะนี้ เนื่องจากการพัฒนาอย่างรวดเร็วของเทคโนโลยีนี้ จึงมีความคิดเห็นที่ขัดแย้งกันมากมายและการถกเถียงอย่างเผ็ดร้อนในหัวข้อนี้ ซึ่งกระตุ้นความสนใจเป็นพิเศษ
หากคุณเจาะลึกสาระสำคัญของข้อพิพาทเหล่านี้ทั้งหมด คุณจะเห็นว่าข้อพิพาทเหล่านี้เกิดขึ้นเนื่องจากแนวทางที่ไม่ถูกต้อง ผู้ที่ใช้ฐานข้อมูล NoSQL ตรงจุดที่ต้องการจะพึงพอใจและได้รับข้อดีทั้งหมดจากโซลูชันนี้ และผู้ทดลองที่ใช้เทคโนโลยีนี้เป็นยาครอบจักรวาลซึ่งไม่สามารถนำมาใช้ได้เลยจะต้องผิดหวัง โดยสูญเสียจุดแข็งของฐานข้อมูลเชิงสัมพันธ์โดยไม่ได้รับผลประโยชน์ที่สำคัญ
ฉันจะเล่าให้คุณฟังเกี่ยวกับประสบการณ์ของเราในการใช้โซลูชันโดยใช้ Cassandra DBMS: สิ่งที่เราเผชิญ วิธีที่เราออกจากสถานการณ์ที่ยากลำบาก ไม่ว่าเราจะได้รับประโยชน์จากการใช้ NoSQL หรือไม่ และที่ที่เราต้องลงทุนความพยายาม/เงินทุนเพิ่มเติม .
ภารกิจเริ่มแรกคือการสร้างระบบที่บันทึกการโทรในพื้นที่เก็บข้อมูลบางประเภท
หลักการทำงานของระบบมีดังนี้ อินพุตประกอบด้วยไฟล์ที่มีโครงสร้างเฉพาะที่อธิบายโครงสร้างของการโทร แอปพลิเคชันตรวจสอบให้แน่ใจว่าโครงสร้างนี้ถูกเก็บไว้ในคอลัมน์ที่เหมาะสม ในอนาคต การโทรที่บันทึกไว้จะใช้เพื่อแสดงข้อมูลเกี่ยวกับปริมาณการใช้ข้อมูลของสมาชิก (ค่าบริการ การโทร ประวัติยอดคงเหลือ)
ค่อนข้างชัดเจนว่าทำไมพวกเขาถึงเลือก Cassandra เธอเขียนได้เหมือนปืนกล ปรับขนาดได้ง่าย และทนทานต่อข้อผิดพลาด
นี่คือประสบการณ์ที่มอบให้เรา
ใช่ โหนดที่ล้มเหลวไม่ใช่โศกนาฏกรรม นี่คือแก่นแท้ของการอดทนต่อความผิดพลาดของแคสแซนดรา แต่ โหนดสามารถมีชีวิตอยู่ได้และในเวลาเดียวกันก็เริ่มประสบปัญหาด้านประสิทธิภาพ. เมื่อปรากฏออกมา สิ่งนี้จะส่งผลต่อประสิทธิภาพของคลัสเตอร์ทั้งหมดทันที
Cassandra จะไม่ปกป้องคุณโดยที่ Oracle ช่วยคุณด้วยข้อจำกัด. และหากผู้เขียนแอปพลิเคชันไม่เข้าใจสิ่งนี้ล่วงหน้า สองเท่าที่มาถึงคาสซานดราก็ไม่เลวร้ายไปกว่าต้นฉบับ เมื่อมาถึงแล้วเราจะใส่มันลงไป
IB ไม่ชอบ Cassandra ที่เป็นอิสระอย่างยิ่งเมื่อแกะกล่อง: ไม่มีการบันทึกการกระทำของผู้ใช้ ไม่มีการแยกสิทธิ์. ข้อมูลเกี่ยวกับการโทรถือเป็นข้อมูลส่วนบุคคล ซึ่งหมายความว่าความพยายามทั้งหมดในการร้องขอ/เปลี่ยนแปลงข้อมูลในทางใดทางหนึ่งจะต้องได้รับการบันทึกไว้และสามารถตรวจสอบได้ในภายหลัง นอกจากนี้ คุณต้องคำนึงถึงความจำเป็นในการแยกสิทธิ์ในระดับต่างๆ สำหรับผู้ใช้ที่แตกต่างกัน วิศวกรฝ่ายปฏิบัติการที่เรียบง่ายและผู้ดูแลระบบขั้นสูงที่สามารถลบคีย์สเปซทั้งหมดได้อย่างอิสระนั้น มีบทบาท ความรับผิดชอบ และความสามารถที่แตกต่างกัน หากไม่มีการแยกสิทธิ์การเข้าถึงดังกล่าว มูลค่าและความสมบูรณ์ของข้อมูลจะถูกตั้งคำถามได้เร็วกว่าระดับความสอดคล้องใดๆ ทันที
เราไม่ได้คำนึงว่าการโทรต้องใช้ทั้งการวิเคราะห์ที่จริงจังและการสุ่มตัวอย่างเป็นระยะสำหรับเงื่อนไขต่างๆ เนื่องจากบันทึกที่เลือกควรจะถูกลบและเขียนใหม่ (ซึ่งเป็นส่วนหนึ่งของงาน เราต้องสนับสนุนกระบวนการอัปเดตข้อมูลเมื่อข้อมูลเริ่มเข้าสู่วงวนของเราไม่ถูกต้อง) Cassandra ไม่ใช่เพื่อนของเราที่นี่ คาสซานดราเป็นเหมือนกระปุกออมสิน - ใส่ของได้สะดวก แต่นับไม่ได้
เราพบปัญหาในการถ่ายโอนข้อมูลไปยังโซนทดสอบ (5 โหนดในการทดสอบเทียบกับ 20 โหนดใน Prom) ในกรณีนี้ ไม่สามารถใช้ดัมพ์ได้
ปัญหาในการอัปเดตสคีมาข้อมูลของแอปพลิเคชันที่เขียนไปยัง Cassandra การย้อนกลับจะสร้างหลุมศพจำนวนมาก ซึ่งอาจนำไปสู่การสูญเสียประสิทธิภาพการทำงานในลักษณะที่คาดเดาไม่ได้. Cassandra ได้รับการปรับให้เหมาะสมสำหรับการบันทึกและไม่ต้องคิดมากก่อนเขียน การดำเนินการใด ๆ ที่มีข้อมูลที่มีอยู่ในนั้นก็ถือเป็นการบันทึกเช่นกัน นั่นคือการลบสิ่งที่ไม่จำเป็นออกไปเราจะสร้างบันทึกเพิ่มเติมและมีเพียงบางส่วนเท่านั้นที่จะถูกทำเครื่องหมายด้วยป้ายหลุมศพ
หมดเวลาเมื่อทำการแทรก แคสแซนดรามีความสวยงามในการบันทึกเสียงแต่ บางครั้งกระแสที่เข้ามาอาจทำให้เธอสับสนได้อย่างมาก. สิ่งนี้เกิดขึ้นเมื่อแอปพลิเคชันเริ่มวนรอบบันทึกหลายรายการที่ไม่สามารถแทรกได้ด้วยเหตุผลบางประการ และเราต้องการ DBA จริงที่จะตรวจสอบ gc.log บันทึกระบบและการแก้ไขข้อบกพร่องสำหรับการสืบค้นที่ช้า ตัวชี้วัดในการบีบอัดที่รอดำเนินการ
ศูนย์ข้อมูลหลายแห่งในคลัสเตอร์ อ่านจากไหนและเขียนได้ที่ไหน?
บางทีอาจแบ่งออกเป็นการอ่านและการเขียน? และถ้าเป็นเช่นนั้นควรมี DC ใกล้กับแอปพลิเคชันสำหรับการเขียนหรืออ่านหรือไม่? และเราจะไม่จบลงด้วยสมองที่แตกแยกจริงๆ ถ้าเราเลือกระดับความสม่ำเสมอที่ผิดใช่ไหม? มีคำถามมากมาย การตั้งค่าที่ไม่รู้จักมากมาย ความเป็นไปได้ที่คุณต้องการแก้ไขจริงๆ
เราตัดสินใจอย่างไร
เพื่อป้องกันไม่ให้โหนดจม SWAP จึงถูกปิดใช้งาน. และตอนนี้ หากมีหน่วยความจำไม่เพียงพอ โหนดควรจะหยุดทำงานและไม่สร้างการหยุด gc ขนาดใหญ่
ดังนั้นเราจึงไม่พึ่งพาตรรกะในฐานข้อมูลอีกต่อไป นักพัฒนาแอปพลิเคชันกำลังฝึกอบรมตนเองและเริ่มใช้มาตรการป้องกันในโค้ดของตนเองอย่างจริงจัง การแยกการจัดเก็บและการประมวลผลข้อมูลที่ชัดเจนในอุดมคติ
เราซื้อการสนับสนุนจาก DataStax การพัฒนา Cassandra แบบบรรจุกล่องได้หยุดลงแล้ว (การดำเนินการครั้งล่าสุดคือในเดือนกุมภาพันธ์ 2018) ในเวลาเดียวกัน Datastax นำเสนอบริการที่เป็นเลิศและโซลูชันที่ได้รับการดัดแปลงและปรับใช้จำนวนมากสำหรับโซลูชัน IP ที่มีอยู่
ฉันยังต้องการทราบด้วยว่า Cassandra ไม่สะดวกสำหรับการสืบค้นแบบเลือก แน่นอนว่า CQL ถือเป็นก้าวสำคัญสำหรับผู้ใช้ (เมื่อเทียบกับ Trift) แต่ถ้าคุณมีทั้งแผนกที่คุ้นเคยกับการเข้าร่วมที่สะดวกสบาย การกรองฟิลด์และความสามารถในการเพิ่มประสิทธิภาพคิวรีฟรี และแผนกเหล่านี้กำลังทำงานเพื่อแก้ไขข้อร้องเรียนและอุบัติเหตุ วิธีแก้ปัญหาของ Cassandra ดูเหมือนจะไม่เป็นมิตรและโง่เขลาสำหรับพวกเขา และเราเริ่มตัดสินใจว่าเพื่อนร่วมงานของเราควรทำตัวอย่างอย่างไร
เราพิจารณาสองตัวเลือก ในตัวเลือกแรก เราเขียนการโทรไม่เพียงแต่ในภาษา C* เท่านั้น แต่ยังเขียนในฐานข้อมูล Oracle ที่เก็บถาวรด้วย เท่านั้น ซึ่งแตกต่างจาก C* ตรงที่ฐานข้อมูลนี้จัดเก็บการโทรเฉพาะสำหรับเดือนปัจจุบันเท่านั้น (ความลึกของพื้นที่จัดเก็บการโทรที่เพียงพอสำหรับกรณีการชาร์จใหม่) ที่นี่เราเห็นปัญหาต่อไปนี้ทันที: ถ้าเราเขียนแบบซิงโครนัส เราจะสูญเสียข้อดีทั้งหมดของ C* ที่เกี่ยวข้องกับการแทรกอย่างรวดเร็ว ถ้าเราเขียนแบบอะซิงโครนัส ไม่มีการรับประกันว่าการเรียกที่จำเป็นทั้งหมดจะเข้าสู่ Oracle เลย มีข้อดีอยู่ข้อหนึ่งแต่ข้อใหญ่: สำหรับการดำเนินการ นักพัฒนา PL/SQL ที่คุ้นเคยคนเดิมยังคงอยู่ นั่นคือ เราใช้รูปแบบ "Facade" ในทางปฏิบัติ ทางเลือกอื่น เราใช้กลไกที่ยกเลิกการโหลดการโทรจาก C* ดึงข้อมูลบางส่วนเพื่อเพิ่มคุณค่าจากตารางที่เกี่ยวข้องใน Oracle รวมตัวอย่างผลลัพธ์และให้ผลลัพธ์แก่เรา ซึ่งเราจะนำไปใช้ในทางใดทางหนึ่ง (ย้อนกลับ ทำซ้ำ วิเคราะห์ และชื่นชม) จุดด้อย: กระบวนการนี้ค่อนข้างหลายขั้นตอน และยิ่งไปกว่านั้น ไม่มีอินเทอร์เฟซสำหรับพนักงานปฏิบัติการ
ในที่สุด เราก็ตัดสินใจเลือกทางเลือกที่สอง Apache Spark ถูกใช้เพื่อสุ่มตัวอย่างจากขวดต่างๆ สาระสำคัญของกลไกลดลงเป็นโค้ด Java ซึ่งใช้คีย์ที่ระบุ (สมาชิก เวลาโทร - ปุ่มส่วน) ดึงข้อมูลจาก C* รวมถึงข้อมูลที่จำเป็นสำหรับการตกแต่งจากฐานข้อมูลอื่น ๆ หลังจากนั้นจะรวมไว้ในหน่วยความจำและแสดงผลลัพธ์ในตารางผลลัพธ์ เราวาดหน้าเว็บเหนือประกายไฟ และมันก็ออกมาใช้งานได้ค่อนข้างมาก
เมื่อแก้ไขปัญหาการอัปเดตข้อมูลการทดสอบทางอุตสาหกรรม เราได้พิจารณาวิธีแก้ปัญหาหลายประการอีกครั้ง ทั้งการถ่ายโอนผ่าน Sstloader และตัวเลือกในการแบ่งคลัสเตอร์ในโซนทดสอบออกเป็นสองส่วน ซึ่งแต่ละส่วนจะสลับกันเป็นของคลัสเตอร์เดียวกันกับคลัสเตอร์ส่งเสริมการขาย ดังนั้นจึงขับเคลื่อนโดยคลัสเตอร์นั้น เมื่ออัปเดตการทดสอบ มีการวางแผนที่จะสลับชิ้นส่วนเหล่านั้น: ส่วนที่ทำงานในการทดสอบจะถูกล้างและเข้าสู่การใช้งานจริง และอีกส่วนหนึ่งเริ่มทำงานกับข้อมูลแยกกัน อย่างไรก็ตาม หลังจากคิดอีกครั้ง เราได้ประเมินข้อมูลที่คุ้มค่าในการถ่ายโอนอย่างมีเหตุผลมากขึ้น และตระหนักว่าการโทรนั้นมีลักษณะที่ไม่สอดคล้องกันสำหรับการทดสอบ ซึ่งสร้างขึ้นอย่างรวดเร็วหากจำเป็น และเป็นชุดข้อมูลส่งเสริมการขายที่ไม่มีค่าสำหรับการถ่ายโอนไปยัง ทดสอบ. มีที่เก็บของหลายชิ้นที่ควรค่าแก่การเคลื่อนย้าย แต่จริงๆ แล้วเป็นโต๊ะสองสามโต๊ะและไม่หนักมาก ดังนั้นเราจึง เพื่อเป็นวิธีแก้ปัญหา Spark ได้เข้ามาช่วยเหลืออีกครั้งด้วยความช่วยเหลือที่เราเขียนและเริ่มใช้สคริปต์ในการถ่ายโอนข้อมูลระหว่างตารางการทดสอบพรหม
นโยบายการปรับใช้ปัจจุบันของเราช่วยให้เราทำงานโดยไม่มีการย้อนกลับ ก่อนโปรโมชัน จะมีการทดสอบภาคบังคับ ซึ่งข้อผิดพลาดนั้นไม่แพงนัก ในกรณีที่เกิดความล้มเหลว คุณสามารถละทิ้ง casespace และม้วนโครงร่างทั้งหมดตั้งแต่ต้นได้เสมอ
เพื่อให้แน่ใจว่า Cassandra จะพร้อมใช้งานอย่างต่อเนื่อง คุณต้องมี dba ไม่ใช่เฉพาะเขาเท่านั้น ทุกคนที่ทำงานกับแอปพลิเคชันจะต้องเข้าใจว่าจะดูสถานการณ์ปัจจุบันที่ไหนและอย่างไร รวมถึงวิธีวินิจฉัยปัญหาอย่างทันท่วงที ในการดำเนินการนี้ เราใช้ DataStax OpsCenter อย่างจริงจัง (การดูแลระบบและการตรวจสอบปริมาณงาน), ตัวชี้วัดระบบไดรเวอร์ Cassandra (จำนวนการหมดเวลาสำหรับการเขียนไปยัง C*, จำนวนการหมดเวลาสำหรับการอ่านจาก C*, เวลาแฝงสูงสุด ฯลฯ) ) ตรวจสอบการดำเนินการ ของตัวแอปพลิเคชันเอง โดยทำงานร่วมกับ Cassandra
เมื่อเรานึกถึงคำถามก่อนหน้านี้ เราก็ตระหนักได้ว่าความเสี่ยงหลักของเราอยู่ที่ไหน เหล่านี้เป็นแบบฟอร์มการแสดงข้อมูลที่จะแสดงข้อมูลจากแบบสอบถามอิสระหลายรายการไปยังที่เก็บข้อมูล วิธีนี้ทำให้เราได้รับข้อมูลที่ค่อนข้างไม่สอดคล้องกัน แต่ปัญหานี้ก็จะเกี่ยวข้องเช่นกันหากเราทำงานร่วมกับศูนย์ข้อมูลเพียงแห่งเดียว แน่นอนว่าสิ่งที่สมเหตุสมผลที่สุดคือการสร้างฟังก์ชันแบทช์สำหรับการอ่านข้อมูลบนแอปพลิเคชันบุคคลที่สาม ซึ่งจะทำให้มั่นใจว่าข้อมูลจะได้รับภายในระยะเวลาเดียว สำหรับการแบ่งส่วนการอ่านและการเขียนในแง่ของประสิทธิภาพ เราถูกหยุดไว้ที่นี่ด้วยความเสี่ยงที่สูญเสียการเชื่อมต่อระหว่าง DC เราอาจจบลงด้วยสองคลัสเตอร์ที่ไม่สอดคล้องกันโดยสิ้นเชิง
ด้วยเหตุนี้สำหรับตอนนี้ หยุดที่ระดับความสอดคล้องในการเขียน EACH_QUORUM เพื่อการอ่าน - LOCAL_QUORUM
ความประทับใจและข้อสรุปโดยย่อ
เพื่อประเมินผลลัพธ์การแก้ปัญหาจากมุมมองของการสนับสนุนการปฏิบัติงานและโอกาสในการพัฒนาต่อไป เราจึงตัดสินใจว่าจะนำการพัฒนาดังกล่าวไปใช้ที่ใดอีกบ้าง
ทันที จากนั้นจึงให้คะแนนข้อมูลสำหรับโปรแกรม เช่น "ชำระเงินเมื่อสะดวก" (เราโหลดข้อมูลลงใน C* การคำนวณโดยใช้สคริปต์ Spark) การบัญชีสำหรับการอ้างสิทธิ์โดยการรวมตามพื้นที่ การจัดเก็บบทบาท และการคำนวณสิทธิ์การเข้าถึงของผู้ใช้ตามบทบาท เมทริกซ์
อย่างที่คุณเห็น ละครมีความกว้างและหลากหลาย และหากเราเลือกกลุ่มผู้สนับสนุน/ฝ่ายตรงข้ามของ NoSQL เราก็จะเข้าร่วมกับผู้สนับสนุน เนื่องจากเราได้รับข้อได้เปรียบและตรงกับที่เราคาดหวังไว้
แม้แต่ตัวเลือก Cassandra ที่แกะกล่องก็ทำให้สามารถปรับขนาดแนวนอนแบบเรียลไทม์ได้ ซึ่งช่วยแก้ปัญหาการเพิ่มข้อมูลในระบบได้อย่างง่ายดาย เราสามารถย้ายกลไกที่มีภาระงานสูงมากสำหรับการคำนวณการรวมการโทรไปยังวงจรที่แยกจากกัน และยังแยกสคีมาและตรรกะของแอปพลิเคชันออก กำจัดแนวปฏิบัติที่ไม่ดีในการเขียนงานและอ็อบเจ็กต์แบบกำหนดเองในฐานข้อมูลเอง เรามีโอกาสเลือกและกำหนดค่าเพื่อเร่งความเร็ว DC ใดที่เราจะทำการคำนวณและเราจะบันทึกข้อมูลใด เราประกันตนเองจากการล่มของทั้งโหนดแต่ละโหนดและ DC โดยรวม
เมื่อใช้สถาปัตยกรรมของเรากับโปรเจ็กต์ใหม่และมีประสบการณ์มาบ้างแล้ว ฉันอยากจะคำนึงถึงความแตกต่างที่อธิบายไว้ข้างต้นทันที และป้องกันข้อผิดพลาด และทำให้มุมแหลมคมบางส่วนที่ไม่สามารถหลีกเลี่ยงได้ในตอนแรกเรียบขึ้น
ตัวอย่างเช่น ติดตามการอัปเดตของ Cassandra อย่างทันท่วงทีเพราะปัญหาบางประการที่เราได้รับทราบและแก้ไขแล้ว
อย่าวางทั้งฐานข้อมูลและ Spark ไว้บนโหนดเดียวกัน (หรือหารด้วยจำนวนการใช้ทรัพยากรที่อนุญาตอย่างเคร่งครัด) เนื่องจาก Spark สามารถกิน OP ได้มากกว่าที่คาดไว้ และเราจะได้รับปัญหาหมายเลข 1 จากรายการของเราอย่างรวดเร็ว
ปรับปรุงความสามารถในการติดตามและการปฏิบัติงานในขั้นตอนการทดสอบโครงการ ในขั้นแรก ให้คำนึงถึงผู้บริโภคที่มีศักยภาพทั้งหมดของโซลูชันของเราให้มากที่สุดเท่าที่จะเป็นไปได้เพราะนี่คือสิ่งที่โครงสร้างฐานข้อมูลจะขึ้นอยู่กับในที่สุด
หมุนวงจรผลลัพธ์หลาย ๆ ครั้งเพื่อการปรับให้เหมาะสมที่สุด เลือกฟิลด์ที่สามารถซีเรียลไลซ์ได้ ทำความเข้าใจว่าเราควรทำตารางเพิ่มเติมใดเพื่อนำมาพิจารณาอย่างถูกต้องและเหมาะสมที่สุด จากนั้นให้ข้อมูลที่จำเป็นเมื่อมีการร้องขอ (เช่น โดยสมมติว่าเราสามารถจัดเก็บข้อมูลเดียวกันในตารางที่แตกต่างกัน โดยคำนึงถึงรายละเอียดที่แตกต่างกันตาม เกณฑ์ที่แตกต่างกัน เราสามารถประหยัดเวลา CPU สำหรับการร้องขอการอ่านได้อย่างมาก)
เฉลี่ย จัดเตรียมการแนบ TTL และล้างข้อมูลที่ล้าสมัยทันที
เมื่อดาวน์โหลดข้อมูลจาก Cassandra ตรรกะของแอปพลิเคชันควรทำงานบนหลักการ FETCH เพื่อไม่ให้โหลดทุกแถวลงในหน่วยความจำในคราวเดียว แต่จะถูกเลือกเป็นชุด
ขอแนะนำก่อนโอนโครงการไปยังโซลูชันที่อธิบายไว้ ตรวจสอบความทนทานต่อข้อผิดพลาดของระบบโดยทำการทดสอบการชนหลายชุดเช่น การสูญหายของข้อมูลในศูนย์ข้อมูลแห่งเดียว การกู้คืนข้อมูลที่เสียหายในช่วงเวลาหนึ่ง เครือข่ายกลางคันระหว่างศูนย์ข้อมูล การทดสอบดังกล่าวจะไม่เพียงแต่ช่วยให้ประเมินข้อดีและข้อเสียของสถาปัตยกรรมที่นำเสนอเท่านั้น แต่ยังให้แนวทางปฏิบัติที่ดีในการอุ่นเครื่องสำหรับวิศวกรที่ดำเนินการเหล่านั้น และทักษะที่ได้รับจะไม่ฟุ่มเฟือยหากระบบเกิดความล้มเหลวในการผลิตซ้ำ
หากเราทำงานกับข้อมูลที่สำคัญ (เช่น ข้อมูลสำหรับการเรียกเก็บเงิน การคำนวณหนี้ของสมาชิก) ก็ควรให้ความสนใจกับเครื่องมือที่จะลดความเสี่ยงที่เกิดขึ้นเนื่องจากคุณสมบัติของ DBMS ตัวอย่างเช่น ใช้ยูทิลิตี้ nodesync (Datastax) โดยพัฒนากลยุทธ์ที่เหมาะสมที่สุดสำหรับการใช้งานตามลำดับ เพื่อความสม่ำเสมอ อย่าสร้างภาระให้กับ Cassandra มากเกินไป และใช้เฉพาะบางตารางในช่วงเวลาหนึ่งเท่านั้น
จะเกิดอะไรขึ้นกับคาสซานดราหลังจากหกเดือนของชีวิต? โดยทั่วไปจะไม่มีปัญหาที่ยังไม่ได้รับการแก้ไข นอกจากนี้เรายังไม่อนุญาตให้เกิดอุบัติเหตุร้ายแรงหรือการสูญหายของข้อมูล ใช่ เราต้องคิดถึงการชดเชยปัญหาบางอย่างที่ไม่เคยเกิดขึ้นมาก่อน แต่ท้ายที่สุดแล้ว วิธีนี้ก็ไม่ได้ทำให้โซลูชันทางสถาปัตยกรรมของเราคลุมเครือมากนัก หากคุณต้องการและไม่กลัวที่จะลองสิ่งใหม่ ๆ และในขณะเดียวกันก็ไม่อยากผิดหวังเกินไป เตรียมตัวให้พร้อมสำหรับความจริงที่ว่าไม่มีอะไรฟรี คุณจะต้องเข้าใจ เจาะลึกเอกสารประกอบ และประกอบคราดของคุณเองมากกว่าในโซลูชันแบบเก่า และไม่มีทฤษฎีใดที่จะบอกคุณล่วงหน้าได้ว่าคราดใดรอคุณอยู่
ที่มา: will.com