Сравнение на MySQL и PostgreSQL. Изберете subd между mysql, postgresql, mariadb и mssql? Сравнение на производителността на ms sql сървър и postgresql

Нека бъдем честни, въпреки че 1C Enterprise е съвместим с много СУБД, всъщност 99 процента работят или в MS SQL, или в безплатен PostgreSQL.

С други думи, тези два "подчинения" завладяха пазара клиент-сървър 1C.

И можем спокойно да предположим, че ако компанията не работи в MS SQL, тогава най-вероятно те просто използват PostgreSQL.

Съответно има смисъл да се сравнява Postgres само с MS SQL.

Днес се пише много както за MS SQL, така и за PostgreSQL, но обикновено не ги сравняват обективно.

В тази статия ще анализираме основните технически точки на безплатния PostgreSQL, сравнявайки го с MS SQL.

Това ще ви позволи да направите най-добрия избор в бъдеще и да сте подготвени за различни „изненади“ или, което би било по-правилно, „характеристиките“ на работата в тази безплатна СУБД.

Ще оценим всичко такова, каквото е, без да добавяме към Postgres тези предимства, които няма и без да украсяваме платената MS.

Веднага ще отговоря на въпроса, който тревожи много начинаещи!

ДА! MS SQL е по-бърз от PostgreSQL, това е факт! И има редица причини за това!

Може би веднага разочаровах някого и може би не сте съгласни с това твърдение, съжалявам, но самата физика на тази безплатна СУБД не й позволява да изпревари MS SQL, особено ако говорим за такъв куп като "Monster 1C" и PostgreSQL.

Подобни аргументи ще срещнете повече от веднъж на различни конференции и семинари, посветени на тази СУБД. Никой нищо не крие и не отрича, фактът си е факт.

Въпреки това, производителността на PostgreSQL е напълно достатъчна за потребителите може да работи удобно в 1C.

Независимо дали става въпрос за дузина потребители или дори няколкостотин, работещи едновременно в 1C Enterprise.

Защо "Monster 1C"?

Всъщност ето как 1C вижда PostgreSQL без инсталирани специални „кръпки“ и разширения.

Да, това, което се нарича извън кутията, чрез изтегляне на комплекта за разпространение на PostgreSQL в офиса. сайт, няма да можете да го използвате за работа заедно с 1C. 1C-ka ужасно ще се забави и просто ще спре, ще откаже да работи.

Защо се случва това и защо "кръпки"?

Факт е, че 1C Enterprise създава огромен брой временни таблици в хода на работата си, можем да говорим около хиляди таблици в секунда,и ако вземем например регистъра „Отрез от последното“ - „Остатъци и обороти“, там може и и милион редада бъде.

Факт е, че по подразбиране (без „кръпки“) PostgreSQL не отчита статистики за тези големи временни таблици, с други думи, оптимизаторът на заявките, който се ръководи от данните от статистиката (и, както си спомняме, той е празен, няма какво да броим) грубо казано, прави селекция с помощта на ИЗБЕРЕТЕ *което разбира се ще работи много, много бавно!

Оттук и грандиозните спирачки в 1C!

Разбира се, това не са всички проблеми, които трябва да бъдат решени, така че PostgreSQL да работи нормално в тандем с 1C. Ще са необходими и други "кръпки". специални разширенияа след 15-20 потребителя и доп. настройките в конфиг

Да, в действителност всичко изглежда много по-сложно, отколкото описах по-горе, но ако го опростите много, основният проблем на бавната работа на 1C с PostgreSQL ще изглежда така.

Второто нещо, което наистина не харесвам в PostgreSQL е няма многопоточност в рамките на една заявкав сравнение с MS SQL.

(Започвайки от версия 9.6, направихме първия опит за паралелизиране на заявки, но досега работи зле, понякога ефектът е обратен). но за опита 5!)

Което разбира се влияе върху производителността, така че да разберете с прости думи -

PostgreSQL може да свали вашия 48-ядрен сървър с една голяма заявка!

Просто е, няма паралелизиране на нишки в рамките на една заявка и една голяма заявка "зарежда" само едно ядро.

Да, ако има много заявки, тогава всички ядра ще бъдат заредени и всичко ще работи добре.

И почти забравих сравняваме PostgreSQL с MS SQL Standard, а не Express!

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

като 10 GB на база, използване на един процесор, 1 GB оперативна памет,

прави използването на такъв продукт почти нереалистично за работа в 1C Enterprise.

Освен ако нямате много малка база данни и само няколко потребители (и дори тогава има много малко спирачки от 1 GB за СУБД).

Така че нека сравним PostgreSQL с популярната стандартна версия.

СЦЕНАРИИ!!!

PostgreSQL е предимно скриптове в сравнение с MS SQL, повечето операции трябва да се извършват на ръка, да, разбира се, можете да инсталирате някои основни неща през интерфейса, но подчертавам, че основните и стъпка вляво, стъпка надясно и трябва да напишете скрипт или BASH на Linux или cmd, powershell на Windows.

Преглеждайте и анализирайте следите с помощта на SQL Server Profiler.

