Alanların yeniden kullanılması ile alan ölçeklenebilirliği bağlamında yenileri oluşturmak arasında iyi bir denge var mı?


34

Bir web sitesinde aşağıdaki ifadeyi okudum:

Bir içerik türüne yeni alanlar eklemek yerine, mevcut alanları eklemek sistemin karmaşıklığını azaltmak ve ölçeklenebilirliği artırmak için daha iyi bir seçenektir.

Ve bazı şüpheler ortaya çıkar.

Geliştirmekte olduğumuz sistemde, bir alanı 3 veya 4 içerik türünde yeniden kullanma olanağımız var, ancak belirtilen cümlenin dediği gibi ölçeklenebilirliği geliştirmek yerine, alanın daha hızlı bir tıkanıklığa neden olacağı için onu azaltacağından korkuyorum (en azından bu durumda benim düşüncem, o alanın tüm değerleri bir arada olduğu için yılda bir kaç milyon olacaktır ve bu da masayı çok büyük yapar). Katılıyor musun?

Mimarlık yaparken kaç tane satır hedeflenebilir bir maksimum olacaktır? Bu şekilde ne zaman alanları ne zaman kullanacağınıza ve ne zaman yeni alanlar oluşturacağınıza karar verebiliriz (yeniden kullanma şansı olsa bile).


6
Gerçek ölçütlerle desteklenmiş cevapları görmeyi çok isterim.
mpdonadio

Bu soru hakkında çok yapıcı ve bilgilendirici yorumlar topladığımızı düşünüyorum. Ancak, cevaplandırılmış olarak işaretlemeden önce bir veya iki gün bekleyeceğim, içimdeki bir şey, en çok bir veya iki ağır alanı ayrı tutmanın (tekrar kullanılabilse de) iyi bir fikir olabileceği konusunda ısrar ediyor :) fileds, yılda 5, 10 veya 20 milyon ürün kolayca büyüyebilirdi.
rafamd

Yanıtlar:


24

Bir alandaki veri miktarı genellikle bir sorun değildir. Bunun için endişeleniyorsanız, alternatif saha depolama eklentilerine bakın veya kendinizinkini yazın. Örneğin , içine koyduğunuz hemen hemen her şeyle başa çıkabilecek MongoDB . Örneğin, http://examiner.com adresinde kullanılır .

Bir gerçek sorun ancak sahip alanların sayısıdır. Çünkü şu anda Drupal 7'de, yüklenen olsun veya olmasın tüm alanların tam alan yapılandırması , her bir istek için önbellekten alınır.

250'den fazla alana sahip siteleri gördüm, alan konfigürasyonunun yüklenmesi ve seri hale getirilmesi 13 MB + bellek gerektiriyor.

Düzenleme: Drupal 7.22 ile alan bilgisi önbelleği iyileştirildi ( ayrıntılar için http://drupal.org/node/1040790'a bakınız), yalnızca belirli bir sayfada görüntülenen paket alanları önbellekten yüklenir ve önbellek girişlerini ayır. Bu sadece birden fazla paket üzerinde örnek talep eden yanlış API çağrıları yoksa işe yarar.


Merhaba Berdir, cevabınız için teşekkürler. Tarla sayısı için bu ek yükü bilmiyordum. Öyleyse, mümkün olduğunca tekrar kullanmaya çalışmalıyız, ama yine de en ağır olanlar olduğunu bildiklerimizi bölmeye çalışmamalı mıyız? Mongo ve benzerleri hakkında fazla bir şey bilmiyorum ama sorgulamaları gereken grubun büyüklüğünü umursamıyorlar mı? Teşekkürler !
rafamd

Aslında bilmiyorum. Bağlıdır, sanırım. MPD'nin önerdiği gibi bir test yapmak kötü bir fikir olmayabilir. Hatta çok düşük seviyeyi doğrudan Mysql'de karşılaştırabilirsiniz. Aynı veri düzenine sahip iki tablo oluşturun ve alan veri tablolarıyla indeksleyin, 10m yazın (aslında entity_id için farklı değerler kullandığınızdan emin olun) satırları ikinciye bir ve 5m. Ardından yazma performansını karşılaştırın ve performansı okuyun (entity_id aka bir indeks temelinde). Endeks sayesinde okuma performansının neredeyse eşit olacağından şüpheleniyorum, ancak yazma performansı bir fark yaratabilir.
Berdir

Bununla birlikte, bir avuç tarlaya az veya çok sahip olmak gerçekten bir fark yaratmayacaktır, bu yüzden daha rahat hissederseniz, bu bir sorun olmamalıdır.
Berdir

Yazma zor kısmıdır, bu yüzden bir test yapma önerim var. Karşı karşıya gelebilecek bir şey, MySQL'in tabloya göre değil, satırlara göre önbelleğe alınmış girdileri bırakmasıdır (en son kontrol ettiğimde). Hangi etkinin daha fazla olacağından emin değilim, çoklu alanların ve tabloların ek yükü ya da yazımdan aynı tabloya önbellek özeti. Yine de kesinlikle trafik / kullanıma bağlıdır. Çoklu önbellekli sistemler (Drupal önbellek, APC opcode, APC kullanıcısı, MySQL sorgu önbelleği, memcached, vernik, vb.), Bağırsak tabanlı kararları profillemeden zorlaştırır.
mpdonadio

artık durum böyle değil: drupal.org/node/1040790
jackbravo

13

Berdir’e tamamen katılıyorum. İşte bazı düğüm tiplerinde milyonlarca satır ve 30-40 alan içeren bir projeyle ilgili deneyimlerim.

  1. Alan tablosundaki satır sayısı, tüm alanlar birincil anahtar tarafından alındığından, okuma performansı için büyük bir sorun değildir.
  2. Düğüm türü başına düşen alan sayısı, yeni düğümler yazarken hızla büyük performans sorunlarına dönüşebilir. Bir düğüm türü için 30+ alana sahip olmak , yeni bir düğüm oluşturduğunuzda 60+ INSERT ifadesine yol açar. Bu işlemin tamamlanması birkaç saniye sürer. Çok fazla veri oluşturan kullanıcıysanız, bu performansınıza varacaktır. 1000 düğümün toplu eklemeleri neredeyse bir saat sürecek. 100.000 düğümü güncellemeniz gerekiyorsa, bu büyük bir sorundur.
  3. Alan sayısı sorununun size çarpacağını düşünüyorsanız, kendi alan depolama alanınızı yazmayı ya da sadece alan kullanmamayı düşünmelisiniz. (Düğümünüzü biraz fazla çaba göstererek görünümlerle çalışmaya devam ettirebilirsiniz.)
  4. MongoDB hakkında bir kelime. Bu çok ilginç bir proje ve umarım büyük DB'lerin olimpiyatına giriyordur. Maalesef MySQL veya PgSql'nin vadesine göre bir bebek. Çok genç bir ürünle baş etmeye hazır olun.

Merhaba @BetaRide, anlayışınız için teşekkürler. Yaklaşık 2), içerik türü başına düşen alan sayısını en aza indirmeye çalışıyoruz ve bu tam olarak burada tartıştığımız şey değil. Asıl mesele şudur: mümkün olduğunda alanları kör olarak yeniden kullanmalı mıyım veya en azından bir veya iki kişiyi ayrı tutmaya çalışmalı mıyım (kolayca aynı olabilirlerse bile: aslında aynı isme sahipler, vb.). Evet, mongo şu an için son alternatifimiz olmalı :)
rafamd

5

Ne olacağı konusunda gerçekten endişeleniyorsanız, bir simülasyonun uygun olduğunu düşünüyorum.

