Olay / etkinlik verileri için JSON nesnelerine karşı ilişkisel veritabanı kullanma


28

Bir olay veya etkinlikle ilgili verileri depolamak için standart bir SQL ilişkisel veritabanı veya JSON nesneleri kullanma arasında karar vermeye çalıştığım bir proje üzerinde çalışıyorum.

Proje birden fazla etkinlik türünde veri depolayacaktır, bu yüzden bu soru için yalnızca bir etkinlik türünü tanımlamaya karar verdim.

Canlı müzik etkinliği (bu sorunun altındaki JSON şeması kullanılarak tam olarak açıklanmıştır), etkinliğin gerçekleşeceği yer, etkinliğin saati / tarihi ve etkinliğin maliyeti gibi verileri depolayan bir nesnedir. Canlı müzik etkinliği nesnesinde hem bire bir (etkinlik -> ad, etkinlik -> açıklama) ve bire çok (etkinlik -> mekanlar, etkinlik -> tarihler, etkinlik -> bilet türleri vardır. ) ilişkiler. Ayrıca, olay nesnesi, performans nesnesine bağlantı veren bir veya daha fazla performans kimliği içerebilir. Sanatçı nesnesi, canlı müzik etkinliğinde performans gösteren müzisyenlerle ilgili verileri depolar.

Veriler, kullanıcılar tarafından hem basit ("Beni 'x' adıyla olayları bul") hem de karmaşık ("Beni 'x' müzik türüne sahip olayları bul ve mevcut olan 'z" yarıçapında' y 'maliyetiyle bul konum ") sorgular. Veriler, kullanıcılar tarafından bir web formu kullanılarak gönderilecektir.

Tanımlanan JSON şemasından muhtemelen söyleyebileceğiniz gibi, başlangıçta bu verileri depolamak için JSON nesnelerini kullanacaktım, ancak verilerim tamamen ilişkisel olduğundan, eski yöntemlere bağlı kalmam gerektiğini söyleyen bazı insanlardan duydum.

İhtiyaçlarım doğrultusunda her yaklaşımın artıları ve eksileri hakkındaki düşüncelerimi takdir ediyorum. Eğer net bir şeye ihtiyacınız olursa, lütfen sormaya çekinmeyin.

{
    "event": {
        "eventID":{
            "type":"string"
        },  
        "eventType":{
            "type":"array",
            "eventTypeItem":{
                "type":"string"
            }
        },
        "eventName":{
            "type":"string"
        },      
        "eventDescription":{
            "type":"string"
        },
        "eventVenueList":{
            "type":"array",
            "eventVenueListID":{
                "type":"integer"
            }
        },
        "eventURL":{
            "type":"string"
        },
        "eventTwitter":{
            "type":"string"
        },
        "eventFB":{
            "type":"string"
        },
        "eventInstagram":{
            "type":"string"
        },
        "eventEmail":{
            "type":"string",
            "format":"email"
        },
        "eventContactPerson":{
            "type":"string"
        },
        "eventDoorTime": {
            "type":"string",
            "format":"date-time"
        },  
        "eventPerformerIDList":{
            "type":"array",
            "liveMusicPerformerID":{
                "type":"integer"
            }
        },  
        "eventSetList":{
            "type":"array",
            "eventPerformerID":{
                "type":"integer"
            },
            "eventPerformerStartTime":{
                "type":"string",
                "format":"date-time"
            },
            "eventPerformerEndTime":{
                "type":"string",
                "format":"date-time"
            }                                   
        },
        "eventDateList": {
            "type":"array",
            "eventDateItem": {
                "type":"string",
                "format":"date-time"
            }   
        },
        "eventDateStartTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventDateEndTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventTicket":{ 
            "type":"array",
            "eventTicketType":{
                "type":"string" 
            },
            "eventTicketLowPrice":{
                "type":"number"
            },
            "eventTicketHighPrice":{
                "type":"number" 
            },
            "eventDatesAdvancePrice": {
                "type":"number"
            }   
        }
    },  
    "performer": {
        "performerID": {
            "type":"integer"
        },
        "performerType": {
            "type":"string"
        },
        "performerName": {
            "type":"string"
        },
        "performerAlternateName": {
            "type":"array",
            "performerAlterateNameItem":{
                "type":"string"
            }
        },
        "performerGenreList": {
            "type":"array",
            "performerGenreItem":{
                "type":"string"
            }
        },
        "performerURL": {
            "type":"string"
        }                                       
    }
}   

Site gereksinimlerini bilmiyorum, ancak aramak istediğim: sanatçı, mekanlar ve muhtemelen tarihler. Dizi türlerinde tutuldukları için bu bir problem olur mu?
JeffO

Sorgunuzu ilgili dizideki değerleri aramak için programlayamadınız mı?
zgall1

13
JSON bir depolama formatı değil. Doğru, verileri metin öğelerini kullanarak ancak en basit senaryoların altında depolayabilirsiniz. JSON'un ilişkisel veritabanlarından daha "yeni" olması, kararınızla hiçbir ilgisi yoktur.
Robert Harvey,

1
Depolama formatı olmadığını biliyorum. Yani, JSON formatlamasıyla verileri depolamak için MongoDB veya Postgre'nin JSON nesnesini kullanabilirim.
zgall1

2
@RobertHarvey ve seçmen, günümüzde (2017) 'de JSON olan bir mağaza formatı : bkz PostgreSQL 9.6+ ~ 2012, profesyonel beri ... Basic ve son 2015 (JSONb veri türü) beri olgunlaşır.
Peter Krauss

Yanıtlar:


45

Sorunuzun gerçekten azaldığını düşünüyorum: Ne zaman RDBMS'ye karşı NoSQL yaklaşımı kullanmalıyım? JSON'a erken yerleştiniz (NoSQL-ish kararı), belki de Ajax tüketicileriniz olabilir.

Tabii ki, ne zaman NoSQL yaklaşımlarını kullanacağınıza ve RDBMS'lere cevap vermenin cevabı, temelde ne tür verilerle çalıştığınız ve hangi tüketicilere sahip olmayı beklediğinizle ilgilidir. Verileriniz esas olarak ilişkisel ise (oldukça düz hiyerarşiler, görüntü veya ses gibi garip veri türleri yoksa, anahtarlarda kolayca tanımlanabilen şemalar arasında öngörülebilir ilişkiler) ve tüketicilerinizin sonunda Business Intelligence sorguları yapmak isteyen kişileri içermesi beklenir (geçici sorgulama), daha sonra bir RDBMS gitmek yoludur. Bir sorguyu JSON temsiline dönüştürmek oldukça kolaydır, bu nedenle Ajax tüketicilerinize önemli bir yük getirmez - sadece uç noktalarınıza kodlama yapan küçük bir dönüşüm ekler (REST / SOAP / neyse). tersineVerileriniz çok hiyerarşikse (derin şemalar), görüntüler, ses, video vb. gibi garip veri türleri içeriyorsa, varlıklar arasında çok az ilişki vardır ve son kullanıcılarınızın BI yapamayacağını biliyorsunuzdur, sonra NoSQL / saklama JSON uygun olabilir.

Tabii ki, bu genel kurallar bile sağlam değil. Nedeni Google'ın Google dosya sistemi, mapreduce (iş Yahoo Hadoop inşa etmek Doug Cutting tarafından kullanılmıştır) geliştirdi ve kesin idi sonradan BigQuery'yi (büyük ölçekli veri yönetmenin NoSQL odaklı [şemasız] yol) çünkü onlar ad hoc bir sürü vardı BI talepleri ve yönetmeye çalıştıkları tera / peta / exa / zetta / yotta ölçeklerine ölçeklendirme için ilişkisel yaklaşımlar alamadılar. Tek pratik yaklaşım, bir RDBMS'nin sağladığı bazı geçici kullanıcı kullanım kolaylıklarından ödün vermek, verilen herhangi bir sorgu için oldukça kolay bir şekilde kodlanabilen basit bir algoritmayı (MapReduce) kullanmaktır.

Neden: sorum temelde olacağını yukarıdaki şema Verilen olmaz bir RDBMS kullanabilir? Yapmamak için bir sebep görmüyorum. Mesleğimizin moda odaklı değil, mühendislik odaklı olması gerekiyor, bu yüzden içgüdümüz çalışan en kolay çözümü seçmek olmalı, değil mi? Tüketicileriniz Ajaxy ise uç noktalarınızın küçük bir çeviri yapması gerekebilir, ancak verileriniz çok düz görünüyor ve işletme kullanıcılarının müzik etkinlikleri gibi şeyler üzerinde her türlü geçici sorguyu yapmak isteyecekleri görünüyor. etkinliğe en çok geçen yıl başkentimizden 50 mil içinde katıldık?)

'Avukatların elflerine gitme, çünkü hem evet hem de evet diyecekler. - Frodo


“Mesleğimizin moda odaklı değil, mühendislik odaklı olması gerekiyor, bu yüzden içgüdülerimiz seçmeli ...” İYİ çözüm işe yarıyor mu? ;)
Bink

5

Burada aramayacağınız daha fazla husus olduğuna inanıyorum. Burada iki geniş endişe var:

  • Depolama
  • Arama ve Alma

Depolama

Verileriniz için no-sql veya RDBMS mağazası kullanmanın nedenleri hakkında birçok fikir vardır. Yararlı olduğunu düşündüğümüz en önemli maddelerden biri, tam yapısını veya farklı nesne türleri arasındaki ilişkiyi tanımlamaktan endişe etmeden json nesnelerini depoda kolayca tanımlayıp saklayabilmemizdir. NoSql db kullanmanın diğer nedenlerinden bazıları otomatik shard verilerini, konum tabanlı aramaları ve kolay bakımı yapabilme yeteneği olacaktır. Dışarıda birçok NoSql veri tabanı var, benim kişisel tercihim MongoDB. Ancak, daha önce NoSql veritabanını kullanmadıysanız, fikrinizi yeniden bağlamayı öğrenirken kesin bir öğrenme eğrisi vardır. Çoğumuz bir süredir RDBMS kullanıyoruz ve bu alışkanlıktan kurtulmak için bilinçli bir çaba harcıyoruz. Ayrıca, çabalarınızı sürdürürken veri modelinizi yeniden yapmak ve kavramların daha iyi anlaşılmasını sağlamak için kendinizi bulacaksınız. Refactor veya remodel yeteneği projeniz için bir seçenek değilse, zaten en iyi bildiğiniz şeylere bağlı kalmanızı öneririm.

Arama

Kullanılabilir herhangi bir arama sağlamayı düşünüyorsanız , aramalarınızı yapmak için SOLR gibi özel bir metin arama motoru kullanmanızı şiddetle tavsiye ederim . Metin aramaları yavaştır ve birden fazla parçanız varsa, o zaman daha da yavaşlar. SOLR, ağırlıklı arama paragrafları, konum tabanlı aramalar ve daha fazlasını içeren yanan hızlı metin aramalarını destekler. Ancak SOLR, verilerinizin birincil deposu olarak uygun değildir. Bu, etkinlik eklerken veya güncellerken hem birincil veritabanınıza hem de SOLR katmanınıza çift ekleme ve güncelleme için mekanizmalar oluşturmanız gerektiği anlamına gelir. Ayrıca, eski / sona eren olayları kaldırarak SOLR'ı daha sonra güncel tutmanız gerekecektir.

Bu fazladan çalışma gibi görünse de, daha sonra tam metin arama motoru kullandığınız için kendinize teşekkür edeceksiniz. NoSql veritabanlarının veya RDBMS'lerin hiçbiri, SOLR / Lucene'nin performansına ve çevikliğine yakın değildir.


3

Öncelikle, çalışıyorsanız Mağaza bir herhangi depoda JSON veri değil NoSQL veritabanı, ben kesinlikle JSON kullanmak önermem. Bunun nedeni, verilerinizi bir JSON dosyası olarak saklarsanız, örneğin, açmak, ayrıştırmak, döngüden geçirmek, vb. İçin son derece yavaştır.

Başladı, sorunuzu daraltabilirim: NoSQL ve RDBMS'nin artıları ve eksileri nelerdir? Ve zaten internette binlerce kez cevaplandı '.

Projenizi yeniden düzenleyerek, elbette NoSQL veya RDBMS kullanabilirsiniz ; Ancak, size genel olarak önerebileceğim şey, kutunun dışında düşünmek ve iki seçenek arasında karar vermenize yardımcı olabilecek daha az görünür diğer faktörleri aramak. Hangi seçeneğin gelişimi hızlandıracağını görmeye çalışın mı? Diğer takım üyeleri için daha uygun olan - tek bir geliştirici değilseniz. Bunu satıyorsanız, hangisi daha ucuz, daha kolay ve genellikle geliştirici olmayan müşterileriniz için daha uygun?

Bu şekilde nihayet hangi yöne gideceğinize karar verebilirsiniz, aksi takdirde her iki seçenek de oldukça uygun olabileceğinden, verilen bilgilere dayanarak karar vermek gerçekten zor olacaktır.


2

Çoğu uygulamada yapılması gerekenler vardır.

  1. Verileri girin, bir miktar işlem yapın, verileri kaydedin, verileri alın ve verileri sorgulayın. Veriler hakkında raporlar oluşturmak için de bir gereksinim olabilir.
  2. Sistemin farklı bölümleri arasında veya harici sistemlerle veri değişimi yapın

Öğe 1 için gereklilikleri elde etmek için kalıcı bir veri yöntemi gereklidir. Genellikle veri hacmi çok küçükse ve veri türü basitse ve kapsamlı arama özellikleri gerektirmiyorsa, basit bir dosya yapısı kullanılabilir. Veriler daha karmaşık hale geldikçe, hala dosyalarda depolanan verilerde bir XML (hatta JSON) yapısı kullanılabilir. Yine de arama yapmak daha problemli hale geliyor. Veri hacmi arttıkça ve aramaların karmaşıklığı arttıkça, normalde veri kalıcılığı, sorgulama vb. İçin endüstri standardı yöntemler sunan bir veritabanı seçilir. .

Öğe 2'deki gereksinimleri yerine getirmek için, XML, JSON vb. Sistemler arasında veri alışverişine izin vermek için çeşitli yöntemler vardır.

Bu yöntemler veri yapısının bir kullanıcı tarafından tanımlanmasına izin verir ve farklı sistemin veri alışverişinde bulunmasına izin veren dilden bağımsızdır.

Özel durumunuzda doğru bir şekilde JSON kullanıyorsanız, bir dizi müzik olayını tanımlamaktır. Verileri JSON biçiminde saklayabilmenize rağmen, bu etkinliklerde müzik olaylarının sayısı arttıkça arama yavaş ve verimsiz olacaktır.

Endişeler ayrımı yaklaşımını kullanarak daha iyi yaklaşım, verileri toplamak, bir veritabanında saklamak, veritabanındaki kullanıcı girdisine dayanarak sorgunuzu gerçekleştirmek ve sonuçları görüntülemek için JSON biçiminde sonuçları Müşteri tarafına döndürmektir.

JSON yaklaşımındaki ek bir problem de değişen veri yapılarıdır. Şu anda yapınız nispeten basit. Bu yapıyı birkaç ay boyunca kullanabilirsiniz ve ardından ek bir alan tanımlanır. Daha sonra mevcut tüm JSON nesnelerinizle ne yaparsınız? Bunları güncellemek sorunlu olurdu.

Bir veritabanı kullandıysanız, ek bir alan eklemek nispeten basittir ve yalnızca JSON'u oluşturmak için kodunuzun tek bir yerde değiştirilmesi gerekir, böylece yeni alanla birlikte tüm yeni JSON'unuzu verirsiniz.

