Dziesięć najważniejszych powodów, dla których warto przejść z Oracle na PostgreSQL

System zarządzania relacyjną bazą danych Oracle (RDBMS) jest szeroko stosowany przez duże organizacje i jest uważany za najbardziej zaawansowaną technologię baz danych dostępną na rynku. Jest to zazwyczaj najczęściej porównywany RDBMS z innymi produktami bazodanowymi służącymi jako standardowe „de-facto” tego, co produkt powinien oferować. Jest oceniany przez db-engines.com jako nr 1 RDBMS dostępny obecnie na rynku.

PostgreSQL jest klasyfikowany jako 4 RDBMS, ale to nie znaczy, że nie ma żadnych korzyści z migracji do PostgreSQL. PostgreSQL istnieje od 1989 roku jako open source w 1996 roku. PostgreSQL wygrał DBMS roku przez dwa kolejne lata, w 2017 i 2018 roku. To tylko wskazuje, że nie ma oznak zaprzestania przyciągania dużej liczby użytkowników i dużych organizacji.

Jednym z powodów, dla których PostgreSQL przyciągnął wiele uwagi, jest to, że ludzie szukają alternatywy dla Oracle, dzięki czemu mogą obniżyć koszty organizacji i uniknąć uzależnienia od dostawcy.

Przejście z działającej i produktywnej bazy danych Oracle może być trudnym zadaniem. Obawy, takie jak TCO (całkowity koszt posiadania) firmy, są jednym z powodów, dla których firmy przeciągają decyzję o rezygnacji z Oracle.

W tym blogu przyjrzymy się niektórym z głównych powodów, dla których firmy decydują się na odejście z Oracle i migrację do PostgreSQL.

Powód pierwszy:to prawdziwy projekt Open Source

PostgreSQL jest oprogramowaniem typu open source i jest udostępniany na licencji PostgreSQL, liberalnej licencji Open Source, podobnej do licencji BSD lub MIT. Zakup produktu i wsparcia nie wiąże się z żadnymi opłatami.

Jeżeli chcesz wykorzystać oprogramowanie bazy danych, oznacza to, że możesz uzyskać wszystkie dostępne funkcje bazy danych PostgreSQL za darmo. PostgreSQL ma ponad 30 lat dojrzałości w świecie baz danych, a od 1996 roku jest oparty na technologii dotykowej jako open-source. Przez dziesięciolecia programiści pracowali nad tworzeniem rozszerzeń. To samo w sobie sprawia, że ​​programiści, instytucje i organizacje wybierają PostgreSQL do aplikacji korporacyjnych; zasilanie wiodących aplikacji biznesowych i mobilnych.

Po raz kolejny organizacje uświadamiają sobie, że rozwiązania bazodanowe typu open source, takie jak Postgres, oferują większą pojemność, elastyczność i wsparcie, które nie są całkowicie zależne od żadnej firmy lub programisty. Postgres, podobnie jak wcześniej Linux, był (i nadal jest) zaprojektowany przez oddanych użytkowników rozwiązujących codzienne problemy biznesowe, którzy decydują się zwrócić swoje rozwiązania społeczności. W przeciwieństwie do dużego programisty, takiego jak Oracle, który może mieć różne motywy tworzenia dochodowych produktów lub obsługi wąskiego, ale lukratywnego rynku, społeczność Postgres jest zaangażowana w opracowywanie najlepszych możliwych narzędzi dla codziennych użytkowników relacyjnych baz danych.

PostgreSQL często wykonuje te zadania bez zbytniego zwiększania złożoności. Jego projekt koncentruje się wyłącznie na obsłudze bazy danych bez konieczności marnowania zasobów, takich jak zarządzanie dodatkowymi środowiskami IT za pomocą dodatkowych funkcji. Jest to jedna z rzeczy, które konsumenci tego oprogramowania o otwartym kodzie źródłowym lubią podczas migracji z Oracle do PostgreSQL. Poświęcenie godzin na studiowanie złożonej technologii na temat działania bazy danych Oracle lub optymalizacji i optymalizacji może skończyć się kosztownym wsparciem. Skłania to instytucje lub organizacje do znalezienia alternatywy, która może być mniej uciążliwa dla kosztów i przynosząca zysk i produktywność. Sprawdź nasz poprzedni blog o tym, jak PostgreSQL może dopasować składnię SQL do składni Oracle.

Powód drugi:brak licencji i duża społeczność

Dla użytkowników platformy Oracle RDBMS trudno jest znaleźć jakikolwiek rodzaj wsparcia społeczności, który jest bezpłatny lub nie wymaga dużych opłat. Instytucje, organizacje i programiści często znajdują w Internecie alternatywne informacje, które mogą bezpłatnie oferować odpowiedzi lub rozwiązania ich problemów.

Podczas korzystania z Oracle trudno jest zdecydować, który produkt lub czy skorzystać z pomocy technicznej, ponieważ (zazwyczaj) wiąże się to z dużymi nakładami finansowymi. Możesz wypróbować konkretny produkt, aby go przetestować, w końcu go kupić, tylko po to, by zdać sobie sprawę, że nie może ci pomóc. Dzięki PostgreSQL społeczność jest bezpłatna i pełna ekspertów, którzy mają duże doświadczenie, którzy chętnie pomogą Ci rozwiązać bieżące problemy.

Możesz zapisać się na listę mailingową tutaj na https://lists.postgresql.org/, aby zacząć kontaktować się ze społecznością. Nowicjusze lub cudowne osoby korzystające z dotyku PostgreSQL, które mają tutaj siedzibę, aby komunikować się, prezentować i dzielić się swoimi rozwiązaniami, technologią, błędami, nowymi odkryciami, a nawet udostępniać swoje nowe oprogramowanie. Możesz nawet poprosić o pomoc czat IRC używając irc.freenode.net i dołączając do kanału #postgresql. Możesz również skontaktować się ze społecznością przez Slack, dołączając do https://postgres-slack.herokuapp.com/ lub https://postgresteam.slack.com/. Jest wiele opcji do podjęcia i wiele organizacji Open Source, które mogą zaoferować Ci pytania

Więcej szczegółów i informacji o tym, od czego zacząć, znajdziesz tutaj https://www.postgresql.org/community/.

Jeśli chcesz skorzystać z usług profesjonalnych w PostgreSQL, masz do wyboru mnóstwo opcji. Nawet sprawdzając ich stronę internetową https://www.postgresql.org/support/professional_support/northamerica/, można tam znaleźć dużą listę firm, a niektóre z nich są w niskiej cenie. Nawet tutaj, w Manynines, oferujemy również wsparcie dla Postgres, które jest częścią licencji ClusterControl lub doradztwa DBA.

Powód trzeci:  Szerokie wsparcie dla zgodności z SQL

PostgreSQL zawsze był chętny do adaptacji i dostosowania się do SQL jako de facto standardu dla swojego języka. Formalna nazwa standardu SQL to ISO/IEC 9075 „Język bazy danych SQL”. Wszelkie kolejne poprawione wersje wydań standardowych zastępują poprzednie, więc deklaracje zgodności z wcześniejszymi wersjami nie mają oficjalnej wartości.

W przeciwieństwie do Oracle, niektóre słowa kluczowe lub operatory są nadal obecne, które nie są zgodne ze standardem ANSI SQL (Structured Query Language). Na przykład, operator OUTER JOIN (+) może przypisywać pomyłki z innymi administratorami baz danych, którzy nie dotknęli lub najmniej znają Oracle. PostgreSQL jest zgodny ze standardem ANSI-SQL dla składni JOIN, co daje przewagę łatwego i prostego przeskakiwania z innymi bazami danych RDBMS typu open source, takimi jak bazy danych MySQL/Percona/MariaDB.

Kolejną składnią, która jest bardzo powszechna w Oracle, jest używanie zapytań hierarchicznych. Oracle używa niestandardowej składni START WITH..CONNECT BY, podczas gdy w SQL:1999 zapytania hierarchiczne są implementowane za pomocą rekurencyjnych wyrażeń tabelarycznych. Na przykład poniższe zapytania różnią się składnią zgodnie z zapytaniami hierarchicznymi:

Wyrocznia

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 ma bardzo podobne podejście do innych najlepszych RDBMS typu open source, takich jak MySQL/MariaDB.

Według podręcznika PostgreSQL, rozwój PostgreSQL ma na celu zapewnienie zgodności z najnowszą oficjalną wersją standardu, gdzie taka zgodność nie jest sprzeczna z tradycyjnymi funkcjami lub zdrowym rozsądkiem. Wiele funkcji wymaganych przez standard SQL jest obsługiwanych, choć czasami z nieco inną składnią lub funkcją. W rzeczywistości jest to wspaniałe w PostgreSQL, ponieważ jest on również wspierany i współpracujący z różnymi organizacjami, zarówno małymi, jak i dużymi. Piękno pozostaje w zgodności języka SQL z tym, co przeforsowuje standard.

Rozwój PostgreSQL ma na celu zapewnienie zgodności z najnowszą oficjalną wersją standardu, gdzie taka zgodność nie jest sprzeczna z tradycyjnymi funkcjami ani zdrowym rozsądkiem. Wiele funkcji wymaganych przez standard SQL jest obsługiwanych, choć czasami z nieco inną składnią lub funkcją. Z czasem można spodziewać się dalszych kroków w kierunku zgodności.

Powód czwarty:równoległość zapytań

Szczerze mówiąc, równoległość zapytań PostgreSQL nie jest tak bogata w porównaniu z równoległym wykonywaniem instrukcji SQL w Oracle. Wśród cech, które paralelizm Oracle jest kolejkowanie instrukcji z podpowiedziami, możliwość ustawienia stopnia paralelizmu (DOP), ustawienie polityki stopni równoległych lub paralelizm adaptacyjny.

PostgreSQL charakteryzuje się prostym stopniem równoległości w oparciu o obsługiwane plany, ale to nie oznacza, że ​​Oracle wyprzedza PostgreSQL o otwartym kodzie źródłowym.

Równoległość PostgreSQL jest stale ulepszana i stale ulepszana przez społeczność. Kiedy PostgreSQL 10 został wydany, dodał więcej atrakcyjności opinii publicznej, zwłaszcza ulepszenia w obsłudze równoległości dla łączenia przez scalanie, skanowania sterty bitmapowej, skanowania indeksu i skanowania tylko indeksu, łączenia zbierania itp. Ulepszenia dodają również statystyki do pg_stat_activity.

W wersjach PostgreSQL <10, paralelizm jest domyślnie wyłączony, co należy ustawić w zmiennej 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

Plan zapytań pokazuje, że rzeczywisty czas może wynieść około 522,5 ms, a rzeczywisty czas wykonania zapytania wynosi około 596,95 ms. Natomiast włączenie równoległości,

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

Plan zapytania określa, że ​​zapytanie musi używać równoległości, a następnie używa węzła Gather. Rzeczywiste szacunki czasu wynoszą 339 ms z 2 pracami, a szacunki wynoszą 264 ms, zanim zostaną zagregowane przez plan zapytań. Teraz rzeczywisty czas wykonania zapytania wyniósł 346 ms, co jest bardzo zbliżone do szacowanego rzeczywistego czasu z planu zapytania.

To tylko ilustruje, jak szybki i korzystny jest PostgreSQL. Chociaż PostgreSQL ma swoje własne ograniczenia, gdy może wystąpić paralelizm lub gdy plan zapytań określa, że ​​jest szybszy niż użycie paralelizmu, nie robi to dużej różnicy niż Oracle. Równoległość PostgreSQL jest elastyczna i może być włączona lub używana poprawnie, o ile twoje zapytanie pasuje do sekwencji wymaganej dla równoległości zapytań.

Powód piąty:zaawansowana obsługa JSON i zawsze się poprawia

Obsługa JSON w PostgreSQL jest zawsze na równi z innymi RDBMS o otwartym kodzie źródłowym. Rzuć okiem na ten zewnętrzny blog z LiveJournal, gdzie obsługa JSON PostgreSQL okazuje się być zawsze bardziej zaawansowana w porównaniu z innymi RDBMS. PostgreSQL ma wiele funkcji i funkcji JSON.

Typ danych JSON został wprowadzony w PostgreSQL-9.2. Od tego czasu ma wiele znaczących ulepszeń, a jednym z głównych dodatków, które pojawiły się w PostgreSQL-9.4, jest dodanie typu danych JSONB. PostgreSQL oferuje dwa typy danych do przechowywania danych JSON:json i jsonb. Z jsonb jest to zaawansowana wersja typu danych JSON, która przechowuje dane JSON w formacie binarnym. Jest to główne ulepszenie, które znacznie zmieniło sposób wyszukiwania i przetwarzania danych JSON w PostgreSQL.

Oracle ma również szerokie wsparcie dla JSON. W przeciwieństwie do tego, PostgreSQL ma szerokie wsparcie, a także funkcje, które można wykorzystać do pobierania danych, formatowania danych lub operacji warunkowych, które wpływają na wyjście danych, a nawet dane przechowywane w bazie danych. Dane przechowywane w typie danych jsonb mają większą przewagę dzięki możliwości korzystania z GIN (Generalized Inverted Index), które można wykorzystać do wydajnego wyszukiwania kluczy lub par klucz/wartość występujących w dużej liczbie dokumentów jsonb.

PostgreSQL ma dodatkowe rozszerzenia, które są pomocne przy implementacji TRANSFORM FOR TYPE dla typu jsonb do obsługiwanych języków procedur. Te rozszerzenia to jsonb_plperl i jsonb_plperlu dla PL/Perl. Natomiast w przypadku PL/Pythona są to jsonb_plpythonu, jsonb_plpython2u i jsonb_plpython3u. Na przykład, używając wartości jsonb do mapowania tablic Perla, możesz użyć rozszerzeń jsonb_plperl lub jsonb_plperlu.

ArangoDB opublikował test porównawczy porównujący wydajność JSON PostgreSQL z innymi bazami danych obsługującymi JSON. Chociaż jest to stary blog, nadal pokazuje, jak działa JSON PostgreSQL w porównaniu z innymi bazami danych, w których JSON jest podstawową funkcją w jądrze bazy danych. To po prostu sprawia, że ​​PostgreSQL ma swoją przewagę, nawet ze swoją funkcją poboczną.

Powód szósty:Obsługa DBaaS przez głównych dostawców chmury

PostgreSQL jest szeroko obsługiwany jako DBaaS. Usługi te pochodzą od Amazona, Microsoftu z jego bazą danych Azure dla PostgreSQL oraz Google Cloud SQL dla PostgreSQL.

Dla porównania Oracle jest dostępny tylko w Amazon RDS for Oracle. Usługi oferowane przez głównych graczy zaczynają się w przystępnej cenie i są bardzo elastyczne w konfiguracji zgodnie z Twoimi potrzebami. Pomaga to instytucjom i organizacjom w odpowiedniej konfiguracji i zmniejszeniu dużych kosztów związanych z platformą Oracle.

Powód siódmy: lepsza obsługa ogromnych ilości danych

RDBMS PostgreSQL nie są przeznaczone do obsługi obciążeń analitycznych i hurtowni danych. PostgreSQL jest bazą danych zorientowaną na wiersze, ale ma możliwość przechowywania dużej ilości danych. PostgreSQL ma następujące ograniczenia dotyczące przechowywania danych:

Jeśli chcesz korzystać z podstawowych funkcji PostgreSQL, możesz przechowywać duże ilości danych za pomocą jsonb. Na przykład duża ilość dokumentów (PDF, Word, Arkusze kalkulacyjne) i przechowuj je przy użyciu typu danych jsonb. W przypadku aplikacji i systemów geolokalizacyjnych możesz użyć PostGIS.

Powód ósmy:skalowalność, wysoka dostępność, nadmiarowość/geo-nadmiarowość i tanie rozwiązania odporne na błędy

Oracle oferuje podobne, ale potężne rozwiązania, takie jak Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware i Oracle Data Guard, aby wymienić tylko kilka. Technologie te mogą zwiększać koszty, a ich wdrożenie i ustabilizowanie jest nieprzewidywalnie kosztowne. Trudno z tymi rozwiązaniami zrezygnować. Szkolenie i umiejętności należy doskonalić i rozwijać osoby zaangażowane w proces wdrażania i wdrażania.

PostgreSQL ma ogromne wsparcie i ma wiele opcji do wyboru. PostgreSQL obejmuje przesyłanie strumieniowe i replikację logiczną wbudowaną w podstawowy pakiet oprogramowania. Możesz także skonfigurować synchroniczną replikację dla PostgreSQL, aby mieć więcej klastra o wysokiej dostępności, podczas gdy węzeł gotowości przetwarza zapytania odczytu. Aby uzyskać wysoką dostępność, zalecamy przeczytanie naszego bloga Top PG Clustering High Availability (HA) Solutions dla PostgreSQL, który obejmuje wiele wspaniałych narzędzi i technologii do wyboru.

Istnieją również funkcje korporacyjne, które oferują rozwiązania wysokiej dostępności, monitorowania i tworzenia kopii zapasowych. ClusterControl jest jedną z tych technologii i oferuje przystępną cenę w porównaniu z rozwiązaniami Oracle.

Powód dziewiąty:  Obsługa kilku języków proceduralnych:PL/pgSQL, PL/Tcl, PL/Perl i PL/Python.

Od wersji 9.4 PostgreSQL ma świetną funkcję, dzięki której możesz zdefiniować nowy język proceduralny zgodnie z własnym wyborem. Chociaż nie wszystkie różne języki programowania są obsługiwane, ale ma wiele obsługiwanych języków. Obecnie, z podstawową dystrybucją, obejmuje PL/pgSQL, PL/Tcl, PL/Perl i PL/Python. Języki zewnętrzne to:

Wspaniałe w tym jest to, że w przeciwieństwie do Oracle, programiści, którzy niedawno przeszli do PostgreSQL, mogą szybko dostarczać logikę biznesową do swoich systemów aplikacji bez poświęcania czasu na poznawanie PL/SQL. PostgreSQL sprawia, że ​​środowisko dla programistów jest łatwiejsze i wydajniejsze. Ten charakter PostgreSQL przyczynia się do tego, że programiści kochają PostgreSQL i zaczynają odchodzić od rozwiązań platform korporacyjnych do środowiska open source.

Powód dziesiąty:  Elastyczne indeksy dla dużych i danych tekstowych (GIN, GiST, SP-GiST i BRIN)

PostgreSQL ma ogromną przewagę, jeśli chodzi o obsługę indeksów, które są korzystne przy obsłudze dużych ilości danych. Oracle ma wiele typów indeksów, które są korzystne również w przypadku obsługi dużych zestawów danych, zwłaszcza w przypadku indeksowania pełnotekstowego. Ale w przypadku PostgreSQL tego typu indeksy są dostosowane do Twoich potrzeb. Na przykład te typy indeksów mają zastosowanie do dużych danych:

WZ — (uogólnione indeksy odwrócone) 

Ten typ indeksu ma zastosowanie do kolumn typu danych jsonb, hstore, range i arrays. Jest to przydatne, gdy masz typy danych, które zawierają wiele wartości w jednej kolumnie. Zgodnie z dokumentacją PostgreSQL „GIN jest przeznaczony do obsługi przypadków, w których indeksowane elementy są wartościami złożonymi, a zapytania, które mają być obsługiwane przez indeks, muszą szukać wartości elementów, które pojawiają się w elementach złożonych. Na przykład pozycjami mogą być dokumenty, a zapytania mogą być wyszukiwaniami dokumentów zawierających określone słowa”.

GiST — (uogólnione drzewo wyszukiwania)

Zrównoważone pod względem wysokości drzewo wyszukiwania składające się ze stron węzłów. Węzły składają się z wierszy indeksu. Ogólnie rzecz biorąc, każdy wiersz węzła liścia (wiersz liścia) zawiera predykat (wyrażenie logiczne) i odwołanie do wiersza tabeli (TID). Indeksy GiST są najlepsze, jeśli używasz tego do geometrycznych typów danych, takich jak chcesz sprawdzić, czy dwa wielokąty zawierają jakiś punkt. W jednym przypadku określony punkt może znajdować się w ramce, podczas gdy inny punkt istnieje tylko w jednym wielokącie. Najczęstsze typy danych, w których chcesz wykorzystać indeksy GiST, to typy geometrii i tekst podczas wyszukiwania pełnotekstowego

Wybierając typ indeksu, GiST lub GIN, należy wziąć pod uwagę następujące różnice w wydajności:

• Wyszukiwanie indeksu GIN jest około trzy razy szybsze niż GiST
• Indeksy GIN są budowane około trzy razy dłużej niż GiST
• Indeksy GIN są aktualizowane umiarkowanie wolniej niż indeksy GiST, ale około 10 razy wolniej, jeśli obsługa szybkich aktualizacji była wyłączona
• Indeksy GIN są dwa do trzech razy większe niż indeksy GiST

Z reguły indeksy GIN są najlepsze dla danych statycznych, ponieważ wyszukiwania są szybsze. W przypadku danych dynamicznych indeksy GiST są szybciej aktualizowane.

SP-GiST — (GiST z partycjami przestrzeni) 

Dla większych zestawów danych z naturalnym, ale nierównym grupowaniem. Ten typ indeksu wykorzystuje drzewa partycjonujące przestrzeń. Indeksy SP-GiST są najbardziej przydatne, gdy dane mają naturalny element klastrowania, a także nie są równo zrównoważonym drzewem. Świetnym tego przykładem są numery telefonów, na przykład w USA mają następujący format:

• 3 cyfry dla numeru kierunkowego
• 3 cyfry dla prefiksu (historycznie powiązane z przełącznikiem operatora)
• 4 cyfry numeru linii

Oznacza to, że masz pewne naturalne grupowanie wokół pierwszego zestawu 3 cyfr, wokół drugiego zestawu 3 cyfr, a następnie liczby mogą rozłożyć się w bardziej równomierny rozkład. Ale w przypadku numerów telefonów niektóre numery kierunkowe mają znacznie wyższe nasycenie niż inne. Rezultatem może być to, że drzewo jest bardzo niezrównoważone. Z powodu tego naturalnego klastrowania z góry i nierównej dystrybucji danych – dane, takie jak numery telefonów, mogą być dobrym argumentem dla SP-GiST.

BRIN — (Indeks zakresu bloków) 

Dla naprawdę dużych zestawów danych, które ustawiają się sekwencyjnie. Zakres bloków to grupa sąsiadujących ze sobą stron, w której w indeksie przechowywane są informacje podsumowujące o wszystkich tych stronach. Indeksy zakresów bloków mogą koncentrować się na niektórych przypadkach użycia podobnych do SP-GiST, ponieważ są najlepsze, gdy dane są uporządkowane w naturalny sposób, a dane są zwykle bardzo duże. Masz tabelę miliardów rekordów, zwłaszcza jeśli są to dane szeregów czasowych? BRIN może pomóc. Jeśli wysyłasz zapytania do dużego zestawu danych, które są naturalnie zgrupowane razem, takie jak dane dla kilku kodów pocztowych (które następnie są akumulowane w niektórych miastach), BRIN pomaga zapewnić, że podobne kody pocztowe znajdują się blisko siebie na dysku.

Gdy masz bardzo duże zbiory danych, które są uporządkowane, takie jak daty lub kody pocztowe, indeksy BRIN pozwalają bardzo szybko pominąć lub wykluczyć wiele niepotrzebnych danych. BRIN dodatkowo są utrzymywane jako mniejsze indeksy w stosunku do całkowitego rozmiaru danych, co czyni je wielką wygraną, gdy masz duży zestaw danych.

Wnioski

PostgreSQL ma kilka głównych zalet, gdy konkuruje z platformą korporacyjną i rozwiązaniami biznesowymi Oracle. Zdecydowanie łatwo jest okrzyknąć PostgreSQL jako swój wybór wśród RDBMS o otwartym kodzie źródłowym, ponieważ jest prawie potężny jak Oracle.

Oracle jest trudny do pokonania (i jest to trudna do zaakceptowania prawda), a także nie jest łatwo porzucić platformę korporacyjną giganta technologicznego. Gdy systemy zapewniają moc i wydajne wyniki, może to stanowić dylemat.

Czasami jednak zdarzają się sytuacje, w których należy podjąć decyzję, ponieważ ciągłe nadmierne inwestowanie w koszt platformy może przewyższać koszty innych warstw biznesowych i priorytetów, które mogą wpływać na postęp.

PostgreSQL i jego podstawowe rozwiązania platformowe mogą być wyborem, który pomoże Ci obniżyć koszty, złagodzić problemy budżetowe; wszystkie z umiarkowanymi lub małymi zmianami.