แหล่งข้อมูลใดดีที่สุดสำหรับสถานการณ์ของฉัน


10

ฉันกำลังทำงานกับแอปพลิเคชันที่เกี่ยวข้องกับการเรียกใช้คิวรีแบบเลือกใช้ / อัปเดตในฐานข้อมูล

ฉันมีตารางฐาน (A) ซึ่งจะมีระเบียนประมาณ 500 รายการสำหรับหนึ่งวัน และสำหรับผู้ใช้ทุกคนในระบบรูปแบบของเอนทิตีนี้จะถูกสร้างขึ้นตามการตั้งค่าบางอย่างของผู้ใช้และพวกเขาจะถูกเก็บไว้ในตารางอื่น (B) ทำได้โดยงาน cron ที่ทำงานตอนเที่ยงคืนทุกวัน

ดังนั้นหากมี 10,000 ผู้ใช้และ 500 บันทึกในตาราง A จะมีระเบียน 5M ในตาราง B สำหรับวันนั้น ฉันมักจะเก็บข้อมูลเป็นเวลาหนึ่งวันในตารางเหล่านี้และในเวลาเที่ยงคืนฉันจะเก็บข้อมูลประวัติเพื่อ HBase การตั้งค่านี้ทำงานได้ดีและฉันไม่มีปัญหาด้านประสิทธิภาพมาก่อน

มีการเปลี่ยนแปลงข้อกำหนดทางธุรกิจเมื่อไม่นานมานี้และตอนนี้คุณลักษณะบางอย่างในตารางฐาน A (สำหรับ 15 - 20 บันทึก) จะเปลี่ยนทุก ๆ 20 วินาทีและขึ้นอยู่กับว่าฉันต้องคำนวณค่าบางอย่างสำหรับบันทึกชุดรูปแบบทั้งหมดในตาราง B สำหรับ ผู้ใช้ทั้งหมด. แม้ว่าจะมีการเปลี่ยนแปลงเรคคอร์ดหลักเพียง 20 รายการ แต่ฉันต้องทำการคำนวณใหม่และอัปเดตระเบียนผู้ใช้ 200,000 รายการซึ่งใช้เวลามากกว่า 20 วินาทีจากนั้นการอัปเดตครั้งต่อไปก็เกิดขึ้นในที่สุดจึงทำให้คิวรี Select ทั้งหมดเริ่มคิว ฉันได้รับคำขอประมาณ 3 ครั้ง / 5 วินาทีจากผู้ใช้ออนไลน์ซึ่งผลใน 6-9 เลือกข้อความค้นหา เพื่อตอบสนองต่อคำขอ API ฉันมักจะใช้เขตข้อมูลในตาราง B

ฉันสามารถซื้อพลังการประมวลผลเพิ่มเติมและแก้ไขสถานการณ์นี้ แต่ฉันสนใจที่จะมีระบบที่ปรับขนาดได้อย่างเหมาะสมซึ่งสามารถรองรับผู้ใช้กว่าล้านคน

ใครช่วยแนะนำทางเลือกที่ดีกว่านี้ได้ไหม ฐานข้อมูลเชิงสัมพันธ์ nosql + ช่วยฉันได้ไหม มีแพลตฟอร์ม / ดาต้าสโตร์ที่จะให้ฉันอัปเดตข้อมูลบ่อยครั้งโดยไม่ล็อคหรือไม่ในเวลาเดียวกันก็ให้ความยืดหยุ่นในการรันคิวรีแบบเลือกในฟิลด์ต่าง ๆ ในเอนทิตีหรือไม่


คุณต้องการจัดเก็บข้อมูลทั้งหมดหรือไม่? ดูเหมือนว่าคุณจะคำนวณได้ดีกว่า หากคุณสามารถคำนวณระเบียน 200k ในเวลามากกว่า 20 วินาทีคุณควรคำนวณระเบียนเหล่านั้น 20 รายการ * 3 ผู้ใช้ = 60 รายการในเวลาไม่นาน อาจเป็นไปได้ว่าคุณอาจดูว่าผู้ใช้รายใดออนไลน์ในเวลาใดและปรับให้เหมาะสมมากกว่านี้หรือไม่? ดูเหมือนว่าคุณกำลังสร้างข้อมูลจำนวนมากที่ไม่เคยมีใครใช้ (ในช่วงเวลาที่ข้อมูลยังใช้ได้อย่างน้อย)
thorsten müller

การสร้างเฉพาะสำหรับผู้ใช้ที่เข้าสู่ระบบเป็นตัวเลือกที่ดีมาก ฉันก็คิดเกี่ยวกับเรื่องนั้นเหมือนกัน แต่ก็ยังไม่ใช่วิธีที่ปรับขนาดได้ แพลตฟอร์มของฉันจะใช้เฉพาะในช่วงกลางวันและด้วยเหตุนี้ในช่วงเวลานั้นผู้ใช้ส่วนใหญ่จะใช้งานได้ ข้อเสนอแนะอื่น ๆ คู่?
เหยือก

@ เหยือก - ยังคงทิ้งคำถามว่าคุณสามารถคำนวณได้ทันทีหรือไม่ คุณต้องอัปเดตระเบียนหรือแอปพลิเคชันของคุณต้องการข้อมูลที่มีอยู่หรือไม่
Bobson

ฉันเกรงว่าฉันไม่สามารถคำนวณได้ทันทีเนื่องจากตารางรายการ B ถูกจัดอันดับสำหรับผู้ใช้ (5 ดาวถึง 1 ดาว) และหลังจากการคำนวณเหล่านี้เสร็จสิ้นเราจะทำการจัดอันดับอีกครั้งสำหรับผู้ใช้ กระบวนการทั้งหมดสำหรับผู้ใช้ใช้เวลา 500 msecs และถ้าฉันทำได้ทันทีมันจะส่งผลต่อเวลาตอบสนอง API ของเรา
Jugs

ฉันคิดว่ามันสมเหตุสมผลที่จะเก็บคะแนนและการจัดอันดับนอก RDBMS อาจอยู่ใน nosql db ดังนั้นคำสั่งที่เลือกจะยังคงทำงานโดยไม่มีอาการสะอึกใด ๆ อย่างไรก็ตามบางครั้งฉันก็ต้องค้นหาคะแนนและอันดับด้วยเช่นกัน ดังนั้นฉันกำลังหลงทางอยู่ในขณะนี้ซึ่งเป็นสาเหตุที่ฉันกำลังมองหาคำแนะนำจากผู้เชี่ยวชาญบางคนเช่นคุณ
Jugs

คำตอบ:


1

ดูเหมือนว่าตารางBจะเป็นแคชบางประเภท แต่แคชชนิดนั้นทำให้ประสิทธิภาพลดลง ..

แม้ว่าคุณจะมี 25 แบบสอบถามต่อวินาทีคุณสามารถปฏิเสธการใช้งานของตารางBและคำนวณคำตอบสำหรับแต่ละคำขอ

อย่างไรก็ตามถ้าคุณมีความล่าช้า 30 วินาทีในการอัปเดต 20 รายการมันเป็นความล้มเหลวในสถาปัตยกรรมซอฟต์แวร์ (ฉันผิดถ้าฐานข้อมูลของคุณคำนวณสัญญาณ 10 PI แรกของ 100 สำหรับทุกเรกคอร์ด)

ดังที่ฉันทราบแล้วฐานข้อมูลเชิงสัมพันธ์ที่ไม่มี SQL-query ที่น่าเกลียดพร้อมดัชนีและมีน้อยกว่า 1,000,000 ระเบียนจะทำงานได้อย่างสมบูรณ์แบบสำหรับแบบสอบถามเกือบทั้งหมด

พยายามปฏิเสธการใช้ตารางBและเพิ่มดัชนีที่เหมาะสมลงในตารางของคุณA(ฐานข้อมูลที่ทันสมัยส่วนใหญ่มีเครื่องมือช่วยเหลือ) ถัดไป: ลองปรับโครงสร้างของข้อมูล (ตารางA) และแบบสอบถามให้เหมาะสม (ใช้ตัววิเคราะห์แบบสอบถามหรือกับผู้เชี่ยวชาญ SQL) เพื่อเพิ่มความเร็วในการคำนวณ หากคุณจะอัปเดตเพียง 20 รายการการมีอยู่ของดัชนีจะไม่เป็นอันตรายต่อประสิทธิภาพการทำงานของกระบวนการอัปเดตแต่จะปรับปรุงความเร็วในการเลือกอย่างมาก


1

คำถามคือสิ่งที่ระบบคำนวณระเบียนเพื่อแทรกลงใน B และขนาดของข้อมูล B

ฐานข้อมูลใด ๆ (เช่น MSSQL) ควรจะสามารถจัดการกับปริมาณของเม็ดมีดที่คุณกำลังพูดถึงได้โดยไม่มีปัญหาหากมีวัตถุไม่มาก

การอัปเดตอาจเกิดจากปัญหาที่ยากขึ้น แต่ด้วยการจัดทำดัชนีและล็อคที่ถูกต้องอีกครั้งไม่ควรเป็นปัญหาใหญ่

99% ของเวลาที่ฉันเห็นปัญหาเช่นนี้เนื่องจากบันทึก B ถูกคำนวณโดย proc ที่จัดเก็บ สิ่งนี้ทำให้โหลดทั้งหมดบนเซิร์ฟเวอร์ db

หากเป็นกรณีนี้การแก้ปัญหาคือการย้ายรหัสนี้ไปยังบริการออฟไลน์ซึ่งสามารถเรียกผ่านระบบการจัดคิว

ดังนั้นการอัพเดตข้อความของคุณจะทริกเกอร์กระบวนการผู้ปฏิบัติงานซึ่งจะวนซ้ำผู้ใช้และสร้างข้อความอัปเดต B สำหรับผู้ใช้แต่ละคน

กระบวนการของผู้ปฏิบัติงานที่สอง B จะรับการอัปเดต User X ด้วยข้อมูลเหตุการณ์สร้างระเบียน B และอัปเดตฐานข้อมูล

สิ่งนี้สามารถปรับขนาดได้โดยการเพิ่มกล่องที่มีคนทำงานคิวไว้มากขึ้นดังนั้นคุณจึงมีกำลังการประมวลผลมากขึ้นเรื่อย ๆ ที่อยู่เบื้องหลังการคำนวณปล่อยให้ db ของคุณว่างเพื่อให้มีสมาธิกับการอัพเดตและการเลือก

คุณสามารถปรับให้เหมาะสมต่อไปโดยแยกการเลือกจากการปรับปรุง / แทรก มีฐานข้อมูลใหม่ที่ได้รับการร้องขอที่เลือกทั้งหมดเป็นแบบจำลองทาสฐานข้อมูลเก่าซึ่งได้รับการปรับปรุงทั้งหมด


0

หากคุณกำลังทำงานในอเมซอนฉันจะพิจารณา DynamoDB มันขึ้นอยู่กับหน่วยความจำแฟลช นี่คือลิงค์ไป: https://aws.amazon.com/dynamodb/

คุณใช้ RDBMS ประเภทใด คุณอาจเพิ่มประสิทธิภาพได้โดยใช้ UDF หรือเขตข้อมูลจากการคำนวณในมุมมอง คุณกำลังเรียกใช้การคำนวณในฐานข้อมูลผ่านแบบสอบถามแบบใช้ครั้งเดียวหรือคุณเลือกข้อมูลออกจากฐานข้อมูลเรียกใช้การคำนวณในกระบวนการอื่นแล้วโหลดกลับเข้ามาหรือไม่

Oracle ได้รับการกำหนดค่าตามค่าเริ่มต้นเพื่อใช้การดำเนินการในโหมดสแนปชอตหมายความว่าแถวจะไม่ถูกล็อคระหว่างการอัปเดตและการเลือกพร้อมกันจะได้รับค่าดั้งเดิม SQL Server มีการกำหนดค่าตามค่าเริ่มต้นพร้อม ๆ กันในแง่ร้ายดังนั้นการเลือกพร้อมกันจะถูกบล็อกจนกว่าการปรับปรุงจะเสร็จสมบูรณ์ SQL Server บางเวอร์ชันสามารถใส่ในโหมด snapshot ได้ แต่จะเพิ่มความเค้นบนโต๊ะอุณหภูมิ

สภาพแวดล้อมแบบใดที่คุณใช้อยู่ หากเป็น RDBMS ในอินสแตนซ์ EC2 ใน Amazon ให้ลองวางดาต้าไทล์ DB ลงในดิสก์แฟลชภายใน ฉันเห็นลำดับความแตกต่างในการย้ายไฟล์จาก EBS ไปยังดิสก์ภายในเครื่อง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.