ชุดข้อมูลเชิงพื้นที่ขนาดใหญ่ (> 22 ล้านล้านรายการ) พร้อมประสิทธิภาพการสืบค้นอย่างรวดเร็ว (<1s)

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

ข้อมูลจะถูกผลิตอย่างต่อเนื่องจากข้อมูลเรดาร์ดาวเทียมที่ผ่านการประมวลผลซึ่งจะครอบคลุมทั่วโลก จากความละเอียดของดาวเทียมและพื้นที่ครอบคลุมของโลกฉันประเมินชุดข้อมูลทั้งหมดเพื่อสร้างมูลค่าที่ 75 พันล้านตำแหน่งโดยสิ้นเชิงในโลก ตลอดช่วงชีวิตของดาวเทียมดวงเดียวเอาต์พุตจะสร้างค่าได้สูงสุด 300 ค่าในแต่ละตำแหน่งเหล่านี้ (ดังนั้นชุดข้อมูลทั้งหมดที่มีค่า> 22 ล้านล้านค่า) นี่เป็นดาวเทียมหนึ่งดวงและมีวงโคจรอยู่หนึ่งวินาทีและอีกสองวางแผนในไม่กี่ปีใหม่ ดังนั้นจะมีข้อมูลจำนวนมาก! รายการข้อมูลเดียวนั้นง่ายมากและจะประกอบไปด้วย (ลองจิจูด, ค่าละติจูด, ค่า) แต่เนื่องจากจำนวนรายการที่ฉันประเมินดาวเทียมหนึ่งดวงเพื่อผลิตสูงสุด 100TB

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

จากข้อกำหนดเหล่านี้ฐานข้อมูลจะต้องสามารถปรับขนาดได้และเรามีแนวโน้มที่จะมองหาโซลูชั่นระบบคลาวด์ ระบบจะต้องสามารถจัดการกับข้อความค้นหาเชิงพื้นที่เช่น "points near (lat, lon)" และ "points within (box)" และมีประสิทธิภาพการอ่าน <1s สำหรับการหาจุดเดียวและรูปหลายเหลี่ยมที่มีถึง 50,000 คะแนน (ถึง 200,000 คะแนนน่าจะดีกว่า)

จนถึงตอนนี้ฉันมีชุดข้อมูลทดสอบ ~ 750 ล้านรายการข้อมูลที่ 111 ล้านแห่ง ฉันได้ทดลองใช้อินสแตนซ์ postgres / postGIS ซึ่งใช้งานได้ แต่ไม่มีความเป็นไปได้ที่จะหักอกฉันไม่สามารถทำสิ่งนี้ได้เพื่อรับมือกับการเติบโตของข้อมูล เท่าที่ผ่านมาและด้วยการใช้เศษก็อาจเพียงพอที่จะไต่ระดับด้วยปริมาณข้อมูล เมื่อเร็ว ๆ นี้ฉันได้เรียนรู้เกี่ยวกับ elasticsearch เล็กน้อยดังนั้นความคิดเห็นใด ๆ เกี่ยวกับเรื่องนี้จะเป็นประโยชน์เพราะเป็นเรื่องใหม่สำหรับฉัน

นี่คือภาพเคลื่อนไหวอย่างรวดเร็วของสิ่งที่เราต้องการบรรลุด้วยชุดข้อมูลแบบเต็ม:

gif นี้ (จากการทดลอง postgres ของฉัน) ให้บริการ (6x3) กระเบื้องแรสเตอร์ที่คำนวณล่วงหน้าซึ่งแต่ละแผ่นมี ~ 200,000 คะแนนและใช้เวลา ~ 17 วินาทีเพื่อสร้างแต่ละภาพ โดยการคลิกที่จุดกราฟจะทำโดยการดึงค่าประวัติศาสตร์ทั้งหมดที่สถานที่ที่ใกล้ที่สุดใน <1s

ขอโทษสำหรับการโพสต์ยาวความคิดเห็น / คำแนะนำทั้งหมดยินดีต้อนรับ

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

