Сравнение на MySQL и PostgreSQL. Сравнение на MySQL и PostgreSQL Сравнение на MySQL и PostgreSQL: прилики и разлики

Поради бързото обезценяване на рублата закупуването на СУБД Microsoft SQL стана много скъпо, а за някои компании цената на тези лицензи стана напълно непосилна. В момента, за да разположите Microsoft SQL сървър за 20 потребители, трябва да закупите следните лицензи:

    1 лиценз за операционна система (WinSvrStd 2012R2)

    20 лиценза за връзка със сървъра (WinSvrCAL 2012)

    1 лиценз за DBMS сървър (SQLSvrStd 2014)

    20 лиценза за свързване към СУБД (SQLCAL 2014)

Приблизителна цена на такъв пакет 275 000 рубли,което е доста скъпо за компания от само 20 души. Тези разходи могат да бъдат избегнати, ако създадете СУБД сървър с помощта на безплатен софтуер. Инсталирайте операционна система Linux и безплатна версия на СУБД - PostgreSQL. На такъв сървър можете лесно да разположите корпоративен сървър 1C, както и други роли, които потенциално могат да се комбинират с ролята на бази данни, например WebServer или хранилище на файлове.

Тъй като използването на безплатен софтуер е много привлекателно от финансова гледна точка, беше решено да се види колко е добър по отношение на производителността.

Тестване на производителността на 1C:

За да извършим теста, използвахме оборудването и софтуера, изброени в таблица 1. Физическият сървър и за двата стенда беше един и същ, само софтуерът беше променен. Настройките на двете СУБД се използват по подразбиране и не ги описваме подробно в статията. Комплектът за разпространение на PostGreSQL със съответните пачове е взет от уебсайта на компанията 1C, версията е най-новата, налична на този сайт.

Таблица 1. Стендове за изпитване

Характеристики

Щанд №1

Щанд №2

операционна система

CentOS 6

Windows Server 2012R2

PostgreSQL 9.3.3

Microsoft SQL Server 2012R2

процесор

Intel Core i 5 3330 (3.0 Ghz)

RAM

24 GB DDD 3 1333 Ghz

HDD

SSD 240 GB Intel

Като начало беше направен „тестът на Гилев“, който показа леко предимство на стенд номер 2 спрямо стенд със свободен софтуер.

Вижте резултатите по-долу, разликата в стойностите е само 3%.

За информация:„Тестът на Гилев“ е популярен синтетичен 1C тест, който изпълнява редица стандартни операции - колкото по-бързо се изпълнява тестът, толкова по-висок е резултатът. Оценката се извършва в условни единици. Полученият резултат може да се сравни със скалата, приложена към теста, която ще покаже колко висока е производителността на текущата система.

Фигура 1. Резултат от теста на Гилев. Щанд №2 СУБДГ-ЦА SQL


Фигура 2. Резултат от теста на Гилев. Щанд №1 СУБДPostgreSQL


След това беше решено да се извърши тестване по метода APDEX. Същността на метода е да се измери времето, необходимо за извършване на основни операции в 1C; измерванията се правят няколко пъти за определен период от време. След това полученият резултат се сравнява с приемливото време за извършване на определена операция.

За да направим това, взехме реална работеща база на една от най-тежките конфигурации 1C, характеристиките на основата са посочени в таблица № 2.

Таблица 2. Характеристики на тестовата база


Измерено е времето, необходимо за извършване на 7 стандартни операции с обекти в базата данни. Всеки тест беше извършен 10 пъти и беше получена средната стойност. Измерванията бяха извършени с помощта на дебел клиент през локална мрежа. Клиентът беше инсталиран на работна станция, работеща под Windows 7. Опитахме се също така да стартираме тестове от клиент, инсталиран на Ubuntu Linux, но той не работи стабилно и беше решено да стартираме всички тестове само от клиента на Windows.

Таблица 3. РезултатиAPDEX

Ключова операция

Време за изпълнение в секунди

отклонение

Щанд №2 (MSSQL )

Щанд №1

(Безплатен софтуер)

Отваряне на документ

Клиентска поръчка

Осъществяване на документи

Клиентска поръчка

Публикуване на нов документ

Обект на документа: Поръчка на клиента

Отчетът е генериран

Анализ на приходите и разходите

Отчетът е генериран

Списък на партидите стоки

Отчетът е генериран

Списък на стоките в складовете

Отчетът е генериран

Разплащания с клиенти


Средно нашата реална база данни при използване на MSSQL работи с 45% по-бързо, отколкото на маса с безплатен софтуер. При някои тестове разликата беше много значителна, но при други, например при провеждане на нов документ, беше само 11%.

Заключение:

    1Cна MSSQL DBMS работи приблизително 1,5 пъти по-бързо, отколкото на PostgreSQL. Съответно, ако е възможно да закупите или наемете MSSQL лицензи, по-добре е да го използвате за по-висока производителност. За малки и леки бази данни можете да опитате да използвате версията MSSQL Express. Не сме провеждали тестове с него, така че може да се покаже по отношение на производителността или по-добре, или по-лошо от PostgreSQL. Това издание е ограничено до използването на 1 процесор и 1 GB RAM и също така не работи с бази данни, по-големи от 10 GB. Ако базата данни нарасне до този размер, тогава тя ще спре да работи напълно, но както показва практиката, ако има 15-20 потребители в базата данни, тогава можете да работите удобно с размер на базата данни от 4-5GB, тогава базата данни започва да забавят силно.

    Оценката чрез теста Gilev показва изключително леко превъзходство на MSSQL, което ни позволява да направим предположението, че други 1C бази данни могат да работят на PostgreSQL също толкова добре, колкото и на MSSQL, и вероятно по-бързо. Преди да изберете СУБД, препоръчваме да изпълните тестове на вашата конкретна база данни и да сравните резултатите.

    Използването на СУБД PostgreSQL за внедряване на 1C върху него е приемливо решение в условия на ограничен бюджет. Базата данни няма да работи толкова бързо, колкото на MSSQL, но не е необходимо да плащате за лицензи.

