Apakah Anda membuat konferensi CHAR(10) kami bulan lalu atau tidak, Anda sekarang dapat menghidupkan kembali sebagian dari pengalaman dengan mengunduh slide konferensi. Beberapa di antaranya diposting langsung selama konferensi, beberapa muncul kemudian, tetapi hampir semuanya ada di sana sekarang. Sayangnya, presentasi menghibur Nic Ferrier tentang bagaimana WooMe (diakuisisi oleh Zoosk) ditingkatkan menggunakan Londiste dan Django tidak tersedia dalam bentuk yang dapat kami putar ulang dengan mudah. Untuk yang satu itu, Anda tentu harus ada di sana, dalam lebih dari satu cara.
Dua pembicaraan yang menurut saya paling informatif adalah pembaruan status pgpool-II dan pgmemcache. Kedua alat tersebut memiliki kombinasi yang sedikit membuat frustrasi karena sangat berguna dan sedikit terdokumentasi dibandingkan dengan betapa rumitnya mereka (setidaknya dalam bahasa Inggris!), jadi mendapatkan wawasan tambahan tentang mereka dari mereka yang benar-benar mengerjakan kode itu hebat.
Diskusi Markus tentang MVCC dan pengelompokan juga memiliki twist yang menyenangkan. Pembicaraannya diakhiri dengan analisis kinerja Postgres-R-nya terhadap pgpool-II, Postgres-XC, dan PostgreSQL 9 menggunakan Streaming Replication plus Hot Standby, semuanya digunakan dalam konfigurasi cluster untuk mempercepat hasil pengujian dbt2. Saya tidak begitu setuju dengan premisnya bahwa kemacetan jaringan adalah komponen cluster yang paling vital karena "daya komputasi secara keseluruhan, memori dan kapasitas penyimpanan skala dengan mudah"–itu tidak selalu benar–tetapi itu memuaskan untuk melihat bahwa PG9 HS/SR penyandingan efisien dalam hal itu.
Konferensi menyisihkan dua sesi untuk membicarakan topik pengelompokan umum dengan cara yang relatif tidak terstruktur. Diskusi yang lebih panas berbicara tentang apa yang akan membuat penyebaran PostgreSQL ke dalam infrastruktur komputasi awan lebih mudah untuk ditangani. Hal itu menimbulkan cukup banyak ide untuk menghasilkan dua entri blog dari rekan kerja saya.
Salah satu ide dari sesi itu yang menurut saya sangat menarik adalah mencatat bahwa jika Anda memiliki penerapan di mana node ditambahkan dengan cara "elastis" yang disukai orang untuk membahas terkait dengan konsep cloud, ada celah keterkelolaan saat ini dalam hal kemudahan aplikasi untuk berbicara dengan kumpulan node tersebut. Jika Anda dapat menempatkan pgpool-II atau pgBouncer di antara aplikasi Anda dan kumpulan node, Anda dapat sedikit mengabstraksikan apa yang ada di balik node sekarang. Tapi sekarang Anda telah menambahkan lapisan lain dan karena itu potensi kemacetan untuk semuanya. Itu kebalikan dari apa penerapan elastic cloud yang seharusnya:hanya menambahkan kapasitas sesuai kebutuhan dengan pekerjaan manajemen yang minimal.
Pendekatan solusi yang disarankan adalah mempermudah pembuatan direktori perutean basis data di tingkat aplikasi, sehingga aplikasi hanya dapat meminta jenis simpul yang dibutuhkan dan mendapatkannya untuk langsung terhubung. Node hanya dapat mendaftarkan diri ke direktori saat dibawa online (atau diturunkan). Ini memiliki kesamaan dengan beberapa komponen yang sudah beredar. Bagian pencarian direktori yang mungkin Anda masukkan ke dalam LDAP; Server PostgreSQL sudah dapat mengumumkan dirinya melalui ZeroConf AKA Bonjour. Tidak sulit membayangkan menggabungkan keduanya, menempatkan lapisan aplikasi yang melakukan pencarian LDAP terhubung ke backend perutean yang melacak node yang tersedia melalui sejumlah protokol. Seperti biasa, iblis ada dalam detailnya. Hal-hal seperti waktu habis node yang gagal, membedakan antara lalu lintas baca dan tulis (pgpool-II melakukannya dengan benar-benar mengurai SQL, yang mahal), dan membuat siaran direktori yang dihasilkan di-cache untuk kinerja tinggi sementara juga menampilkan pembatalan cache adalah semua detail implementasi yang rumit untuk memperbaikinya.
Dengan PostgreSQL 9.0 menampilkan lebih banyak cara dari sebelumnya untuk meningkatkan arsitektur basis data, masalah ini tidak akan hilang. Saya tidak yakin dalam bentuk apa orang akan menyelesaikannya, tetapi ini adalah masalah yang cukup umum sehingga layak untuk dipecahkan.
