InfluxDB ile çalışırken öfke, pazarlık ve depresyon

Bir zaman serisi veritabanı kullanıyorsanız (zaman serisi veritabanı, wiki) istatistik içeren bir sitenin ana depolama alanı olarak kullanırsanız, sorunu çözmek yerine çok fazla baş ağrısı yaşayabilirsiniz. Böyle bir veritabanı kullanan bir proje üzerinde çalışıyorum ve bazen tartışılacak olan InfluxDB tamamen beklenmedik sürprizler sunuyordu.

Feragatname: Listelenen sorunlar InfluxDB sürüm 1.7.4 için geçerlidir.

Neden zaman serisi?

Projenin amacı çeşitli blockchainlerdeki işlemleri takip etmek ve istatistikleri görüntülemek. Spesifik olarak, stabil paraların emisyonuna ve yakılmasına bakıyoruz (wiki). Bu işlemlere dayanarak grafikler oluşturmanız ve özet tabloları göstermeniz gerekir.

İşlemleri analiz ederken bir fikir ortaya çıktı: InfluxDB zaman serisi veritabanını ana depolama olarak kullanmak. İşlemler zaman içindeki noktalardır ve zaman serisi modeline iyi uyum sağlarlar.

Toplama işlevleri de çok kullanışlı görünüyordu; uzun süreli grafikleri işlemek için ideal. Kullanıcının bir yıllık bir grafiğe ihtiyacı vardır ve veritabanı beş dakikalık bir zaman dilimine sahip bir veri seti içerir. Ona yüz bin noktanın tamamını göndermenin bir anlamı yok; uzun işlemler dışında ekrana bile sığmıyorlar. Zaman çerçevesini artırmak için kendi uygulamanızı yazabilir veya Influx'ta yerleşik toplama işlevlerini kullanabilirsiniz. Onların yardımıyla verileri güne göre gruplandırabilir ve gerekli 365 puanı gönderebilirsiniz.

Bu tür veritabanlarının genellikle metrik toplamak amacıyla kullanılması biraz kafa karıştırıcıydı. Sunucuların, IoT cihazlarının ve milyonlarca noktanın "aktığı" her şeyin izlenmesi: [<zaman> - <metrik değer>]. Ancak veritabanı büyük bir veri akışıyla iyi çalışıyorsa, o zaman küçük bir hacim neden sorunlara neden olsun ki? Bunu aklımızda tutarak InfluxDB'yi çalışmaya aldık.

InfluxDB'de başka neler kullanışlıdır?

Bahsedilen toplama işlevlerinin dışında harika bir şey daha var: sürekli sorgular (dok). Bu, verileri bir zamanlamaya göre işleyebilen, veritabanına yerleşik bir zamanlayıcıdır. Örneğin 24 saatte bir, güne ait tüm kayıtları gruplandırabilir, ortalamayı hesaplayabilir ve kendi bisikletlerinizi yazmadan yeni bir noktayı başka bir tabloya kaydedebilirsiniz.

Ayrıca orada saklama politikaları (dok)—belirli bir süre sonra verilerin silinmesini ayarlama. Örneğin, CPU yükünü saniyede bir kez yapılan ölçümlerle bir hafta boyunca saklamanız gerektiğinde kullanışlıdır, ancak birkaç aylık bir mesafe için bu tür bir doğruluğa gerek yoktur. Böyle bir durumda şunları yapabilirsiniz:

1. verileri başka bir tabloda toplamak için sürekli bir sorgu oluşturun;
2. ilk tablo için aynı haftadan daha eski olan metriklerin silinmesine ilişkin bir politika tanımlayın.

Ve Influx bağımsız olarak verilerin boyutunu azaltacak ve gereksiz şeyleri silecektir.

Saklanan veriler hakkında

Çok fazla veri depolanmıyor: yaklaşık 70 bin işlem ve piyasa bilgilerinin bulunduğu bir milyon nokta daha. Yeni girişler ekleme - günde en fazla 3000 puan. Siteye yönelik metrikler de var ancak orada çok az veri var ve saklama politikasına göre bunlar bir aydan fazla saklanmıyor.

Sorunları

Hizmetin geliştirilmesi ve sonraki testleri sırasında InfluxDB'nin çalışmasında giderek daha kritik sorunlar ortaya çıktı.

1. Verilerin silinmesi

İşlemlerle ilgili bir dizi veri var:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

Sonuç:

Verileri silmek için bir komut gönderiyorum:

DELETE FROM transactions WHERE symbol=’USDT’

Daha sonra zaten silinmiş olan verileri almak için bir talepte bulunuyorum. Ve boş bir yanıt yerine Influx, silinmesi gereken verilerin bir kısmını döndürür.

Tablonun tamamını silmeye çalışıyorum:

DROP MEASUREMENT transactions

Tablonun silinmesini kontrol ediyorum:

SHOW MEASUREMENTS

Tabloyu listede göremiyorum ancak yeni bir veri sorgusu yine de aynı işlem kümesini döndürüyor.

Silme olayı münferit bir durum olduğu için sorun sadece bir kez başıma geldi. Ancak veritabanının bu davranışı açıkça "doğru" çalışma çerçevesine uymuyor. Daha sonra github'da açık buldum bilet neredeyse bir yıl önce bu konuyla ilgili.

Sonuç olarak, tüm veritabanını silip geri yüklemek işe yaradı.

2. Kayan noktalı sayılar

InfluxDB'de yerleşik işlevler kullanılırken yapılan matematik hesaplamalarında doğruluk hataları var. Bu olağandışı bir şey değil ama hoş olmayan bir durum.

Benim durumumda verinin finansal bir bileşeni var ve onu yüksek doğrulukla işlemek istiyorum. Bu nedenle sürekli sorgulamalardan vazgeçmeyi planlıyoruz.

3. Sürekli sorgular farklı zaman dilimlerine uyarlanamaz

Hizmetin günlük işlem istatistiklerini içeren bir tablosu vardır. Her gün için o güne ait tüm işlemleri gruplandırmanız gerekir. Ancak her kullanıcının günü farklı bir saatte başlayacak ve dolayısıyla işlem seti de farklı olacaktır. UTC'ye göre evet 37 çeşit verileri toplamanız gereken vardiyalar.

InfluxDB'de zamana göre gruplama yaparken ek olarak bir vardiya belirleyebilirsiniz, örneğin Moskova saati (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

Ancak sorgu sonucu yanlış olacaktır. Bazı nedenlerden dolayı, güne göre gruplandırılmış veriler 1677'den başlayacak (InfluxDB resmi olarak bu yıldan itibaren bir zaman aralığını destekliyor):

Bu soruna geçici bir çözüm bulmak için hizmeti geçici olarak UTC+0 olarak değiştirdik.

4. Performans

İnternette InfluxDB ile diğer veritabanlarını karşılaştıran birçok kriter var. İlk bakışta pazarlama materyallerine benziyorlardı ama artık bunların içinde bazı gerçekler olduğunu düşünüyorum.

Sana durumumu anlatacağım.

Hizmet, son güne ait istatistikleri döndüren bir API yöntemi sağlar. Hesaplamalar yapılırken, yöntem aşağıdaki sorgularla veritabanını üç kez sorgular:

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

açıklama:

1. İlk istekte piyasa verileriyle birlikte her bir coin için son puanları alıyoruz. Benim durumumda sekiz madeni paraya sekiz puan.
2. İkinci istek en yeni puanlardan birini alır.
3. Üçüncüsü, son XNUMX saatteki işlemlerin bir listesini ister; bunlardan birkaç yüz tane olabilir.

InfluxDB'nin otomatik olarak etiketlere ve zamana dayalı bir dizin oluşturduğunu ve bunun da sorguları hızlandırdığını açıklığa kavuşturayım. İlk istekte sembol bir etikettir.

Bu API yönteminde bir stres testi yaptım. 25 RPS için sunucu altı CPU'nun tam yükünü gösterdi:

Aynı zamanda NodeJs süreci hiçbir şekilde yük sağlamadı.

Yürütme hızı zaten 7-10 RPS kadar düştü: eğer bir istemci 200 ms içinde yanıt alabilirse, 10 istemcinin bir saniye beklemesi gerekiyordu. 25 RPS, istikrarın bozulduğu sınırdır; istemcilere 500 hata döndürüldü.

Böyle bir performansla projemizde Influx'u kullanmak imkansızdır. Üstelik izlemenin birçok müşteriye gösterilmesi gereken bir projede benzer sorunlar ortaya çıkabilir ve metrik sunucusu aşırı yüklenebilir.

Aviator apk

Kazanılan deneyimlerden çıkan en önemli sonuç, bilinmeyen bir teknolojiyi yeterli analiz yapılmadan bir projeye alamayacağınızdır. Github'daki açık sorunların basit bir taraması, InfluxDB'yi ana veri deposu olarak seçmekten kaçınmak için bilgi sağlayabilir.

InfluxDB'nin projemin görevleri için uygun olması gerekirdi, ancak uygulamanın gösterdiği gibi bu veritabanı ihtiyaçları karşılamıyor ve birçok hata içeriyor.

2.0.0-beta sürümünü zaten proje deposunda bulabilirsiniz; yalnızca ikinci sürümün önemli iyileştirmeler içereceğini umabiliriz. Bu arada TimescaleDB belgelerini inceleyeceğim.

Kaynak: habr.com