Genel olarak, böylesi yapılandırılmış bir veri kümesi için, çoğu günlük işlem için daha hızlı olan özel bir veri biçimi yazabileceğinizi zannediyorum (yani küçük veriler isteğe bağlı bir zamandan çekiyor). Standart bir DB aracına geçmenin avantajı, bazı ekstralarda, örneğin geçici sorgular, çoklu erişim, çoğaltma, kullanılabilirlik vb. Olabilir. Standart tabanlı bir veri deposunu korumak için yardım almak da daha kolaydır.
Bu verileri depolamak için bir veritabanı kurmam istendiyse, aşağıdakileri yapardım:
Önerilen şema
(1) Çekirdek verileri, her biri iki sütun içeren sayısız (1000'in) bireysel tabloya yerleştirilir:
- time: Bir SQL DATETIME veri türü ya da bazı çağlardan sayısal bir tür (bu birincil anahtardır)
- değer: verilerinize uygun olarak yazılmıştır. Tek bir kesinti yüzer için varsayılan olurdu, ancak sabit nokta veri türü finansal işlemler için daha uygun olabilir. Bu muhtemelen açık değildir.
Bu tablolar oldukça büyüyecek ve bunları (örneğin) bir yıla göre elle bölümlemek isteyebilirsiniz. Ancak, sistem performansını kontrol etmeniz ve uygun şekilde ayarlamanız gerekir.
Bu tabloların benzersiz adlara ihtiyacı vardır ve birkaç seçenek vardır. İnsan tarafından okunabilir (örneğin, nyse_goog_dailyhighs_2010) veya (tercihim) rasgele olabilirler. Her iki şekilde de, bir meta veri tabloları seti gereklidir ve rastgele tablo adları, geliştiricilerin, çıkarımı amaçlanmayan adlara bir şey çıkarmasını önler.
(2) Meta veriler, uygulamanın gerektirdiği şekilde ayrı tablolarda saklanır :
Meta verileri takip etmek için ek bir tablo veya tablo seti gerekir. Bu tablolarda değişim, enstrüman, değer, sıklık, tarih aralıkları, provenans (verilerin nereden geldiği) ve ihtiyacınız olan her şey hakkında veriler yer alacaktır. Bunlar veri tablosu adlarıyla eşleştirilir.
Yeterli veri varsa, bu arama aslında bir tablo adı ve veritabanı adı sağlayarak bir tür kendi kendine uygulanan veri paylaşımına izin verebilir (bu, terimin doğru kullanımıysa). Ama bunu yedek tutacağım.
Daha sonra uygulama katmanında, verilerimin bulunduğu yeri belirlemek için meta veri tablolarını sorgularım ve verilerimi almak için büyük veri tablolarında nispeten basit sorgular gerçekleştiririm.
Avantajları:
Benim (göreceli olarak sınırlı) deneyimlerim, veritabanlarının genellikle daha az sayıda büyük tablodan daha kolay olan çok sayıda küçük tabloyu idare edebilmesidir. Bu yaklaşım aynı zamanda daha kolay bakım sağlar (örneğin, eski verileri temizleme, bozuk bir tabloyu yeniden oluşturma, yedeklerden oluşturma / yeniden yükleme, yeni bir varlık ekleme). Bu, (örneğin) farklı hızlarda verilere sahipseniz veya farklı veri türleri gerektiriyorsa, farklı veri türlerini tamamen ayrıştırır.
Bu sıska masa konsepti aynı zamanda tek bir varlıktan bitişik bir veri aralığı olan en yaygın sorgu olduğundan şüphelendiğim şey için hızlı disk erişimine izin vermelidir. Çoğu veri uygulaması disk G / Ç sınırlıdır, bu nedenle dikkate değer. Yorum yapanların zaten belirttiği gibi, bu benim sütun odaklı bir veritabanı için ideal bir uygulama olabilir, ancak kariyerim için bahse girmem için yeterince ana olan sütun odaklı bir ürün bulamadım. Bu şema oldukça yaklaşıyor.
Dezavantajları:
Disk alanınızın yaklaşık yarısı zaman damgası saklamaya adanmıştır, açıkçası 100'lerin veya 1000'lerin tabloları zaman damgası sütununda aynı verilere sahip olduğunda. (Aslında kolay masa birleştirmelerini gerçekleştirmek istiyorsanız bu bir zorunluluktur).
Tablo adlarını saklamak ve dinamik aramayı gerçekleştirmek, çok fazla uygulama karmaşıklığı ve dize işlemi gerektirir; bu da beni sıkıştırabilir. Ancak yine de alternatiflerden daha iyi görünüyor (aşağıda tartışılmaktadır).
hususlar:
Zaman diliminde yuvarlama konusunda dikkatli ol. Değerlerinizin birleşmeleri mümkün kılacak kadar yuvarlak (uygunsa), ancak kesin olmaya yetecek kadar kesin olmasını istiyorsunuz.
Saat dilimleri ve gün ışığından yararlanma saati konusunda dikkatli olun. Bunları test etmek zor. Veri deposunda bir UTC gereksinimi uygulardım (bu beni sevilmeyen yapabilir) ve uygulamadaki dönüşümleri yönetirim.
Varyasyonlar:
Düşündüğüm bazı varyasyonlar:
Veri katlama: Zaman dilimleri eşit aralıklarla yerleştirilmişse, bir zaman damgası sütunu ve (örneğin) 10 veri sütunu kullanın. Zaman damgası şimdi ilk veri sütununun zamanına atıfta bulunur ve diğer veri sütunları bu zaman damgası ile bir sonraki arasında eşit aralıklarla kabul edilir. Bu, daha önce önemli bir sorgu ve / veya uygulama karmaşıklığı pahasına, zaman damgalarını depolamak için kullanılmış olan çok fazla depolama alanı kazandırır. Bitişik aralık, tek varlık sorguları artık daha az disk erişimi gerektiriyor.
Çoklu pleksleme: Eğer çoklu zaman serilerinin aynı zaman serilerini kullandığı biliniyorsa, yukarıda açıklandığı gibi bir zaman damgası ve (örneğin) 10 veri sütunu kullanın. Ancak şimdi her sütun farklı bir zaman serisini temsil ediyor. Bu, tablo ve sütun adına bir arama olmayan meta veri tablosunda bir güncelleme gerektirir. Depolama alanı azalır. Sorgular basit kalır. Ancak bitişik aralıkta, tek varlık sorguları artık önemli ölçüde daha fazla disk erişimi gerektiriyor.
Mega masa: "Çok katlı" konseptini en uç noktaya götürün ve tüm verileri sütun başına bir zaman serisi olan tek bir masaya koyun. Bu, bitişik aralık için büyük miktarlarda disk erişimi gerektirir, tek varlık sorguları ve bir bakım kabusu. Örneğin, yeni bir varlık eklemek artık birçok TB tablosunda bir MODIFY TABLE komutu gerektiriyor.
Bu formatla ilgili ek tartışma için, aşağıdaki cevaplara bakın:
MySQL'de çok fazla sütun var.
Tamamen normalleştirilmiş tablo:
Çok sayıda 2 sütun tablo kullanmak yerine, sütunların zaman, dataid ve değer olduğu bir, üç sütun tablo kullanabilirsiniz. Artık meta veri tablolarınız, uygulama katmanından ziyade SQL sorgularına daha fazla mantık itmeyi sağlayan tablenames veya sütun adlarından ziyade ID değerlerini aramaya ihtiyaç duyuyor.
Artık normalleştirme sütunlarıyla yaklaşık 2 / 3'lük Depolama tüketiliyor, bu yüzden çok fazla disk alanı kullanılacak.
Hızlı bitişik, tek varlık sorguları için birincil anahtar sırasını (dataid, zaman damgası) kullanabilirsiniz. Veya daha hızlı ekler için birincil anahtar sırasını (zaman damgası. Dataid) kullanabilirsiniz.
Ancak, bu farklılıkları düşündükten sonra bile, bir sonraki gelişimim için planım her biri iki sütun olmak üzere birçok tablo. Bu, ya da yöntem yakında benden daha akıllı biri tarafından gönderilecek :).