Niezależnie od tego, czy była to nasza konferencja CHAR(10) w zeszłym miesiącu, możesz teraz ponownie przeżyć część tego doświadczenia, pobierając slajdy z konferencji. Niektóre z nich zostały opublikowane na żywo podczas konferencji, niektóre pojawiły się później, ale już prawie wszystko jest. Niestety, zabawna prezentacja Nica Ferriera o tym, jak WooMe (przejęta przez Zoosk) została powiększona za pomocą Londiste i Django, nie była dostępna w formie, którą moglibyśmy łatwo odtworzyć. W tym przypadku z pewnością musiałeś tam być, na więcej niż jeden sposób.
Dwie rozmowy, które wydały mi się najbardziej pouczające, dotyczyły aktualizacji stanów pgpool-II i pgmemcache. Oba te narzędzia mają tę nieco frustrującą kombinację, że są naprawdę przydatne i nieco niedostatecznie udokumentowane w porównaniu z tym, jak bardzo są skomplikowane (przynajmniej w języku angielskim!), więc uzyskanie dodatkowego wglądu w nie od osób faktycznie pracujących nad kodem było świetne.
Dyskusja Markusa o MVCC i klastrowaniu również miała zabawny zwrot. Jego wystąpienie zakończyło się analizą wydajności jego Postgres-R względem pgpool-II, Postgres-XC i PostgreSQL 9 przy użyciu Streaming Replication plus Hot Standby, wszystkie używane w konfiguracjach klastrowych w celu przyspieszenia wyników testów dbt2. Nie do końca zgadzam się z jego założeniem, że przeciążenie sieci jest najważniejszym elementem klastra, ponieważ „całkowita moc obliczeniowa, pamięć i pojemność pamięci masowej można łatwo skalować” – to nie zawsze prawda – ale z satysfakcją zobaczyłem, że PG9 HS/SR parowanie jest pod tym względem skuteczne.
Konferencja przeznaczyła dwie sesje na omówienie ogólnych tematów grupowania w stosunkowo nieustrukturyzowany sposób. Bardziej gorąca dyskusja mówiła o tym, co ułatwiłoby wdrażanie PostgreSQL w infrastrukturze przetwarzania w chmurze. To wywołało wystarczająco dużo pomysłów, aby wygenerować już dwa wpisy na blogu od moich współpracowników.
Jednym z pomysłów z tej sesji, który wydał mi się szczególnie interesujący, było zauważenie, że jeśli masz wdrożenie, w którym węzły są dodawane w „elastyczny” sposób, który ludzie lubią Aby omówić w odniesieniu do koncepcji chmury, istnieje obecnie luka w zarządzaniu, jeśli chodzi o ułatwienie aplikacjom komunikowania się z tym zestawem węzłów. Jeśli możesz umieścić pgpool-II lub pgBouncer między twoją aplikacją a zbiorem węzłów, możesz wyabstrahować dokładnie to, co jest teraz za węzłami. Ale teraz dodałeś kolejną warstwę, a tym samym potencjalne wąskie gardło całej sprawy. Jest to przeciwieństwo elastycznych wdrożeń w chmurze:po prostu zwiększanie pojemności w razie potrzeby przy minimalnym nakładzie pracy.
Sugerowanym rozwiązaniem było ułatwienie budowania katalogu routingu bazy danych na poziomie aplikacji, tak aby aplikacje może po prostu poprosić o typ potrzebnego węzła i uzyskać taki, z którym można się bezpośrednio połączyć. Węzły mogą po prostu zarejestrować się w katalogu, gdy zostaną przeniesione do trybu online (lub zostaną usunięte). Ma to podobieństwa do niektórych komponentów, które już się unoszą. Część wyszukiwania katalogów, którą możesz umieścić w LDAP; Serwery PostgreSQL mogą już ogłaszać się za pośrednictwem ZeroConf AKA Bonjour. Nietrudno wyobrazić sobie połączenie tych dwóch elementów, tworząc warstwę aplikacji, która wykonuje wyszukiwania LDAP, połączoną z backendem routingu, który śledzi dostępne węzły za pomocą dowolnej liczby protokołów. Jak zwykle diabeł tkwi w szczegółach. Rzeczy takie jak limitowanie czasu uszkodzonych węzłów, rozróżnianie między ruchem odczytu i zapisu (pgpool-II robi to przez faktyczne analizowanie SQL, co jest drogie) i buforowanie wynikowych rozgłoszeń katalogowych w pamięci podręcznej w celu uzyskania wysokiej wydajności, przy jednoczesnym unieważnianiu pamięci podręcznej, są trudnymi szczegółami implementacji aby uzyskać właściwe rozwiązanie.
Dzięki PostgreSQL 9.0, który oferuje więcej niż kiedykolwiek sposobów skalowania architektury bazy danych w górę, ten problem nie znika. Nie jestem pewien, w jakiej formie ludzie będą go rozwiązywać, ale jest to na tyle powszechny problem, że warto go rozwiązać.
