Hstore ile indeksleme özellikli JSONB

Bu aşamada, veritabanı tasarımına karar vermeye çalışıyorum (web uygulamasının gerçekte nasıl geliştiği).

İlk adım olarak, JOINS'in pahalı olduğunu anlamak, çok sayıda normalize edilmiş küçük masanın aksine az sayıda monolitik masayı düşünüyorum. İkinci bir nokta olarak, hstore ile normal tabloları vs JSONB (GiST indeksleme ile) kullanmak arasında kafam karışık.

AFAIK (düzeltmek için çekinmeyin):

Genellikle Postgres'te hstore'un diğer veri türlerinden daha iyi performans gösterdiği bilinmektedir. FOSDEM PGDAY'ın bu sunumunda bazı ilginç istatistikler var (slaytların ikinci yarısında). https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
Hstore ile bir avantaj hızlı indeksleme (GiN veya GiST). Bununla birlikte, JSONB ile, JSON verilerine GiN ve GiST indekslemesi de uygulanabilir.
2. Çeyrek'teki bir profesyonelden gelen bu blog "Bu noktada muhtemelen tüm yeni uygulamalarda hstore kullanımını jsonb ile değiştirmeye değer" ( http://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary) -jsonhstore devingen sütun /

Bu yüzden aşağıdakilere karar vermek istiyorum:

Verilerin ana (yapılandırılmış) kısmı için: Birkaç ilişkisel tabloya mı girmeli (birçok sütunla nispeten büyük) veya hstore'u kullanan bir kaç anahtar-değer depoda mı olmalı?
Özel (kullanıcı katkısı yapılmış / yapılandırılmamış) verileri için, hstore'da JSON'da mı yoksa geçici anahtar değeri depolarında mı (ana ilişkisel tablolardan birinde saklanan anahtarlarla) olmalıdır?

postgresql database-design

— Yogesch
kaynak

Katılmaları pahalı değil. Bunu sana kim söyledi? Temel olarak tüm ilişkisel veritabanları kavramı, birleşme yerleri etrafında (pratik bir bakış açısıyla) döndüğü için, bu ürün birleştirme konusunda çok iyidir. Normal düşünme şekli, düzgün biçimde normalize edilmiş yapılarla başlamak ve performansın gerçekten okuma tarafında ihtiyaç duyduğu durumlarda süslü denormalizasyonlara ve benzeri şeylere girmektir. JSON(B)ve hstore(ve EAV) bilinmeyen bir yapıya sahip veriler için iyidir.

— dezso,

@Yogesch, bu bağlantılar bazı ilginç ve çılgınca çelişkili şeyler içeriyor :) Ahlaki olarak, MySQL'in katılımda kötüydü ve NoSQL çalışanları bu fikri herhangi bir fiili temele dayanmadan genelleme eğilimindedir. Öte yandan, Aaron ve Max bu p-kelimeye karşı hassastır - geniş kullanımı, anadili olmayan konuşmacıların (kendim dahil) nasıl yanlış kelime kullandığını gösterir.

— dezso

@Yogesch gerçekçi bir şekilde internette bir şeyi "kanıtlamak" için bir kaynak olduğundan eminim, tıpkı herhangi bir dini metnin vahşet haklılaştırmak için kullanılabileceği gibi (tarih boyunca çarpıcı biçimde gösterildiği gibi). Ne kadar az iş yaparsan o kadar az masraflı olur, ama her zaman biraz takas olur .

— Erik

@Yogesch: Veri erişim düzenini önceden bildiğiniz okuma ağırlıklı işlemler için birleştirme işleminden kaçınılması önemlidir, böylece ihtiyacınız olan tüm verileri tek bir satıra güvenle koyabilirsiniz. Ancak, bu diğer birleşmeleri potansiyel olarak daha maliyetli hale getirir . Çeşitli soruları cevaplamak için verilere birçok farklı şekilde katılmanız gerekmeyeceğini kim söyleyebilir? Şimdi sadece ilişkisel veri modelleme teorisine

— Chris

