Обединяване на връзки за приложение за Android, което се свързва с Postgresql DB

Как да направите групиране на връзки

Всяка платформа има различен интерфейс за групиране на връзки. Ще трябва да прочетете документацията за конкретната платформа, която използвате (Ruby+Rails или друга) или да използвате общ междинен слой за обединяване като PgBouncer.

Отговорите, свързани с един инструмент (да речем PHP със Zend Framework), няма да имат нищо общо с отговорите, свързани с друг инструмент (като Ruby on Rails). Дори ако изберете нещо като PgBouncer, все още има подробности, свързани с това как платформата обработва живота на транзакциите, режим на обединяване, който да избирате въз основа на нуждите на приложението и т.н.

Така че първо трябва да определите какво използвате и какво трябва да правите с него. Тогава проучете как да настроите групирането на връзките си. (С много инструменти е само автоматично).

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

Обединяване и междинен софтуер

Не свързвайте приложението си директно с PostgreSQL. Особено ако е по интернет от произволни клиенти.

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

Това не е просто случай на получена мъдрост - има основателни причини да го направите и сериозни проблеми с изпълнението на PostgreSQL от произволни устройства през Интернет.

Приложението за Android говори директно с Pg

Проблемите с говоренето с Pg направо по интернет от много клиенти включват:

• Всеки бекенд на PostgreSQL има цена, независимо дали е неактивен или не. PgBouncer в режим на групиране на транзакции помага с това до известна степен.

• Връзките се губят произволно, когато работите през интернет. Падане на Wi-Fi, промени на IP адреса при динамични IP услуги, мобилна услуга, която избледнява или достига до максимален капацитет или просто се залита заедно с висока загуба на пакети там. Това ви оставя с много PostgreSQL връзки в неопределени състояния, вероятно с отворени транзакции, което ви дава <IDLE> in transaction проблеми и необходимостта да се разрешат много повече връзки, отколкото наистина вършат работа.

• Това е транзакция - ако нещо не завърши, можете да прекратите транзакцията и да знаете, че няма да има ефект.

Предимства от наличието на междинен слой

Сървър, който отговаря на заявки за HTTP уеб услуга от вашето приложение на устройства с Android, за да действа като посредник за достъп до база данни, може да бъде голямо предимство.

• Можете да дефинирате API с версии, така че когато въвеждате нови функции или трябва да промените API, не е нужно да прекъсвате старите клиенти. Това е възможно с Pg, използващ запомнени процедури или много изгледи, но може да стане тромаво.

• Вие стриктно контролирате обхвата на достъпа до базата данни и живота на транзакциите.

• Можете да дефинирате идемпотентен API, където изпълнението на една и съща заявка многократно има само един ефект. (Силно препоръчвам да направите това поради следващата точка).

• Всичко е без състояние и може да има кратки изчаквания. Ако нещо не работи, просто опитайте отново.

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

• Можете да поставите работа на опашка, вместо да се опитвате да правите тонове едновременно и да разбивате сървъра. (Можете също да направите това с PgBouncer в режим на групиране на транзакции).

... и повторете редакцията си, за да промените значението на въпроса:

Ефективност

Вашето „Също“ повторно представяне е наистина съвсем различен въпрос (и за предпочитане трябва да бъде публикуван като такъв). Много кратката версия:напълно невъзможно да се предвиди без много повече информация за работното натоварване, като брой заявки за db на заявка за клиентско приложение, вид данни, вид заявки, размер на данните, честота на заявките, практичност на кеширане, .. .... безкрайно. Всеки, който твърди, че дава категоричен отговор на този въпрос, е или първият истински екстрасенс в историята, или е напълно пълен с това.

Трябва да разберете приблизително какъв ще бъде размерът на вашите данни, моделите на заявки и т.н. Разберете колко можете да си позволите да кеширате в кеш на междинен слой като redis/memcached, колко остарял можете да го оставите да стане, какво ниво на анулиране на кеша ви трябва. Определете дали вашият "горещ" набор от данни (до който имате достъп много) ще се побере в RAM или не. Определете дали индексите за често търсени таблици ще се поберат в RAM или не. Разберете какъв е грубият ви баланс за четене/запис и колко е вероятно записите ви да бъдат само за вмъкване (добавяне) или по-обикновен OLTP (вмъкване/актуализиране/изтриване). Измислете набор от данни и някои клиентски натоварвания. Тогава можете да започнете да отговаряте на този въпрос - може би. За да го направите правилно, вие също трябва да симулирате блокирани/изчезнали клиенти и т.н.

Вижте защо не е просто „Също така?“.