ภาพจากภาพยนตร์เรื่อง Our Secret Universe: The Hidden Life of the Cell
ธุรกิจการลงทุนเป็นหนึ่งในพื้นที่ที่ซับซ้อนที่สุดในโลกการธนาคาร เนื่องจากไม่ได้มีแค่สินเชื่อ การกู้ยืม และเงินฝากเท่านั้น แต่ยังรวมถึงหลักทรัพย์ สกุลเงิน สินค้าโภคภัณฑ์ อนุพันธ์ และความซับซ้อนทุกประเภทในรูปแบบของผลิตภัณฑ์ที่มีโครงสร้าง
เมื่อเร็ว ๆ นี้ เราได้เห็นความรู้ทางการเงินของประชากรเพิ่มขึ้น ผู้คนจำนวนมากขึ้นเรื่อยๆ มีส่วนร่วมในการซื้อขายในตลาดหลักทรัพย์ บัญชีการลงทุนส่วนบุคคลปรากฏขึ้นเมื่อไม่นานมานี้ พวกเขาอนุญาตให้คุณซื้อขายในตลาดหลักทรัพย์และรับการหักภาษีหรือหลีกเลี่ยงการจ่ายภาษี และลูกค้าทุกคนที่มาหาเราต้องการจัดการพอร์ตโฟลิโอของตนและดูการรายงานแบบเรียลไทม์ ยิ่งไปกว่านั้น พอร์ตโฟลิโอนี้ส่วนใหญ่มักจะเป็นแบบหลายผลิตภัณฑ์ กล่าวคือ ผู้คนเป็นลูกค้าของสายธุรกิจที่หลากหลาย
นอกจากนี้ความต้องการของหน่วยงานกำกับดูแลทั้งรัสเซียและต่างประเทศก็กำลังเพิ่มขึ้น
เพื่อตอบสนองความต้องการในปัจจุบันและวางรากฐานสำหรับการอัพเกรดในอนาคต เราได้พัฒนาแกนธุรกิจการลงทุนโดยใช้ Tarantool
สถิติบางอย่าง. ธุรกิจการลงทุนของ Alfa-Bank ให้บริการนายหน้าซื้อขายหลักทรัพย์สำหรับบุคคลและนิติบุคคลเพื่อให้โอกาสในการซื้อขายในตลาดหลักทรัพย์ต่างๆ บริการรับฝากเพื่อการจัดเก็บหลักทรัพย์ บริการการจัดการความน่าเชื่อถือสำหรับบุคคลที่มีเงินทุนส่วนตัวและขนาดใหญ่ บริการในการออกหลักทรัพย์ให้กับบริษัทอื่น . ธุรกิจการลงทุนของ Alfa-Bank มีการเสนอราคามากกว่า 3 รายการต่อวินาที ซึ่งดาวน์โหลดจากแพลตฟอร์มการซื้อขายต่างๆ ในระหว่างวันทำการ มีการสรุปธุรกรรมมากกว่า 300 รายการในตลาดในนามของธนาคารหรือลูกค้า การประมวลผลคำสั่งสูงสุด 5 รายการต่อวินาทีเกิดขึ้นบนแพลตฟอร์มภายนอกและภายใน ในเวลาเดียวกัน ลูกค้าทั้งหมดทั้งภายในและภายนอกต้องการดูตำแหน่งของตนแบบเรียลไทม์
ประวัติศาสตร์
ตั้งแต่ต้นทศวรรษ 2000 ธุรกิจการลงทุนของเราได้รับการพัฒนาอย่างเป็นอิสระ: การซื้อขายแลกเปลี่ยน บริการนายหน้าซื้อขายหลักทรัพย์ การซื้อขายสกุลเงิน การซื้อขายหลักทรัพย์และอนุพันธ์ต่างๆ เป็นผลให้เราตกหลุมพรางของบ่อน้ำที่ใช้งานได้ มันคืออะไร? ธุรกิจแต่ละสายมีระบบของตัวเองที่ทำซ้ำฟังก์ชันของกันและกัน แต่ละระบบมีโมเดลข้อมูลของตัวเอง แม้ว่าจะดำเนินการโดยใช้แนวคิดเดียวกัน: ธุรกรรม ตราสาร คู่สัญญา ราคา และอื่นๆ และในขณะที่แต่ละระบบมีการพัฒนาอย่างอิสระ สวนสัตว์แห่งเทคโนโลยีที่หลากหลายก็ถือกำเนิดขึ้น
นอกจากนี้ ฐานโค้ดของระบบค่อนข้างล้าสมัยไปแล้ว เนื่องจากผลิตภัณฑ์บางอย่างมีต้นกำเนิดในช่วงกลางทศวรรษ 1990 และในบางพื้นที่สิ่งนี้ทำให้กระบวนการพัฒนาช้าลงและมีปัญหาด้านประสิทธิภาพ
ข้อกำหนดสำหรับโซลูชันใหม่
ธุรกิจต่างๆ ตระหนักดีว่าการเปลี่ยนแปลงทางเทคโนโลยีมีความสำคัญต่อการพัฒนาต่อไป เราได้รับมอบหมายงาน:
- รวบรวมข้อมูลทางธุรกิจทั้งหมดในพื้นที่จัดเก็บข้อมูลที่รวดเร็วเพียงแห่งเดียวและในรูปแบบข้อมูลเดียว
- เราต้องไม่สูญเสียหรือเปลี่ยนแปลงข้อมูลนี้
- มีความจำเป็นต้องกำหนดเวอร์ชันของข้อมูล เนื่องจากหน่วยงานกำกับดูแลอาจขอสถิติสำหรับปีก่อนหน้าเมื่อใดก็ได้
- เราต้องไม่เพียงแค่นำ DBMS ที่ทันสมัยใหม่ๆ มาใช้ แต่ต้องสร้างแพลตฟอร์มสำหรับแก้ไขปัญหาทางธุรกิจด้วย
นอกจากนี้ สถาปนิกของเรายังกำหนดเงื่อนไขของตนเอง:
- โซลูชันใหม่จะต้องเป็นระดับองค์กร กล่าวคือ จะต้องได้รับการทดสอบในบริษัทขนาดใหญ่บางแห่งแล้ว
- โหมดการทำงานของโซลูชันควรมีความสำคัญต่อภารกิจ ซึ่งหมายความว่าเราจะต้องอยู่ในศูนย์ข้อมูลหลายแห่งพร้อมๆ กัน และเอาตัวรอดจากเหตุขัดข้องของศูนย์ข้อมูลแห่งเดียวได้อย่างใจเย็น
- ระบบจะต้องปรับขนาดได้ในแนวนอน ความจริงก็คือระบบปัจจุบันทั้งหมดของเราสามารถปรับขยายได้ในแนวตั้งเท่านั้น และเรากำลังถึงขีดสุดแล้วเนื่องจากการเติบโตของพลังงานฮาร์ดแวร์ที่ต่ำ ดังนั้นถึงเวลาแล้วที่เราต้องมีระบบที่ปรับขนาดได้ในแนวนอนเพื่อความอยู่รอด
- เหนือสิ่งอื่นใด เราได้รับแจ้งว่าโซลูชันต้องมีราคาถูก
เราปฏิบัติตามเส้นทางมาตรฐาน: เรากำหนดข้อกำหนดและติดต่อแผนกจัดซื้อ จากนั้นเราได้รับรายชื่อบริษัทที่โดยทั่วไปพร้อมที่จะดำเนินการนี้ให้กับเรา เราแจ้งให้ทุกคนทราบเกี่ยวกับปัญหา และได้รับการประเมินแนวทางแก้ไขจากหกคน
ที่ธนาคาร เราไม่ฟังคำใคร เราชอบทดสอบทุกอย่างด้วยตัวเอง ดังนั้นเงื่อนไขบังคับสำหรับการแข่งขันประกวดราคาของเราคือการผ่านการทดสอบการรับน้ำหนัก เรากำหนดงานทดสอบโหลด และบริษัทสามในหกแห่งได้ตกลงที่จะใช้โซลูชันต้นแบบที่ใช้เทคโนโลยีในหน่วยความจำด้วยค่าใช้จ่ายของตนเองเพื่อทดสอบ
ฉันจะไม่บอกคุณว่าเราทดสอบทุกอย่างอย่างไรและใช้เวลานานเท่าใด ฉันจะสรุปเท่านั้น: ประสิทธิภาพที่ดีที่สุดในการทดสอบโหลดแสดงโดยโซลูชันต้นแบบที่ใช้ Tarantool จากทีมพัฒนากลุ่ม Mail.ru เราได้ลงนามในข้อตกลงและเริ่มการพัฒนา มีสี่คนจาก Mail.ru Group และจาก Alfa-Bank มีนักพัฒนาสามคน นักวิเคราะห์ระบบสามคน สถาปนิกโซลูชันหนึ่งคน เจ้าของผลิตภัณฑ์ และ Scrum master
ต่อไป ฉันจะบอกคุณเกี่ยวกับวิธีการที่ระบบของเราเติบโต มีการพัฒนาอย่างไร สิ่งที่เราทำ และเหตุใดจึงเป็นเช่นนั้น
ออกแบบ
คำถามแรกที่เราถามตัวเองคือจะรับข้อมูลจากระบบปัจจุบันของเราได้อย่างไร เราตัดสินใจว่า HTTP ค่อนข้างเหมาะสมกับเรา เนื่องจากระบบปัจจุบันทั้งหมดสื่อสารถึงกันโดยการส่ง XML หรือ JSON ผ่าน HTTP
เราใช้เซิร์ฟเวอร์ HTTP ที่สร้างไว้ใน Tarantool เพราะเราไม่จำเป็นต้องยุติเซสชัน SSL และประสิทธิภาพของมันก็เพียงพอสำหรับเรา
ดังที่ฉันได้กล่าวไปแล้ว ระบบทั้งหมดของเราอยู่ในโมเดลข้อมูลที่แตกต่างกัน และที่อินพุต เราจำเป็นต้องนำออบเจ็กต์มาสู่โมเดลที่เราอธิบายตัวเราเอง จำเป็นต้องมีภาษาที่อนุญาตให้แปลงข้อมูลได้ เราเลือกลัวะที่จำเป็น เราเรียกใช้โค้ดการแปลงข้อมูลทั้งหมดในแซนด์บ็อกซ์ - นี่เป็นสถานที่ที่ปลอดภัยซึ่งโค้ดที่กำลังทำงานอยู่จะไม่ไป ในการดำเนินการนี้ เราเพียงโหลดโค้ดที่จำเป็นเพื่อสร้างสภาพแวดล้อมที่มีฟังก์ชันที่ไม่สามารถบล็อกหรือปล่อยสิ่งใดๆ ได้
หลังจากการแปลงข้อมูลจะต้องได้รับการตรวจสอบว่าสอดคล้องกับแบบจำลองที่เรากำลังสร้างหรือไม่ เราพูดคุยกันมานานแล้วว่าโมเดลควรเป็นอย่างไรและควรใช้ภาษาใดในการอธิบาย เราเลือก Apache Avro เนื่องจากภาษานั้นเรียบง่ายและได้รับการสนับสนุนจาก Tarantool โมเดลและโค้ดแบบกำหนดเองเวอร์ชันใหม่สามารถใช้งานได้หลายครั้งต่อวัน แม้จะอยู่ภายใต้ภาระงานหรือไม่ก็ตาม ในเวลาใดก็ได้ของวัน และปรับให้เข้ากับการเปลี่ยนแปลงได้อย่างรวดเร็ว
หลังจากการตรวจสอบแล้ว จะต้องบันทึกข้อมูล เราทำสิ่งนี้โดยใช้ vshard (เรามีชิ้นส่วนจำลองที่กระจายตามภูมิศาสตร์)
ยิ่งไปกว่านั้น ความเฉพาะเจาะจงก็คือระบบส่วนใหญ่ที่ส่งข้อมูลมาให้เราไม่สนใจว่าจะได้รับหรือไม่ นั่นเป็นเหตุผลที่เราดำเนินการคิวการซ่อมแซมตั้งแต่เริ่มต้น มันคืออะไร? หากออบเจ็กต์ไม่ผ่านการแปลงข้อมูลหรือการตรวจสอบด้วยเหตุผลบางประการ เรายังคงยืนยันการรับ แต่ในขณะเดียวกันก็บันทึกออบเจ็กต์ไว้ในคิวการซ่อมแซม มีความสอดคล้องและตั้งอยู่ในคลังข้อมูลธุรกิจหลัก เราเขียนอินเทอร์เฟซผู้ดูแลระบบ ตัวชี้วัดและการแจ้งเตือนต่างๆ ทันที ส่งผลให้เราไม่สูญเสียข้อมูล แม้ว่าจะมีบางสิ่งเปลี่ยนแปลงไปในแหล่งที่มา หากโมเดลข้อมูลมีการเปลี่ยนแปลง เราจะตรวจจับได้ทันทีและสามารถปรับเปลี่ยนได้
ตอนนี้คุณต้องเรียนรู้วิธีดึงข้อมูลที่บันทึกไว้ เราวิเคราะห์ระบบของเราอย่างรอบคอบและเห็นว่าสแต็กคลาสสิกของ Java และ Oracle จำเป็นต้องมี ORM บางประเภทที่จะแปลงข้อมูลจากเชิงสัมพันธ์เป็นวัตถุ แล้วทำไมไม่มอบวัตถุให้กับระบบในรูปแบบของกราฟทันทีล่ะ? ดังนั้นเราจึงนำ GraphQL มาใช้อย่างมีความสุข ซึ่งตอบสนองทุกความต้องการของเรา ช่วยให้คุณรับข้อมูลในรูปแบบกราฟและดึงออกมาเฉพาะสิ่งที่คุณต้องการในขณะนี้ คุณยังสามารถกำหนดเวอร์ชันของ API ได้อย่างยืดหยุ่นอีกด้วย
เกือบจะในทันทีที่เราตระหนักว่าข้อมูลที่เราดึงมานั้นไม่เพียงพอ เราสร้างฟังก์ชันที่สามารถเชื่อมโยงกับออบเจ็กต์ในโมเดล ซึ่งโดยพื้นฐานแล้วคือฟิลด์ที่มีการคำนวณ นั่นคือเราแนบฟังก์ชันบางอย่างเข้ากับฟิลด์ ซึ่งตัวอย่างเช่น คำนวณราคาเสนอราคาเฉลี่ย และผู้บริโภคภายนอกที่ร้องขอข้อมูลจะไม่รู้ด้วยซ้ำว่านี่เป็นฟิลด์ที่มีการคำนวณ
ได้นำระบบการรับรองความถูกต้องไปใช้
จากนั้นเราสังเกตเห็นว่ามีหลายบทบาทที่ตกผลึกในการตัดสินใจของเรา บทบาทคือตัวรวบรวมฟังก์ชันชนิดหนึ่ง โดยทั่วไป บทบาทจะมีโปรไฟล์การใช้งานอุปกรณ์ที่แตกต่างกัน:
- T-Connect: จัดการการเชื่อมต่อขาเข้า, CPU ที่จำกัด, การใช้หน่วยความจำต่ำ, ไร้สัญชาติ
- IB-Core: แปลงข้อมูลที่ได้รับผ่านโปรโตคอล Tarantool นั่นคือมันทำงานกับตาราง นอกจากนี้ยังไม่จัดเก็บสถานะและสามารถปรับขนาดได้
- พื้นที่เก็บข้อมูล: เก็บข้อมูลเท่านั้น ไม่ใช้ตรรกะใดๆ บทบาทนี้ใช้อินเทอร์เฟซที่ง่ายที่สุด ปรับขนาดได้ด้วย vshard
นั่นคือการใช้บทบาททำให้เราแยกส่วนต่างๆ ของคลัสเตอร์ออกจากกัน ซึ่งสามารถปรับขนาดได้อย่างอิสระ
ดังนั้นเราจึงสร้างการบันทึกโฟลว์ข้อมูลธุรกรรมแบบอะซิงโครนัสและคิวการซ่อมแซมด้วยอินเทอร์เฟซผู้ดูแลระบบ การบันทึกเป็นแบบอะซิงโครนัสจากมุมมองทางธุรกิจ หากเรารับประกันว่าจะเขียนข้อมูลถึงตัวเราเอง ไม่ว่าที่ไหน เราจะยืนยัน หากไม่ได้รับการยืนยัน แสดงว่ามีสิ่งผิดปกติเกิดขึ้นและจำเป็นต้องส่งข้อมูล นี่คือการบันทึกแบบอะซิงโครนัส
การทดสอบ
จากจุดเริ่มต้นของโครงการ เราตัดสินใจว่าจะพยายามนำการพัฒนาที่ขับเคลื่อนด้วยการทดสอบไปใช้ เราเขียนการทดสอบหน่วยใน Lua โดยใช้เฟรมเวิร์ก tarantool/tap และการทดสอบการรวมใน Python โดยใช้เฟรมเวิร์ก pytest ในเวลาเดียวกัน เราให้ทั้งนักพัฒนาและนักวิเคราะห์มีส่วนร่วมในการเขียนการทดสอบการบูรณาการ
เราจะใช้การพัฒนาที่ขับเคลื่อนด้วยการทดสอบได้อย่างไร
หากเราต้องการคุณสมบัติใหม่ เราจะพยายามเขียนการทดสอบก่อน เมื่อเราพบข้อบกพร่อง เราต้องแน่ใจว่าได้เขียนการทดสอบก่อน จากนั้นจึงแก้ไขเท่านั้น ในตอนแรกมันยากที่จะทำงานแบบนี้ พนักงานมีความเข้าใจผิด แม้กระทั่งการก่อวินาศกรรม: “รีบแก้ไขตอนนี้ ทำอะไรใหม่ ๆ แล้วจึงทดสอบด้วย” มีเพียง "ภายหลัง" นี้เท่านั้นที่แทบไม่เคยมาเลย
ดังนั้นคุณต้องบังคับตัวเองให้เขียนแบบทดสอบก่อนและขอให้คนอื่นทำ เชื่อฉันเถอะว่าการพัฒนาที่ขับเคลื่อนด้วยการทดสอบนั้นให้ประโยชน์แม้ในระยะสั้น คุณจะรู้สึกว่าชีวิตของคุณง่ายขึ้น เรารู้สึกว่าขณะนี้โค้ด 99% ครอบคลุมโดยการทดสอบแล้ว ดูเหมือนจะเยอะ แต่เราไม่มีปัญหาใดๆ การทดสอบจะดำเนินการกับทุกคอมมิต
อย่างไรก็ตาม สิ่งที่เราชอบที่สุดคือการทดสอบโหลดซึ่งเราถือว่าเป็นสิ่งสำคัญที่สุดและดำเนินการอย่างสม่ำเสมอ
ฉันจะเล่าเรื่องราวเล็กๆ น้อยๆ ให้คุณฟังเกี่ยวกับวิธีที่เราดำเนินการทดสอบโหลดขั้นแรกของเวอร์ชันแรก เราติดตั้งระบบบนแล็ปท็อปของนักพัฒนา เปิดโหลด และรับธุรกรรม 4 รายการต่อวินาที ผลลัพธ์ที่ดีสำหรับแล็ปท็อป เราติดตั้งมันบนบัลลังก์โหลดเสมือนของเซิร์ฟเวอร์สี่ตัว ซึ่งอ่อนแอกว่าในการใช้งานจริง ปรับใช้ให้เหลือน้อยที่สุด เราดำเนินการและได้ผลลัพธ์ที่แย่กว่าบนแล็ปท็อปในเธรดเดียว เนื้อหาที่น่าตกใจ
เราเสียใจมาก เราดูที่โหลดของเซิร์ฟเวอร์ แต่ปรากฎว่าไม่ได้ใช้งาน
เราโทรหานักพัฒนา และพวกเขาก็อธิบายให้เราฟังว่าผู้ที่มาจากโลกของ Java ว่า Tarantool เป็นแบบเธรดเดียว สามารถใช้งานได้อย่างมีประสิทธิภาพโดยโปรเซสเซอร์คอร์เดียวเท่านั้นภายใต้โหลด จากนั้น เราได้ปรับใช้อินสแตนซ์ Tarantool จำนวนสูงสุดที่เป็นไปได้ในแต่ละเซิร์ฟเวอร์ เปิดโหลด และได้รับธุรกรรม 14,5 พันรายการต่อวินาทีแล้ว
ให้ฉันอธิบายอีกครั้ง เนื่องจากการแบ่งออกเป็นบทบาทที่ใช้ทรัพยากรแตกต่างกัน บทบาทของเราที่รับผิดชอบในการประมวลผลการเชื่อมต่อและการแปลงข้อมูลจะโหลดเฉพาะตัวประมวลผลเท่านั้น และเป็นสัดส่วนกับโหลดอย่างเคร่งครัด
ในกรณีนี้ หน่วยความจำถูกใช้สำหรับการประมวลผลการเชื่อมต่อขาเข้าและอ็อบเจ็กต์ชั่วคราวเท่านั้น
ในทางตรงกันข้าม บนเซิร์ฟเวอร์จัดเก็บข้อมูล โหลดตัวประมวลผลเพิ่มขึ้น แต่ช้ากว่าบนเซิร์ฟเวอร์ที่ประมวลผลการเชื่อมต่อมาก
และการใช้หน่วยความจำก็เพิ่มขึ้นตามสัดส่วนโดยตรงกับปริมาณข้อมูลที่โหลด
บริการ
ในการพัฒนาผลิตภัณฑ์ใหม่ของเราโดยเฉพาะเป็นแพลตฟอร์มแอปพลิเคชัน เราได้สร้างส่วนประกอบสำหรับการปรับใช้บริการและไลบรารีบนนั้น
บริการไม่ใช่เพียงโค้ดชิ้นเล็กๆ ที่ทำงานในบางฟิลด์ อาจมีโครงสร้างที่ค่อนข้างใหญ่และซับซ้อนซึ่งเป็นส่วนหนึ่งของคลัสเตอร์ ตรวจสอบข้อมูลอ้างอิง รันตรรกะทางธุรกิจ และส่งคืนการตอบกลับ นอกจากนี้เรายังส่งออกสคีมาบริการไปยัง GraphQL และผู้บริโภคจะได้รับจุดเข้าถึงข้อมูลที่เป็นสากล พร้อมการพิจารณาทบทวนโมเดลทั้งหมด มันสะดวกสบายมาก
เนื่องจากบริการต่างๆ มีฟังก์ชันต่างๆ มากมาย เราจึงตัดสินใจว่าควรมีไลบรารีที่เราจะย้ายโค้ดที่ใช้บ่อย เราได้เพิ่มพวกมันเข้าไปในสภาพแวดล้อมที่ปลอดภัย โดยได้ตรวจสอบก่อนหน้านี้แล้วว่ามันไม่ทำลายสิ่งใดสำหรับเรา และตอนนี้เราสามารถกำหนดสภาพแวดล้อมเพิ่มเติมให้กับฟังก์ชันต่างๆ ในรูปแบบของไลบรารีได้
เราต้องการที่จะมีแพลตฟอร์มที่ไม่เพียงแต่สำหรับการจัดเก็บข้อมูลเท่านั้น แต่ยังสำหรับการประมวลผลด้วย และเนื่องจากเรามีแบบจำลองและชิ้นส่วนจำนวนมากอยู่แล้ว เราจึงใช้การประมวลผลแบบกระจาย และเรียกมันว่าการลดแผนที่ เพราะมันดูคล้ายกับการลดแผนที่ดั้งเดิม
ระบบเก่า
ระบบเดิมของเราบางระบบไม่สามารถโทรหาเราผ่าน HTTP และใช้ GraphQL ได้ แม้ว่าจะรองรับโปรโตคอลก็ตาม ดังนั้นเราจึงสร้างกลไกที่ช่วยให้สามารถจำลองข้อมูลเข้าสู่ระบบเหล่านี้ได้
หากมีการเปลี่ยนแปลงบางอย่างสำหรับเรา ทริกเกอร์เฉพาะจะถูกทริกเกอร์ในบทบาทพื้นที่จัดเก็บข้อมูล และข้อความที่มีการเปลี่ยนแปลงจะจบลงในคิวการประมวลผล ถูกส่งไปยังระบบภายนอกโดยใช้บทบาทตัวจำลองแบบแยกกัน บทบาทนี้ไม่ได้จัดเก็บสถานะ
การปรับปรุงใหม่
อย่างที่คุณจำได้ จากมุมมองทางธุรกิจ เราได้บันทึกแบบอะซิงโครนัส แต่แล้วพวกเขาก็ตระหนักว่ามันไม่เพียงพอ เนื่องจากมีคลาสของระบบที่ต้องได้รับการตอบกลับทันทีเกี่ยวกับสถานะของการดำเนินการ ดังนั้นเราจึงขยาย GraphQL ของเราและเพิ่มการกลายพันธุ์ พวกมันเข้ากันได้ดีกับกระบวนทัศน์การทำงานกับข้อมูลที่มีอยู่ สำหรับเรา นี่เป็นเพียงจุดเดียวของทั้งการอ่านและการเขียนสำหรับระบบประเภทอื่น
นอกจากนี้เรายังตระหนักด้วยว่าบริการเพียงอย่างเดียวไม่เพียงพอสำหรับเรา เนื่องจากมีรายงานที่ค่อนข้างหนักซึ่งจำเป็นต้องสร้างวันละครั้ง สัปดาห์ เดือน การดำเนินการนี้อาจใช้เวลานาน และรายงานยังสามารถบล็อกลูปเหตุการณ์ของ Tarantool ได้อีกด้วย ดังนั้นเราจึงสร้างบทบาทที่แยกจากกัน: ผู้จัดตารางเวลาและนักวิ่ง นักวิ่งไม่เก็บสถานะ พวกเขาทำงานหนักซึ่งเราไม่สามารถคำนวณได้ทันที และบทบาทผู้จัดกำหนดการจะตรวจสอบกำหนดการเปิดตัวของงานเหล่านี้ ซึ่งอธิบายไว้ในการกำหนดค่า งานต่างๆ จะถูกจัดเก็บไว้ในที่เดียวกับข้อมูลทางธุรกิจ เมื่อถึงเวลาที่เหมาะสม ผู้จัดกำหนดการจะรับภารกิจนั้น มอบให้นักวิ่ง เป็นผู้นับและบันทึกผลลัพธ์
งานบางอย่างไม่จำเป็นต้องดำเนินการตามกำหนดเวลา รายงานบางฉบับจำเป็นต้องอ่านตามความต้องการ ทันทีที่ข้อกำหนดนี้มาถึง งานจะถูกสร้างขึ้นในแซนด์บ็อกซ์และส่งไปยังนักวิ่งเพื่อดำเนินการ หลังจากนั้นครู่หนึ่ง ผู้ใช้จะได้รับการตอบสนองแบบอะซิงโครนัสว่าทุกอย่างได้รับการคำนวณแล้วและรายงานก็พร้อมแล้ว
ในตอนแรก เราปฏิบัติตามกระบวนทัศน์ของการจัดเก็บข้อมูลทั้งหมด การกำหนดเวอร์ชัน และไม่ลบข้อมูล แต่ในชีวิตในบางครั้งคุณยังคงต้องลบบางสิ่งซึ่งส่วนใหญ่เป็นข้อมูลดิบหรือข้อมูลกลาง ตามการหมดอายุ เราได้สร้างกลไกในการล้างพื้นที่เก็บข้อมูลจากข้อมูลที่ล้าสมัย
นอกจากนี้เรายังเข้าใจด้วยว่าไม่ช้าก็เร็วสถานการณ์จะเกิดขึ้นเมื่อพื้นที่ไม่เพียงพอที่จะจัดเก็บข้อมูลในหน่วยความจำ แต่อย่างไรก็ตามข้อมูลจะต้องถูกเก็บไว้ เพื่อวัตถุประสงค์เหล่านี้ เราจะสร้างที่เก็บข้อมูลบนดิสก์เร็วๆ นี้
ข้อสรุป
เราเริ่มต้นด้วยงานโหลดข้อมูลลงในโมเดลเดียวและใช้เวลาสามเดือนในการพัฒนามัน เรามีระบบการจัดหาข้อมูลหกระบบ โค้ดการแปลงทั้งหมดเป็นโมเดลเดียวมีประมาณ 30 บรรทัดใน Lua และงานส่วนใหญ่ยังรออยู่ข้างหน้า บางครั้งขาดแรงจูงใจจากทีมเพื่อนบ้าน และมีหลายสถานการณ์ที่ทำให้งานยุ่งยาก หากคุณเคยเผชิญกับงานที่คล้ายกัน ให้คูณเวลาที่ดูเหมือนปกติสำหรับคุณในการดำเนินการด้วยสามหรือสี่ครั้ง
โปรดจำไว้ว่าปัญหาที่มีอยู่ในกระบวนการทางธุรกิจไม่สามารถแก้ไขได้โดยใช้ DBMS ใหม่ แม้จะเป็นปัญหาที่มีประสิทธิผลมากก็ตาม สิ่งที่ผมหมายถึง? ในช่วงเริ่มต้นของโครงการ เราสร้างความประทับใจให้กับลูกค้าว่าตอนนี้เราจะนำฐานข้อมูลที่รวดเร็วใหม่และเราจะมีชีวิตอยู่! กระบวนการต่างๆจะเร็วขึ้นทุกอย่างจะเรียบร้อยดี ในความเป็นจริง เทคโนโลยีไม่ได้แก้ปัญหาที่กระบวนการทางธุรกิจมี เนื่องจากกระบวนการทางธุรกิจคือคน และคุณต้องทำงานร่วมกับผู้คน ไม่ใช่เทคโนโลยี
การพัฒนาที่ขับเคลื่อนด้วยการทดสอบอาจสร้างความเจ็บปวดและใช้เวลานานในระยะแรก แต่ผลเชิงบวกของสิ่งนี้จะเห็นได้ชัดเจนแม้ในระยะสั้น เมื่อคุณไม่จำเป็นต้องทำอะไรเพื่อทำการทดสอบการถดถอย
เป็นสิ่งสำคัญอย่างยิ่งที่ต้องทำการทดสอบโหลดในทุกขั้นตอนของการพัฒนา ยิ่งคุณสังเกตเห็นข้อบกพร่องในสถาปัตยกรรมได้เร็วเท่าไร ก็จะยิ่งแก้ไขได้ง่ายขึ้นเท่านั้น ซึ่งจะช่วยคุณประหยัดเวลาได้มากในอนาคต
ไม่มีอะไรผิดปกติกับ Lua ใครๆ ก็สามารถเรียนรู้ที่จะเขียนมันได้: นักพัฒนา Java, นักพัฒนา JavaScript, นักพัฒนา Python, ส่วนหน้าหรือส่วนหลัง แม้แต่นักวิเคราะห์ของเราก็ยังเขียนถึงเรื่องนี้
เมื่อเราพูดถึงความจริงที่ว่าเราไม่มี SQL มันทำให้ผู้คนหวาดกลัว “คุณจะได้รับข้อมูลโดยไม่มี SQL ได้อย่างไร? เป็นไปได้ไหม? แน่นอน. ในระบบคลาส OLTP ไม่จำเป็นต้องใช้ SQL มีทางเลือกอื่นในรูปแบบของภาษาบางประเภทที่จะนำคุณกลับสู่มุมมองเชิงเอกสารทันที ตัวอย่างเช่น GraphQL และมีทางเลือกอื่นในรูปแบบของการคำนวณแบบกระจาย
หากคุณเข้าใจว่าคุณจะต้องขยายขนาด ให้ออกแบบโซลูชันของคุณบน Tarantool ในลักษณะที่สามารถทำงานคู่ขนานกับอินสแตนซ์ของ Tarantool หลายสิบรายการได้ หากคุณไม่ทำเช่นนี้ มันจะยากและเจ็บปวดในภายหลัง เนื่องจาก Tarantool สามารถใช้โปรเซสเซอร์คอร์เดียวได้อย่างมีประสิทธิภาพเท่านั้น
ที่มา: will.com