Някои интересни разлики от PostgreSQL MySQL, програмист бележки

MySQL без причина е много популярен в света на релационни бази данни. Това е добре, подходящ RDBMS с отворен код. Но не и единствен по рода си. PostgreSQL е не по-лошо от MySQL, и в много отношения - още по-добре. Нека се опитаме да разберем какво е то.

В PostgreSQL, можете да използвате курсори. Представете си, че някои от заявката покажат гигабайта данни. Трябва да се премине целия концерт в мрежата (ако базата данни се изпълнява на отделен сървър) и да го съхранява в паметта, преди нещо общо с него. Дори ако използвате драйвера поддържа функции като fetch_next_row, всъщност, той все още е първи поставя цялата резултатите от търсенето в паметта. С помощта на курсора, можете не само да вземете парчета от данни, като по този начин им лечение в постоянно количество памет, но и свободно да ги преместите в различни посоки. Например, можете да прочетете първите 100 линии, след това погледнете 10,001th, и в зависимост от стойността си отидете на последния ред или дори закриване на курсора.

Не по-малко интересен е механизмът на функционалните показатели. Да предположим, че трябва да се съхранява на името на потребителя в отделни колони и чувствителен, но търсенето на потребителите в същото време има пълното име и безчувствени. Ако базата данни не поддържа функционалните кодове, трябва да се създаде допълнително поле в таблицата с по-ниска стойност # 40; first_name || '' || last_name # 41. изгради върху него и да запази индексът в тази област е правилната стойност. Ако тези искания варианти на десет, ще трябва десет допълнителни колони. Функционални показатели, както подсказва името, дава възможност за изграждане на индекс на произволна функция, като по този начин се избягват всички проблеми, описани по-горе. Например, може ефективно да изпълнява заявки с условия, като например КЪДЕ грях # 40; х # 41;> 0.45 И грях # 40; х # 41; <0.46 .

PostgreSQL кодове могат да изградят само част от редовете в таблицата. Този механизъм се нарича частичен индекс. Например, ако отидете в базата данни с въпроси, като например SELECT * FROM трупи КЪДЕ IP> Инет "192.168.0.0" и НС

PostgreSQL поддържа растерни сканиране. Например, вие трябва да пуснете запитване с условието, където А = 1 и В = 2. В MySQL, можете да създадете индекс на няколко колони. ефективно да изпълни това искане и искания КЪДЕ а = 1. Когато> 1. Но къде б = 2, или когато б> 10 и б <20. Для эффективного выполнения двух последних запросов понадобится дополнительный индекс по полю b. PostgreSQL также поддерживает индексы по нескольким столбцам. Однако, благодаря поддержке bitmap scans, в PostgreSQL вы можете построить отдельный индекс по a, отдельный индекс по b и использовать эти индексы во всех приведенных запросах, даже с участием в условии обоих полей. Помимо одновременного использования нескольких индексов bitmap scans позволяет эффективно выполнять запросы с условиями вроде WHERE a = 4 OR a = 8 OR a = 15 OR a = 16. Работает это очень просто. Запрос разбивается на несколько подзапросов, каждый из которых выполняется с использованием подходящих индексов, а потом результаты выполнения этих запросов объединяются OR’ом или AND’ом.

PostgreSQL предоставя различни видове показатели в допълнение към класическия Hash и B-Tree индексите. Например, използвайки GIST и SP-GIST индекси могат да намерят всички точки, разположени в рамките на предварително определен диапазон. Основно съдържание индекси също така позволяват, например, попълване подреди по разстояние до вашето настоящо местонахождение, както и да правят други операции с геоданни. ДЖИН индекси са проектирани да работят с видове, които могат да съдържат повече от една стойност. Например, с помощта на индекса на този вид можете да намерите всички масиви, които съдържат определен елемент. Като джин и ГИСТ индекси може да се използва за търсене на пълен текст. Докато пълно текстово търсене на PostgreSQL се работи много по-лошо от Сфинкса, какво да кажем за MySQL не може да се каже. Друг от най-интересните видове индекси трябва да се отбележи индекс Брин (не много бърз код, но супер компактен) и Блум (Bloom филтър).

От другите, но не по-малко важно, MySQL разлики от PostgreSQL бих искал да потвърдя подкрепата на последния регулярен израз. savepoint'ov (това е почти че вложени транзакции), рекурсивни запитвания. маса наследство. способността да пишат съхранени процедури и тригери на Tcl, Perl и Python, както и при влизане бавни заявки с времето, в рамките на милисекунди. Разбира се, разликите не свършват дотук.

Невъзможно е да не се обърне внимание на няколко неща, които не са свързани с функционалната PostgreSQL и MySQL. Както PostgreSQL предимства пред други RDBMS често маркиран надеждност код. Един ден слушах доклад Константина Osipova. което, наред с други неща, той спомена един интересен експеримент. случайните неправилни SQL-заявки в стила на КЪДЕТО * FROM SELECT е написана. Повечето хора никога няма да мисля за написването на тази. Тези заявки са хранени MySQL. В резултат на това е установено, дузина искания, отпадат базата данни. Въпросът е, ако MySQL толкова зле написана заявка за синтактичен анализ. какво се случва в останалата част от базата данни? Аз със сигурност няма да й вярвам да пазят информация за банковата си сметка.

Разбира се, PostgreSQL има свои нюанси. Например, ако имате една маса (номер, вход, мине). можете да го ALERT'nut и да получите (номер, вход, мине, електронна поща). но не и (номер, вход, електронна поща, мине). Това означава, че можете да добавите само колони до края. Разбира се, ако не се създаде напълно нова таблица. Все пак, това обикновено не е голям проблем. Също така в PostgreSQL не мога да пиша при заявка като вмъкнете в blablabla на повтарящо KEY UPDATE blablabla (допълнение: в PostgreSQL 9.5 е фиксирана). Тя ще изглежда, в една сделка, можете да напишете ИЗТРИЙ и след това поставете, но тя не работи. Правилното решение е да се напише по обединяване-функция. Кодекс за сливане-функция е лесно да се генерира автоматично. така че това също не е голям проблем.

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

Подобно на този пост? Споделете с другите: