PostgreSQL, четвъртата най-популярна база данни и СУБД на годината през 2017 г., избухна в популярност сред общностите за разработка и бази данни по целия свят. Открадвайки пазарен дял от лидерите Oracle, MySQL и Microsoft SQL Server, PostgreSQL хостингът също е силно използван от нови бизнеси във вълнуващи пространства като интернет на нещата, електронна търговия, SaaS, анализи и други.
И така, какво е набиращо популярност в управлението на PostgreSQL?
Миналия месец присъствахме на PostgresOpen в Сан Франциско, за да разкрием най-новите тенденции от самите експерти.
Най-отнемащи време задачи за управление на PostgreSQL
И така, какво отнема времето ви в управлението на PostgreSQL? Въпреки че има хиляди задачи, свързани с управлението на вашите производствени внедрявания на PostgreSQL, управлението на заявки беше силен лидер с над 30% от респондентите.
Управлението на пространството беше далечна секунда, като 15% от потребителите на PostgreSQL го намираха за най-трудната си задача, последвано от репликация, надстройки и наблюдение. 23% от потребителите на PostgreSQL попадат в категорията „Всички останали“, състояща се от задачи като корекция, възстановяване, разделяне и миграции.
Управление на разбивка на PostgreSQL заявки
С далечната преднина в управлението на заявки на PostgreSQL, ние се потопихме по-дълбоко, за да видим какви конкретни задачи отнемат времето им. Резултатите се разпространяват в целия процес на управление на заявки, от структуриране при настройка до оптимизиране след анализ.
За да обясним това допълнително, нека започнем от началото на процеса на управление на заявките:
Структура на заявката
Най-малкият сегмент, управляващ структурите на заявки, представлява 22% от отговорите от потребителите на PostgreSQL, които са избрали заявките като най-отнемаща време задача за управление.
Преди да започнете, трябва да създадете PostgreSQL план за заявки около вашите клъстери, за да съпоставите структурата на заявката със свойствата на вашите данни. Те се състоят от възли, вариращи от възли за сканиране на най-долното ниво за връщане на необработена таблица с редове, заедно с редове извън таблицата, като стойности.
Бавен анализ на заявката
След като сте установили структурата си, следващата стъпка е да анализирате вашите заявки, за да идентифицирате бавно изпълняващи се заявки, които могат да повлияят на производителността на приложението ви. По подразбиране „бавните заявки“ се дефинират като заявки, които отнемат повече от 100 мс.
Оптимизиране на заявки
Сега, след като идентифицирахте бавните си заявки, започва истинската работа – оптимизирането на вашите PostgreSQL заявки. Настройката на производителността на Postgres може да бъде ужасна задача, но с подходяща идентификация и анализ можете да усъвършенствате тесните места и да направите необходимите промени в заявката и да добавите индекси, където е необходимо, за да подобрите изпълнението си. Ето страхотна статия за заявките за настройка на производителността в PostgreSQL.
Последните тенденции в PostgreSQL:Най-отнемащи време задачи и важни показатели за проследяване с кликване до Tweet
Най-важните показатели за проследяване за ефективност на PostgreSQL
Сега, когато идентифицирахме най-отнемащата време задача за управление на PostgreSQL, нека разгледаме по-задълбочено важните показатели, които потребителите на PostgreSQL проследяват, за да оптимизират своята производителност.
Най-важните резултати от показателите на PostgreSQL бяха значително по-равномерни от задачите за управление, което доведе до четирипосочна връзка между статистиките за репликация, използване на CPU и RAM, транзакции в секунда (TPS) и бавни заявки:
Статистика за репликация
Наблюдението на състоянието на репликация на PostgreSQL е решаваща задача, за да гарантирате, че вашите репликации се изпълняват правилно и вашите производствени разгръщания остават високо достъпни. Процесът на репликация трябва да бъде персонализиран така, че да отговаря най-добре на нуждите на вашето приложение, а непрекъснатото наблюдение на крайната точка е най-добрият начин да гарантирате, че данните ви са защитени и готови за възстановяване.
Важно е да проследявате показатели както на вашите резервни сървъри, така и на основните сървъри. Вашите резервни сървъри трябва да бъдат наблюдавани за входящо репликация и състояние на възстановяване, а основните ви сървъри трябва да бъдат наблюдавани за изходящи слотове за репликация и репликация. Ако използвате поточно репликация на PostgreSQL, слотовете за репликация не винаги са необходими. Поточно репликацията осигурява незабавна наличност на данни на вашите сървъри в режим на готовност и е идеална за сървъри с нисък TPS.
Използване на процесора и RAM
Проследяването на използването на вашия процесор и RAM (памет) са важни показатели за наблюдение, за да се гарантира здравето на вашите PostgreSQL сървъри. Ако използването на процесора ви е твърде високо, вашето приложение ще има забавяне, което ще доведе до страдание на потребителите ви. Често е резултат от лошо оптимизирани заявки или дори високи паралелизми на заявки. Наблюдението на RAM е много важно, за да се гарантира, че имате достатъчно дисково пространство и да разберете за какво точно се използва вашата RAM. Препоръчително е да имате приблизително 25% от паметта си, разпределена за shared_buffers. PostgreSQL също така задава по подразбиране размера на буфера на работната памет на 4MB, което често е твърде малко и води до много време за изпълнение.
Транзакции в секунда
Наблюдението на броя на транзакциите в секунда ви позволява да определите натоварването на системата и текущата пропускателна способност. Чрез анализиране на този показател човек може да реши да мащабира съответно системата, за да постигне желаната пропускателна способност. Можете също да определите как промяната в конфигурационните настройки или системните ресурси се отразява на пропускателната способност.
Бавни заявки
Неефективните заявки могат да забавят производителността на PostgreSQL, дори ако системата е конфигурирана с адекватни ресурси. Винаги е добра практика да анализирате тези неефективни заявки и да ги коригирате. PostgreSQL предоставя параметър, наречен log_min_duration_statement . Когато това е зададено, това води до записване на продължителността на всеки завършен оператор, ако операторът се изпълнява поне за определения брой милисекунди. След като се получат бавните заявки, можете да стартирате EXPLAIN ANALYZE, за да разберете плана за изпълнение. Това ще ви позволи да проследите проблема и съответно да оптимизирате заявката. Следователно, редовното наблюдение на бавните заявки ще избегне забавянето на производителността.
Намерете ни следващата седмица на събитието PostgresConf Silicon Valley 2018, където се надяваме да разкрием повече прозрения за това, което е актуално в пространството за управление на PostgreSQL. Ако имате въпроси или коментари, не се колебайте да ги споделите с нас тук в нашите коментари или в Twitter на @scalegridio.
