Uygulama sürekli olarak (yaklaşık her saniye) kullanıcıların yerini toplar ve saklar.

Bu veriler yapılandırılmıştır. İlişkisel bir veritabanında şu şekilde depolanır: | user | timestamp | latitude | longitude |

Ancak, çok fazla veri var. Kullanıcı başına günlük 60 × 60 × 24 = 86.400 kayıt olacaktır. 1000 kullanıcıyla bile günlük 86.400.000 kayıt anlamına gelir.

Ve bu sadece günlük 86.400.000 kayıt değil. Çünkü bu kayıtlar işlenecek ve işlenmiş sürümleri de saklanacaktır. Yani, bu sayıyı yaklaşık 2 ile çarpın.

Verileri nasıl kullanmayı planlıyorum

Esasen, daha kolay tüketim için konum verilerinin daha kaba taneli sürümlerini yapmayı planlıyorum. Yani:

1. Alınan verileri zaman damgalarına göre sıralayın.
2. Bu listede sırayla yinelenerek, konumun önemli ölçüde değişip değişmediğini belirleyin (enlem ve boylamın ne kadar değiştiğini kontrol ederek)
3. Önemli olmayan konum değişikliklerini çıktıda tek bir girdi olarak gösterin (dolayısıyla çıktı, konum verilerinin daha kaba taneli bir sürümüdür).
4. Önemli bir değişiklik için daha büyük bir enlem ve boylam değişikliği gerektirerek bu işlemi çıktıda yineleyin. Dolayısıyla, önceki çıktıdan üretilecek çıktı daha kaba taneli olacaktır.
5. Tüm süreci gerektiği kadar yineleyin.
6. Bir dizi çözünürlük toplayın ve bunları kullanıcılara gönderin. Ayrıca, verilerin tüm çözünürlüklerini daha sonra kullanmak üzere saklayın.

Bu verileri saklamak için ne kullanmalıyım? İlişkisel veritabanı mı yoksa NoSQL çözümü mü kullanmalıyım? Bu uygulamayı tasarlarken başka nelere dikkat etmeliyim?

Bu verileri depolamak için bazı alternatifler:

1. Mesaj kuyruğu (muhtemelen dağıtılmış), Apache Kafka gibi

Bu, bir veri akışı yazmak ve okumak için optimize edilecektir. Veri akışlarını işlenmesi kolay bir formatta toplamak için idealdir, ancak akışı bütünüyle okumak dışında genellikle sorgulanamaz. Dolayısıyla bu, arşivleme amaçları için veya bir işleme katmanına giden yolda bir ara adım olacaktır.

2. İlişkisel veritabanı

Sadece veritabanına yazabilirsiniz ve birim DB'nin işleme kapasitesini aştığında, veritabanını parçalayabilirsiniz (= verilerin birden çok alt kümesinin farklı veritabanı sunucularında oturmasını sağlayabilirsiniz). Faydası: ilişkisel bir DB kullanabilirsiniz ve yeni bir şey öğrenmek zorunda değilsiniz. Dezavantajı: DB ile ilgili tüm kodlar, hangi veri parçasının yaşandığı, uygulama yazılımında toplu sorgular yapılması gerektiğinin farkında olmalıdır.

3. Cassandra gibi dağıtılmış NoSQL veritabanı.

Verilerinizi dağıtılmış bir NoSQL veritabanına yazarsınız ve bu veriler sizin için otomatik olarak parçalanır. Cassandra, verilere geri dönmek için daha az uygulama kodu gerektirerek, küme genelinde sorgular yapmanızı sağlar. Faydası: büyük miktarlarda veri için daha doğal olarak uygundur, olumsuz: bu sistemlerin iyi performans elde etmek ve verilerin ihtiyaçlarınıza göre sorgulanabilir hale getirilmesi konusunda nasıl çalıştığı konusunda belirli bir uzmanlık ve derinlemesine bilgi gerektirir. NoSQL sihirli bir performans düzeltmesi değildir, navigasyon için anlaşılması gereken bir dizi ödünleşmedir.

4. Hadoop / dosya

Veriler Hadoop platformu tarafından sunucular arasında otomatik olarak dağıtılan, M / R veya Apache Spark gibi araçlar kullanılarak bu sunucularda işlenen ve son olarak Hiveop Impala gibi bir Hadoop SQL motoru kullanılarak sorgulanan (dosya olarak) dosyalara eklenir.

Hangisini seçmeli?

Bu alternatifler arasındaki ödünleşimler karmaşıktır ve bunlar hem yazınıza hem de okuma alışkanlıklarınıza bağlıdır, bu nedenle bu değiş tokuşlara karar verebilecek tek kişi sizsiniz. Bu alternatifleri derinlemesine anlamak için zamanınız yoksa, ilişkisel bir DB kullanın ve ilerlerken bir parçalama çözümü bulun. Muhtemelen, YAGNI .

Gereksinimlerinize biraz daha derinlemesine bakın. Her saniye izleme konumu yanılsaması yaratmanın bir yolu var.

Geçerli GPS konumunuzu bilen ve bir veritabanına yazan bir uygulamanız varsa, neden değişmezse konumu yazmaya devam edersiniz? Verilere ihtiyacınız olsa bile, kullanıcı 7 saat uykuda kalıyorsa, hesaplamalarınızı veya eşlemenizi veya başka bir şey yapmanız gerekenleri yapmak için eksik zaman aralıklarını programlı olarak yinelenen bir konumla doldurabilirsiniz.

Konumu her saniye izlerseniz, bu verileri sonsuza kadar saklamanız gerekir mi? Geçerli tablonun çok büyük olmasını önlemek için kayıtları başka bir veritabanına arşivleyebilirsiniz. Ya da sadece pozisyon değişikliği olan kayıtları tutabilirsiniz. Bu, veri ambarlarında yaygındır.

Verileriniz bir dizi zaman dizisidir. Zamanla gelişen sayı kümelerini (kullanıcı başına iki adet) verdiniz. Tipik olarak, herhangi bir ilişkisel depolama değil, bir RRD depolama arıyorsunuz. Bu depolama, çok sayıda küçük yazının G / Ç çalışmalarını arabelleğe alarak azaltmaya odaklanır.

İlişkisel depolama, bu zaman serisi hacmi için bir sapkınlıktır. Bununla birlikte, RRD'nin geliştirilmesinin, programlanabilir sömürü açısından SQL'den daha iyi desteklenmediği konusunda uyarılmalıdır. Muhtemelen ciddi entegrasyon çalışmalarına bakıyorsunuz, ancak gereksinimleriniz göz önüne alındığında pek önlenemiyor.