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

ข้อมูลนี้มีโครงสร้าง ในฐานข้อมูลเชิงสัมพันธ์มันจะถูกเก็บไว้เป็น: | user | timestamp | latitude | longitude |

อย่างไรก็ตามมีข้อมูลมากเกินไป จะมี 60 × 60 × 24 = 86,400 บันทึกต่อผู้ใช้ทุกวัน แม้จะมีผู้ใช้ 1,000 ราย แต่ก็หมายถึงบันทึก 86,400,000 ต่อวัน

และไม่เพียงบันทึก 86,400,000 ต่อวัน เนื่องจากบันทึกเหล่านี้จะถูกประมวลผลและเวอร์ชันที่ประมวลผลจะถูกเก็บไว้เช่นกัน ดังนั้นจงคูณจำนวนนั้นด้วยประมาณ 2

ฉันวางแผนจะใช้ข้อมูลอย่างไร

โดยพื้นฐานแล้วฉันวางแผนที่จะสร้างข้อมูลตำแหน่งที่หยาบขึ้นเพื่อให้ง่ายต่อการใช้งาน นั่นคือ:

1. เรียงลำดับข้อมูล wrt timestamps ที่ได้รับ
2. ทำรายการนี้ตามลำดับพิจารณาว่าสถานที่มีการเปลี่ยนแปลงอย่างมีนัยสำคัญ (โดยการตรวจสอบว่าละติจูดและลองจิจูดเปลี่ยนไปมากน้อยเพียงใด)
3. แสดงถึงการเปลี่ยนแปลงตำแหน่งที่ไม่สำคัญเป็นรายการเดียวในเอาต์พุต (ดังนั้นเอาต์พุตคือเวอร์ชันที่หยาบกว่าของข้อมูลตำแหน่ง)
4. ทำซ้ำขั้นตอนนี้กับผลลัพธ์โดยกำหนดให้มีการเปลี่ยนแปลงละติจูดและลองจิจูดที่ยิ่งใหญ่ขึ้นเพื่อการเปลี่ยนแปลงที่สำคัญ ดังนั้นผลผลิตที่จะผลิตจากผลผลิตก่อนหน้านี้จะยิ่งทำให้หยาบยิ่งขึ้น
5. ทำซ้ำขั้นตอนทั้งหมดเท่าที่จำเป็น
6. รวมช่วงของการแก้ปัญหาและส่งไปยังผู้ใช้ และเก็บความละเอียดทั้งหมดของข้อมูลไว้เพื่อการบริโภคในภายหลัง

ฉันควรใช้อะไรเพื่อจัดเก็บข้อมูลนี้ ฉันควรใช้ฐานข้อมูลเชิงสัมพันธ์หรือโซลูชัน NoSQL หรือไม่ ฉันควรพิจารณาสิ่งอื่นใดเมื่อออกแบบแอปพลิเคชันนี้

ทางเลือกบางอย่างสำหรับการจัดเก็บข้อมูลนี้:

1. คิวข้อความ (อาจแจกจ่าย) เช่น Apache Kafka

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

2. ฐานข้อมูลเชิงสัมพันธ์

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

3. กระจายฐานข้อมูล NoSQL เช่น Cassandra

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

4. Hadoop / ไฟล์

ข้อมูลจะถูกผนวกเข้ากับไฟล์ที่แจกจ่ายโดยอัตโนมัติผ่านเซิร์ฟเวอร์โดยแพลตฟอร์ม Hadoop ประมวลผลบนเซิร์ฟเวอร์เหล่านั้นโดยใช้เครื่องมือเช่น M / R หรือ Apache Spark และสุดท้ายถูกสอบถาม (เป็นไฟล์) โดยใช้เครื่องมือ Hadoop SQL เช่น Hive หรือ Impala

เลือกแบบไหน?

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

มองลึกลงไปในความต้องการของคุณ มีวิธีสร้างภาพลวงตาของตำแหน่งการติดตามทุกวินาที

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

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

ข้อมูลของคุณเป็นชุดของอนุกรมเวลา คุณได้รับชุดของตัวเลข (สองต่อผู้ใช้) ที่วิวัฒนาการไปตามกาลเวลา โดยทั่วไปแล้วคุณไม่ต้องการพื้นที่เก็บข้อมูลเชิงสัมพันธ์ใด ๆ แต่เป็นที่เก็บข้อมูล RRD ที่เก็บข้อมูลเหล่านี้เน้นที่การลดงาน I / O ของการเขียนขนาดเล็กจำนวนมากโดยการบัฟเฟอร์

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