การสำรองข้อมูลเว็บไซต์โดย cube OLAP ของ SQL Server 2012 ถือว่าสมเหตุสมผลหรือไม่

ฉันได้รับมอบหมายให้ออกแบบสถาปัตยกรรมสำหรับโซลูชั่นค้าปลีกขนาดใหญ่ พวกเขาต้องการอนุญาตให้ลูกค้า 1.2 ล้านคนแต่ละคนเข้าสู่ระบบเว็บไซต์เพื่อดูการกระจายของการซื้อสินค้าล่าสุด (เดือนปัจจุบันเดือนก่อนหน้าปีต่อปี) มากกว่า 50 หมวดหมู่ ข้อมูลจะถูกอัปเดตทุกวัน

ฉันกำลังคิดที่จะวาง OLAP cube ที่ใช้ SQL Server 2012 และให้เว็บไซต์สอบถามคิวบ์นี้โดยตรงใช้ประโยชน์จากคุณสมบัติเช่นการแคชเชิงรุก อย่างไรก็ตามในฐานะนักพัฒนาซอฟต์แวร์ฉันไม่มีประสบการณ์กับส่วนวิเคราะห์บริการของ SQL Server ดังนั้นฉันค่อนข้างกังวลเกี่ยวกับประสิทธิภาพของโซลูชันนี้

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

ฉันไม่คาดหวังให้ผู้ใช้ตรวจสอบสถานะของพวกเขาบ่อยนักและแน่นอนว่าฉันจะใช้แคชกับเว็บเซิร์ฟเวอร์ ฯลฯ

คุณสามารถทำได้ด้วยระบบ OLAP ประโยชน์บางประการของ SSAS สำหรับแอปพลิเคชันประเภทนี้ ได้แก่ :

• SSAS สามารถปรับขนาดได้อย่างง่ายดายโดยเฉพาะอย่างยิ่งเนื่องจากเป็นแอปพลิเคชันแบบอ่านอย่างเดียวโดยไม่มีข้อกำหนดสำหรับการเขียนข้อมูลแบบคิวบ์

• การรวมสามารถปรับแต่งเพื่อลด I / O ให้สามารถปรับลูกบาศก์ได้อย่างมีประสิทธิภาพ

• ซอฟต์แวร์ไคลเอนต์ OLAP และการควบคุมโดยบุคคลที่สาม (เว็บและไคลเอนต์รวย) นั้นหาได้ง่ายจากผู้ขายหลายราย

• SQL Server 2012 Business Intelligence edition มีคุณลักษณะความสามารถในการปรับขนาดได้มากสำหรับ SSAS ดังนั้นจึงสามารถใช้เป็นแพลตฟอร์มที่ประหยัดต้นทุนสำหรับคิวบ์ด้านหน้าสำหรับฐานข้อมูล Enterprise Edition (หรือบุคคลที่สาม) ของ SQL Server โปรดทราบว่าการให้สิทธิ์ใช้งานอาจเป็นปัญหาสำหรับกรณีนี้เนื่องจาก BI edition เป็น CAL เท่านั้น

• SSAS มีฟังก์ชั่นการขุดข้อมูลที่สามารถใช้ในการวิเคราะห์ตะกร้าสินค้าบนข้อมูลและฟีดคุณสมบัติ 'การซื้อที่แนะนำ' บนเว็บไซต์

ในทางตรงกันข้ามความต้องการคือการแสดงชุดข้อมูลที่ค่อนข้าง จำกัด ดังนั้นความสามารถในการหั่นและลูกเต๋าของเซิร์ฟเวอร์ OLAP อาจเกินความจำเป็นทั้งในด้านค่าใช้จ่ายซอฟต์แวร์และค่าใช้จ่ายของโครงสร้างพื้นฐานด้านฮาร์ดแวร์ที่จะเรียกใช้ ( SSAS ค่อนข้างหิวทรัพยากร) คุณอาจจะสามารถบรรลุความต้องการของคุณได้ทันทีด้วยฐานข้อมูลสรุปที่รีเฟรชเป็นระยะและทำได้โดยลดค่าใช้จ่ายด้านฮาร์ดแวร์และใบอนุญาต

จากภาพรวมแรกฉันขอแนะนำ OLAP อาจไม่จำเป็นต้องตอบสนองความต้องการที่มีอยู่ของคุณ อย่างไรก็ตามวิธีนี้สามารถทำได้อย่างแน่นอนและคุณอาจได้รับไมล์สะสมจากฟีเจอร์ data mining เพื่อมอบคุณสมบัติ 'การซื้อที่แนะนำ'

SSAS เป็นหัวข้อที่เนื้อมาก แทบไม่มีสิ่งใดที่คุณรู้เกี่ยวกับเอ็นจิ้นฐานข้อมูลที่สามารถใช้กับ Analysis Services ได้ หากเป้าหมายเพียงอย่างเดียวคือให้บริการแบ็คเอนด์สำหรับรายงานนี้การเพิ่มความเร็วในการวิเคราะห์บริการและการใช้ฐานข้อมูล OLAP จะเป็นค่าใช้จ่ายที่ค่อนข้างสูงเมื่อเทียบกับวิธีการทั่วไปในการรีเฟรชข้อมูลสรุปบางส่วนที่เก็บไว้ใน ฐานข้อมูลเชิงสัมพันธ์หรือสร้างรายงาน Reporting Services ที่ทำงานจากสแน็ปช็อตการดำเนินการที่สร้างขึ้นเป็นระยะ

ถ้าคุณมีความต้องการระยะยาวสำหรับจุดแข็งของ Analysis Services เช่นการรายงาน ad-hoc multidimensional และการแสดง MDX (คุณสามารถทำสิ่งดีๆได้) และคุณกำลังทำงานกับสิ่งที่มีขนาดใหญ่มาก คลังข้อมูลที่ช่วยให้มันมีประสิทธิภาพสูงกว่าฐานข้อมูลเชิงสัมพันธ์อย่างมีนัยสำคัญจากนั้นมันก็คุ้มค่าที่จะเรียนรู้มัน อย่าคาดหวังว่าจะหยิบมันขึ้นมาในหนึ่งวัน

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