Десетте най-добри причини за мигриране от Oracle към PostgreSQL

Системата за управление на релационни бази данни на Oracle (RDBMS) се използва широко от големите организации и се счита за най-модерната технология за бази данни, налична на пазара. Обикновено това е най-често сравняваната RDBMS с други продукти за бази данни, служещи като стандартен „де-факто“ за това, което продуктът трябва да предлага. Тя е класирана от db-engines.com като RDBMS №1, налична на пазара днес.

PostgreSQL е класиран като #4 RDBMS, но това не означава, че няма никакви предимства при мигрирането към  PostgreSQL. PostgreSQL съществува от 1989 г. и е с отворен код през 1996 г. PostgreSQL печели СУБД на годината в две последователни години от 2017 и 2018 г. Това само показва, че няма признаци за спиране на привличането на голям брой потребители и големи организации.

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

Преминаването от работеща и продуктивна база данни на Oracle може да бъде трудна задача. Притеснения като общата цена на собственост на компанията (общата цена на собственост) са една от причините компаниите да протакат решението си дали да се откажат от Oracle.

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

Причина първа:Това е истински проект с отворен код

PostgreSQL е с отворен код и се издава под PostgreSQL License, либерален лиценз с отворен код, подобен на лицензите BSD или MIT. Придобиването на продукта и поддръжката не изисква такса.

Ако искате да използвате софтуера на базата данни, това означава, че можете да получите всички налични функции на базата данни PostgreSQL безплатно. PostgreSQL е на повече от 30 години на зрялост в света на базата данни и е базиран на докосване като отворен код от 1996 г. Той се радва на десетилетия на разработчиците, които работят за създаване на разширения. Това само по себе си кара разработчиците, институциите и организациите да избират PostgreSQL за корпоративни приложения; захранване на водещи бизнес и мобилни приложения.

Отново организациите се събуждат с осъзнаването, че решенията за бази данни с отворен код като Postgres предлагат по-голям капацитет, гъвкавост и поддръжка, които не зависят изцяло от нито една компания или разработчик. Postgres, подобно на Linux преди него, е бил (и продължава да бъде) проектиран от отдадени потребители, решаващи ежедневни бизнес проблеми, които избират да върнат своите решения на общността. За разлика от голям разработчик като Oracle, който може да има различни мотиви за разработване на продукти, които са печеливши или поддържат тесен, но доходоносен пазар, общността на Postgres се ангажира да разработи възможно най-добрите инструменти за ежедневните потребители на релационни бази данни.

PostgreSQL често изпълнява тези задачи, без да добавя твърде много сложност. Дизайнът му е фокусиран стриктно върху боравене с базата данни, без да се налага да се губят ресурси като управление на допълнителни ИТ среди чрез добавени функции. Това е едно от нещата, които потребителите на този софтуер с отворен код харесват, когато мигрират от Oracle към PostgreSQL. Прекарването на часове за изучаване на сложни технологии за това как функционира една база данни на Oracle или как да се оптимизира и настройва, може  да се окаже с нейната скъпа поддръжка. Това примамва институциите или организациите да намерят алтернатива, която може да бъде по-малко главоболие за разходите и да носи печалба и производителност. Моля, вижте предишния ни блог за това колко способен е PostgreSQL да съпоставя присъствието на синтаксиса на SQL със синтаксиса на Oracle.

Причина втора:Без лиценз и голяма общност

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

Когато използвате Oracle, е трудно да вземете решение за конкретен продукт или дали да отидете с поддръжка на продукти, тъй като (обикновено) се включват много пари. Може да опитате конкретен продукт, за да го тествате, в крайна сметка да го купите, само за да разберете, че не може да ви помогне. С PostgreSQL общността е безплатна и пълна с експерти, които имат богат опит, които се радват да ви помогнат с настоящите ви проблеми.

Можете да се абонирате за пощенския списък тук на https://lists.postgresql.org/, за да започнете да се свързвате с общността. Новобранци или чудо на PostgreSQL докосват базирани тук, за да комуникират, демонстрират и споделят своите решения, технологии, грешки, нови открития или дори да споделят своя нов софтуер. Можете дори да поискате помощ от IRC чат, като използвате irc.freenode.net и се присъедините към #postgresql канал. Можете също да се свържете с общността чрез Slack, като се присъедините с https://postgres-slack.herokuapp.com/ или https://postgresteam.slack.com/. Има много възможности за използване и много организации с отворен код, които могат да ви предложат въпроси

За повече подробности и информация откъде да започнете, вижте тук https://www.postgresql.org/community/.

Ако искате да отидете и да закупите професионални услуги в PostgreSQL, има много опции, от които да избирате. Дори като проверите уебсайта им на адрес https://www.postgresql.org/support/professional_support/northamerica/, можете да намерите голям списък с компании там и някои от тях са на ниска цена. Дори тук, в Severalnines, ние предлагаме също поддръжка за Postgres, която е част от лиценза на ClusterControl или DBA Consultancy.

Причина трета:  Широка поддръжка за SQL съответствие

PostgreSQL винаги е искал да се адаптира и да отговаря на SQL като де факто стандарт за своя език. Официалното име на SQL стандарта е ISO/IEC 9075 „Език на база данни SQL“. Всякакви последователни ревизирани версии на стандартните издания заместват предишната, така че твърденията за съответствие с по-ранните версии нямат официална основа.

За разлика от Oracle, някои ключови думи или оператори все още присъстват, които не отговарят на ANSI стандартния SQL (структуриран език за заявки). Например, операторът OUTER JOIN (+) може да припише обърквания с други DBA, които не са докоснали или са най-малко познати на Oracle. PostgreSQL следва стандарта ANSI-SQL за синтаксис на JOIN и това оставя предимство за лесно и просто прескачане с други RDBMS база данни с отворен код, като MySQL/Percona/MariaDB бази данни.

Друг синтаксис, който е много често срещан при Oracle, е използването на йерархични заявки. Oracle използва нестандартния синтаксис START WITH..CONNECT BY, докато в SQL:1999 йерархичните заявки се изпълняват чрез рекурсивни изрази за обща таблица. Например, заявките по-долу се различават своя синтаксис в съответствие с йерархичните заявки:

Oracle

SELECT

    restaurant_name, 

    city_name 

FROM

    restaurants rs 

START WITH rs.city_name = 'TOKYO'

CONNECT BY PRIOR rs.restaurant_name = rs.city_name;

PostgreSQL

WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name

                                 FROM restaurants

                                WHERE city_name = 'TOKYO'

                                UNION

                               SELECT m.restaurant_name, m.city_name

                                 FROM restaurants m

                                 JOIN tmp ON tmp.restaurant_name = m.city_name)

                  SELECT restaurant_name, city_name FROM tmp;

PostgreSQL има много подобен подход като другите най-добри RDBMS с отворен код като MySQL/MariaDB.

Според ръководството на PostgreSQL, разработката на PostgreSQL цели съответствие с последната официална версия на стандарта, където това съответствие не противоречи на традиционните функции или здравия разум. Много от функциите, изисквани от стандарта SQL, се поддържат, макар и понякога с леко различен синтаксис или функция. Това всъщност е страхотното с PostgreSQL, тъй като също се поддържа и сътрудничи от различни организации, независимо дали е малка или голяма. Красавицата остава на съответствието на своя SQL език с това, което има стандартното прокарване.

Разработката на PostgreSQL цели съответствие с последната официална версия на стандарта, където това съответствие не противоречи на традиционните характеристики или здравия разум. Много от функциите, изисквани от стандарта SQL, се поддържат, макар и понякога с леко различен синтаксис или функция. С течение на времето могат да се очакват по-нататъшни движения към съответствие.

Причина четвърта:Паралелизъм на заявките

За да бъда честен, паралелността на заявките на PostgreSQL не е толкова богата в сравнение с паралелното изпълнение на Oracle за SQL изрази. Сред характеристиките на паралелизма на Oracle са опашката на оператори с подсказки, възможността за задаване на степента на паралелизъм (DOP), задаване на политика за паралелност на степените или адаптивен паралелизъм.

PostgreSQL има проста степен на паралелизъм, базирана на поддържаните планове, но това не дефинира, че Oracle надделява над PostgreSQL с отворен код.

Паралелизмът на PostgreSQL непрекъснато се подобрява и непрекъснато се подобрява от общността. Когато PostgreSQL 10 беше пуснат, той добави повече привлекателност за обществеността, особено подобренията в поддръжката на паралелизъм за обединяване при сливане, сканиране на купчина растерни изображения, сканиране на индекс и сканиране само на индекс, сливане на събиране и т.н. Подобренията също добавят статистика към pg_stat_activity.

В PostgreSQL версии <10 паралелизмът е деактивиран по подразбиране, което трябва да зададете променливата max_parallel_workers_per_gather.

postgres=# \timing

Timing is on.

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                   QUERY PLAN                                                   

----------------------------------------------------------------------------------------------------------------

 Seq Scan on movies  (cost=0.00..215677.28 rows=41630 width=68) (actual time=0.013..522.520 rows=84473 loops=1)

   Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

   Rows Removed by Filter: 8241546

 Planning time: 0.039 ms

 Execution time: 525.195 ms

(5 rows)



Time: 525.582 ms

postgres=# \o /dev/null 

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 596.947 ms

Планът на заявката разкрива, че действителното време може да достигне около 522,5 ms, след което реалното време за изпълнение на заявката е около 596,95 ms. Като има предвид, че разрешаването на паралелизъм,

postgres=# set max_parallel_workers_per_gather=2;

Time: 0.247 ms

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                          QUERY PLAN                                                           

-------------------------------------------------------------------------------------------------------------------------------

 Gather  (cost=1000.00..147987.62 rows=41630 width=68) (actual time=0.172..339.258 rows=84473 loops=1)

   Workers Planned: 2

   Workers Launched: 2

   ->  Parallel Seq Scan on movies  (cost=0.00..142824.62 rows=17346 width=68) (actual time=0.029..264.980 rows=28158 loops=3)

         Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

         Rows Removed by Filter: 2747182

 Planning time: 0.096 ms

 Execution time: 342.735 ms

(8 rows)



Time: 343.142 ms

postgres=# \o /dev/null

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 346.020 ms

Планът на заявката определя, че заявката трябва да използва паралелизъм и след това използва възел за събиране. Действителното време е изчислено до 339 мс с 2 работи и оценките до 264 мс, преди да бъде обобщено от плана за заявка. Сега реалното време за изпълнение на заявката отне 346 ms, което е много близо до очакваното действително време от плана на заявката.

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

Причина пета:Разширена поддръжка на JSON и винаги се подобрява

Поддръжката на JSON в PostgreSQL винаги е на ниво в сравнение с другите RDBMS с отворен код. Разгледайте този външен блог от LiveJournal, където поддръжката на JSON на PostgreSQL показва, че винаги е по-напреднала в сравнение с другите RDBMS. PostgreSQL има голям брой JSON функции и функции.

Типът данни JSON беше въведен в PostgreSQL-9.2. Оттогава той има много значителни подобрения и сред основните добавки, които се появиха в PostgreSQL-9.4 с добавянето на тип данни JSONB. PostgreSQL предлага два типа данни за съхранение на JSON данни:json и jsonb. С jsonb това е усъвършенствана версия на JSON тип данни, която съхранява JSON данните в двоичен формат. Това е основното подобрение, което направи голяма разлика в начина, по който JSON данните се търсят и обработват в PostgreSQL.

Oracle също има широка поддръжка на JSON. За разлика от това, PostgreSQL има обширна поддръжка, както и функции, които могат да се използват за извличане на данни, форматиране на данни или условни операции, които засягат изхода на данните или дори данните, съхранявани в базата данни. Данните, съхранявани с тип данни jsonb, имат по-голямо предимство с възможността за използване на GIN (обобщен инвертиран индекс), който може да се използва за ефективно търсене на ключове или двойки ключ/стойност, срещащи се в голям брой jsonb документи.

PostgreSQL има допълнителни разширения, които са полезни за внедряване на TRANSFORM FOR TYPE за типа jsonb към поддържаните от него процедурни езици. Тези разширения са jsonb_plperl и jsonb_plperlu за PL/Perl. Докато за PL/Python това са jsonb_plpythonu, jsonb_plpython2u и jsonb_plpython3u. Например, като използвате jsonb стойности за картографиране на Perl масиви, можете да използвате разширения jsonb_plperl или jsonb_plperlu.

ArangoDB публикува бенчмарк, сравняващ JSON производителността на PostgreSQL заедно с други бази данни с поддръжка на JSON. Въпреки че е стар блог, той все пак показва как се представя JSON на PostgreSQL в сравнение с други бази данни, където JSON е основната му функция в ядрото на базата данни. Това просто кара PostgreSQL да има собствено предимство дори със страничната си функция.

Причина шеста:Поддръжка на DBaaS от основните доставчици на облак

PostgreSQL се поддържа широко като DBaaS. Тези услуги идват от Amazon, Microsoft с неговата Azure Database за PostgreSQL и Cloud SQL на Google за PostgreSQL.

За сравнение Oracle, е наличен само в Amazon RDS за Oracle. Услугите, предлагани от основните играчи, започват на достъпна цена и са много гъвкави за настройка в съответствие с вашите нужди. Това помага на институциите и организациите да се настроят съответно и да се освободят от големите разходи, свързани с платформата Oracle.

Причина седма:  По-добро боравене с огромни количества данни

PostgreSQL RDBMS не са проектирани да обработват аналитични и складови натоварвания на данни. PostgreSQL е база данни, ориентирана към редове, но има способността да съхранява голямо количество данни. PostgreSQL има следните ограничения за работа със съхранение на данни:

Ако искате да използвате основните функции на PostgreSQL, можете да съхранявате голямо количество данни с помощта на jsonb. Например голямо количество документи (PDF, Word, електронни таблици) и съхранявайте това с помощта на тип данни jsonb. За приложения и системи за геолокация можете да използвате PostGIS.

Причина осма:мащабируемост, висока достъпност, резервиране/гео-резервиране и отказоустойчиви решения на евтини

Oracle предлага подобни, но мощни решения като Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware и Oracle Data Guard, за да назовем само няколко. Тези технологии могат да доведат до нарастващите ви разходи и са непредвидимо скъпи за внедряване и стабилизиране. Трудно е да се изоставят тези решения. Обучението и уменията трябва да се подобрят и развият хората, участващи в процеса на внедряване и внедряване.

PostgreSQL има огромна поддръжка и има много опции за избор. PostgreSQL включва стрийминг и логическа репликация, вградени в основния пакет на софтуера. Може също да успеете да настроите синхронна репликация за PostgreSQL, за да имате клъстер с по-висока наличност, като същевременно накарате възел в готовност да обработва вашите заявки за четене. За висока наличност ви предлагаме да прочетете нашия блог Top PG Clustering High Availability (HA) решения за PostgreSQL и който обхваща много страхотни инструменти и технологии, от които да избирате.

Има и корпоративни функции, които предлагат решения за висока наличност, наблюдение и архивиране. ClusterControl е една от тези технологии и предлага на достъпна цена в сравнение с решенията на Oracle.

Причина девет:  Поддръжка на няколко процедурни езика:PL/pgSQL, PL/Tcl, PL/Perl и PL/Python.

От версия 9.4 PostgreSQL има страхотна функция, в която можете да дефинирате нов процедурен език в съответствие с избора си. Въпреки че не се поддържа цялото разнообразие от езици за програмиране, но има редица езици, които се поддържат. Понастоящем с базова дистрибуция включва PL/pgSQL, PL/Tcl, PL/Perl и PL/Python. Външните езици са:

Страхотното в това е, че за разлика от Oracle, разработчиците, които са преминали наскоро към PostgreSQL, могат бързо да предоставят бизнес логика на своите приложни системи, без да отделят допълнително време, за да научат повече за PL/SQL. PostgreSQL прави средата за разработчиците по-лесна и ефективна. Тази природа на PostgreSQL допринася за причината, поради която разработчиците обичат PostgreSQL и започват да се отклоняват от решенията на корпоративната платформа към средата с отворен код.

Причина десета:  Гъвкави индекси за големи и текстови данни (GIN, GiST, SP-GiST и BRIN)

PostgreSQL има огромно предимство, когато става въпрос за поддръжка на индекси, които са полезни за обработката на големи данни. Oracle има много типове индекси, които са полезни и за работа с големи набори от данни, особено за индексиране на пълен текст. Но за PostgreSQL тези типове индекси са направени така, че да бъдат гъвкави според вашата цел. Например, тези типове индекси са приложими за големи данни:

GIN - (обобщени обърнати индекси) 

Този тип индекс е приложим за колони от тип данни jsonb, hstore, диапазон и масиви. Полезно е, когато имате типове данни, които съдържат множество стойности в една колона. Според документите на PostgreSQL „GIN е предназначен за обработка на случаи, при които елементите, които трябва да бъдат индексирани, са съставни стойности, а заявките, които трябва да бъдат обработени от индекса, трябва да търсят стойности на елементи, които се появяват в съставните елементи. Например елементите могат да бъдат документи, а заявките могат да бъдат търсения на документи, съдържащи конкретни думи.“

GiST - (обобщено дърво за търсене)

Дърво за търсене, балансирано по височина, което се състои от страници на възли. Възлите се състоят от индексни редове. Всеки ред на листов възел (листов ред), като цяло, съдържа някакъв предикат (булев израз) и препратка към ред на таблица (TID). GiST индексите са най-добри, ако използвате това за геометричен тип данни, като например, искате да видите дали два полигона съдържат някаква точка. В един случай конкретна точка може да се съдържа в полето, докато друга точка съществува само в рамките на един полигон. Най-често срещаните типове данни, при които искате да използвате индексите на GiST, са геометрични типове и текст, когато работите с пълнотекстово търсене

При избора на кой тип индекс да използвате, GiST или GIN, вземете предвид тези разлики в производителността:

• Проверките на GIN индекс са около три пъти по-бързи от GiST
• Изграждането на GIN индексите отнема около три пъти повече време, отколкото GiST
• GIN индексите се актуализират умерено по-бавно от индексите GiST, но около 10 пъти по-бавно, ако поддръжката за бързо актуализиране е била деактивирана
• GIN индексите са два до три пъти по-големи от индексите GiST

Като практическо правило, GIN индексите са най-добри за статични данни, защото търсенето е по-бързо. За динамични данни индексите на GiST се актуализират по-бързо.

SP-GiST - (GiST, разделен на пространство) 

За по-големи набори от данни с естествено, но неравномерно групиране. Този тип индекс на лоста за разделяне на пространството дървета. Индексите на SP-GiST са най-полезни, когато вашите данни имат естествен елемент за клъстериране и освен това не са еднакво балансирано дърво. Чудесен пример за това са телефонните номера, например в САЩ те използват следния формат:

• 3 цифри за регионалния код
• 3 цифри за префикс (исторически свързани с превключвателя на телефонен оператор)
• 4 цифри за номера на реда

Това означава, че имате естествено групиране около първия набор от 3 цифри, около втория набор от 3 цифри, след което числата може да се разпределят в по-равномерно разпределение. Но с телефонните номера някои регионални кодове имат много по-висока наситеност от други. Резултатът може да бъде, че дървото е много небалансирано. Поради това естествено групиране отпред и неравномерното разпределение на данни – данни като телефонни номера могат да бъдат добър случай за SP-GiST.

BRIN - (Индекс на обхвата на блокове) 

За наистина големи набори от данни, които се подреждат последователно. Блоков диапазон е група от страници, съседни една до друга, където обобщена информация за всички тези страници се съхранява в индекса. Индексите на блоков диапазон могат да се фокусират върху някои подобни случаи на употреба на SP-GiST, тъй като те са най-добри, когато има някаква естествена подредба на данните и данните обикновено са много големи. Имате таблица с милиард записи, особено ако това са данни от времеви серии? BRIN може да е в състояние да помогне. Ако правите заявка към голям набор от данни, които са естествено групирани заедно, като например данни за няколко пощенски кода (които след това се събират до някой град), BRIN помага да се гарантира, че подобни пощенски кодове са разположени един до друг на диска.

Когато имате много големи набори от данни, които са подредени като дати или пощенски кодове, BRIN индексите ви позволяват да пропуснете или изключите много от ненужните данни много бързо. Освен това BRIN се поддържат като по-малки индекси спрямо общия размер на данните, което ги прави голяма печалба, когато имате голям набор от данни.

Заключение

PostgreSQL има някои основни предимства, когато се конкурира с корпоративната платформа и бизнес решенията на Oracle. Определено е лесно да приветствате PostgreSQL като предпочитан избор на RDBMS с отворен код, тъй като е почти мощен като Oracle.

Oracle е труден за победа (и това е трудно да се приеме истината) и също така не е лесно да се отървете от корпоративната платформа на технологичния гигант. Когато системите ви предоставят мощност и продуктивни резултати, това може да бъде дилема.

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

PostgreSQL и неговите основни платформени решения могат да бъдат избор, за да ви помогнат да намалите разходите, да облекчите бюджетните си проблеми; всички с умерени до малки промени.