Всеки архитект на база данни, който проектира MySQL база данни, се сблъсква с проблема с избора на правилната машина за съхранение. Обикновено едно приложение използва само една машина:MyISAM или InnoDB . Но нека се опитаме да бъдем малко по-гъвкави и да си представим как могат да се използват различни механизми за съхранение.
Началният модел на данни
За да започнем, нека изградим опростен модел на данни за CRM (управление на взаимоотношенията с клиенти) система, която ще използваме, за да илюстрираме въпроса. Дизайнът ще обхваща основните функции на CRM:данни за продажбите, дефиниции на продукти и информация за анализ. Той няма да съдържа подробности, които обикновено се използват в CRM системите.
Както можете да видите, този модел на данни има таблици, които съхраняват транзакционна информация, наречена sale и sale_item . Когато клиент закупи нещо, приложението ще създаде нов ред в sale маса. Всеки закупен продукт ще бъде отразен в sale_item маса. Свързана таблица, sale_status , е за съхраняване на възможни състояния (т.е. чакащо, завършено и т.н.).
product таблицата съхранява информация за стоки. Той дефинира всеки продукт и неговите основни дескриптори. В по-подробна диаграма бих добавил още таблици за обработка на спецификацията и категоризацията на продукта. Но за настоящите ни нужди това не е необходимо.
Таблицата с клиенти съхранява данни за клиентите. Това е неразделна част от всяка CRM система и обикновено проследява индивидуалната активност на всички потребители. Очевидно често има наистина подробна информация. Но както отбелязах, в момента нямаме нужда от тези подробности.
log таблицата съхранява какво е направил всеки клиент в приложението. И report_sales таблицата е предназначена за използване на анализ на данни.
След това ще опиша MySQL двигателите за съхранение, които евентуално биха могли да бъдат използвани в този дизайн. И по-късно ще обсъдим кой двигател е подходящ за всеки тип маса.
Преглед на MySQL Storage Engines
Машината за съхранение е софтуерен модул, който MySQL използва за създаване, четене или актуализиране на данни от база данни. Не се препоръчва произволно да избирате двигател, но много разработчици с удоволствие използват MyISAM или InnoDB, въпреки че са налични и други опции. Всеки двигател има своите плюсове и минуси, а правилният избор на двигател зависи от няколко фактора. Нека да разгледаме най-популярните двигатели.
- MyISAM има дълга история с MySQL. Това беше машината по подразбиране за MySQL бази данни преди изданието 5.5. MyISAM не поддържа транзакции и има само заключване на ниво таблица. Използва се предимно за приложения с интензивно четене.
- InnoDB е общ двигател за съхранение, който балансира висока надеждност и добра производителност. Той поддържа транзакции, заключване на ниво ред, възстановяване при срив и контрол на паралелност в няколко версии. Освен това предоставя ограничение за референтна цялост на външния ключ.
- Паметта двигателят съхранява всички данни в RAM. Може да се използва за съхраняване на справки за търсене.
- Друг двигател, CSV , съхранява данни в текстови файлове със стойности, разделени със запетая. Този формат се използва предимно за интеграция с други системи.
- Обединяване е добър избор за системи за отчитане, като например в складовете на данни. Позволява логическото групиране на набор от идентични MyISAM таблици, които също могат да бъдат посочени като един обект.
- Архив е оптимизиран за високоскоростно вмъкване. Той съхранява информация в компактни, неиндексирани таблици и не поддържа транзакции. Системата за съхранение на архиви е идеална за съхраняване на големи количества рядко препращани исторически или архивирани данни.
- Федерацията engine предлага възможност за отделяне на MySQL сървъри или създаване на една логическа база данни от много физически сървъри. В локалните таблици не се съхраняват данни и заявките се изпълняват автоматично в отдалечените (обединени) таблици.
- Черната дупка двигателят действа като „черна дупка“, която приема данни, но не ги съхранява. Всички селекти връщат празен набор от данни.
- Двигателят Пример се използва, за да покаже как се разработват нови машини за съхранение.
Това не е пълен списък с двигатели за съхранение. MySQL 5.x поддържа девет от тях директно от кутията, плюс още десетки, разработени от MySQL общността. Повече подробности за двигателите за съхранение можете да намерите в официалната документация на MySQL.
Актуализиране на дизайна на модела на данни
Погледнете отново нашия модел на данни. Очевидно различните таблици ще се използват по различни начини. sale таблицата трябва да поддържа транзакции. От друга страна, log и report_sales таблиците не изискват тази функция. Основната мисия на log таблицата съхранява данни с максимална ефективност. Бързото извличане е основното изискване за report_sales маса.
Нека имаме предвид точките по-горе и да променим схемата на нашата база данни. Във Vertabelo можете да зададете „Storage engine“ в Свойства на таблицата панел. Моля, разгледайте снимките по-долу.
Настройка на машината за съхранение
И така, нека видим актуализиран дизайн на базата данни.
Посочих механизми за съхранение за съществуващи таблици и реорганизирах report_sales маса. Както можете да видите, таблиците са разделени на три групи:
- Таблици с транзакции, които се използват с основното приложение
- Отчетни таблици за BI анализ
- Регистрационна таблица за съхраняване на цялата потребителска активност
Нека поговорим за всички поотделно.
Таблици с транзакции
Тези таблици съдържат данни, въведени от потребителите по време на ежедневни рутинни операции. В нашия случай ще има информация за продажба, като например:
- кой служител е извършил продажбата
- кой е закупил продукта
- какво е продадено
- колко струва
В повечето случаи InnoDB е най-доброто решение за таблици за транзакции. Този механизъм за съхранение поддържа заключване на редове и някои потребители могат да работят заедно. По същия начин InnoDB позволява използването на транзакции и външни ключове. Но, както знаете, тези предимства не са безплатни; машината може да изпълнява оператори за избор по-бавно от MyISAM и да запазва данни с по-малка ефективност от Archive.
Всички описани по-горе двигатели имат някои защити на място, така че разработчиците не трябва да пишат сложни функции за връщане назад за всяка операция. В типично приложение за продажби запазването на последователността на данните е по-важно от възможните проблеми с производителността.
Таблици с отчети
В новия дизайн разделих една маса на няколко по-малки маси. Това спестява усилия, когато дойде време за управление на данни и извършване на поддръжка на таблици и индекси. Също така ни позволява да създадем таблицата MERGE sale_report за комбиниране на други отчетни таблици. В резултат на това BI инструментът все още извлича данни от една огромна таблица (за целите на анализа), но ние имаме предимството да работим с по-малки таблици.
Report_sale_{year} таблиците са MyISAM таблици. Този механизъм за съхранение не поддържа транзакции и може само да заключи таблицата като цяло. Тъй като MyISAM не се тревожи за тези сложни елементи, той извършва операции за манипулиране на данни с висока скорост. Поради своята файлова структура, този механизъм за съхранение чете данни по-бързо от по-популярния InnoDB.
Регистрационната таблица
Двигателят за съхранение на архиви е добър избор за съхранение на регистрационни данни. Може да вмъква редове и бързо да компресира съхранените данни. Има големи предимства за съхраняване на информация за дейностите на потребителите. Архивът обаче има някои ограничения. Той не поддържа операции за актуализиране и извлича данни бавно. Но в таблицата с дневници описаните предимства са по-важни от недостатъците.
Интегриране на двигатели за съхранение
Всяка система трябва да бъде интегрирана с външния живот. За приложения това могат да бъдат потребители, които попълват справочни и транзакционни таблици. Това могат да бъдат услуги и интеграция чрез REST, SOAP, WCF или нещо подобно. И не на последно място, това може да бъде интегриране на база данни.
MySQL и Oracle разработиха две наистина полезни машини за съхранение:Федерирани и CSV . Първият, Федериран , трябва да се използва за зареждане на данни от външна MySQL база данни. Вторият механизъм за съхранение, CSV , позволява на бази данни да записват записи във формат CSV и да четат файлове, разделени със запетая, в ефир, без допълнителни усилия.
Както можете да видите, използването на различни машини за съхранение за различни цели дава на вашата база данни по-голяма гъвкавост. Ако архитектът на база данни вземе своето решение, след като обмисли всички плюсове и минуси, тогава резултатът може да бъде наистина впечатляващ.
Имате ли опит с използването на различни машини за съхранение в дизайна на база данни? Бих искал да видя вашите съвети и предложения. Моля, споделете ги в секцията за коментари.
