Tabelltyper i mysql

[mikaelandre]

Hei!

 

Jeg lurte på om noen kunne forklare meg forskjellen på de forskjellige tabelltypene i mysql, og hva som bør velges. Jeg er spesielt interessert i en som støtter transactions og fremmednøkler.

[Ernie]

Eneste motoren som føler med mysql som støtter transactions er vel innodb. Så du har forsåvidt ikke noe valg.

Ellers må det vel sies at myisam vs. innodb er et klassisk problem:

http://dev.mysql.com/tech-resources/articl...ine/part_1.html

http://dev.mysql.com/tech-resources/articl...ine/part_2.html

http://dev.mysql.com/tech-resources/articl...ine/part_3.html

 

A general guideline could be as follows: if you require multi-statement transactions, advanced isolation levels and row-level locking, foreign key constraints, or otherwise have a requirement for ACID features, go for InnoDB. Otherwise, simply use MyISAM, the default.

 

If you have a message board application with lots of selects, inserts as well as updates, InnoDB is probably the generally appropriate choice for the actual message board tables.

 

Edit: Kan likegod linke direkte til artikklen.

Endret 14. november 2005 av Ernie

[mikaelandre]

takk for svar!

 

hva er ulempene med innodb? hvorfor er ikke den default? antar at det kan være forskjeller på hastigheten, men hvor stor vil den være?

[blackbrrd]

Hei, forskjellen i hastighet er egentlig ikke viktig.. enten trenger du transaksjoner og kjører InnoDB eller så kjører du MyISAM.

 

Personlig foretrekker jeg Postgres

 

Sitater angående "LOCKING and CONCURRENCY SUPPORT"

 

"PostgreSQL has a mechanism called MVCC (MultiVersion Concurrency Control), comparable or superior to best commercial databases. It can do row-level locking, can lock rows for writing in one session but give these rows unaffected in another session. MVCC is considered better than row-level locking because a reader is never blocked by writer. Instead, Postgres keeps track of all transactions and is able to manage the records without waiting to become available. "

 

"MySQL can do table locking for ISAM/MyISAM and HEAP tables, page level locking for BDB tables.

InnoDB has full row level locking support."

 

EDIT: glemte å linke til websida sitatene er hentet fra:

http://www-css.fnal.gov/dsg/external/freew...l-vs-mysql.html

 

Er egentlig litt skeptisk til noe av det som står der, men vet at det som står om transaksjoner og postgres stemmer. Det er endel andre ting som står om postgres som ikke stemmer - ihvertfall ikke pr idag.

 

Spesiellt "Speed" kommentarene om postgres:

"Postgres slower on low-end but has some options for improving. Postgres forks on every incoming connection - and the forking process and backend setup is a bit slow, but one can speed up PostgreSQL by coding things as stored procedures. "

 

Er relativt tvilsomme.. Det er jo sant at postgres fork'r og at det er tregt - ihvertfall til og med postgres 7.4 for linux, men jeg ser ikke for meg noen som ikke bruker connection pools (dvs at du oppretter f.eks 10 connections som du deler ut tilgang til). Mao, praktisk sett så er det ikke ytelsesproblem.

 

Jeg tror mer på kommentaren om at "Postgres [is] slower on low-end", personlig så jeg ett kjempehopp i ytelse fra postgres 7.2 til 7.4, så rom for forbedring har det nok vært ja. Postgres bruker også en god del funksjonalitet fra operativsystemet, så når linux kernel 2.6 kom ga dette en merkbar økning i ytelse. (Har bare fått testet det på en maskin som stod som db/web server hvor samme maskin brukte 1/7 av tida før software oppgraderinger..)

 

Postgres har etterhvert fått et godt databaseverktøy i pgadmin, bl.a. en genial query "optimizer" - den viser deg grafisk hva som tar lang tid i spørringene dine, noe som gjør det mye mindre tidkrevende å finne f.eks tabeller/kolonner du bør indeksere f.eks. - evt gjøre om på databasestrukturen.

 

Eksempel på syntax for å opprette tabeller med foreign keys og indekser i postgres:

 

CREATE TABLE tcontact (

contactid serial PRIMARY KEY NOT NULL,

contactinfo text

);

 

CREATE TABLE order (

ordreid serial PRIMARY KEY NOT NULL,

id_contactid REFERENCES tcontact.

orderinfo text

);

 

CREATE INDEX i_order_id_contactid ON order (id_contactid);

 

Disse tre sql setningene vil lage to tabeller med indekser på primary key'ene og en foreign key constraint på id_contactid. Den siste sql setningen lager en indeks på id_contactid så du slipper sequential scans på order tabellen når den får mange rader..

 

Ang. ytelse, er rimelig sikker på at mysql er vesentlig kjappere enn postgres på low-end maskiner, har sett noen tester som hinter til at mysql skalerer dårlig fra en core og oppover - men ikke verre enn at den på 4 cores er kommet ned på samme ytelsesnivå som diverse andre databaser. http://www.anandtech.com/IT/showdoc.aspx?i=2447&p=7

 

(PS: det siste der er laget som en test av cpu'r og å sammenligne databaser på det grunnlaget er egentlig heller tvilsomt det også, men det som blir sagt er rimelig objektivt)

Endret 9. desember 2005 av blackbrrd

[Oracel]

Hei!

 

Jeg lurte på om noen kunne forklare meg forskjellen på de forskjellige tabelltypene i mysql, og hva som bør velges. Jeg er spesielt interessert i en som støtter transactions og fremmednøkler.

5151750[/snapback]

Hvis du har tabeller med fremmednøkler, bruk InnoDB. Dette gjelder stort sett alt annet enn banale gjestebøker o.l. Hvis du får problemer med ytelse (noe jeg stiller meg særdeles tvilende til), så bruk heller andre løsninger som f.eks. memcached på de mest kritiske spørringene.

 

Du kan selvsagt bruke MyISAM og hive absolutt all integritet på dør, og heller implementere kvasi-tøyse-integritet på applikasjonslaget. I såfall, good luck & have fun.

[blackbrrd]

Egentlig så er det en god ide å bruke en ORM som f.eks Hibernate, har sett litt på det men ikke fått testet den ordentlig i bruk enda. Så lenge du ikke har en gammel databasestruktur å vedlikeholde burde det være ganske rett fram å bruke Hibernate.

 

Hibernate er en Object Relation Mapper, mao, den laget er overgang mellom en relasjonsdatabase og et objektorientert programmeringsspråk. I dette tilfellet java.