@harrasteblogi JUURI NYT
--:--

Tilaa uutiskirje

Saat tuoreimmat 10 uusinta artikkelia kerran viikossa sähköpostiisi.

Tilaa uutiskirje

WordPressin multisite-tietokantarakenne selitettynäWordPress Multisite mahdollistaa useiden sivustojen ajamisen yhdellä WordPress-asennuksella. Vaikka frontendissä sivustot näyttävät erillisiltä, taustalla ne jakavat saman WordPress-coren, käyttäjäjärjestelmän ja osittain myös tietokannan.

Tiivistelmä
Tavallinen WordPress vs multisite

Normaali WordPress:...

1. Globaalit taulut

Nämä ovat yhteisiä koko verkolle:...

2. wp_blogs

Keskeinen multisite-taulu....

3. wp_site

Määrittää verkon:...

4. wp_sitemeta

Verkkotason asetukset:...

5. Käyttäjät ovat yhteisiä

Kaikki käyttäjät tallennetaan:...

6. Roolit tallennetaan usermeta-tauluun

Käyttäjän rooli on site-kohtainen:...

7. Site-kohtaiset taulut

Jokaisella sivustolla omat:...

9. switch_to_blog()

Keskeinen multisite-funktio:...

10. Object cache multisitessa

Cache keyt sisältävät site-ID:n....

11. wp_options kasvaa nopeasti

Jokaisella siteillä:...

12. Autoload ongelmat

Yleinen multisite-ongelma:...

13. Plugin-kehitys multisiteen

Pluginin pitää huomioida:...

14. Network activation

Kun plugin aktivoidaan verkolle:...

15. Media multisitessa

Media tallentuu:...

16. Suorituskykyhaasteet

Multisite ei automaattisesti skaalaudu hyvin....

17. Cross-site queryt

Huono idea:...

18. Global data architecture

Jos dataa pitää jakaa sitejen välillä:...

19. WooCommerce + multisite

Yksi raskaimmista yhdistelmistä....

20. Multisite ja Redis

Redis tarvitsee:...

21. Backup ja migraatiot

Multisite-backup ei ole triviali....

23. Paras enterprise-arkkitehtuuri

Iso multisite stack:...

24. Yleisimmät virheet

WordPress Multisite rakentuu yhdestä yhteisestä WordPress-asennuksesta, jossa käyttäjät ja verkkotason data ovat globaaleja, mutta sisältötaulut eriytetään site-ID:n perusteella....

Yhteenveto

WordPress Multisite rakentuu yhdestä yhteisestä WordPress-asennuksesta, jossa käyttäjät ja verkkotason data ovat globaaleja, mutta sisältötaulut eriytetään site-ID:n perusteella....

Monisite näyttää yksinkertaiselta käyttöliittymässä, mutta tietokantarakenne muuttuu huomattavasti monimutkaisemmaksi verrattuna tavalliseen WordPress-asennukseen. Ilman ymmärrystä rakenteesta syntyy helposti:

  • hitaita queryjä
  • väärää datan käsittelyä
  • plugin-yhteensopivuusongelmia
  • skaalautuvuushaasteita
  • vahingollisia migraatioita

Kun rakenne ymmärretään oikein, multisite voi skaalautua erittäin suuriin ympäristöihin tehokkaasti.

Miten multisite toimii arkkitehtuuritasolla

Perusidea:

1 WordPress Core
↓
Useita sivustoja
↓
Yhteiset käyttäjät
↓
Site-kohtaiset taulut

Kaikki sivustot käyttävät samaa:

  • WordPress-asennusta
  • plugin-kantaa
  • teemakantaa
  • käyttäjäjärjestelmää

Mutta sisältötaulut eriytetään site-ID:n perusteella.

Tavallinen WordPress vs multisite

Normaali WordPress:

wp_posts
wp_options
wp_postmeta

Multisite:

wp_2_posts
wp_2_options
wp_2_postmeta

wp_3_posts
wp_3_options
wp_3_postmeta

Jokaisella sivustolla oma “mini-WordPress”.

1. Globaalit taulut

Nämä ovat yhteisiä koko verkolle:

wp_users
wp_usermeta
wp_site
wp_sitemeta
wp_blogs
wp_blogmeta
wp_registration_log
wp_signups

2. wp_blogs

Keskeinen multisite-taulu.

Sisältää:

  • site ID
  • domain
  • path
  • status

Esimerkki:

blog_id = 7
domain = example.com
path = /shop/

WordPress käyttää tätä routingiin.

3. wp_site

Määrittää verkon:

network-level config

Yleensä yksi network, mutta mahdollista useampi.

4. wp_sitemeta

Verkkotason asetukset:

  • network admin config
  • global plugin settings
  • multisite flags

5. Käyttäjät ovat yhteisiä

Kaikki käyttäjät tallennetaan:

wp_users

Tämä on tärkeä ero tavalliseen WordPressiin.

Yksi käyttäjä voi kuulua:

  • yhteen sivustoon
  • useisiin sivustoihin
  • koko verkkoon

6. Roolit tallennetaan usermeta-tauluun

Käyttäjän rooli on site-kohtainen:

wp_2_capabilities
wp_5_capabilities

Sama käyttäjä voi olla:

Admin sivulla 2
Editor sivulla 5

7. Site-kohtaiset taulut

Jokaisella sivustolla omat:

posts
postmeta
options
terms
term_taxonomy
comments

Prefix muuttuu:

wp_2_
wp_3_
wp_4_

8. Pääsivusto käyttää oletustauluja

Site ID 1 käyttää:

wp_posts
wp_options

Ei:

wp_1_posts

Tämä aiheuttaa usein sekaannusta.

9. switch_to_blog()

Keskeinen multisite-funktio:

switch_to_blog(5);

Vaihtaa:

  • DB-prefixin
  • option contextin
  • cache contextin

Palautus:

restore_current_blog();

10. Object cache multisitessa

Cache keyt sisältävät site-ID:n.

Esimerkki:

site:3:option:home

Muuten data vuotaisi sivustojen välillä.

11. wp_options kasvaa nopeasti

Jokaisella siteillä:

oma wp_options

Suuri multisite voi sisältää:

1000+ options-taulua

12. Autoload ongelmat

Yleinen multisite-ongelma:

autoload=yes kaikkialla

Jokainen sivu lataa oman options-memoryn.

13. Plugin-kehitys multisiteen

Pluginin pitää huomioida:

  • site context
  • network activation
  • switch_to_blog
  • globaalit asetukset

14. Network activation

Kun plugin aktivoidaan verkolle:

plugin käytössä kaikilla siteillä

Mutta data voi silti olla site-kohtaista.

15. Media multisitessa

Media tallentuu:

/uploads/sites/{blog_id}/

Esimerkiksi:

/uploads/sites/7/

16. Suorituskykyhaasteet

Multisite ei automaattisesti skaalaudu hyvin.

Ongelmia:

  • massiivinen wp_options määrä
  • isot usermeta-taulut
  • cross-site queryt
  • cache invalidation

17. Cross-site queryt

Huono idea:

SELECT * kaikista wp_*_posts tauluista

Tämä ei skaalaudu.

Parempi:

  • indexing layer
  • custom global tables
  • search engine

18. Global data architecture

Jos dataa pitää jakaa sitejen välillä:

Älä käytä:

kopioitua post dataa

Parempi:

custom global table

19. WooCommerce + multisite

Yksi raskaimmista yhdistelmistä.

Haasteita:

  • sessions
  • object cache
  • orders
  • analytics
  • inventory sync

20. Multisite ja Redis

Redis tarvitsee:

site-prefixed cache keys

Muuten cache corruption mahdollinen.

21. Backup ja migraatiot

Multisite-backup ei ole triviali.

Yksi site sisältää:

  • omat taulut
  • uploads/site-id
  • user relationships

22. Milloin multisite EI ole hyvä idea

Huono valinta jos:

  • sivustot täysin erillisiä
  • eri asiakkaat tarvitsevat server-eristyksen
  • plugin-stackit eroavat paljon
  • erittäin raskas WooCommerce jokaisessa siteissä

23. Paras enterprise-arkkitehtuuri

Iso multisite stack:

NGINX
↓
Redis Object Cache
↓
MariaDB Cluster
↓
CDN
↓
Separate Search Layer

24. Yleisimmät virheet

  • suorat queryt ilman blog-prefixiä
  • switch_to_blog ilman restore_current_blog
  • cache key collisionit
  • globaalin datan väärä rakenne
  • multisite käyttö ilman oikeaa syytä
  • autoload-ongelmat

Yhteenveto

WordPress Multisite rakentuu yhdestä yhteisestä WordPress-asennuksesta, jossa käyttäjät ja verkkotason data ovat globaaleja, mutta sisältötaulut eriytetään site-ID:n perusteella.

Kun tietokantarakenne ymmärretään oikein, multisite mahdollistaa erittäin tehokkaan useiden sivustojen hallinnan yhdestä ympäristöstä. Ilman tätä ymmärrystä syntyy helposti suorituskyky-, cache- ja data-eristysongelmia erityisesti suurissa verkostoissa.

🍪