@Yogesch Benim uygulamada, veritabanları ile darboğaz nadiren RAM veya CPU ama I / O - bu şekilde gereksiz veri depolamaktan kaçınmak hala önemli bir şey. Chris'in dediği gibi, verilerinizi her zaman yalnızca bir şekilde görürseniz, bu fiyat değerinde olabilir. Değilse, hantal ve oldukça esnek olmayan bir veri yığınına sahipsiniz.

— dezso

İlişkisel veritabanları birleştirme çevresinde tasarlanmıştır ve bunları iyi yapmak için en iyi duruma getirilmiştir.

Normalize edilmiş bir tasarım kullanmamak için iyi bir nedeniniz yoksa , normalize edilmiş bir tasarım kullanın.

jsonbve işler gibi hstorene zaman için iyidir olamaz böyle veri modeli hızla değişen ve kullanıcı tanımlı olması gibi bir normalize veri modelini kullanır.

İlişkisel olarak modelleyebiliyorsanız, ilişkisel olarak modelleyin. Eğer, vb json dikkate yapamıyorsanız Eğer siz arasında bir seçim yapacaksanız json / jsonb değil bir nedeniniz yoksa / hstore, genellikle jsonb seçin.

Blog postamda söylediğim şey buydu , bu sadece bu konuyu ele alıyor. Lütfen tüm yazıyı okuyun . Alıntı yaptığınız paragraf , dinamik bir yapı seçtiyseniz, hstore'dan jsonb'u seçmeniz gerektiğine işaret eder, ancak blog gönderisinin geri kalanı, genellikle neden yapabiliyorsanız ilişkisel olarak modellemeyi tercih etmeniz gerektiği ile ilgilidir.

Yani. Ana yapısal bölümü ilişkisel olarak modelleyin. Tablolar çok fazla sütunla gerçekten genişse, bu daha fazla normalleşmenin gerekli olduğunun bir işareti olabilir. Katılmadan korkma. Katılmayı sevmeyi öğren. Birçok küçük masaya katılmak çoğu zaman büyük denormalize masaları sorgulamak ve sürdürmekten daha hızlı olacaktır. Sadece belirli durumlar için ve tercihen maddi görüşler aracılığıyla ihtiyaç duyuyorsanız denormalize edin ... fakat çözmeniz gereken gerçek bir somut probleminiz olduğunu bilmeden bunu yapmayın.

Serbest biçimli ve yapılandırılmamış kullanıcı tarafından eklenen veriler için, jsonb kullanın. Mağazada olduğu kadar iyi performans göstermeli, fakat çalışması daha esnek ve daha kolay.

Anlaşılması gereken bir konu var: jsonb'da kullanılanlar gibi GiST ve GIN endeksleri , normal bir b-ağacı endeksinden çok daha az etkilidir. Daha esnektirler, ancak normal bir sütundaki b-ağacı endeksi neredeyse her zaman çok, çok daha hızlı olacaktır.

— Craig Ringer
kaynak

Çok teşekkürler Craig, şimdi çok daha iyi bir anlayışa sahibim ve ne yapacağımı biliyorum. Bir takip sorusu: Eğer beğeniler veya takipçiler gibi bir şeyi iki sütun formatında (post_id ve user_id, beğeniler gibi ) saklıyorsam, iki sütunlu bir ilişkisel tablo kullanmak mı yoksa bir mağaza kullanmak daha mı iyidir? (Bunu yeni bir soru haline getirmeyi umursamıyorum)

— Yogesch 23:15

@Yogesch Bog-standart m: n gibi sağlam ve sağlam bir formatta birleştirme masasına benziyor. Soru her zaman "Bunu , bu özel durum için olağan ilişkisel şekilde yapmamam için iyi bir neden var mı?" Olmalı.

— Craig Ringer

hstorekullanımdan kaldırıldı. Kullanın jsonb.

— tehlike89

@ danger89 Aslına bakarsanız resmen onaylanmadı, ancak artık jsonb lehine kullanmak için bir neden olduğunu sanmıyorum. Her durumda ... bu noktayı kaçırıyor. Soru, ilişkisel olarak modellemek veya yapılandırılmış bir veri türünü kullanmak olup olmadığıdır.

— Craig Ringer,