Rackspace Cloud, Amazon, Linode veya VPS'yi kolayca döndürebileceğiniz başka bir yerde bir hesap edinin. İki özdeş örnek oluşturun. Her birine Drupal yükleyin. Bazı yapay içerik türleri oluşturun ve alanları bir sistemde bir şekilde, diğerini diğerinde ayarlayın. Bir tekne dolusu içerik oluşturmak için devel modülünü kullanın. Drupal'ın gerektiğinde önbelleğe aldığından emin olmak için performans ayarlarını düzenleyin. Mysqltuner'ı çalıştırın ve her bir tavsiye için MySQL'i ayarlayın. PHP ve APC ayarlarını iki kez kontrol ederek, takas isabet etmemek ve APC önbelleğini çalkalamamak için kullanın.

Her biri için iyi bir temel konfigürasyon elde ettikten sonra, trafiği (normal ziyaretçiler ve yönetici güncellemeleri) wget ve drush ile simüle etmeye başlayın ve ardından profile.

Simülasyonlar asla mükemmel değildir, ancak sizi doğru yöne doğru ilerletebilirler.


2

Oluşturulan tablodaki her alandaki her bir tablo alanındaki dizinlerin kullanıldığı alanlardaki ölçeklendirilebilirlik ile ilgili bir sorun. Birincil anahtar kümelenmiş dizin, alanların çoğunun bir birleşimidir, daha sonra her bir alanda ayrı ayrı dizinler oluşturur. Endeksler, veri tabanı için bir ton genel gider yazısı oluşturur ve çoğu durumda asla kullanılmaz.


2

Başka bir ipucu: Çok fazla alana sahip olmak, birçok farklı modülde de sorunlara yol açacaktır. Örneğin Token GUI, örneğin url takma adlarını düzenlemeyi denerseniz tarayıcınızı dakikalarca geciktirir. Bu davranış, belirtecin yükleneceği ve görüntüleneceği tüm sayfalarda görülebilir (devel - dpm () vb. Dahil)

InnoDB kullanılırken bu verilerin birden fazla tabloya bölünmesinde performans avantajı yoktur (MyISAM, masa kilitleme nedeniyle farklıdır). Öyleyse - benzer alanlarla çok sayıda benzer içerik türüne sahip olduğunuzu biliyorsanız (bu yapılandırmalar aynı olacaktır, sadece etiketlemede farklı olabilir) alanlarınızı yeniden kullanın!

Benzer düğüm öznitelikleri nedeniyle şablon oluşturma işlemlerini de kolaylaştırabilir.


1

Hikayemi paylaşırken, Drupal Commerce kullanıyoruz ve ürün çeşitlerimizde (Sku) yaklaşık 40 alanımız ve ardından Ürün Teşhirimizde bir başka 460 (evet, çılgın) var. Tüm bu alanlara bakacak ürün karşılaştırma görüşlerimiz vardı. Önbelleğe alma olmadan, bazı sayfa yükleri bir dakika kadar sürebilir!

Ancak, işe yaradı. Önbelleğe alma ve Vernik kullandıysanız, kullanıcı bekleme süresi o kadar da kötü değildi.

Bir çok alanda karşılaştığımız asıl sorun, bir alanı yeniden düzenlemeye ya da hareket ettirmeye kalkıştığımızda, çok yavaş olacağından (bazen yanıt vermeyen) Display Suite ile ilgilidir.

Neyse ki, ürünlerimizi biraz yeniden belirlemeye karar verdik, böylece en karmaşık ürünlerimiz için maksimum alan sayımızı 200-250 aralığına indirebiliriz (bilimsel enstrümantasyondayız, bu nedenle karmaşık ölçümler ve özellikler gereklidir) .


0

Bu ilginç bir soru. Bunu daha önce düşünmüştüm, bazen bir alanı tekrar kullanmak, 'etrafta yatar' benzer alanlara sahip olmamak için uygun olabilir, ancak büyük miktarda veri yükünden seçim yapmak zorunda olan belirli bir içerik türüne sahip olmak aptalca görünüyor. bilmek sonuçta iade edilmek değildir.

Ölçeklendirme için en iyi uygulama hakkında önerilerde bulunmak için proje hakkında biraz daha bilgiye ihtiyacım var. Beklenen trafik nedir, bu kullanıcıların kaç tanesinin giriş yapması vb? Örneğin, yönetici kullanıcılarınız dışındaki tüm trafiklerin kimliği doğrulanmamış ve adsız olarak önbelleğe alınmışsa


Merhaba @ drupaljoe, Cevabınız için teşekkürler. Beklenen trafiği tahmin etmek zordur, çünkü yepyeni bir site. Çok dikkatli bir şekilde geliştiriliyor ve bir tür başarı bekliyoruz, bu nedenle diyelim ki birkaç yüz eşzamanlı kullanıcının (çoğu kimliğinin doğrulanması) var. Tam olarak düşündüğüm şey buydu, bu devasa masanın sorgulanması bir acı olmalı, bu yüzden fazla büyümeyecek alanları yeniden kullanmak ve daha fazla veri tutacak alanları ayırmak için mimar oluşturmalıyız. Ne çok fazla düşünülebilirdi? 1 milyon ? 100 milyon ? 300 milyon ? ...
rafamd

Bence diğer ikisinin ne kadar önemli olmaması gerektiği konusundaki yorumları, çünkü seçimlerin birincil anahtarda olması iyi noktalar. Sanırım şimdilik bununla devam edeceğim, ancak gelecek için seçenekleriniz, alanlar için mongo vb. Hakkında biraz okuma yaptığınızdan emin olun. Sitenizin geleceği hakkında her zaman ikinci tahmin edemezsiniz
joevallender

0

Şimdiye dek tarlaları her zaman yeniden kullanıyordum, ancak şimdi yeni bir proje için düğüm türü başına benzersiz alanlar kullanmayı düşünüyorum. Aslında her varlık paketi için her şeyi güzelce ayrı alanlara (alanlar, görünümler, kurallar, bağlamlar, vb.) Tutmak istiyorum. Bu yüzden beni burada yönlendiren ölçeklenebilirlik sorununu gündeme getirdi. Berdir'in (Alan bilgisi önbelleği, Drupal 7.22 ile geliştirildi (bkz. Http://drupal.org/node/1040790 ), Drupal 7.22 ile, yalnızca belirli bir sayfada görüntülenen paket alanlarından yüklenmiştir. önbellek ve bunlar ayrı önbellek girdileridir. Bu, yalnızca birden fazla paket üzerinde örnek talep eden yanlış API çağrıları yoksa çalışır.

Sadece aylardır kullandığım çok sayıda karmaşık sitede çok ilginç bir modül olduğunu belirtmek istiyorum . : https://www.drupal.org/project/render_cache . Bence bu gizli mücevherlerden biri.

Proje sayfasında yazdığı gibi, yorumlar bölümü aslında DO'nun üzerinde kullanılıyor.

Öyleyse, bütün bunları göz önünde bulundurarak, fikir birliğini ayrı alanlar lehine çevirir mi? Yine de, DS hakkında bahsettiğim ihtar yine de bir serseri. Çekirdek blok yönetimi arabiriminin yeniden sipariş işleme biçimini yerine, ajax aracılığıyla kaydetme biçimini süper derecede rahatsız ediyor. Bunun bir ds sorunu olduğunu düşünüyorum ...


-3

Önerilerime göre Ayrı içerik türünde aynı alanları kullanmak iyi bir fikirdir. Çünkü sitenizin performansını artıracak. Drupal 7'de, o zaman seçim işlemini kullanırken, içerik türündeki aynı alanları kullanmak gerçekten Drupal7 siteniz için kullanışlıdır.


1
Drupal 7'de Doctrine ORM kullanmaya başladılar ... hayır yapmadılar. Drupal 8, Doctrine
Clive

"Doktrin her zaman tüm haritalanmış verilerden nesneyi döndürür", ayrıca yanlış bir ifadedir. Nesnelere, varsayılan davranışın uygun olmadığını doktrinine göstermek için açıklama eklenebilir. Clive’nin dediği gibi Drupal’ın Doctrine’ı kullanmadığı göz önüne alındığında, bunun konu ile ilgili olduğu söylenemez.
Letharion
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.