MYSQL - Дизайн на бази данни Широкомащабно внедряване в реалния свят

Бих искал да чуя някои мнения или мисли относно дизайна на mysql база данни.

По принцип имам сървър tomcat, който получава различни типове данни от около 1000 системи на място. Всяка от тези системи е уникална и ще докладва уникални данни.

Изпращаните данни могат да бъдат категоризирани като чести и нечести данни. Нечестите данни се изпращат само около веднъж на ден и не се променят много - това са основно данни, базирани на конфигурация.

Чести данни се изпращат на всеки 2-3 минути, докато системата е включена. И представлява текущото състояние на системата.

Тези данни трябва да бъдат базирани в база данни за всяка система и да бъдат достъпни по всяко време от php страница. По същество за всяка система в областта, една PHP страница трябва да има достъп до всички данни на тази клиентска система и да ги показва. С други думи, базата данни трябва да показва състоянието на системата.

Самата информация е изцяло текстова и има много. Конфигурационните данни (които не се променят много) са двойки ключ-стойност и в момента има около 100 от тях.

Идеята ми за дизайна беше да има 100+ колони и 1 ред за всяка система, за да съхранява конфигурационните данни. Но се притеснявам да имам толкова много колони, главно защото не е твърде надеждно за бъдещето, ако трябва да добавя колони в бъдеще. Освен това се притеснявам за скоростта на вмъкване, ако го направя по този начин. Това може да доведе до таблица с 2000 реда x 200 колони, която се осъществява около 100 пъти в секунда, така че трябва да се погрижа за това в първоначалния си дизайн.

Също така се чудя дали има някакви философии на дизайна, които се грижат за често променящи се и рядко променящи се данни, базирани на двигателя. Това би имало смисъл, тъй като искам да поддържам ниско време за INSERT/UPDATE и не ме интересува твърде много времето за SELECT от php.

Бих искал също да знам как да разделям данните. т.е. ако често променящите се данни могат да бъдат категоризирани по няколко различни начина, трябва ли да имам куп таблици, представящи данните и да ги обединявам при избори? Притеснявам се за това, защото вероятно ще трябва да направя отчет, за да покажа общи свойства между всички системи (т.е. да покажа всички системи с определено условие).

Надявам се, че съм предоставил достатъчно информация тук, за да може някой да ме насочи в правилната посока, всяка помощ по въпроса би била чудесна. Или ако някой е правил нещо подобно и може да даде съвет, ще съм много благодарен. Благодаря купища :)

~ Дан


person FaddishWorm    schedule 20.08.2012    source източник
comment
Някои въпроси тук: (1) Трябва ли да съхранявате историята или просто текущото състояние на всяка система във вашите често срещани данни? Ако трябва да съхранявате историята, колко назад? (2) имате ли нужда от история за вашите конфигурационни данни? Ако да, колко назад? (3) има ли сходство в честите данни между системите или всяка система е уникална? Как изглеждат тези данни? (4) достъпен 100 пъти в секунда? Това е много бърза скорост на достъп за всяка СУБД. Можете ли да дадете повече подробности за това?   -  person O. Jones    schedule 20.08.2012
comment
(1) Не, само някои неща ще се съхраняват в историята - и аз ги базирам в отделни таблици чрез tomcat. (2) Не е необходима история за конфигурационни данни. (3) Да, има общо, тъй като всяка система ще има повечето от конфигурационните ключове, само стойностите ще се променят в двойките ключ-стойност. (4) 100 пъти в секунда може да е надценка, но ако се стремя да удовлетворя това, тогава знам, че сървърът ще издържи на почти всичко.   -  person FaddishWorm    schedule 20.08.2012
comment
100 достъпа в секунда (6000 в минута), ако е реално, е една от онези спецификации, които трябва да управляват целия ви дизайн. Ако е реално, това ще ви накара да направите много оптимизации. Ако не е реално, ще увеличите разходите и сложността си без добра цел. Много разработчици проектират по начин, който кара нещата да работят, и след това се тревожат за мащабирането. Ако закъснеете да накарате системата си да работи, никога няма да имате възможност да я увеличите. Така че внимавайте с прекомерното уточняване!   -  person O. Jones    schedule 20.08.2012
comment
Точно така! Ето защо се свързах с всички - надявам се таблиците с памет да са наред.   -  person FaddishWorm    schedule 20.08.2012


Отговори (1)


Публикувах няколко въпроса в коментар. Трудно е да ви дам съвет относно вашите бързо променящи се данни, без да знаете повече за това, което се опитвате да направите.

За вашите конфигурационни данни не използвайте таблица със 100 колони. Известно е, че широките маси са трудни за работа в производството. Вместо това използвайте таблица с четири колони, съдържаща следните колони:

SYSTEM_ID  VARCHAR    System identifier
POSTTIME   DATETIME   The time the information was posted
NAME       VARCHAR    The name of the parameter
VALUE      VARCHAR    The value of the parameter

Първите три от тези колони са вашият съставен първичен ключ.

Този дизайн има предимството, че расте (или се свива), докато добавяте към (или изваждате от) вашия набор от конфигурационни параметри. Той също така позволява съхраняване на исторически данни. Това означава, че новите точки от данни могат да бъдат ВМЪКВАНИ вместо АКТУАЛИЗИРАНИ, което е по-бързо. Можете да стартирате ежедневна или седмична работа, за да изтриете историята, която вече не искате да пазите.

(Редактирайте, ако наистина не се нуждаете от история, отървете се от колоната POSTTIME и използвайте хубавата функция за разширение на MySQL INSERT ON DUPLICATE KEY UPDATE, когато публикувате неща. Вижте http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html)

Ако вашите бързо променящи се данни са подобни по форма (двойки име/стойност) на вашите конфигурационни данни, можете да използвате подобна схема, за да ги съхраните.

Може да искате да създадете таблица с "текущи данни", като използвате метода за достъп MEMORY за тези неща. Таблиците MEMORY са много бързи за четене и запис, тъй като всички данни са в RAM на вашия MySQL сървър. Недостатъкът е, че сривът и рестартирането на MySQL ще ви даде празна таблица със загубено предишно съдържание. (MySQL сървърите се сриват много рядко, но когато го направят, те губят съдържанието на таблицата MEMORY.)

Можете да изпълнявате случайно задание (на всеки няколко минути или часове), за да копирате съдържанието на вашата таблица MEMORY в таблица на диска, ако трябва да запазите хронология.

(Редактиране: Може да обмислите добавянето на memcached http://memcached.org/ към вашата система за уеб приложения в бъдеще, за да се справите с висока скорост на четене, вместо да създавате дизайн на база данни за версия 1, която обработва висока скорост на четене. По този начин можете да видите кои части от цялостния дизайн на вашето приложение имат проблеми с мащабирането . Иска ми се някой да ме беше убедил да направя това в миналото, вместо да прекалявам с дизайна за ранните версии. )

person O. Jones    schedule 20.08.2012
comment
Не бях чувал за таблици с памет преди - звучат като чудесно решение за следене на текущото състояние. Текущото състояние е списък с уникални идентификатори на песни, които съставляват плейлист. Докато песните се възпроизвеждат, плейлистът се променя, така че състоянието се променя. Има други неща, които съставляват текущото състояние, като ниво на звука например. Те трябва да са достъпни по всяко време и ще се променят често. Мисля, че е страхотна идея това, което сте публикували, тъй като всяка конфигурационна стойност ще има свой собствен запис, но с posttime като част от първичния ключ, възможно ли е все пак да правите актуализации? - person FaddishWorm; 20.08.2012