Добре познатият SQL Server Profiler липсва в PostgreSQL и под думата „липсва“ имам предвид, че ще вляза напълно, уви, няма нищо подобно в PostgreSQL.

Има, разбира се, помощни програми, които позволяват, ако имате време, да прихванете заявката или да зададете точка на прекъсване на 1C в дебъгера и да получите нещо и да видите, но в сравнение с Profiler, както се казва, това дори не беше близо.

Можете да настроите дневник и след това да прегледате всичко - но за дълго време!

Ето един пример:

1C програмист се опитва да отстрани грешки в някаква голяма заявка, отнема много време, например 30 минути, така че в PostgreSQL, за да влязат данните в дневника, тази заявка трябва да бъде изпълнена! Можете ли да си представите колко време отнема отстраняването на грешки в такава заявка?

Докато сте в MS SQL, можете да прекъснете изпълнението на заявката и да я анализирате в Profiler, тъй като тя вече ще бъде там, но със статус „неуспешно“.

Postgres няма равен по отношение на създаването на „резервни копия“!

Тук имате както инкрементално „резервно копие“, така и пълно архивиранеи непрекъснато WAL архивиране.

Всъщност има частично архивиране и частично възстановяване на данни.

Можете да конфигурирате непрекъснато архивиране и възстановяване в даден момент (Възстановяване в даден момент (PITR)).

Също репликация, се предлага първоначално в PostgreSQl без никакви „кръпки“ от помощни програми и добавки!

• Каскадна репликация
• Поточно репликиране
• Синхронна репликация
• Непрекъснато архивиране на резервен сървър

Всичко това вече е първоначално в PostgreSQl и, разбира се, не е в "експрес" и не е налично във версията MS SQL Standard.

За да получите всичко изброено по-горе в MS SQL, трябва да закупите много скъп MS SQL Enterprise, сега около $15 000.

Какво не е в сравнение с MS SQL?

БЕЗ диференциално "резервно"

Да, в PostgreSQl няма диференциално „резервно копие“, но има различни аналози на инкрементални „резервни копия“.

Например, постепенно "резервно копие" на ниво блок.

ИМА разделение на TABLESPACEs, което вече поддържа 1C по подразбиране!

Което между другото не е в MS SQL!

Например, можете да конфигурирате на кой диск ще имате „индекси“ и на кой диск ще се намира „таблицата“, това е много удобно при планиране на ИТ инфраструктура, когато става въпрос за големи 1C бази данни. ONLINE_ANALYZE за преизчисляване на статистиката. Същото важи и за файла *dt.

С PostgreSQL рядко се нуждаете от REINDEX!

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

Можете да правите "резервни копия" с изключение на таблици!

Например, имате няколко 1C програмисти, които работят във вашата компания, те са гарантирани резервни копиясъздаване на „резервни копия“ за по-нататъшно развитие.

В резултат на това потребителите страдат, базата данни се забавя по време на създаването на голямо „резервно копие“, особено ако тази база данни съдържа неща като различни прикачени файлове, архиви, документи от писма. Такива файлови таблици могат лесно да съдържат стотици гигабайти. И те също могат да бъдат изключени в PostgreSQl чрез създаване на „резервно копие“, следователно с малък размер и с цялата функционалност едновременно.

Така че отново не зареждаме мрежови устройства, не задръстваме канала, отделяме много по-малко време за създаване на такова „резервно копие“

В крайна сметка всички печелят! И потребителите, и програмистите, и админите спят спокойно.

В тази статия анализирахме само основните разлики между PostgreSQl и MS SQL (има и други), но ако решите да изберете в полза на една или друга СУБД, статията трябва да ви помогне!

Успех Колега!

P.S. Сега работя върху нов курс "1C и PostgreSQL" (Вече на етап запис, изчакайте, скоро!)

С уважение, Богдан.

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

репликация

Проблемът е, че много системи за управление на съхранение... често правят свои собствени WAL и PITR. Някои правят собствено управление на буфера, заключване и управление на репликация/зареждане. Така че, както казвате, трудно е да се каже къде трябва да бъде интерфейсът
абстрахиран.

Минаха повече от 10 години и какво виждаме? MySQL има досадни проблеми с транзакциите между таблици на различни машини за съхранение, а MySQL има проблеми с репликацията. През тези десет години PostgreSQL добави pluggable типове данни и индекси, а също така има репликация - тоест предимството на 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 log вече на репликата, което очевидно не е добре за производителността.

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

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

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

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

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

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

Стандарти

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

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

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

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

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

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

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

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

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

Трудно е да се намери организация, която да не използва счетоводни системи от 1C - дори в мегахолдинги, където SAP или OEBS отдавна са внедрени, те почти винаги се използват в една или друга област. Радващо е, че руският приложен софтуер се превърна в де факто стандарт за нашите компании, но има една тънкост: същият де факто стандарт за 1C: Самото предприятие стана Използване на Microsoft SQL Server като СУБД.

Сред практикуващите 1C-никнейми най-разпространеното мнение е, че без търговски СУБД няма да дойде нищо добро от американските производители, казват те, няколкостотин потребители неизбежно изискват инсталиране на база данни на MS SQL, Oracle Database или IBM DB2 в този случай. Относно работата под контрола на свободата на СУБД PostgreSQL, мненията на известните ни практици се различават, но в диапазона от „изобщо не работи“ до „подходящ за няколко десетки потребители, не повече“.

Имаше редица правдоподобни обяснения за такива скромни оценки: както активното използване на механизми за временни таблици от 1C платформи (които са внедрени твърде „честно“ в Postgres - с транзакционен DDL, всички възможности за възстановяване), така и особеностите на работата с текст данни (докато в областта на многоезичните текстове Vanilla Postgres отново е твърде консервативен, използвайки не най-високопроизводителните системни библиотеки), както и редица други по-малко значими аспекти.

Но ние тайно вярвахме в Postgres, особено след като сборката твърдеше, че решава всички онези проблеми, които скептиците използваха, за да оправдаят избора на комерсиална СУБД. Освен това за нас беше важно да получим целеви показатели за хардуерно-софтуерния комплекс - машина за бази данни за СУБД, изградена на базата на защитен от санкции хардуер и софтуер, разработен от IBS съвместно с Postgres Professional.

От репликираните приложения, най-очевидното приложение за такава машина, разбира се, са 1C системите. И резултатите от проведените сравнителни тестове напълно ни прехвърлиха от категорията на „тайните вярващи“ (и дори съмняващите се) в категорията на „убедените“: сега можем спокойно да кажем, че 1C:Enterprise версия 8.3 на Postgres Pro EE 1.5 build за Skala-SR / Postgres Pro работи по-добре отколкото на MS SQL 2012 на същия хардуер с всички възможни оптимизации.

И така, някои подробности за експериментите. По отношение на тестването на производителността, 1C има всичко систематично и научно - има типична конфигурация„Стандартен тест за натоварване“, при който се стартира бенчмаркът, като постепенно се добавят нови потребители към товара, докато приложението стане достатъчно отзивчиво за удобна работа. (По-точно, потребителите се добавят, докато стандартният резултат за производителност на приложението Apdex падне под прага от 0,85, а максималният брой такива ефективни потребители се счита за резултат от бенчмарка.)

Използвахме версия 8.3.9.1850 на 1C:Enterprise, стандартен тест за натоварване във версия 2.0.17.36. Първоначално беше решено да не даваме никакви отстъпки на Postgres: правим максимални оптимизации на MS SQL на възела от комплекса Skala-SR / Postgres Pro (поставяме Windows на гол метал, настройваме го според всички канони, за скорост правим ramdisk за временни таблици), а след това - връщаме същия възел в комплекса Skala-SR, преобръщаме Linux и Postgres Pro EE и само на него (без клъстерни чипове, налични в комплекса) - стартираме същият тест.

Тест първи: започваме със 100 задания, натоварването е 50/50 - половината генерира документи, половината генерира отчети. Тест 2: започнете с 400, заредете 70/30. MS SQL "приключи" в първия тест на 360 потребители, на втория - на 540, освен това ограничителят и в двете стартирания беше работата с локален вход / изход, въпреки факта, че процесорът беше средно само 30% натоварен. Postgres Pro в първия тест достигна 440 задания, а във втория - до 660, като всичко на сървъра на базата данни почиваше на процесора, който влиза в натоварването над 90% на "максимални потребители".

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

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

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

Историята на MySQL започва през 1979 г. с малка компания, ръководена от Monty Widenius. През 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. Пренаписване: дървото на заявката се взема и се проверява наличието на правила (правила) в него, които се намират в системните директории. Всеки път, когато потребителска заявка се пренаписва в заявка, която осъществява достъп до таблиците на базата данни.
4. Оптимизатор: за всяка заявка се създава план на заявка - query plan, който се предава на изпълнителя - изпълнител. Смисълът на плана е, че всички се движат през него възможни вариантиполучаване на резултата (дали да се използват индекси, съединения и т.н.) и се избира най-бързата опция.
5. Изпълнение на заявка: Изпълнителят обикаля дървото рекурсивно и получава резултата чрез сортиране, обединяване и т.н. и връща редове. Postgres е обектно-релационна база данни, всяка таблица в нея представлява клас, между таблиците е имплементирано наследяване. Внедрени стандарти SQL92 и SQL99.

Транзакционният модел се основава на така наречения контрол на паралелността на много версии (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 поддържа така наречената полусинхронна репликация, при която основният сървър (главен) изхвърля данни към друг сървър (подчинен) при всеки комит. Машината NDB извършва пълна синхронна двуфазна репликация.

Транзакции

MySQL: Само за InnoDB. Поддръжка на SAVEPOINT, ROLLBACK TO 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.website/developerworks/js/artrating/

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

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

ArticleTitle=MySQL & PostgreSQL: Част 1 Бенчмаркинг

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

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

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

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

Разказ

MySQL

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

postgresql

Разработването на Postgresql започва през далечната 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:документ за търсене на текст;
• uid: уникален идентификатор;
• xml: XML данни.

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

развитие

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

MySQL

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

postgresql

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

заключения

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

В края на видеото, описващо характеристиките и перспективите на Postgresql: