MySQL table size
5 отговора
0 прегледа
MySQL table size
Здравейте,
Имам интересен въпрос свързан и малко дизайн на база от данни.
Нека препдоложим че конкретна задача изисква да се направи една таблица с много колони (разбирай над 60-70).
Въпросът е - ще ли работи добре MySQL-а с такава таблица, ако да речем месечно се вкарват около 200к - 300к записа, използва се главно за инсерти и селекти по Primary key, без сложни търсения, но с подреждания по едно или повече полета, които ще бъдат индексиран BIGINT.
Има ли смисъл да се прави разделяне на две или повече таблици с връзка 1:1 или така би било добре ?
Имам интересен въпрос свързан и малко дизайн на база от данни.
Нека препдоложим че конкретна задача изисква да се направи една таблица с много колони (разбирай над 60-70).
Въпросът е - ще ли работи добре MySQL-а с такава таблица, ако да речем месечно се вкарват около 200к - 300к записа, използва се главно за инсерти и селекти по Primary key, без сложни търсения, но с подреждания по едно или повече полета, които ще бъдат индексиран BIGINT.
Има ли смисъл да се прави разделяне на две или повече таблици с връзка 1:1 или така би било добре ?
Re: MySQL table size
Въпросът, който задаваш, е доста сложен и това, колко оптимизирана ще е работата на приложението ти зависи от множество фактори. Лично аз на практика съм работил с таблици не по-големи от 3 милиона реда и с достатъчно памет и разумно количество индекси MySQL се държи перфектно. Без да се считам за гуру, бих те посъветвал няколко неща.
Първото нещо, което трябва да помислиш е, дали по всяко време ти е необходимо да разполагаш с всички данни. Ако става въпрос за 200-300 хиляди реда, проблеми едва ли ще има, но с течение на месеците ще станат милиони и тогава положението може да се окаже сериозно. От тази гледна точка ще бъде чудесно ако старите редове се преместват редовно в архивни таблици. ARCHIVE енджина е идеален за целта, според мен.
Отначало можеш да очакваш плавно спадане в производителността, но в един кофти момент, индексите и/или данните няма да могат да се побират в паметта на машината и тогава ще се наложат I/O операции за търсене, включително в индексите. Можеш да очакваш катастрофален спад в производителността в този момент – става въпрос за пъти. Тогава индексирането на таблицата би могло дори да доведе до още по-голямо забавяне и full table scan ще стане по-уместното решение.
Ако select заявките ти правят предимно range scan MyISAM може да е драстично по бавен (според benchmark-ите, които съм гледал – от 2 до 26 ПЪТИ) от InnoDB заради вътрешното складиране на данните (реших, че ще правиш range scan защото каза търсене по PRIMARY KEY + ORDER BY).
И такива нещица. Още много страници може да се изпишат. Трябва да си прецениш нещата много внимателно предварително. Може и да дадеш повече инфо за задачата, тъй като това, което си казал е недостатъчно.
Първото нещо, което трябва да помислиш е, дали по всяко време ти е необходимо да разполагаш с всички данни. Ако става въпрос за 200-300 хиляди реда, проблеми едва ли ще има, но с течение на месеците ще станат милиони и тогава положението може да се окаже сериозно. От тази гледна точка ще бъде чудесно ако старите редове се преместват редовно в архивни таблици. ARCHIVE енджина е идеален за целта, според мен.
Отначало можеш да очакваш плавно спадане в производителността, но в един кофти момент, индексите и/или данните няма да могат да се побират в паметта на машината и тогава ще се наложат I/O операции за търсене, включително в индексите. Можеш да очакваш катастрофален спад в производителността в този момент – става въпрос за пъти. Тогава индексирането на таблицата би могло дори да доведе до още по-голямо забавяне и full table scan ще стане по-уместното решение.
Ако select заявките ти правят предимно range scan MyISAM може да е драстично по бавен (според benchmark-ите, които съм гледал – от 2 до 26 ПЪТИ) от InnoDB заради вътрешното складиране на данните (реших, че ще правиш range scan защото каза търсене по PRIMARY KEY + ORDER BY).
И такива нещица. Още много страници може да се изпишат. Трябва да си прецениш нещата много внимателно предварително. Може и да дадеш повече инфо за задачата, тъй като това, което си казал е недостатъчно.
Re: MySQL table size
Направи view върху base таблицата, което е SELECT * от нея. Ползвай само него навсякъде по заявките.
Когато разбереш, че имаш performance проблеми, split-ваш вертикално или хоризонтално base таблицата и пипаш view-то да връща същите колони/данни.
Btw, индекс по колони в ORDER BY е малко dubious дали ще се ползва. Със сигурност този индекс ще бави INSERT-ите.
Щом ще търсиш по PK, предполагам ще ползваш някакъв natural key -- Date, Order No, etc. щото не вярвам търсене по ID AutoNumber да е особено смислено за потребителя :-))
cheers,
</wqw>
[линк]
Когато разбереш, че имаш performance проблеми, split-ваш вертикално или хоризонтално base таблицата и пипаш view-то да връща същите колони/данни.
Btw, индекс по колони в ORDER BY е малко dubious дали ще се ползва. Със сигурност този индекс ще бави INSERT-ите.
Щом ще търсиш по PK, предполагам ще ползваш някакъв natural key -- Date, Order No, etc. щото не вярвам търсене по ID AutoNumber да е особено смислено за потребителя :-))
cheers,
</wqw>
[линк]
Re: MySQL table size [re: mcdev]
Благодаря за отговора,
за архивиране със сигурност мисля - ще бъде на 3-месечие или 6-месечие, зависи колко се пълни таблицата. Ще видя за ARCHIVE, защото досега не съм се сблъсквал с такъв казус и не ми се налагало чак толкова да архивирам.
А за MyISAM и InnoDB - като имам тестови данни ще направя тестване и ще се види на място.
благодаря отново.
за архивиране със сигурност мисля - ще бъде на 3-месечие или 6-месечие, зависи колко се пълни таблицата. Ще видя за ARCHIVE, защото досега не съм се сблъсквал с такъв казус и не ми се налагало чак толкова да архивирам.
А за MyISAM и InnoDB - като имам тестови данни ще направя тестване и ще се види на място.
благодаря отново.