ด้วยวิธีนี้คุณสามารถใช้โซลูชันฐานข้อมูลใด ๆ ที่คุณชอบ ไม่จำเป็นต้องปรับขนาดได้ด้วยตัวเอง

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

ชุดรูปแบบการแบ่งส่วนนี้ยอดเยี่ยมสำหรับชนิดของแบบสอบถามที่คุณดำเนินการเนื่องจากแบบสอบถามแต่ละรายการจะต้องแตะเศษน้อยมากเท่านั้น การเรียงลำดับเวลาแย่ลงเพราะต้องใช้เวลาในการค้นหาแต่ละครั้ง การสุ่มแบบสุ่มมีปัญหาเดียวกัน

ทั้งหมดนี้เป็นกรณีการแบ่งส่วนที่ง่ายเนื่องจากรูปแบบการสืบค้นที่เหมาะกับโครงร่างการเรียงตัวที่ดี

จริงๆแล้วฉันสงสัยว่าคุณต้องการฐานข้อมูลทั้งหมดหรือไม่ บางทีคุณอาจแบ่งพาร์ติชันของโลกออกเป็น 1000x1000 ไทล์หรือเล็กกว่าและมีไฟล์แบนหนึ่งไฟล์ในที่เก็บข้อมูลหยดสำหรับแต่ละไทล์ พื้นที่เก็บข้อมูล Blob ไม่สนใจ 1M blobs เลย

การดำเนินการค้นหาเป็นแนวคิดที่ง่ายมากด้วยโครงร่างการจัดเก็บนี้ คุณสามารถจัดเก็บข้อมูลซ้ำซ้อนในความละเอียดหลายกริดเช่นกัน

ข้อความค้นหาที่คุณอ่านต้องทันสมัยแค่ไหน?

คุณสามารถแบ่งฐานข้อมูลตามเวลาที่แผนที่ต้องการแสดงการวัดล่าสุด สิ่งนี้จะลดภาระการสืบค้นของคุณสำหรับแผนที่

สำหรับประวัติของจุดที่กำหนดคุณสามารถถือร้านสาขาที่สองโดย x และ y เพื่อแสดงประวัติ ซึ่งสามารถทำได้ด้วยการรีเฟรช / อัปเดตทุกคืนเนื่องจากข้อมูลประวัติจะไม่เปลี่ยนแปลง

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

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

ตกลงดังนั้นคะแนนของคุณต้องคำนวณโดยเฉลี่ยเมื่อเวลาผ่านไป ด้วยการคำนวณนี้ฉันเดาว่าการสอบถามจริงของคุณลดลงมากจาก 22 ล้านล้านรายการเนื่องจากค่าแรสเตอร์สามารถคำนวณได้ล่วงหน้าสำหรับการสืบค้น

ดูเหมือนว่ามีข้อความค้นหาสองชั้น - หนึ่งแห่งเพื่อทำความเข้าใจว่าสถานที่ใดตั้งอยู่ภายในหน้าต่างมุมมองปัจจุบันและอีกหนึ่งวินาทีเพื่อส่งสถิติที่ต้องการสำหรับจุดเหล่านั้น ข้อเสนอแนะของฉันคือการใช้เครื่องมือพิเศษแยกต่างหากสำหรับแต่ละรายการ

ฉันสมมติว่าการวัดทั้งหมดเกี่ยวข้องกับชุดเดียวกันกับ 75Bn จุด lat / long เหล่านี้เมื่อสร้างขึ้นแล้วจะเป็นแบบคงที่ พวกเขาสามารถจัดกลุ่มรวมและจัดทำดัชนีที่ค่าใช้จ่ายครั้งเดียว ดังนั้นฉันขอแนะนำให้แบ่งส่วนตามภูมิภาคและระดับการซูม ขนาดของชิ้นส่วนแต่ละชิ้นจะถูกขับเคลื่อนด้วยประสิทธิภาพที่สามารถทำได้จากอินสแตนซ์ GIS แต่ละตัว

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

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

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

where latitude between x1 and x2
and logitude between y1 and y2

ส่วนนั้นสามารถจัดการได้โดยซอฟต์แวร์การจัดเก็บค่าและ GIS ตัดออกจากสถาปัตยกรรม

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