NoSQL: Yapılandırılmamış veriler nedir?

şu anda mssql sunucu tabanlı çözümümüzle kaynakların kenarında çalışıyoruz.

Şimdi yükü ele almak için bir sonraki hamle ile ilgili birçok geleneksel seçeneğimiz var:

• daha hızlı CPU'lar ve IO satın alın
• bazı müşterileri ayrı bir sunucuya bölme
• db'yi kümeye taşı

Hepsi ya lisanslama ve donanım ya da zaman açısından pahalıdır. Bu yüzden, tüm sistemi nosql motor cassandra'nın vaat ettiği ölçeklenebilir bir çözüme taşıyarak başka bir seçenek eklemek istiyorum.

Ancak, emin değilim ve noSQL veritabanları ile deneyimli değil, bu yüzden "yapılandırılmamış" verilerin yapısını anlamak gerekir.

Uygulamamızda temel olarak kullanıcılar tarafından girilen verileri "anahtar / değer çifti" listeleri olarak çeşitli şekillerde saklıyoruz. Ana öğeyi içeren bir üst tablo (bir Sipariş gibi) ve siparişin içeriğini (Order_Lines gibi) içeren anahtar / değer çiftlerini içeren bir alt tablo vardır.

İş açısından, Order ve OrderLines bir birimdir. Ancak RDBMS nedeniyle, tablolarda depolanır ve her zaman birleştirilmeleri gerekir.

Operasyonlar sırasında bazen sadece üst kısmı yüklemeyi seçiyoruz, ancak çoğu zaman, bazı yararlı bilgileri görüntülemek için kafa sırasını + bazı KVP'leri yüklüyoruz.

Örneğin, bir genel bakış listesinde, kafa tanımlayıcısını + bazı değerleri her satır için sütunlarda gösteririz.

GÜNCELLEME: Her türlü formu saklarız. Yani, temelde "belgeleri" saklıyoruz. Bununla birlikte, bu formları herhangi bir değer, sıralama vb. İle hazırlamak ve aramak zorundayız. Veri erişim kontrolü, veritabanına başka bir karmaşıklık katmanı ekler.

Tahmin edebileceğiniz gibi, belirli KVP'lerin miktarı ve kullanılabilirliği nesneden nesneye değişir. Farklı veri kombinasyonları için binlerce tablo oluşturmamız gerektiğinden, her bir nesne türü için tek bir tablo oluşturmak için geçerli bir olasılık yoktur.

Veri setleri gibi bu tür "Sözlük" bir noSQL veritabanında daha iyi saklanır mı? Ve bundan performans avantajlarımız olacak mı? Cassandra bu kafa + KVP'leri tek bir veri seti olarak modelleyebilir mi? Cassandra web sayfasına ve bazı öğreticilere baktığımda, RDBMS ve cassandra arasında veri organizasyonu açısından çok fazla bir fark olmadığı izlenimi var - 5 KVP seçmek istiyorsanız bize aynı büyük miktarda katılma bırakarak her satır için bir liste.

Aydınlanma açıktır, aynı zamanda sorunları açıklayan makalelere de işaret eder.

Ayırt edilmesi gereken birkaç kavram vardır. Biri yapı, diğeri şema hakkında.

Yapısal veriler, uygulamanın aldığı her baytın anlamını önceden bildiği verilerdir. Buna iyi bir örnek bir sensörden alınan ölçümlerdir. Buna karşılık bir Twitter akışı yapılandırılmamış. Şema, yapının ne kadarının DBMS'ye bunun nasıl uygulanacağı sorulduğunda iletildiği ile ilgilidir. DBMS'nin depoladığı verileri ne kadar ayrıştırdığını kontrol eder. SQL Server gibi şemanın gerektirdiği bir DBMS, ayrıştırılmamış verileri (varbinary) veya isteğe bağlı olarak ayrıştırılmış verileri (xml) ve tam olarak ayrıştırılmış verileri (sütunlar) depolayabilir.