В края на 2017 г. проведохме нови тестове и ги публикувахме в друга статия.

Друг начин да спестите пари при използване на 1C е да наемете 1C сървър.

Системна интеграция. Консултиране

За стартиране на 1C Server (нека го наречем 1C App) е необходим ключ на сървъра.
Необходим е 1C сървър, така че базата данни да не е базирана на файлове, а на три нива.
Тристепенният, известен също като тристепенен, е модел на взаимодействие с 1C клиент<->Приложение 1C<->СУБД (MS SQL, DB2, Oracle, PostgreSQL)
Тези. клиентът всъщност не комуникира със сървъра на СУБД, той комуникира със сървъра 1С, а той от своя страна комуникира със СУБД.
По този начин можете да имате 2,3,5-25-125 DBMS сървъри и само един 1C сървър. Само за всяка база данни на 1C сървър ще трябва да посочите на кой сървър е инсталирана конкретната база данни и какъв вид сървър е (тип СУБД).

Ключът към 1C сървър струва ~ 42 хиляди рубли. за 32-битовата версия и ~74 tr. за 64-битов. В същото време ключът за 64-битовата версия може да се използва за 32-битов сървър (обратното, разбира се, не е възможно).
Като ключ за сървъра смятам, че е по-разумно да се използва хардуерен ключ.

Между другото, относно лицензирането:

- евтино училище
Да, има версия за доставка на 1C с вече включен лиценз за MS SQL. Но:
А.За да получите такава доставка, трябва да закупите комплект: 1C сървър + MS SQL + поне 5 клиентски лиценза (поправете ме, ако греша, възможно е да трябва да закупите поне 10 клиента)
което в случай на вече закупени 1C ключове значително намалява рентабилността на такова придобиване.
b.Съгласно условията на лиценза този вайн може да се използва САМО за 1Ski.
Тези. Изглежда, че можете да разположите друга база данни върху него, но това веднага ще превърне лицензирания MS SQL в нелицензиран.

- правилно лицензиране -
Според правилата лицензирането на MS SQL трябва да се извършва като сървърен лиценз + лицензи за клиентски връзки.
Когато „клиент“ не се счита за 1C приложение с една връзка (може да има повече връзки - в зависимост от това колко процеса конфигурирате на сървъра), а всеки 1C потребител + 1 лиценз за 1C приложение

Или лицензиране на база сървърни процесори.
Освен това може да греша, но в случай на 2005 - 2008 MS SQL трябва да лицензирате сокета (т.е. физическия процесор, ако броят на ядрата не надвишава 4), тогава в случай на 2012 г. лицензирането отива за ядрата на процесора на цена = цена на лиценза * брой ядра/4.
Освен това ORACLE използва тази система за лицензиране от дълго време (има таблица с коефициенти в зависимост от общия брой сървърни ядра),
защото съвременните инструменти за виртуализация позволяват най-малко 4, поне 64 физически 4-6-8 ядрени процесора да бъдат представени на виртуална машина като 1 физически с +100500 ядра (което някои успешно използват)