Kısaca, veri değişimi için JSON için tasarlananlar için her teknolojiyi ve veri kalıcılığı için bir Veritabanını kullanın.


0

Yapmanız gereken sorgular nedeniyle NoSQL'i SQL kullanarak SQL'den daha iyi başaracağınızı düşünüyorum.

Ayrıca, sadece bazı verilerin tamamen ilişkisel olması, artık bazı RDBMS’lerde (SQL) sürdürülmek zorunda olduğu anlamına gelmez. IMO ilişkisel verileri grafik veritabanlarına daha iyi çevrilebilir.

Elbette sorguları SQL'de de yazabilirsiniz, ancak ihtiyacınız olan birleştirme sayısı nedeniyle performans kötüye gidecek (verilerinizin biraz normalize olacağı ve hepsinin tek bir Etkinlik tablosuna eklenmeyeceği göz önünde bulundurularak).

Ancak, sonuçta, zaten ısrarlı verileri hesaba katmadan, şemanızı değiştirebileceğinizi düşünerek NoSQL (böylece JSON veya veritabanının desteklediği başka bir format) kullanarak daha fazla özgürlüğe sahip olacaksınız.

Çok karmaşık sorguları kullanmayı planlıyorsanız, NoSQL'i göz önünde bulundurarak grafik veritabanlarına da bakabilirsiniz, çünkü bunlar size kolay bir şekilde oluşturma ve çok hızlı bir şekilde çalıştırma konusunda avantajlar sağlayacaktır.


0

Bence ikisini de kullanmalısın ve ben bunu 'karşı' bir karar olarak görmüyorum.

İlişkisel bir veritabanı, ilişkisel özelliklere sahip verilerin hızlı ve verimli depolanması ve alınması için anlamlıdır.

JSON mükemmel bir veri biçimidir, çünkü basit, hafif ve ham verilerin etrafından dolaşmak ve metin bilgilerinin depolanması ve değiş tokuşuna uygun bir sözdizimi ile çok basit bir formatta dolaşmak için idealdir. Tarayıcı ve sunucu arasında az miktarda veri iletmek için mükemmeldir. İlişkisel tip veri sorguları için kullanmaya başlamak bu kadar kolay bir biçimde değil.

Bu yüzden veri depolama için SQL ve veri taşıma formatı için JSON tavsiye ederim.

Mongo, Redis, vb. Gibi hiçbir SSL kod-değer seçeneği olmadığı doğrudur. Bunlar JSON formatına göre daha basit haritalama avantajına sahip olacak, ancak genellikle sorgularda kullanmak biraz daha zor olacaktır. Onlarla olan temel engel, genel BT topluluğu tarafından özellikle çok iyi bilinen ve akla gelebilecek her durum için mevcut olan çok sayıda kaynak ve bilgi dizisine sahip olan SQL ile karşılaştırıldığında aşina olmamadır.


NoSQL anahtar-değer depolama yönteminin sorgularda nasıl kullanılacağına dair iyi bir anlayışa sahip bir programcı bulsaydım, JSON'u veri depolama formatı olarak kullanmakta aşılması gereken en önemli zorluk olduğunu söyler miydiniz?
zgall1

Bahse girerim ki, sadece veri yapısının avgdan fakir / fakir olması nedeniyle olabilir. geliştiriciler ilişkisel veritabanı olduğunu biliyor. Bu, geliştiricilerin ortalama kalitesiyle ilgilidir ve öğrenmekten kaçınmayı nasıl öğrendikleriyle ilgili olarak, NoSQL ilişkisel olmayan veriler için doğru seçim olacaktır ... aslında her zaman, verilerinizin gerçekten olmadığını varsaymak, geliştiriciler için genellikle daha kolaydır. -relational. AMA, doğru DB seçimini yapmanız gerekir, NoSQL ilk tercihi yapar ya da bozar .. ve verilere ne kadar iyi uyduğunu.
JM Becker,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.