Olay tabanlı analitik için veritabanı şeması tasarlama

Question

Yazdığım bu olay tabanlı analitik sistemi için şemayı modellemenin en iyi yolunu bulmaya çalışıyorum. Benim asıl kaygım bu soruyu basit ve hızlı bir şekilde yapan bir şekilde yazmak. Ben de MySQL kullanacağım. Gereksinimlerden bazılarını gözden geçireceğim ve olası bir (ama sanırım kötü) şema taslağını sunacağım.

Gereksinimleri

• Parça olaylar ("APP_LAUNCH" olayın örneğin parça oluşumlarını)

• özel olayları> 1 özel özelliklerine segmenti olaylara

• yeteneği (tanımla ör olsun "APP_VERSION" özelliğine bölünmüş "APP_LOUNCH" oluşumu)

• Oturumları izleme

Olası damgası aralığında Modelleme dayalı sorgular gerçekleştirin

yaşıyorum asıl sorun bir olayın genel sayımları almak gerçekleştirmek için segmentasyon ve sorgular modellemek için nasıl .

Orijinal düşüncem bir EVENTS tablosunu bir kimlik, int count, zaman damgası, özellik (?) Ve bir yabancı anahtar olan bir EVENTTYPE ile tanımlamaktı. Bir EVENTTYPE, bir genel olay türüne ait bir kimlik, ad ve ek bilgilere sahiptir.

Örneğin, "APP_LAUNCH" olayında OLENTS tablosunda benzersiz bir kimlik, olayın kaç kez gerçekleştiğini gösteren sayım, zaman damgası (bunun neyin damgalandığından emin olma) ve bir özellik veya özellik listesi (örneğin "APP_VERSION", "COUNTRY", vb.) ve "APP_LAUNCH" ismiyle bir EVENTTYPE'e yabancı bir anahtar.

Yorum ve sorular

Bunu aşağıdaki nedenlerle bu model iyi bir yol değildir eminim. Zaman damgası aralıklı sorgular yapmak zorlaştırır ("x ile y arasındaki APP_LAUNCHES sayısı"). EVENTTYPE tablosu gerçekten bir amaca hizmet etmiyor. Son olarak, farklı segmentasyonlar için nasıl sorgulamalar yapacağımı bile bilmiyorum. Sonuncusu en çok endişelendiğim.

Bunu doğru şekilde modellemeye veya bana yardımcı olacak kaynaklara işaret etmede yardımcı olmak için herhangi bir yardımı takdir ediyorum. (Muhtemelen aptal)

Son bir soru: Her olay için bir satır eklemek için kötü mü? (Bu yakından besbelli şema tasarımı ile ilgilidir)

track("APP_LAUNCH", {count: 4, segmentation: {"APP_VERSION": 1.0}}) 

Nasıl Aslında tabloda saklamak olacaktır: Örneğin, benim istemci tarafı kütüphanesi aşağıdaki benim API çağrı yapar demek? Bu çağrılardan her biri için bir satır eklemeniz kötü bir şey olabilir mi? Benim bağırsak reaksiyonum, genel olarak toplu toplamlarda gerçekten ilgileniyorum. Bu sorguların yüz binlerce girişten fazlasını nasıl gerçekleştirdiğini bilmek için SQL konusunda yeterli tecrübem yok. İstemcinin gerçekten analitiği almasını istediğimde, bir toplu tablo veya bir bellek içi önbellek sorunların giderilmesine yardımcı olur mu?

Burada birçok soru olduğunu anlıyorum, ama her türlü yardımı gerçekten takdir ediyorum. Teşekkürler!

Answer 1

Sanırım endişelerinizin çoğu gereksiz. Sorularınızdan birini aldıktan sonra:

1) En büyük sorun, her olay için farklı olan özel özniteliklerdir. Bunun için EAV (entity-attribute-value) tasarımını kullanmanız gerekir. Asıl soru şu: Bu nitelikler hangi özelliklere sahip olabilir? Birden fazla ise - ör. dize ve tamsayı, daha karmaşıktır.

her veri için ayrı tablolar (değil ölçeklenebilir bir çözüm) ve dizeye şeyi dönüştürmek -

• kullanımı bir tablo ve her türlü değerleri için bir sütun: Orada böyle tasarımın genel iki tip vardır

  Events    EventId int, EventTypeId varchar, TS timestamp 
  EventAttrValueInt EventId int, AttrName varchar, Value int 
  EventAttrValueChar EventId int, AttrName varchar, Value varchar 
  

  : Yani

(Bunun için gitmek istiyorum, çok ölçeklenebilir) yazın tablolar gibi görünecektir

2) Segmentasyon ile ne demek istiyorsun? Etkinliğin çeşitli parametrelerini soruyor musunuz? Yukarıda belirtilen EAV tasarımında, bunu yapabilirsiniz: appVersion> 4'tür ve APP_NAME "Office'i" terimi içeren

select * 
from Events 
    join EventAttrValueInt on Id = EventId and AttrName = 'APPVERSION' and Value > 4 
    join EventAttrValueChar on Id = EventId and AttrName = 'APP_NAME' 
              and Value like "%Office%" 
where EventTypeId = "APP_LAUNCH" 

Bu APP_LAUNCH türünün tüm olayları seçecektir.

3) EventType tablo, tutarlılık amacına hizmet verebilir yapabildin yani: Eğer sayı olarak kimlik kullanan ve EventType tabloda etkinlik adı olabilir,

table EVENTS (.... EVENTTYPE_ID varchar - foreign key to EVENTTYPE ...) 
table EVENTTYPE (EVENTTYPE_ID varchar) 

Veya - bu alanı kazandırır ve olayların kolayca yeniden adlandırılmasına izin verir, ancak her sorguda bu tabloya katılmanız gerekir (biraz daha yavaş sorgular ile sonuçlanır). Depolama alanı kaydetme önceliğine ve daha düşük sorgulama süresine/basitliğine bağlıdır.

4) damgası sorguları aslında tasarımda çok basit değişiyordu:

select * 
from EVENTS 
where EVENTTYPE_ID = "APP_LAUNCH" and TIMESTAMP > '2013-11-1' 

5)"kötü her olay için bir satır eklemek için mi?"

Bu tamamen size bağlı! Bu tür olayların zaman damgası ve/veya farklı parametrelerine ihtiyacınız varsa, muhtemelen her etkinlik için bir satırınız olmalıdır. Aynı tür ve parametrelerde çok fazla sayıda olay varsa, muhtemelen en çok oturum açma sistemlerinin yapabileceklerini yapabilirsiniz: bir satırda gerçekleşen olayları bir araya getirin. Böyle bir hissiniz varsa, muhtemelen gitmek için bir yoldur.

6)sorunsuz ele alınacaktır

Yüzlerce veya binlerce tür girdileri "Bu sorgular, bu girişlerin binlerce belki yüz içinde nasıl performans bilmek SQL ile yeterli deneyime sahip değilsiniz".Milyona ulaştığınızda, verim hakkında daha fazla düşünmek zorunda kalacaksınız.

7)"Keşke toplu bir tablo veya İstemci aslında analiz almak istediğinizde sorunları hafifletmek için bir bellek içi önbellek yardım?" sorgular yavaş olsun ve hızlı yanıt gerekiyorsa Tabii

, bu, aynı zamanda bir çözümdür. Ama sonra periyodik olarak önbelleği yenilemek için bir mekanizma tanıtmalısınız. Aşırı derecede karmaşıktır; girişteki olayları toplamayı düşünmek daha iyi olabilir, bakınız 5).