Независимо дали сте го направили в нашата конференция CHAR(10) миналия месец, сега можете да преживеете отново част от преживяването, като изтеглите слайдовете на конференцията. Някои от тях бяха публикувани на живо по време на конференцията, някои се появиха по-късно, но почти всичко е там сега. За съжаление, забавната презентация на Ник Фериер за това как WooMe (придобита от Zoosk) се разшири с помощта на Londiste и Django не беше достъпна във форма, която лесно бихме могли да възпроизведем. За това със сигурност трябваше да сте там, по повече от един начин.
Двете беседи, които намерих за най-информативни, бяха актуализациите за състоянията на pgpool-II и pgmemcache. И двата инструмента имат тази леко разочароваща комбинация от това, че са наистина полезни и малко недостатъчно документирани в сравнение с това колко сложни са (поне на английски!), така че получаването на допълнителна представа за тях от тези, които действително работят върху кода, беше страхотно.
Обсъждането на Маркус за MVCC и клъстерирането също имаше забавен обрат. Разговорът му завърши с анализ на производителността на неговия Postgres-R срещу pgpool-II, Postgres-XC и PostgreSQL 9, използвайки Streaming Replication плюс Hot Standby, всички използвани в клъстерни конфигурации за ускоряване на резултатите от тестовете на dbt2. Не съм напълно съгласен с неговата предпоставка, че претоварването на мрежата е най-важният компонент на клъстера, тъй като „общата изчислителна мощност, памет и капацитет за съхранение лесно се мащабират“ – това не винаги е вярно – но беше задоволително да видя, че PG9 HS/SR сдвояването е ефективно в това отношение.
Конференцията отдели две сесии за обсъждане на общи теми за групиране по относително неструктуриран начин. По-разгорещената дискусия говори за това какво би направило внедряването на PostgreSQL в инфраструктурата за изчисления в облак по-лесно за справяне. Това предизвика достатъчно идеи, за да генерирам вече два записа в блога от моите колеги.
Една от идеите от тази сесия, която намерих за особено интересна, беше отбелязването, че ако имате внедряване, където възлите се добавят по „еластичния“ начин, хората харесват за да обсъдим във връзка с концепцията за облак, в момента има пропуск в управляемостта по отношение на улесняването на приложенията да разговарят с този набор от възли. Ако можете да поставите pgpool-II или pgBouncer между вашето приложение и набора от възли, можете да абстрахирате малко точно това, което е зад възлите в момента. Но сега сте добавили още един слой и следователно потенциално пречка към цялото нещо. Това е обратното на това, за което се предполага, че се отнасят еластичните облачни внедрявания:просто добавяне на капацитет според нуждите с минимална работа по управление.
Предложеният подход за решение улеснява изграждането на директория за маршрутизиране на база данни на ниво приложение, така че приложенията можете просто да попитате за типа на необходимия възел и да получите такъв, към който да се свържете директно. Възлите могат просто да се регистрират в директорията, когато бъдат въведени онлайн (или са премахнати). Това има прилики с някои компоненти, които вече се носят наоколо. Частта за търсене на директория, която можете да поставите в LDAP; PostgreSQL сървърите вече могат да се обявят чрез ZeroConf AKA Bonjour. Не е трудно да си представим свързването на тези две заедно, поставяйки приложен слой, който прави LDAP търсения, свързани с маршрутизиращ бекенд, който проследява наличните възли чрез произволен брой протоколи. Както обикновено, дяволът е в детайлите. Неща като изчакване на неуспешни възли, разграничаване на трафика за четене и запис (pgpool-II го прави, като действително анализира SQL, което е скъпо) и правенето на полученото излъчване на директория, кеширано за висока производителност, като същевременно включва невалидиране на кеша са всички трудни подробности за внедряването за да се оправя.
С PostgreSQL 9.0, включващ повече начини от всякога за мащабиране на възходящата архитектура на базата данни, този проблем обаче няма да изчезне. Все още не съм сигурен под каква форма хората ще го решат, но това е достатъчно често срещан проблем, който си струва да бъде решен.
