ในหน่วยความจำคือชุดแนวคิดสำหรับการจัดเก็บข้อมูลเมื่อจัดเก็บไว้ใน RAM ของแอปพลิเคชัน และใช้ดิสก์ในการสำรองข้อมูล ในแนวทางคลาสสิก ข้อมูลจะถูกจัดเก็บไว้ในดิสก์และหน่วยความจำจะถูกจัดเก็บไว้ในแคช ตัวอย่างเช่น เว็บแอปพลิเคชันที่มีแบ็กเอนด์สำหรับการประมวลผลข้อมูลจะร้องขอแอปพลิเคชันดังกล่าวไปยังพื้นที่จัดเก็บข้อมูล โดยจะรับ แปลงข้อมูล และข้อมูลจำนวนมากจะถูกถ่ายโอนผ่านเครือข่าย ในหน่วยความจำในหน่วยความจำ การคำนวณจะถูกส่งไปยังข้อมูล - ไปยังพื้นที่จัดเก็บข้อมูล ซึ่งมีการประมวลผลและมีการโหลดเครือข่ายน้อยลง
In-Memory มีความเป็นไปได้อื่นใดอีกบ้าง และนี่เป็นแนวทางประเภทใด วลาดิมีร์ พลิกิน - วิศวกรที่ GridGain เอกสารการทบทวนนี้จะเป็นประโยชน์สำหรับนักพัฒนาแบ็กเอนด์เว็บแอปพลิเคชันที่ไม่ได้ทำงานกับ In-Memory และต้องการลอง หรือสนใจในแนวโน้มสมัยใหม่ในการพัฒนาซอฟต์แวร์และการออกแบบสถาปัตยกรรม
หมายเหตุ. บทความนี้อิงตามสำเนารายงานของ Vladimir ที่ #GetIT Conf ก่อนที่จะเริ่มใช้การแยกตนเอง เราได้จัดพบปะและการประชุมสำหรับนักพัฒนาในมอสโกและเซนต์ปีเตอร์สเบิร์กเป็นประจำ: เราได้พูดคุยถึงแนวโน้ม ปัญหาการพัฒนาในปัจจุบัน ปัญหา และแนวทางแก้ไข ขณะนี้ยังจัดการประชุมไม่ได้ แต่ถึงเวลาแบ่งปันเนื้อหาที่เป็นประโยชน์จากการประชุมครั้งก่อนๆ
ใครใช้ In-Memory และอย่างไร
In-Memory มักใช้เมื่อผู้ใช้ต้องโต้ตอบหรือประมวลผลข้อมูลจำนวนมากอย่างรวดเร็ว
- ธนาคาร ใช้ In-Memory เช่น เพื่อลดความล่าช้าเมื่อลูกค้าใช้แอปพลิเคชัน หรือเพื่อวิเคราะห์ลูกค้าก่อนที่จะออกเงินกู้
- Fintech ใช้ In-Memory เพื่อปรับปรุงประสิทธิภาพของบริการและแอปพลิเคชันสำหรับธนาคารที่จ้างบุคคลภายนอกในการประมวลผลและวิเคราะห์ข้อมูล
- บริษัท ประกันภัย: เพื่อคำนวณความเสี่ยง เช่น โดยการวิเคราะห์ข้อมูลลูกค้าในช่วงหลายปีที่ผ่านมา
- บริษัทโลจิสติกส์. พวกเขาประมวลผลข้อมูลจำนวนมาก เช่น เพื่อคำนวณเส้นทางที่เหมาะสมที่สุดสำหรับการขนส่งสินค้าและการขนส่งสินค้าผู้โดยสารด้วยพารามิเตอร์หลายพันรายการ และติดตามสถานะของการจัดส่ง
- ขายปลีก. โซลูชันในหน่วยความจำช่วยให้บริการลูกค้าได้เร็วยิ่งขึ้นและประมวลผลข้อมูลจำนวนมาก เช่น การจัดส่ง ใบแจ้งหนี้ ธุรกรรม การมีอยู่ของสินค้าหลายพันรายการในคลังสินค้า และการเตรียมรายงานการวิเคราะห์
- В IoT In-Memory เข้ามาแทนที่ฐานข้อมูลแบบเดิม
- เภสัชกรรม บริษัทต่างๆ ใช้ In-Memory เพื่อจัดเรียงส่วนผสมของยา
ฉันจะบอกคุณตัวอย่างบางส่วนว่าลูกค้าของเราใช้โซลูชัน In-Memory อย่างไร และคุณสามารถนำไปใช้ด้วยตนเองได้อย่างไร
ในหน่วยความจำเป็นที่เก็บข้อมูลหลัก
ลูกค้ารายหนึ่งของเราคือซัพพลายเออร์อุปกรณ์วิทยาศาสตร์ทางการแพทย์รายใหญ่จากประเทศสหรัฐอเมริกา พวกเขาใช้โซลูชัน In-Memory เป็นที่จัดเก็บข้อมูลหลัก ข้อมูลทั้งหมดจะถูกจัดเก็บไว้ในดิสก์ และชุดย่อยของข้อมูลที่ใช้งานอยู่จะถูกเก็บไว้ใน RAM วิธีการเข้าถึงที่เก็บข้อมูลเป็นแบบมาตรฐาน - GDBC (ตัวเชื่อมต่อฐานข้อมูลทั่วไป) และภาษาคิวรี SQL
เรียกรวมกันว่า In-Memory Database (IMDB) หรือ Memory-Centric Storage โซลูชันประเภทนี้มีหลายชื่อ ซึ่งไม่ใช่ชื่อเดียวเท่านั้น
คุณสมบัติของไอเอ็มดีบี:
- ข้อมูลที่เก็บอยู่ใน In-Memory และเข้าถึงผ่าน SQL จะเหมือนกับข้อมูลในวิธีอื่นๆ พวกมันประสานกัน มีเพียงวิธีการนำเสนอเท่านั้น วิธีการจัดการกับมันแตกต่างออกไป การทำธุรกรรมทำงานระหว่างข้อมูล
- IMDB เร็วกว่าฐานข้อมูลเชิงสัมพันธ์เนื่องจากดึงข้อมูลจาก RAM ได้เร็วกว่าจากดิสก์
- อัลกอริธึมการเพิ่มประสิทธิภาพภายในมีคำแนะนำน้อยกว่า
- IMDB เหมาะสำหรับการจัดการข้อมูล กิจกรรม และธุรกรรมในแอปพลิเคชัน
IMDB รองรับ ACID บางส่วน: ความเป็นอะตอมมิก ความสม่ำเสมอ และการแยกตัว แต่ไม่รองรับ "ความทนทาน" - เมื่อปิดเครื่อง ข้อมูลทั้งหมดจะสูญหาย ในการแก้ปัญหา คุณสามารถใช้สแน็ปช็อต - "สแน็ปช็อต" ของฐานข้อมูล ซึ่งคล้ายกับการสำรองฐานข้อมูลบนฮาร์ดไดรฟ์ หรือบันทึกธุรกรรม (บันทึก) เพื่อกู้คืนข้อมูลหลังจากรีบูต
เพื่อสร้างแอปพลิเคชันที่ทนทานต่อข้อผิดพลาด
ลองจินตนาการถึงสถาปัตยกรรมคลาสสิกของเว็บแอปพลิเคชันที่ทนทานต่อข้อผิดพลาด มันทำงานดังนี้: คำขอทั้งหมดได้รับการแจกจ่ายโดยเว็บบาลานเซอร์ระหว่างเซิร์ฟเวอร์ ระบบนี้มีความเสถียรเนื่องจากเซิร์ฟเวอร์ทำซ้ำกันและสำรองข้อมูลในกรณีที่เกิดเหตุการณ์
บาลานเซอร์ส่งคำขอทั้งหมดจากเซสชันหนึ่งไปยังเซิร์ฟเวอร์เดียวอย่างเคร่งครัด นี่คือกลไกเซสชันแบบแท่ง: แต่ละเซสชันเชื่อมโยงกับเซิร์ฟเวอร์ที่จัดเก็บและประมวลผลในเครื่อง
จะเกิดอะไรขึ้นเมื่อหนึ่งในเซิร์ฟเวอร์ล้มเหลว?
บริการจะไม่ได้รับผลกระทบเนื่องจากมีการทำซ้ำสถาปัตยกรรม แต่เราจะสูญเสียเซ็ตย่อยของเซสชันของเซิร์ฟเวอร์ที่ไม่ทำงาน. และในเวลาเดียวกัน ผู้ใช้ที่เชื่อมโยงกับเซสชันเหล่านี้ ตัวอย่างเช่น ลูกค้าสั่งซื้อสินค้าแล้วจู่ๆ ก็ไล่เขาออกจากออฟฟิศ เขาจะไม่มีความสุขเมื่อเข้าสู่ระบบอีกครั้งและพบว่าทุกอย่างจะต้องทำอีกครั้ง
จำเป็นต้องมีเว็บแอปพลิเคชันเพื่อรองรับผู้ใช้จำนวนมากและไม่ช้าลงเพื่อให้สามารถทำงานได้อย่างสะดวกสบาย แต่หากถูกปฏิเสธ แต่ละคำขอที่ตามมาจะใช้เวลาในการสื่อสารกับที่เก็บเซสชันจะเพิ่มขึ้น สิ่งนี้จะเพิ่มเวลาแฝงโดยเฉลี่ยสำหรับผู้ใช้รายอื่น แต่พวกเขาไม่ต้องการรอนานกว่าปกติ
ปัญหานี้สามารถแก้ไขได้เช่นเดียวกับลูกค้ารายอื่นของเรา ซึ่งเป็นผู้ให้บริการ PASS รายใหญ่จากสหรัฐอเมริกา ใช้ In-Memory เพื่อจัดกลุ่มเซสชันเว็บ ในการดำเนินการนี้ ระบบจะไม่ได้จัดเก็บข้อมูลเหล่านั้นไว้ในเครื่อง แต่เก็บไว้ที่ส่วนกลางในคลัสเตอร์ In-Memory ในกรณีนี้ เซสชันจะพร้อมใช้งานเร็วขึ้นมากเนื่องจากมีอยู่ใน RAM อยู่แล้ว
เมื่อเซิร์ฟเวอร์ขัดข้อง บาลานเซอร์จะส่งคำขอจากเซิร์ฟเวอร์ที่ขัดข้องไปยังเซิร์ฟเวอร์อื่น เช่นเดียวกับในสถาปัตยกรรมคลาสสิก แต่มีความแตกต่างที่สำคัญ: เซสชันจะถูกจัดเก็บไว้ในคลัสเตอร์ในหน่วยความจำ และเซิร์ฟเวอร์สามารถเข้าถึงเซสชันของเซิร์ฟเวอร์ที่ล่มได้
สถาปัตยกรรมนี้เพิ่มความทนทานต่อข้อผิดพลาดของทั้งระบบ ยิ่งไปกว่านั้น ยังสามารถละทิ้งกลไกเซสชันแบบแท่งไปได้เลย
การประมวลผลการวิเคราะห์ธุรกรรมแบบไฮบริด (HTAP)
โดยปกติแล้ว ระบบธุรกรรมและการวิเคราะห์จะถูกแยกออกจากกัน เมื่อแยกออกจากกัน ฐานหลักจะรับภาระ สำหรับการประมวลผลเชิงวิเคราะห์ ข้อมูลจะถูกคัดลอกไปยังแบบจำลองเพื่อให้การประมวลผลเชิงวิเคราะห์ไม่รบกวนกระบวนการทางธุรกรรม แต่การคัดลอกเกิดขึ้นพร้อมกับความล่าช้า ซึ่งเป็นไปไม่ได้ที่จะทำซ้ำโดยไม่ล่าช้า หากเราทำสิ่งนี้พร้อมกัน มันจะทำให้ฐานหลักช้าลงและเราจะไม่ได้รับรางวัลใดๆ
ใน HTAP ทุกอย่างทำงานแตกต่างออกไป - ใช้ที่เก็บข้อมูลเดียวกันสำหรับการโหลดธุรกรรมจากแอปพลิเคชัน และสำหรับการสืบค้นเชิงวิเคราะห์ที่อาจใช้เวลานานในการดำเนินการให้เสร็จสมบูรณ์ เมื่อข้อมูลอยู่ใน RAM การสืบค้นเชิงวิเคราะห์จะดำเนินการเร็วขึ้น และเซิร์ฟเวอร์ที่มีฐานข้อมูลจะถูกโหลดน้อยลง (โดยเฉลี่ย)
แนวทางแบบไฮบริดทลายกำแพงระหว่างการประมวลผลธุรกรรมและการวิเคราะห์ หากเราทำการวิเคราะห์บนพื้นที่จัดเก็บข้อมูลเดียวกัน การสืบค้นเชิงวิเคราะห์จะถูกเรียกใช้กับข้อมูลจาก RAM มีความแม่นยำมากกว่า ตีความได้ง่ายกว่า และเพียงพอมากกว่ามาก
การบูรณาการโซลูชันในหน่วยความจำ
วิธีง่ายๆ (ค่อนข้าง) - พัฒนาทุกอย่างตั้งแต่เริ่มต้น. เราเก็บข้อมูลไว้ในดิสก์และจัดเก็บข้อมูลร้อนไว้ในหน่วยความจำ ซึ่งจะช่วยให้เซิร์ฟเวอร์สามารถรีบูตหรือไฟดับได้
มีสองสถานการณ์หลักในที่ทำงานที่นี่เมื่อข้อมูลถูกจัดเก็บไว้ในดิสก์ ในตอนแรก เราต้องการเอาตัวรอดจากการแครชหรือการรีบูตคลัสเตอร์หรือชิ้นส่วนเป็นประจำ - เราต้องการใช้เป็นฐานข้อมูลอย่างง่าย ในสถานการณ์ที่สอง เมื่อมีข้อมูลมากเกินไป บางส่วนจะอยู่ในหน่วยความจำ
หากไม่สามารถสร้างทุกอย่างตั้งแต่เริ่มต้นได้ ก็เป็นไปได้ที่จะรวม In-Memory เข้ากับสิ่งที่มีอยู่แล้ว สถาปัตยกรรมที่มีอยู่. แต่ไม่ใช่ว่าโซลูชันในหน่วยความจำทั้งหมดจะเหมาะกับสิ่งนี้ มีเงื่อนไขบังคับสามประการ โซลูชันในหน่วยความจำต้องรองรับ:
- วิธีมาตรฐานในการเชื่อมต่อกับฐานข้อมูลที่จะอยู่ใต้ฐานข้อมูล (เช่น MySQL)
- ภาษาคิวรีมาตรฐานเพื่อไม่ให้เขียนซ้ำและเปลี่ยนตรรกะของการโต้ตอบกับที่เก็บข้อมูล
- การทำธุรกรรม - รักษาความหมายของการโต้ตอบ
หากตรงตามเงื่อนไขทั้งสามข้อ ก็สามารถบูรณาการได้ เราวาง In-Memory Data Grid ระหว่างแอปพลิเคชันและฐานข้อมูล ตอนนี้คำขอเขียนจะถูกมอบหมายให้กับฐานข้อมูลพื้นฐาน และคำขออ่านจะถูกมอบหมายให้กับฐานข้อมูลพื้นฐานหากข้อมูลไม่อยู่ในแคช
หากการเข้าถึงข้อมูลอย่างรวดเร็วและการประมวลผลข้อมูลมีความสำคัญสำหรับคุณ เช่น สำหรับการวิเคราะห์ธุรกิจ คุณสามารถคิดถึงการนำ In-Memory ไปใช้ และสำหรับการนำไปปฏิบัติ คุณสามารถใช้ทั้งสองวิธีในการออกแบบสถาปัตยกรรมใหม่ได้
ที่มา: will.com