Vilket är optimalt - Mer rader eller mer tabeller i en databas?

Permalänk
Medlem

Vilket är optimalt - Mer rader eller mer tabeller i en databas?

Sitter och jobbar lite med Django/Mezzanine för tillfället och undrar lite kring optimering av databas för inlägg. Min svaghet är just databaser vilket jag ska fördjupa mig i snarast möjligt. Men just nu har jag en fundering kring Mezzanines val av tables samt WordPress.

I t.ex. WordPress kör man 1 table för varje blogg där man har alla inläggen för den bloggen. Men i Mezzanine väljer dem att köra på enbart en table där alla inlägg som skrivs av alla bloggar hamnar i samma. Men självklart finns en ForeignKey för de olika raderna med ID:et från den specifika bloggen samt author.

Hur är prestanda skillnaderna när man jämför? Om låt mig säga t.ex. att jag har 1000 bloggare på WordPress då blir det ett fasansfullt många tables, men i Mezzanine får jag extremt många rader istället i en table.

Varför ska man välja den ena metoden från den andra osv. Skulle vilja få lite klarhet i tänket här vilken metod som är bäst.

Permalänk
Medlem

Det är ju som du är inne på ett designval och båda har sina för- och nackdelar. Lite fritt spånande runt det (från någon som inte är superbra på databaser):

Alla bloggar i en tabell

  • Alla bloggar kan enkelt indexeras av ett söksystem. Det blir enkelt att flytta data mellan bloggare.

  • Man måste lägga till samma informationsfält för alla bloggar (eller köra någon sorts utökningstabeller kanske).

  • Lätt struktur att konstruera. Lite interaktion med själva databasen. Skapa schema och sen är det klart, mer eller mindre.

En tabell per blogg

  • Kan anpassa bloggarna mer utan att andra bloggar påverkas. Mindre redundant information.

  • Föreställer mig att det är enklare att flytta en delmängd av bloggarna till en annan maskin för lastbalansering.

  • Lättare att få schemat i någon snygg normalform. Se databasnormalisering.

  • Mer jobb med databasen. Men drar också mer nytta av funktionerna i den.

  • Kan göra databas-operationer per blog. (Dumpa helt, backup, indexera och så vidare.)

Givet att jag som ointresserad åskådare vet vad Wordpress är men fick duckduckgoa på Mezzanine så skulle jag gissa på att W har vuxit sig stora nog för att behöva bekymra sig om skala på backend. Men det brukar vara något som är viktigare när sidan blivit stor nog.

Med reservation för att jag kan ha helt fel och garanterat missat några vansinnigt viktiga poänger.

Visa signatur

.<

Permalänk
Medlem
Skrivet av Crqu:

Sitter och jobbar lite med Django/Mezzanine för tillfället och undrar lite kring optimering av databas för inlägg. Min svaghet är just databaser vilket jag ska fördjupa mig i snarast möjligt. Men just nu har jag en fundering kring Mezzanines val av tables samt WordPress.

I t.ex. WordPress kör man 1 table för varje blogg där man har alla inläggen för den bloggen. Men i Mezzanine väljer dem att köra på enbart en table där alla inlägg som skrivs av alla bloggar hamnar i samma. Men självklart finns en ForeignKey för de olika raderna med ID:et från den specifika bloggen samt author.

Hur är prestanda skillnaderna när man jämför? Om låt mig säga t.ex. att jag har 1000 bloggare på WordPress då blir det ett fasansfullt många tables, men i Mezzanine får jag extremt många rader istället i en table.

Varför ska man välja den ena metoden från den andra osv. Skulle vilja få lite klarhet i tänket här vilken metod som är bäst.

Det är inte så att du kör flera installationer/sajter med Mezzanine mot en och samma databas? För då gör du nog fel.

Det vanligaste är att låta en sajt backas av en databas. Det är exempelvis lättare att ta backuper om du inte behöver sålla ut data som egentligen tillhör något annat.

Visa signatur

Kom-pa-TI-bilitet

Permalänk
Medlem
Skrivet av Teknocide:

Det är inte så att du kör flera installationer/sajter med Mezzanine mot en och samma databas? För då gör du nog fel.

Det vanligaste är att låta en sajt backas av en databas. Det är exempelvis lättare att ta backuper om du inte behöver sålla ut data som egentligen tillhör något annat.

Nej, jag kör enbart en installation av Mezzanine. Har två st olika "sites" dock som man skapar inom CMS:et. Sen är det bara att confa för subdomäner som ska finnas. Det som syns i MySQL atm är följande:

mysql> show tables; +-----------------------------+ | Tables_in_domain_dev | +-----------------------------+ | auth_group | | auth_group_permissions | | auth_permission | | auth_user | | auth_user_groups | | auth_user_user_permissions | | blog_blogcategory | | blog_blogpost | | blog_blogpost_categories | | blog_blogpost_related_posts | | conf_setting | | core_sitepermission | | core_sitepermission_sites | | django_admin_log | | django_comment_flags | | django_comments | | django_content_type | | django_migrations | | django_redirect | | django_session | | django_site | | forms_field | | forms_fieldentry | | forms_form | | forms_formentry | | galleries_gallery | | galleries_galleryimage | | generic_assignedkeyword | | generic_keyword | | generic_rating | | generic_threadedcomment | | pages_link | | pages_page | | pages_richtextpage | | twitter_query | | twitter_tweet | +-----------------------------+ 36 rows in set (0,07 sec)

Permalänk
Medlem
Skrivet av Teknocide:

Det är inte så att du kör flera installationer/sajter med Mezzanine mot en och samma databas? För då gör du nog fel.

Det vanligaste är att låta en sajt backas av en databas. Det är exempelvis lättare att ta backuper om du inte behöver sålla ut data som egentligen tillhör något annat.

Sorry, jag läste fel igår. Jag kör flera sajter inom Mezzanine mot en och samma databas. Men är tanken att man ska ha typ flera 100 olika databaser? Jag tänker räcker det inte med att köra flera tabeller istället i en databas där det är specifikt för den bloggen och användaren då (som i WordPress)?

Permalänk
Medlem
Skrivet av Crqu:

Sorry, jag läste fel igår. Jag kör flera sajter inom Mezzanine mot en och samma databas. Men är tanken att man ska ha typ flera 100 olika databaser? Jag tänker räcker det inte med att köra flera tabeller istället i en databas där det är specifikt för den bloggen och användaren då (som i WordPress)?

Jag skulle nog ha använt 100 databaser för 100 sajter av den enkla anledningen att test/backup blir enklare.

Om din enda databas med 100 sajter blir korrupt/får dålig data/blir hackad så får 100 sajter problem. Har du 1 databas för 1 sajt så påverkas bara den sajten.

Samma sak om du behöver ta backup eller vill testa datan på din lokala dator: Det blir mycket krångligare om du behöver ladda ner 100 sajters data och sila igenom den, istället för att bara ta backup på den sajten som du är intresserad av.

Wordpress är inget bra exempel på god databasdesign, snarare tvärtom.

Att köra flera databaser är sällan en nackdel. Det blir lite mer administration men du får i gengäld bättre separation och säkerhet av datan.

Visa signatur

Kom-pa-TI-bilitet

Permalänk
Medlem
Skrivet av Teknocide:

Jag skulle nog ha använt 100 databaser för 100 sajter av den enkla anledningen att test/backup blir enklare.

Om din enda databas med 100 sajter blir korrupt/får dålig data/blir hackad så får 100 sajter problem. Har du 1 databas för 1 sajt så påverkas bara den sajten.

Samma sak om du behöver ta backup eller vill testa datan på din lokala dator: Det blir mycket krångligare om du behöver ladda ner 100 sajters data och sila igenom den, istället för att bara ta backup på den sajten som du är intresserad av.

Wordpress är inget bra exempel på god databasdesign, snarare tvärtom.

Att köra flera databaser är sällan en nackdel. Det blir lite mer administration men du får i gengäld bättre separation och säkerhet av datan.

Men hur fungerar denna lösning på 10 tusentals sajter och ännu mer? Är det hållbart och hur svårt är att det köra SQLs om man vill av någon anledning ändra någon tabell eller rad på alla sajter? Jag funderar lite på hanteringen blir när man delar upp det för varje sajt.

Permalänk
Medlem
Skrivet av Crqu:

Men hur fungerar denna lösning på 10 tusentals sajter och ännu mer? Är det hållbart och hur svårt är att det köra SQLs om man vill av någon anledning ändra någon tabell eller rad på alla sajter? Jag funderar lite på hanteringen blir när man delar upp det för varje sajt.

Om jag får vända lite på frågan och istället besvara "Är det hållbart att köra 10000+ installation i en enda databas/tabell?" är svaret ett bergsäkert NEJ.

Se det inte som att du "delar upp" datan; se det som att du slår samman flera installationer om du kör dem mot en och samma databas. Om inloggningsuppgifterna till en sådan installation läcker får du ett helvete. En dålig rad SQL förstör alla sajter, en hacker som knäcker en sajt skulle få 9999 gratis etc. Att inte ha alla ägg i en korg brukar ju vara rekommenderat.

Hanteringen blir naturlig: du kan uppdatera en sajt utan att påverka andra vilket brukar uppskattas av kunder. Du kan återställa en sajt utan att återställa alla andra, etc.

Visa signatur

Kom-pa-TI-bilitet