NoSQL DBMS'leri, ayrıştırmadan (anahtar / değer depoları) yukarı doğru bir spektrumda bulunur. Cassandra bu açıdan oldukça zengin bir işlevsellik sunuyor. İlişkisel mağazalara belirgin şekilde farklı oldukları yerlerde verilerin tekdüzeliği vardır. Bir tablo tanımlandıktan sonra, yalnızca bu tanımla eşleşen veriler orada tutulabilir. Ancak Cassandra'da, sütunlar ve aileler tanımlanmış olsa bile, aynı tablodaki iki satırın birbirine benzemesine gerek yoktur. Tek bir satırda ne kadar gideceğini (belge olarak da adlandırılır) ve işaretçilerle birbirine bağlı olarak ayrı tutulanları belirlemek için uygulama tasarımcısına düşer. Aslında, ne kadar denormalizasyon istersiniz.

Avantajı, tek bir sıralı okuma ile tam bir veri setini alabilmenizdir. Bu hızlı. Bunun bir dezavantajı, uygulama programcısı olarak, artık tüm veri bütünlüğü ve geriye dönük uyumluluk endişelerinden, bu veri deposuna dokunan her kod bitinden yalnızca sizin sorumlu olmanızdır. Bunu düzeltmek zor olabilir. Ayrıca, veriler üzerinde tek bir bakış açısına kilitlenirsiniz. Satırlarınızı sipariş numarasına göre anahtarlarsanız, belirli bir ürün, bölge veya müşteriye satış hakkında nasıl rapor verirsiniz?

NoSQL veritabanlarının ana akımına rağmen IMHO, bu teknolojiyi benimseme kararı, sadece şu anda sahip olduğunuz performansa değil, depolanan bilgilere göre gerekli başarılara göre yapılmalıdır. Bu, belki de en iyi seçeneğinizin SQL veritabanına bağlı kalmak ve HW'nizi geliştirmek olduğu anlamına gelir.

Ama ek olarak, sorunuzda beni düşündüren bir şey okudum. Veritabanınızın şu anki durumu hakkında pek bir şey yok ama cümleniz "temelde kullanıcılar tarafından girilen verileri" anahtar / değer "listeleri" olarak saklıyoruz, çünkü sorunun sorunun zayıf bir veri modeli olup olmadığı hakkında düşünmemi sağlıyor fiziksel kaynak eksikliği. "Geleneksel" SQL veritabanlarında inanılmaz performans gösteren gerçekten büyük tabloları (+10 milyar satır) yönettim.

Bunun yanlış olduğunu söylemiyorum, elbette sizi doğru veri modelinde mevcut çözümünüz hakkında çok az bilgi ile değerlendiremiyorum, ancak sadece sizden beri veri modelinizi ek bir seçenek olarak tekrar gözden geçirmeyi düşünün orada bazı ipucu çizikleri bulabilir.

Genellikle anahtar / değer listeleri, modeli nihai durumunda uygulayamadığınız zaman bir takas olarak iyidir, çünkü karşılaşmanız gereken farklı anahtarları bilmediğinizde veya mümkün olanlardan birinin değerlerine ihtiyacınız olduğunda belirli bir eleman için tuşları. Ancak uygulandığında, genellikle ortak kullanım durumunu tanımlamak ve veri modeli kararının en iyi olup olmadığına karar vermek için yeterli miktarda bilgi topladığınızda bir süre sonra bu tür kararları yeniden düşünmeyi seviyorum. Belirli sayıda anahtarınız olacağını biliyorsanız, geleneksel şekilde normal bir tablo tasarımı ile bazı ölçütler yapmaya çalışın

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... ve ilgili endeksleri ekliyoruz. Deneyin ve yürütme planlarını her iki yaklaşımla da ölçün. Her seferinde birden fazla anahtar toplarsanız özellikle şaşırabilirsiniz, çünkü diğer avantajların yanı sıra veri bloğu boyutu azaltılmalı ve böylece performans geliştirilecektir.

Umarım bu yardımcı olur veya en azından olasılıkları genişletir ve soruşturma için yeni bir hat açar.