- широко разпространено лицензиране -
Много често се закупува само сървърен лиценз (~28 000 рубли) и се изразходва изцяло за лицензиране на клиентски връзки.
В някои случаи, например в случай на Споразумение за предприятие, това е приемливо (тъй като лиценз за клиентска ОС в рамките на лиценза автоматично предоставя лиценз за връзка със сървъра).
Но в повечето случаи нарушава лицензирането. Въпреки че хленчи и не псува.

  • PostgreSQL

    • В очакване на моя доклад на конференцията PGCONF.RUSSIA 2015, ще споделя някои наблюдения относно важните разлики между СУБД MySQL и PostgreSQL. Този материал ще бъде полезен за всички, които вече не са доволни от възможностите и функциите на MySQL, както и за тези, които правят първите си стъпки в Postgres. Разбира се, тази публикация не трябва да се разглежда като изчерпателен списък от разлики, но ще бъде напълно достатъчна, за да вземете решение в полза на една или друга СУБД.

    Репликация

    Темата на моя доклад е „Асинхронна репликация без цензура или защо PostgreSQL ще завладее света“, а репликацията е една от най-болезнените теми за натоварени проекти, използващи MySQL. Има много проблеми - правилна работа, стабилност, производителност - и на пръв поглед изглеждат несвързани. Ако погледнем историческия контекст, получаваме интересно заключение: репликацията на MySQL има толкова много проблеми, защото не е обмислена и точката, от която няма връщане, беше поддръжката на двигателя за съхранение (plug-in двигатели) без отговори на въпросите "какво да правя с дневника?" и „как различни машини за съхранение могат да участват в репликацията“. През 2004 г. в пощенския списък на PostgreSQL потребител се опита да „намери“ машината за съхранение в изходния код на PostgreSQL и беше много изненадан, че те не са там. По време на дискусията някой предложи добавянето на тази функция към PostgreSQL и един от разработчиците отговори: „Момчета, ако направим това, ще имаме проблеми с репликацията и транзакциите между двигателите.“
    Проблемът е, че много системи за управление на съхранение... често правят свои собствени WAL и PITR. Някои правят собствено управление на буфера, заключване и управление на репликация/зареждане. Така че, както казвате, трудно е да се каже къде трябва да бъде интерфейсът
    абстрахиран.
    връзка към това писмо в пощенския списък на postgresql

    Минаха повече от 10 години и какво виждаме? MySQL има досадни проблеми с транзакциите между таблици в различни машини за съхранение, а MySQL има проблеми с репликацията. През тези десет години PostgreSQL добави допълнителни типове данни и индекси, а също така има репликация - тоест предимството на MySQL е изравнено, докато архитектурните проблеми на MySQL остават и пречат на живота. MySQL 5.7 се опита да реши проблема с производителността на репликацията, като го паралелизира. Тъй като проектът по време на работа е много чувствителен към производителността на репликация поради неговия мащаб, аз се опитах да тествам дали се е подобрил. Открих, че паралелната репликация в 5.7 е по-бавна от репликацията с една нишка в 5.5 и само в някои случаи - приблизително същата. Ако в момента използвате MySQL 5.5 и искате да надстроите до по-нова версия, моля, имайте предвид, че миграцията не е възможна за силно натоварени проекти, тъй като репликацията просто вече няма да се справи.

    След разговора за високо натоварване Oracle взе под внимание разработения от мен тест и каза, че ще се опитат да решат проблема; наскоро дори ми писаха, че са успели да видят паралелизъм в техните тестове и ми изпратиха настройките. Ако не се лъжа при 16 нишки имаше леко ускорение спрямо еднонишковия вариант. За съжаление, все още не съм повторил тестовете си на предоставените настройки - особено защото с такива резултати нашите проблеми все още остават актуални.

    Точните причини за тази регресия на производителността не са известни. Имаше няколко предположения - например Кристиан Нелсен, един от разработчиците на MariaDB, написа в блога си, че може да има проблеми със схемата за изпълнение и синхронизирането на нишки. Поради това има регресия от 40%, която се вижда при редовни тестове. Разработчиците на Oracle опровергават това и дори ме убедиха, че не съществува; явно виждам някакъв друг проблем (и колко от тях има?).

    При репликацията на MySQL проблемите с механизма за съхранение се утежняват от избраното ниво на репликация - те са логически, докато в PostgreSQL те са физически. По принцип логическата репликация има своите предимства, позволява ви да правите по-интересни неща, това също ще спомена в доклада. Но PostgreSQL, дори в рамките на своята физическа репликация, вече намалява всички тези предимства до нищо. С други думи, почти всичко, което е в MySQL, вече може да се направи в PostgreSQL (или ще бъде възможно в близко бъдеще).

    Не можете да се надявате да приложите физическа репликация на ниско ниво в MySQL. Проблемът е, че вместо един журнал (както в PostgreSQL), има два или четири от тях, в зависимост от това как ги броите. PostgreSQL просто извършва заявки, те отиват в дневник и този дневник се използва при репликация. Репликацията на PostgreSQL е супер стабилна, защото използва същия журнал като операциите за преодоляване при отказ. Този механизъм е написан отдавна, добре тестван и оптимизиран.

    В MySQL ситуацията е различна. Имаме отделен журнал на InnoDB и регистър на репликация и трябва да извършим и двете. И това е двуфазов ангажимент между журналите, който по дефиниция е бавен. Тоест не можем просто да кажем, че повтаряме транзакция от журнала на InnoDB - трябва да разберем какъв вид заявка е и да я изпълним отново. Дори ако това е логическа репликация, на ниво ред, тогава тези редове трябва да се търсят в индекса. И не само, че трябва да свършите много работа, за да изпълните заявката, но тя отново ще бъде записана в нейния InnoDB журнал на репликата, което очевидно не е добро за производителността.

    В PostgreSQL в този смисъл архитектурата е много по-обмислена и по-добре реализирана. Наскоро обяви функция, наречена Логическо декодиране - която ви позволява да правите всякакви интересни неща, които са много трудни за правене в границите на физическо списание. В PostgreSQL това е добавка отгоре, логическото декодиране ви позволява да работите с физически журнал, сякаш е логически. Именно тази функционалност скоро ще премахне всички предимства на репликацията на MySQL, с изключение може би на размера на дневника - базираната на изявления MySQL репликация ще спечели - но базираната на изявления репликация на MySQL има напълно диви проблеми на най-неочакваните места и не трябва се счита за добро решение (за това също ще говоря за всичко това в доклада).

    Освен това има тригер репликация за PostgreSQL - това е Tungsten, който ви позволява да правите същото. Репликацията на тригера работи по следния начин: тригерите се задават, те попълват таблици или записват файлове, резултатът се изпраща до репликата и се прилага там. Чрез Tungsten, доколкото знам, те мигрират от MySQL към PostgreSQL и обратно. В MySQL логическата репликация работи директно на ниво двигател и вече не е възможно да се направи по друг начин.

    Документация

    PostgreSQL има много по-добра документация. MySQL дори формално изглежда го има, но значението на отделните опции може да бъде трудно за разбиране. Изглежда, че е написано какво правят, но за да разберете как да ги конфигурирате правилно, трябва да използвате неофициална документация и да потърсите статии по тази тема. Често трябва да разберете архитектурата на MySQL; без това разбиране настройките изглеждат като някаква магия.

    Например, компанията Percona излетя: те пуснаха MySQL Performance Blog и в този блог имаше много статии, които обсъждаха някои аспекти на използването на MySQL. Това донесе дива популярност, насочи клиентите към консултации и ни позволи да привлечем ресурси, за да стартираме разработката на нашия собствен Percona-Server fork. Съществуването и популярността на MySQL Performance Blog доказва, че официалната документация просто не е достатъчна.

    PostgreSQL всъщност има всички отговори в своята документация. От друга страна, чух много критики, когато сравнявах документацията на PostgreSQL с „порасналия“ Oracle. Но всъщност това е много важен показател. Никой изобщо не се опитва да сравнява MySQL с възрастния Oracle - това би било смешно и абсурдно - но PostgreSQL вече започва да се сравнява доста сериозно, общността на PostgreSQL чува тази критика и работи за подобряване на продукта. Това предполага, че по своите възможности и производителност започва да се конкурира с такава мощна система като Oracle, която се използва от мобилни оператори и банки, докато MySQL остава в нишата на уебсайтовете. И гигантски проекти, които са нараснали до голямо количество данни и потребители, лапат MySQL с голяма лъжица, непрекъснато се натъкват на неговите ограничения и архитектурни проблеми, които не могат да бъдат коригирани с изразходване на разумно количество усилия и време.

    Пример за такива големи проекти на PostgreSQL е 1C: PostgreSQL идва като опция вместо Microsoft SQL, а Microsoft SQL е наистина фантастична СУБД, една от най-мощните. PostgreSQL може да замени MS SQL, а опитвайки се да го заменим с MySQL... нека спуснем завесата на съжалението над тази сцена, както е писал Марк Твен.

    Стандарти

    PostgreSQL отговаря на SQL-92, SQL-98, SQL-2003 (всички разумни части от него са внедрени) и вече работи върху SQL-2011. Това е много яко. За сравнение MySQL дори не поддържа SQL-92. Някои ще кажат, че в MySQL такава цел просто не е била поставена от разработчиците. Но трябва да разберете, че разликата между версиите на стандарта не са малки промени - това са нови функции. Тоест, в момента, в който MySQL каза: „Ние няма да следваме стандарта“, те не само въвеждаха някои незначителни разлики, които правеха MySQL труден за поддръжка, но също така затваряха вратата за внедряването на много необходими и важни функции. Все още няма подходящ оптимизатор. Това, което там се нарича оптимизация, се нарича „парсер“ плюс нормализиране в PostgreSQL. В MySQL това е просто план за изпълнение на заявка, без разделяне. И MySQL няма да дойде да поддържа стандарти много скоро, тъй като тежестта на обратната съвместимост тежи върху тях. Да, искат го, но след пет години може би ще имат нещо. PostgreSQL вече има всичко.

    Изпълнение и административна сложност

    От гледна точка ти простоадминистративното сравнение не е в полза на PostgreSQL. MySQL е много по-лесен за администриране. И не защото в този смисъл е по-добре обмислен, а просто знае как да направи много по-малко. Съответно е по-лесно да го конфигурирате.

    MySQL има проблем със сложни заявки. Например MySQL не знае как да раздели група на отделни части на union all. Разликата между двете заявки - в нашия пример групирането по отделни таблици и обединяването на всички отгоре работи 15 пъти по-бързо от обединяването на всички и след това групирането, въпреки че оптимизаторът трябва да приведе и двете заявки в един и същ ефективен план за изпълнение на заявката. Ще трябва да генерираме такива заявки ръчно - тоест да губим времето на разработчиците за това какво трябва да прави базата данни.

    „Простотата“ на MySQL е резултат, както може да се види по-горе, от изключително слаби възможности - MySQL просто работи по-зле и изисква повече време и усилия по време на разработката. За разлика от тях PostrgreSQL има хистограми и нормален оптимизатор и ще изпълнява такива заявки ефективно. Но ако има хистограми, има и техните настройки - поне размер на кофата. Трябва да знаете за настройките и да ги промените в някои случаи - следователно трябва да разберете какво представлява тази настройка, за какво отговаря, да можете да разпознавате такива ситуации и да видите как да изберете оптималните параметри.

    Понякога се случва умението на PostrgreSQL да попречи, вместо да помогне. 95% от времето всичко работи добре - по-добре от MySQL - но една глупава заявка работи много по-бавно. Или всичко работи добре и след това изведнъж (от гледна точка на потребителя), докато проектът расте, някои заявки започват да работят зле (има повече данни, започва да се избира различен план за изпълнение на заявката). Най-вероятно, за да го поправите, просто стартирайте анализ или коригирайте малко настройките. Но трябва да знаете какво да правите и как да го правите. Като минимум трябва да прочетете документацията на PostgreSQL по тази тема, но по някаква причина те не обичат да четат документация. Може би защото е от малка помощ в MySQL? :)

    Бих искал да подчертая, че PostgreSQL не е по-лош в този смисъл, той просто ви позволява да отлагате проблемите, докато MySQL веднага ги изхвърля и трябва да отделите време и пари за решаването им. В този смисъл MySQL винаги работи постоянно лошо и дори на етапа на разработка хората вземат предвид тези функции: те правят всичко по възможно най-простия начин. Това се отнася само за производителността, по-точно за методите за нейното постигане и нейната предвидимост. От гледна точка на коректност и удобство, PostgreSQL е с глава над MySQL.

    И така, какво трябва да изберете?

    За да изберете между MySQL и PostgreSQL за конкретен проект, първо трябва да отговорите на други въпроси.

    Първо, какъв опит има екипът? Ако целият екип има 10 години опит в работата с MySQL и трябва да започне да работи възможно най-бързо, тогава не е факт, че си струва да смените познат инструмент с непознат. Но ако крайните срокове не са критични, тогава PostgreSQL си струва да опитате.

    Второ, не трябва да забравяме за оперативните проблеми. Ако нямате силно натоварен проект, тогава от гледна точка на производителността няма разлика между тези две СУБД. Но PostgreSQL има друго важно предимство: той е по-стриктен, прави повече проверки вместо вас, дава ви по-малко възможности да правите грешки и това е огромно предимство в дългосрочен план. Например в MySQL трябва да напишете свои собствени инструменти, за да проверите редовната референтна цялост на базата данни. И дори с това може да има проблеми. В този смисъл PostgreSQL е по-мощен, по-гъвкав инструмент и е по-приятно да се развива върху него. Но това до голяма степен зависи от опита на разработчика.

    Да обобщим: ако имате обикновен онлайн магазин, нямате пари за администратор, нямате сериозни амбиции да прераснете в голям проект и имате опит в работата с MySQL, тогава вземете MySQL. Ако очаквате, че проектът ще бъде популярен, ако е голям, ще бъде трудно да го пренапишете, ако има сложна логика и връзки между таблици - вземете PostgreSQL. Дори и извън кутията, той ще работи за вас, ще ви помогне в развитието, ще спести време и ще ви улесни в растежа.

    Релационните бази данни се използват отдавна. Те станаха популярни благодарение на системите за управление, които прилагат релационния модел толкова добре, че това е най-добрият начин за работа с данни, особено за критични приложения и услуги.

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

    Базите данни са предназначени за структурирано съхранение и бърз достъп до различни данни. Всяка база данни, освен самите данни, трябва да има определен оперативен модел, според който ще се извършва обработката на данните. За управление на бази данни се използват СУБД или системи за управление на бази данни, като такива програми включват MySQL и Postgresql.

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

    Разказ

    MySQL

    Разработката на MySQL започва още през 90-те години. Първото вътрешно издание на базата данни се състоя през 1995 г. През това време няколко компании разработваха програмата. Разработката започна от шведската компания MySQL AB, която беше придобита от Sun Microsystems, която сама стана собственост на Oracle. В момента, от 2010 г., Oracle го разработва.

    Postgresql

    Разработката на Postrgresql започва през 1986 г. в Калифорнийския университет в Бъркли. Разработката продължи почти осем години, след което проектът беше разделен на две части: комерсиалната база данни IIlustra и напълно безплатният проект Postrgesql, който се разработва от ентусиасти.

    Хранилище за данни

    MySQL

    MySQL е релационна база данни; различни двигатели се използват за съхраняване на данни в таблици, но работата с двигателите е скрита в самата система. Двигателят не влияе върху синтаксиса на заявките и тяхното изпълнение. Основните поддържани машини са MyISAM, InnoDB, MEMORY, Berkeley DB. Те се различават по начина, по който данните се записват на диска, както и по методите за четенето им.

    Postgresql

    Postgresql е обектно-релационна база данни, която работи само на един двигател - двигателят за съхранение. Всички таблици са представени като обекти, могат да се наследяват и всички действия с таблици се извършват с помощта на целево-ориентирани функции. Както и в MySQL, всички данни се съхраняват на диск, в специално сортирани файлове, но структурата на тези файлове и записите в тях е много различна.

    SQL стандарт

    Независимо от използваната система за управление на база данни, SQL е стандартизиран език за заявки. И се поддържа от всички решения, дори MySQL или Postgresql. Стандартът SQL е разработен през 1986 г. и през това време вече са пуснати няколко версии.

    MySQL

    MySQL не поддържа всички нови функции на стандарта SQL. Разработчиците избраха този път на развитие, за да поддържат MySQL лесен за използване. Компанията се старае да отговаря на стандартите, но не за сметка на простотата. Ако някоя функция може да подобри използваемостта, тогава разработчиците могат да я внедрят като свое собствено разширение, без да обръщат внимание на стандарта.

    Postgresql

    Postgresql е проект с отворен код, разработен е от екип ентусиасти и разработчиците се опитват да се съобразят с SQL стандарта, доколкото е възможно, и да внедрят всички най-нови стандарти. Но всичко това е за сметка на простотата. Postgresql е много сложен и поради това не е толкова популярен като MySQL.

    Възможности за обработка

    Други разлики между postgresql и mysql излизат от предишния параграф: възможности за обработка на данни и ограничения. Естествено, съответствието с по-новите стандарти носи по-нови възможности.

    MySQL

    Когато изпълнява заявка, MySQL зарежда целия отговор на сървъра в паметта на клиента; за големи количества данни това може да не е много удобно. По принцип Postgresql превъзхожда Mysql по отношение на функции; ще разгледаме кои от тях по-нататък.

    Postgresql

    Postgresql поддържа използването на курсори за навигация в получените данни. Получавате само указател; целият отговор се съхранява в паметта на сървъра на базата данни. Този указател може да се запазва между сесиите. Поддържа изграждане на индекси за няколко колони на таблица наведнъж. Освен това индексите могат да бъдат от различни видове; в допълнение към хеш и b-дърво, GiST и SP-GiST са налични за работа с градове, GIN за текстово търсене, BRIN и Bloom.

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

    производителност

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

    MySQL

    В повечето случаи InnoDB таблица се използва за организиране на работа с база данни в MySQL; тази таблица е B-дърво с индекси. Индексите ви позволяват да извличате данни от диска много бързо и изискват по-малко дискови операции. Но сканирането на дърво изисква намирането на два индекса, а това вече е бавно. Всичко това означава, че MySQL ще бъде по-бърз от Postgresql само когато използва първичен ключ.

    Postgresql

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

    Като цяло PostgreSQL е по-бърз, с изключение на използването на първични ключове. Нека да разгледаме някои тестове с различни операции:


    Типове данни

    Един от акцентите на двете бази данни е поддържаните типове данни, които можете да използвате. Тъй като и двете решения се опитват да съпоставят SQL синтаксиса, те имат подобни набори, но все пак се различават по някои начини.

    MySQL

    MySQL поддържа следните типове данни:

    • TINYINT: много малко цяло число.;
    • SMALLINT:малко цяло;
    • СРЕДЕН:средно голямо цяло;
    • INT:цялата е с нормален размер;
    • BIGINT:голямо цяло;
    • FLOAT:число с плаваща запетая с единична точност със знак;
    • ДВОЙНА, ДВОЙНА ТОЧНОСТ, ИСТИНСКИ:число с плаваща запетая с двойна точност със знак
    • DECIMAL, NUMERIC:число с плаваща запетая със знак;
    • ДАТА:дата на;
      ВРЕМЕ ЗА СРЕЩА:комбинация от дата и час;
    • КЛАВО ЗА ЧАС:клеймо за време;
    • ВРЕМЕ:време;
      ГОДИНА:година във формат ГГ или ГГГГ;
    • CHAR: низ с фиксиран размер, подплатен отдясно с интервали до максимална дължина;
    • VARCHAR:низ с променлива дължина;
    • TINYBLOB, TINYTEXT:двоични или текстови данни с максимална дължина 255 знака;
    • BLOB, ТЕКСТ: двоични или текстови данни с максимална дължина 65535 знака;
    • MEDIUMBLOB, MEDIUMTEXT:текстови или двоични данни;
    • LONGBLOB, LONGTEXT:текст или двоични данни с дължина максимум 4294967295 знака;
    • ENUM:изброяване;
    • КОМПЛЕКТ:множества.

    Postgresql

    Поддържаните типове полета в Postgresql са доста различни, но ви позволяват да записвате абсолютно същите данни:

    • bigint: 8-байтово цяло число със знак;
    • bigserial: автоматично увеличаващо се 8-байтово цяло число;
    • малко:двоичен низ с фиксирана дължина;
    • малко варира:двоичен низ с променлива дължина;
    • булево:флаг;
    • кутия:правоъгълник на равнина;
    • байт: двоични данни;
    • променлив характер:символен низ с фиксирана дължина;
    • персонаж:
    • cidr: IPv4 или IPv6 мрежов адрес;
    • кръг:кръг на равнина;
    • дата: календарна дата;
    • двойна точност:число с плаваща запетая с двойна точност;
    • инет:Интернет адрес IPv4 или IPv6;
    • цяло число: 4-байтово цяло число със знак;
    • интервал:Период;
    • линия:безкрайна права линия на равнина;
    • lseg:сегмент на равнина;
    • macaddr:Мак адрес;
    • пари:парична стойност;
    • път:геометричен път на равнина;
    • точка:геометрична точка на равнина;
    • многоъгълник:многоъгълник на равнина;
    • истински:число с плаваща запетая с единична точност;
    • smallint:двубайтово цяло число;
    • сериен:автоматично увеличаващо се четири-битово цяло число;
    • текст:символен низ с променлива дължина;
    • време:Часове от деня;
    • клеймо за време:дата и час;
    • tsquery: заявка за търсене на текст;
    • tsvector:документ за търсене на текст;
    • uuid: уникален идентификатор;
    • xml: XML данни.

    Както можете да видите, в Postgresql има повече типове данни и те са по-разнообразни; има типове полета за определени типове данни, които MySQL няма. Разликата между MySQL и Postgresql е очевидна.

    развитие

    И двата проекта са с отворен код, но са разработени по различен начин. Не всеки харесва развитието на MySQL. И тук сравнението на mysql и postgresql дава много разлики.

    MySQL

    Базата данни MySQL се разработва от Oracle и има слухове, че компанията възнамерява да забави развитието на двигателя. Бяха създадени много разклонения на проекта, включително разклонение на MariaDB от разработчика на оригиналния MySQL. Но все пак развитието остава бавно.

    Postgresql

    Както бе споменато в началото на статията, разработката започна в университета в Бъркли. След това се премества в търговско дружество. В момента програмата се разработва от независима група програмисти и борда на няколко компании. Новите версии се пускат доста активно и получават все повече и повече нови функции.

    заключения

    В тази статия сравнихме mysql и postgresql, разгледахме основните разлики между двете системи за управление на бази данни и се опитахме да разберем кое е по-добро, postgresql или mysql. Като цяло Postgresql е най-добрият като възможности, но е сложен и не може да се използва навсякъде. MySQL е по-опростен, но не поддържа някои интересни функции. Коя база данни ще изберете за вашия проект? Защо тя? Пишете в коментарите!

    В заключение на видеото, описващо възможностите и перспективите на Postgresql:

    Серия съдържание:

    1. История на развитието на MySQL и PostgreSQL

    Историята на MySQL започва през 1979 г., в основата му имаше малка компания, ръководена от Монти Видениус. През 1996 г. се появи първото издание на 3.11 за Solaris с публичен лиценз. Тогава MySQL беше пренесен към други операционни системи и се появи специален търговски лиценз. През 2000 г., след добавяне на интерфейс, подобен на Berkeley DB, базата данни става транзакционна. Репликацията беше добавена приблизително по същото време. През 2001 г. версия 4.0 добави двигателя InnoDB към съществуващия MyISAM, което доведе до кеширане и повишена производителност. През 2004 г. беше пусната версия 4.1, която въведе подзаявки, частично индексиране за MyISAM и Unicode. Във версия 5.0 през 2005 г. се появиха съхранени процедури, курсори, тригери и изгледи. MySQL развива търговски тенденции: през 2009 г. MySQL стана търговска марка на Oracle.

    Историята на Postgres започва през 1977 г. с базата данни Ingress.

    През 1986 г. е преименуван на PostgreSQL в университета Бъркли, Калифорния.

    През 1995 г. Postgres стана отворена база данни. Появи се интерактивен psql.

    През 1996 г. Postgres95 беше преименуван на PostgreSQL версия 6.0.

    Postgres има няколкостотин разработчици по целия свят.

    2. Архитектура на MySQL и PostgreSQL

    PostgreSQL– унифициран сървър на база данни с един двигател – двигател за съхранение. Postgres използва модел клиент-сървър.

    За всеки клиент на сървъра се създава нов процес (не нишка!). За да работи с такива клиентски процеси, сървърът използва семафори.

    Клиентската заявка преминава през следните етапи.

    1. Свържете се.
    2. Разбор: проверява се коректността на заявката и се създава дърво на заявката. Анализаторът е базиран на основните Unix помощни програми yacc и lex.
    3. Rewrite: взема се дърво на заявка и се проверява наличието на правила в него, които се намират в системните директории. Всеки път, когато потребителската заявка се пренаписва в заявка, която има достъп до таблиците на базата данни.
    4. Оптимизатор: за всяка заявка се създава план за заявка, който се предава на изпълнителя. Смисълът на плана е, че преминава през всички възможни варианти за получаване на резултата (дали да се използват индекси, обединения и т.н.), и се избира най-бързият вариант.
    5. Изпълнение на заявка: изпълнителят преминава рекурсивно в дървото и получава резултата, използвайки сортиране, обединяване и т.н., и връща редове. Postgres е обектно-релационна база данни, всяка таблица в нея представлява клас, а между таблиците е имплементирано наследяване. Внедрени стандарти SQL92 и SQL99.

    Транзакционният модел е изграден на базата на т. нар. multi-version concurrency control (MVCC), което дава максимална производителност. Референтната цялост се осигурява от наличието на първичен и вторичен ключ.

    MySQLима два слоя - външен sql слой и вътрешен набор от машини, от които най-често се използва InnoDb машината, тъй като тя най-пълно поддържа ACID.

    Въведен стандарт SQL92.

    От модулна гледна точка кодът на MySQL може да бъде разделен на следните модули.

    1. Инициализация на сървъра.
    2. Мениджър на връзките.
    3. Мениджър на потоци.
    4. Манипулатор на команди.
    5. Удостоверяване.
    6. Анализатор.
    7. Оптимизатор.
    8. Мениджър на маса.
    9. Двигатели (MyISAM, InnoDB, MEMORY, Berkeley DB).
    10. Сеч.
    11. Репликация.
    12. API на мрежата.
    13. API на ядрото.

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

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

    Клиентските заявки, в зависимост от вида им, се обработват на най-високо ниво от четвъртия модул (диспечер). Заявките ще бъдат регистрирани до 11-ия модул. Командата се предава на анализатора и кеша се проверява. След това заявката може да отиде до оптимизатора, модула за таблица, модула за репликация и т.н. В резултат на това данните се връщат на клиента чрез мениджъра на потока.

    Най-важният код е във файла sql/mysqld.cc. Той съдържа основни функции, които не са променени от версия 3.22: init_common_variables() init_thread_environment() init_server_components() grant_init() // sql/sql_acl.cc init_slave() // sql/slave.cc get_options() handle_connections_sockets() create_new_thread () handle_one_connection() check_connection() acl_check_host() // sql/sql_acl.cc create_random_string() // sql/password.cc check_user() // sql/sql_parse.cc mysql_parse() // sql/sql_parse.cc dispatch_command() Query_cache ::store_query() // sql/sql_cache.cc JOIN::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update.cc mysql_check_table() // sql/sql_table.cc

    Заглавката sql/sql_class.h дефинира базовите класове: Query_arena, Statement, Security_context, класове Open_tables_state, THD. Обект от класа THD е дескриптор на нишка и е аргумент на голям брой функции.

    3. Сравнение на MySQL и PostgreSQL: прилики и разлики

    Стандарт ACID

    Стандартът ACID се основава на атомарност, цялост, изолация и надеждност. Този модел се използва за гарантиране на целостта на данните. Това се осъществява на базата на транзакции. PostgreSQL е напълно съвместим с ACID. За да поддържате изцяло ACID в MySQL, трябва да зададете default-storage-engine=innodb в конфигурацията.

    производителност

    Базите данни често се оптимизират въз основа на средата, в която работят. И двете бази имат различни технологии за подобряване на производителността. Исторически погледнато, MySQL е разработен с мисъл за скоростта, докато PostgreSQL е проектиран от самото начало да бъде силно персонализиран и съвместим със стандартите. PostgreSQL има редица настройки, които увеличават скоростта на достъп:

    • частични индекси;
    • компресиране на данни;
    • разпределение на паметта;
    • подобрен кеш.

    MySQL има частична поддръжка за частични индекси в InnoDB. Ако вземете двигателя MySQL ISAM, той се оказва по-бърз при плоски заявки, докато няма блокиране на вмъквания, няма поддръжка за транзакции, външни ключове.

    Компресия

    PostgreSQL компресира и декомпресира данните по-добре, което ви позволява да спестите повече данни на дисковото пространство. В същото време компресираните данни се четат по-бързо от диска.

    Компресията на MySQL за различни двигатели се поддържа отчасти, отчасти не и това зависи от конкретната версия на даден двигател.

    По отношение на многопроцесорната производителност, PostgreSQL има предимство пред MySQL. Дори самите разработчици на MySQL признават, че техният двигател не е толкова добър в това отношение.

    Типове данни

    MySQL: използва типове TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB за съхраняване на двоични данни, които се различават по размер (до 4 GB).

    Символ: четири типа - TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

    PostgreSQL: Поддържа машина за потребителски данни с команда CREATE TYPE, тип BOOLEAN, геометрични типове.

    Символ: ТЕКСТ (ограничение – максимален размер на реда).

    За съхраняване на двоични данни има тип BLOB, който се съхранява във файловата система. Колоните на таблицата могат да бъдат дефинирани като многоизмерен масив с променлива дължина. Обектно-релационно разширение: Структурата на една таблица може да бъде наследена от друга таблица.

    Съхранени процедури

    И PostgreSQL, и MySQL поддържат съхранени процедури. PostgreSQL следва стандарта Oracle PL/SQL, MySQL следва стандарта IBM DB2. MySQL поддържа разширение на SQL за писане на функции в C/C++ от версия 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C за писане на съхранени процедури.

    Ключове

    Както PostgreSQL, така и MySQL поддържат уникален първичен ключ и външен ключ. MySQL не поддържа ограничение за проверка, плюс вторичните ключове са частично внедрени. PostgreSQL: пълно внедряване плюс поддръжка за ON DELETE CASCADE и ON UPDATE CASCADE.

    Тригери

    MySQL: елементарна поддръжка. PostgreSQL: декларативни тригери: SELECT, INSERT, DELETE, UPDATE, INSTEAD OF; процедурни тригери: CONSTRAINT TRIGGER. Събития: ПРЕДИ или СЛЕД на INSERT, DELETE, UPDATE.

    Автоматично увеличаване

    MySQL: Може да има само една такава колона в таблица, която трябва да бъде индексирана. PostgreSQL: SERIAL тип данни.

    Репликации

    Поддържа се както в MySQL, така и в PostgreSQL. PostgreSQL има модулна архитектура и репликацията е включена в отделни модули:

    • Slony-I е основният механизъм за репликация в Postgres; производителността намалява като квадратична функция на броя на сървърите;

    Репликацията в PostgreSQL е базирана на тригери и е по-бавна, отколкото в MySQL. Предвижда се добавяне на репликация към ядрото от версия 8.4.

    В MySQL репликацията е включена в ядрото и има два варианта, като се започне от версия 5.1:

    • SBR – репликация, базирана на оператори;
    • RBR – репликация, базирана на ред.

    Първият тип се основава на регистриране на записи в двоичен журнал, вторият е базиран на регистриране на промени. Започвайки от версия 5.5, MySQL поддържа така наречената полусинхронна репликация, при която главният сървър (master) нулира данните към друг сървър (slave) с всеки комит. Машината NDB извършва пълна синхронна двуфазна репликация.

    Транзакции

    MySQL: само InnoDB. Поддръжка на SAVEPOINT, ВЪРТАНЕ КЪМ SAVEPOINT. Нива на заключване: ниво таблица (MyISAM). PostgreSQL: поддържа се плюс ангажирани за четене и нива на изолация. Поддръжка ROLLBACK, ROLLBACK TO SAVEPOINT. Нива на заключване: ниво ред, ниво таблица.

    Нива на привилегии

    PostgreSQL: Привилегиите могат да бъдат присвоени на потребител или потребителска група.

    Експорт-импорт на данни

    MySQL: набор от помощни програми за експортиране: mysqldump, mysqlhotcopy, mysqlsnapshot. Импортиране от текстови файлове, html, dbf. PostgreSQL: експортиране - помощна програма pg_dump. Импортиране между бази данни и файлова система.

    Вложени заявки

    Предлага се както в MySQL, така и в PostgreSQL, но може да не работи ефективно в MySQL.

    Индексиране

    Хеширане на индекс: частично в MySQL, пълно в PostgreSQL. Пълнотекстово търсене: частично в MySQL, пълно в PostgreSQL. Частични индекси: не се поддържат в MySQL, поддържат се в PostgreSQL. Многоколонни индекси: в MySQL ограничението е 16 колони, в PostgreSQL – 32. Експресионни индекси: в MySQL – емулация, в PostgreSQL – пълни. Неблокиращ индекс за създаване: в MySQL - частичен, в PostgreSQL - пълен.

    Преграждане

    MySQL поддържа хоризонтално разделяне: диапазон, списък, хеш, ключ, съставно разделяне. PostgreSQL поддържа RANGE и LIST. Автоматично разделяне на таблици и индекси.

    Автоматично възстановяване от повреди

    MySQL: частично за InnoDB - трябва ръчно да направите резервно копие. PostgreSQL: Предварително записване в журнал (WAL).

    Механизми за съхранение на данни

    PostgreSQL поддържа един двигател – Postgres Storage System. Има няколко от тях в MySQL 5.1:

    • MyISAM – използва се за съхраняване на системни таблици;
    • InnoDB – максимално съответствие с ACID, съхранява данни с първични ключове, кешира вмъквания, поддържа компресия, започвайки от версия 5.1 – вижте атрибута ROW_FORMAT=COMPRESSED;
    • NDB Cluster – двигател, ориентиран към паметта, клъстерна архитектура, използваща синхронна репликация;
    • АРХИВ – поддържа компресия, не използва индекси;
    • и също така: ОБЕДИНЯВАНЕ, ПАМЕТ (HEAP), CSV.

    InnoDB е разработена от InnoBase, дъщерно дружество на Oracle. Във версия 6 трябва да се появят два двигателя - Maria и Falcon. Falcon е двигател, базиран на ACID транзакции.

    Лицензиране

    PostgreSQL: BSD (Berkeley Software Distribution) с отворен код. MySQL: GPL (общ публичен лиценз на Gnu) или търговски. MySQL е продукт с отворен код. Postgres е проект с отворен код.

    Заключение

    За да обобщим, можем да кажем следното: MySQL и PostgreSQL са двете най-популярни бази данни с отворен код в света. Всяка основа има свои собствени характеристики и разлики. Ако имате нужда от бързо съхранение за прости заявки с минимална настройка, бих препоръчал MySQL. Ако имате нужда от надеждно хранилище за големи количества данни, разширяемо, репликируемо и напълно съвместимо със съвременните езикови стандарти SQL, бих предложил да използвате PostgreSQL.

    Ще обсъдим проблеми с конфигурацията за MySQL и PostgreSQL.

    Ресурси за изтегляне

    static.content.url=http://www.site/developerworks/js/artrating/

    Зона=Отворен код, Linux

    ИД на артикула=779830

    ArticleTitle=MySQL & PostgreSQL: Част 1. Сравнителен анализ



     

    Може да е полезно да прочетете: