DBA bot Joe. Anatoly Stansler (Postgres.ai)

Bagaimana pengembang backend memahami bahwa kueri SQL akan berfungsi dengan baik pada "prod"? Di perusahaan besar atau berkembang pesat, tidak semua orang memiliki akses ke "produk". Dan dengan akses, tidak semua permintaan dapat diperiksa dengan mudah, dan membuat salinan database sering memakan waktu berjam-jam. Untuk mengatasi masalah ini, kami membuat DBA buatan - Joe. Ini telah berhasil diterapkan di beberapa perusahaan dan membantu lebih dari selusin pengembang.

Video:

Halo semua! Nama saya Anatoly Stansler. Saya bekerja untuk sebuah perusahaan postgres.ai. Kami berkomitmen untuk mempercepat proses pengembangan dengan menghilangkan penundaan yang terkait dengan pekerjaan Postgres dari pengembang, DBA, dan QA.

Kami memiliki klien yang hebat dan hari ini bagian dari laporan akan dikhususkan untuk kasus yang kami temui saat bekerja dengan mereka. Saya akan berbicara tentang bagaimana kami membantu mereka memecahkan masalah yang cukup serius.

Saat kami mengembangkan dan melakukan migrasi beban tinggi yang kompleks, kami bertanya pada diri sendiri pertanyaan: "Apakah migrasi ini akan lepas landas?". Kami menggunakan ulasan, kami menggunakan pengetahuan dari rekan yang lebih berpengalaman, pakar DBA. Dan mereka bisa mengatakan apakah itu akan terbang atau tidak.

Tapi mungkin akan lebih baik jika kita bisa mengujinya sendiri pada salinan ukuran penuh. Dan hari ini kita hanya akan berbicara tentang pendekatan pengujian apa yang sekarang dan bagaimana hal itu dapat dilakukan dengan lebih baik dan dengan alat apa. Kami juga akan berbicara tentang pro dan kontra dari pendekatan semacam itu, dan apa yang dapat kami perbaiki di sini.

Siapa yang pernah membuat indeks langsung di prod atau membuat perubahan? Cukup banyak. Dan untuk siapa hal ini mengarah pada fakta bahwa data hilang atau ada waktu henti? Maka Anda tahu rasa sakit ini. Alhamdulillah ada cadangan.

Pendekatan pertama adalah pengujian di prod. Atau, ketika pengembang duduk di mesin lokal, dia memiliki data uji, ada semacam pilihan terbatas. Dan kami meluncurkan untuk mendorong, dan kami mendapatkan situasi ini.

Sakit, itu mahal. Mungkin lebih baik tidak.

Dan apa cara terbaik untuk melakukannya?

Mari kita pementasan dan pilih beberapa bagian prod di sana. Atau paling banter, mari kita prod nyata, semua data. Dan setelah kami mengembangkannya secara lokal, kami juga akan memeriksa pementasan.

Ini akan memungkinkan kami untuk menghapus beberapa kesalahan, yaitu mencegahnya dari prod.

Apa masalahnya?

• Masalahnya adalah kami berbagi pementasan ini dengan rekan kerja. Dan sangat sering terjadi bahwa Anda membuat semacam perubahan, bam - dan tidak ada data, pekerjaan sia-sia. Pementasan adalah multi-terabyte. Dan Anda harus menunggu lama untuk bangkit kembali. Dan kami memutuskan untuk menyelesaikannya besok. Itu saja, kami memiliki perkembangan.
• Dan, tentu saja, kami memiliki banyak kolega yang bekerja di sana, banyak tim. Dan itu harus dilakukan secara manual. Dan ini tidak nyaman.

Dan perlu dikatakan bahwa kami hanya memiliki satu upaya, satu kesempatan, jika kami ingin membuat beberapa perubahan pada database, sentuh datanya, ubah strukturnya. Dan jika terjadi kesalahan, jika ada kesalahan dalam migrasi, maka kami tidak akan segera melakukan roll back.

Ini lebih baik daripada pendekatan sebelumnya, tetapi masih ada kemungkinan besar bahwa beberapa jenis kesalahan akan terjadi pada produksi.

Apa yang menghalangi kami untuk memberi setiap pengembang bangku tes, salinan ukuran penuh? Saya pikir sudah jelas apa yang menghalangi.

Siapa yang memiliki database lebih besar dari satu terabyte? Lebih dari setengah ruangan.

Dan jelas menjaga mesin untuk setiap pengembang, ketika ada produksi sebesar itu, sangat mahal, dan selain itu, butuh waktu lama.

Kami memiliki klien yang menyadari bahwa sangat penting untuk menguji semua perubahan pada salinan ukuran penuh, tetapi basis data mereka kurang dari satu terabyte, dan tidak ada sumber daya untuk menyimpan bangku pengujian untuk setiap pengembang. Oleh karena itu, mereka harus mengunduh dump secara lokal ke mesin mereka dan mengujinya dengan cara ini. Butuh banyak waktu.

Bahkan jika Anda melakukannya di dalam infrastruktur, mengunduh satu terabyte data per jam sudah sangat bagus. Tetapi mereka menggunakan dump logis, mereka mengunduh secara lokal dari cloud. Bagi mereka, kecepatannya sekitar 200 gigabyte per jam. Dan masih butuh waktu untuk berbalik dari logical dump, menggulung indeks, dll.

Tetapi mereka menggunakan pendekatan ini karena memungkinkan mereka menjaga produk tetap andal.

Apa yang bisa kita lakukan di sini? Mari buat bangku tes murah dan berikan setiap pengembang bangku tes mereka sendiri.

Dan ini mungkin.

Dan dalam pendekatan ini, saat kami membuat klon tipis untuk setiap pengembang, kami dapat membagikannya di satu mesin. Misalnya, jika Anda memiliki database 10TB dan ingin memberikannya kepada 10 developer, Anda tidak perlu memiliki database XNUMX x XNUMXTB. Anda hanya memerlukan satu mesin untuk membuat salinan tipis yang terisolasi untuk setiap pengembang menggunakan satu mesin. Saya akan memberi tahu Anda cara kerjanya nanti.

Contoh nyata:

• DB - 4,5 terabyte.

• Kami bisa mendapatkan salinan independen dalam 30 detik.

Anda tidak perlu menunggu test stand dan bergantung pada seberapa besar itu. Anda bisa mendapatkannya dalam hitungan detik. Ini akan menjadi lingkungan yang benar-benar terisolasi, tetapi berbagi data di antara mereka sendiri.

Ini bagus. Di sini kita berbicara tentang sihir dan alam semesta paralel.

Dalam kasus kami, ini berfungsi menggunakan sistem OpenZFS.

OpenZFS adalah sistem file copy-on-write yang mendukung snapshot dan klon di luar kotak. Ini dapat diandalkan dan dapat diskalakan. Dia sangat mudah diatur. Ini benar-benar dapat digunakan dalam dua tim.

Ada opsi lain:

• lvm,

• Penyimpanan (misalnya, Penyimpanan Murni).

Lab Basis Data yang saya bicarakan bersifat modular. Dapat diimplementasikan menggunakan opsi ini. Tapi untuk saat ini, kami fokus pada OpenZFS, karena ada masalah khusus dengan LVM.

Bagaimana itu bekerja? Alih-alih menimpa data setiap kali kami mengubahnya, kami menyimpannya hanya dengan menandai bahwa data baru ini berasal dari titik waktu yang baru, snapshot baru.

Dan di masa mendatang, ketika kami ingin mengembalikan atau kami ingin membuat klon baru dari beberapa versi lama, kami hanya mengatakan: "Oke, beri kami blok data yang ditandai seperti ini."

Dan pengguna ini akan bekerja dengan kumpulan data seperti itu. Dia secara bertahap akan mengubahnya, membuat jepretannya sendiri.

Dan kami akan bercabang. Setiap pengembang dalam kasus kami akan memiliki kesempatan untuk memiliki klonnya sendiri yang dia edit, dan data yang dibagikan akan dibagikan di antara semua orang.

Untuk menggunakan sistem seperti itu di rumah, Anda perlu menyelesaikan dua masalah:

• Yang pertama adalah sumber data, dari mana Anda akan mengambilnya. Anda dapat menyiapkan replikasi dengan produksi. Anda sudah dapat menggunakan cadangan yang telah Anda konfigurasikan, saya harap. WAL-E, WAL-G atau Bartender. Dan bahkan jika Anda menggunakan semacam solusi Cloud seperti RDS atau Cloud SQL, Anda dapat menggunakan dump logis. Namun kami tetap menyarankan Anda untuk menggunakan cadangan, karena dengan pendekatan ini Anda juga akan mempertahankan struktur fisik file, yang memungkinkan Anda untuk lebih dekat dengan metrik yang akan Anda lihat dalam produksi untuk mengatasi masalah yang ada.

• Yang kedua adalah tempat Anda ingin menghosting Lab Database. Bisa jadi Cloud, bisa juga On-premise. Penting untuk dikatakan di sini bahwa ZFS mendukung kompresi data. Dan itu melakukannya dengan cukup baik.

Bayangkan bahwa untuk setiap klon seperti itu, bergantung pada operasi yang kita lakukan dengan pangkalan, beberapa pengembang akan tumbuh. Untuk ini, dev juga membutuhkan ruang. Tetapi karena kami mengambil basis 4,5 terabyte, ZFS akan memampatkannya menjadi 3,5 terabyte. Ini dapat bervariasi tergantung pada pengaturan. Dan kami masih memiliki ruang untuk dev.

Sistem seperti itu dapat digunakan untuk berbagai kasus.

• Ini adalah pengembang, DBA untuk validasi kueri, untuk pengoptimalan.

• Ini dapat digunakan dalam pengujian QA untuk menguji migrasi tertentu sebelum kami meluncurkannya ke prod. Dan kami juga dapat meningkatkan lingkungan khusus untuk QA dengan data nyata, tempat mereka dapat menguji fungsionalitas baru. Dan itu akan memakan waktu beberapa detik daripada menunggu berjam-jam, dan mungkin berhari-hari dalam beberapa kasus lain di mana salinan tipis tidak digunakan.

• Dan kasus lain. Jika perusahaan tidak memiliki sistem analitik yang disiapkan, maka kami dapat mengisolasi tiruan tipis dari basis produk dan memberikannya ke kueri panjang atau indeks khusus yang dapat digunakan dalam analitik.

Dengan pendekatan ini:

1. Probabilitas kesalahan yang rendah pada "prod", karena kami menguji semua perubahan pada data ukuran penuh.

2. Kami memiliki budaya pengujian, karena sekarang Anda tidak perlu menunggu berjam-jam untuk berdiri sendiri.

3. Dan tidak ada penghalang, tidak ada penantian di antara ujian. Anda benar-benar dapat pergi dan memeriksa. Dan akan lebih baik seperti ini saat kami mempercepat pengembangan.

• Akan ada lebih sedikit refactoring. Lebih sedikit bug akan berakhir di prod. Kami akan memfaktorkan ulangnya lebih sedikit nanti.

• Kami dapat membalikkan perubahan yang tidak dapat diubah. Ini bukan pendekatan standar.

1. Ini bermanfaat karena kami berbagi sumber daya bangku ujian.

Sudah bagus, tapi apa lagi yang bisa dipercepat?

Berkat sistem seperti itu, kami dapat sangat mengurangi ambang batas untuk memasuki pengujian semacam itu.

Sekarang ada lingkaran setan, ketika seorang pengembang, untuk mendapatkan akses ke data ukuran penuh yang sebenarnya, harus menjadi seorang ahli. Dia harus dipercaya dengan akses tersebut.

Tapi bagaimana tumbuh jika tidak ada. Bagaimana jika Anda hanya memiliki sedikit data pengujian yang tersedia untuk Anda? Maka Anda tidak akan mendapatkan pengalaman nyata.

Bagaimana cara keluar dari lingkaran ini? Sebagai antarmuka pertama, nyaman untuk pengembang di level mana pun, kami memilih bot Slack. Tapi itu bisa berupa antarmuka lain.

Apa yang memungkinkan Anda lakukan? Anda dapat mengambil kueri tertentu dan mengirimkannya ke saluran khusus untuk database. Kami akan secara otomatis menerapkan klon tipis dalam hitungan detik. Mari jalankan permintaan ini. Kami mengumpulkan metrik dan rekomendasi. Mari kita tunjukkan visualisasi. Dan kemudian klon ini akan tetap ada sehingga kueri ini dapat dioptimalkan, menambahkan indeks, dll.

Dan juga Slack memberi kami kesempatan untuk berkolaborasi di luar kotak. Karena ini hanya saluran, Anda dapat mulai mendiskusikan permintaan ini langsung di utas untuk permintaan semacam itu, ping rekan Anda, DBA yang ada di dalam perusahaan.

Tapi tentu saja ada masalah. Karena ini adalah dunia nyata, dan kami menggunakan server yang menghosting banyak klon sekaligus, kami harus mengompres jumlah memori dan daya CPU yang tersedia untuk klon tersebut.

Tetapi agar tes ini masuk akal, Anda perlu menyelesaikan masalah ini.

Jelas bahwa poin penting adalah data yang sama. Tapi kita sudah memilikinya. Dan kami ingin mencapai konfigurasi yang sama. Dan kami dapat memberikan konfigurasi yang hampir identik.

Akan keren memiliki perangkat keras yang sama seperti dalam produksi, tetapi mungkin berbeda.

Mari kita ingat bagaimana Postgres bekerja dengan memori. Kami memiliki dua cache. Satu dari sistem file dan satu Postgres asli, yaitu Shared Buffer Cache.

Penting untuk dicatat bahwa Shared Buffer Cache dialokasikan saat Postgres dimulai, tergantung pada ukuran yang Anda tentukan di konfigurasi.

Dan cache kedua menggunakan semua ruang yang tersedia.

Dan ketika kami membuat beberapa klon pada satu mesin, ternyata kami mengisi memori secara bertahap. Dan untungnya, Shared Buffer Cache adalah 25% dari total jumlah memori yang tersedia di mesin.

Dan ternyata jika kita tidak mengubah parameter ini, maka kita hanya dapat menjalankan 4 instance pada satu mesin, yaitu 4 dari semua klon tipis tersebut. Dan ini, tentu saja, buruk, karena kami ingin memiliki lebih banyak lagi.

Namun di sisi lain, Buffer Cache digunakan untuk mengeksekusi kueri untuk indeks, yaitu rencananya tergantung pada seberapa besar cache kita. Dan jika kita hanya mengambil parameter ini dan menguranginya, maka rencana kita bisa banyak berubah.

Misalnya, jika kita memiliki cache yang besar pada prod, maka Postgres akan lebih memilih untuk menggunakan index. Dan jika tidak, maka akan ada SeqScan. Dan apa gunanya jika rencana kita tidak sesuai?

Tapi di sini kita sampai pada kesimpulan bahwa sebenarnya paket di Postgres tidak bergantung pada ukuran spesifik yang ditentukan dalam Shared Buffer di paket, itu tergantung pada effective_cache_size.

Effective_cache_size adalah perkiraan jumlah cache yang tersedia untuk kita, yaitu jumlah Buffer Cache dan file system cache. Ini diatur oleh konfigurasi. Dan memori ini tidak dialokasikan.

Dan karena parameter ini, kita dapat mengelabui Postgres, dengan mengatakan bahwa kita sebenarnya memiliki banyak data yang tersedia, bahkan jika kita tidak memiliki data ini. Dan dengan demikian, rencananya akan sepenuhnya sesuai dengan produksi.

Tapi ini bisa mempengaruhi waktunya. Dan kami mengoptimalkan kueri berdasarkan waktu, tetapi penting bahwa waktu bergantung pada banyak faktor:

• Itu tergantung pada beban yang saat ini ada di prod.

• Itu tergantung dari karakteristik mesin itu sendiri.

Dan ini adalah parameter tidak langsung, tetapi sebenarnya kami dapat mengoptimalkan dengan tepat jumlah data yang akan dibaca kueri ini untuk mendapatkan hasilnya.

Dan jika Anda ingin waktunya mendekati apa yang akan kita lihat di prod, maka kita perlu mengambil perangkat keras yang paling mirip dan, mungkin, bahkan lebih agar semua klon pas. Tapi ini kompromi, yaitu Anda akan mendapatkan paket yang sama, Anda akan melihat berapa banyak data yang akan dibaca kueri tertentu dan Anda akan dapat menyimpulkan apakah kueri ini baik (atau migrasi) atau buruk, masih perlu dioptimalkan .

Mari kita lihat bagaimana Joe dioptimalkan secara khusus.

Mari kita ambil permintaan dari sistem nyata. Dalam hal ini, database adalah 1 terabyte. Dan kami ingin menghitung jumlah postingan baru yang memiliki lebih dari 10 suka.

Kami sedang menulis pesan ke saluran, klon telah dikerahkan untuk kami. Dan kami akan melihat bahwa permintaan seperti itu akan selesai dalam 2,5 menit. Ini adalah hal pertama yang kami perhatikan.

B Joe akan menampilkan rekomendasi otomatis berdasarkan rencana dan metrik.

Kita akan melihat bahwa kueri memproses terlalu banyak data untuk mendapatkan jumlah baris yang relatif kecil. Dan beberapa jenis indeks khusus diperlukan, karena kami melihat ada terlalu banyak baris yang difilter dalam kueri.

Mari kita lihat lebih dekat apa yang terjadi. Memang, kami melihat bahwa kami telah membaca hampir satu setengah gigabyte data dari cache file atau bahkan dari disk. Dan ini tidak bagus, karena kami hanya mendapat 142 baris.

Dan, tampaknya, kami memiliki pemindaian indeks di sini dan seharusnya bekerja dengan cepat, tetapi karena kami memfilter terlalu banyak baris (kami harus menghitungnya), permintaan tersebut perlahan berhasil.

Dan ini terjadi dalam rencana karena kondisi dalam kueri dan kondisi dalam indeks sebagian tidak cocok.

Mari kita coba membuat indeks lebih tepat dan lihat bagaimana eksekusi kueri berubah setelah itu.

Pembuatan indeks memakan waktu cukup lama, tetapi sekarang kami memeriksa kueri dan melihat bahwa waktu bukannya 2,5 menit hanya 156 milidetik, yang cukup bagus. Dan kami hanya membaca 6 megabyte data.

Dan sekarang kami menggunakan pemindaian indeks saja.

Kisah penting lainnya adalah kami ingin menyajikan rencana tersebut dengan cara yang lebih mudah dipahami. Kami telah mengimplementasikan visualisasi menggunakan Flame Graphs.

Ini adalah permintaan yang berbeda, lebih intens. Dan kami membuat Grafik Api berdasarkan dua parameter: ini adalah jumlah data yang dihitung oleh node tertentu dalam rencana dan waktu, yaitu waktu eksekusi node.

Di sini kita dapat membandingkan node tertentu satu sama lain. Dan akan jelas mana yang membutuhkan lebih banyak atau lebih sedikit, yang biasanya sulit dilakukan dalam metode rendering lainnya.

Tentu saja, semua orang tahu jelas.depesz.com. Fitur bagus dari visualisasi ini adalah kita menyimpan rencana teks dan juga memasukkan beberapa parameter dasar ke dalam tabel sehingga kita dapat mengurutkan.

Dan developer yang belum mendalami topik ini juga menggunakan explain.depesz.com, karena lebih mudah bagi mereka untuk mengetahui metrik mana yang penting dan mana yang tidak.

Ada pendekatan baru untuk visualisasi - ini adalah explain.dalibo.com. Mereka melakukan visualisasi pohon, tetapi sangat sulit untuk membandingkan node satu sama lain. Di sini Anda dapat memahami strukturnya dengan baik, namun, jika ada permintaan besar, Anda perlu menggulir bolak-balik, tetapi juga opsi.

kolaborasi

Dan, seperti yang saya katakan, Slack memberi kita kesempatan untuk berkolaborasi. Misalnya, jika kami menemukan kueri rumit yang tidak jelas cara mengoptimalkannya, kami dapat mengklarifikasi masalah ini dengan kolega kami di utas di Slack.

Bagi kami, penting untuk menguji data ukuran penuh. Untuk melakukan ini, kami membuat alat Perbarui Basis Data Lab, yang tersedia dalam sumber terbuka. Anda juga dapat menggunakan bot Joe. Anda dapat mengambilnya sekarang juga dan menerapkannya di tempat Anda. Semua panduan tersedia di sana.

Penting juga untuk dicatat bahwa solusinya sendiri tidak revolusioner, karena ada Delphix, tetapi ini adalah solusi perusahaan. Itu benar-benar tertutup, sangat mahal. Kami secara khusus berspesialisasi dalam Postgres. Ini semua adalah produk sumber terbuka. Bergabunglah dengan kami!

Di sinilah saya berakhir. Terima kasih!

pertanyaan

Halo! Terima kasih atas laporannya! Sangat menarik, terutama bagi saya, karena saya memecahkan masalah yang sama beberapa waktu lalu. Jadi saya punya sejumlah pertanyaan. Mudah-mudahan saya akan mendapatkan setidaknya bagian dari itu.

Saya bertanya-tanya bagaimana Anda menghitung tempat untuk lingkungan ini? Teknologi berarti bahwa dalam keadaan tertentu, klon Anda dapat tumbuh hingga ukuran maksimum. Secara kasar, jika Anda memiliki database sepuluh terabyte dan 10 klon, maka mudah untuk mensimulasikan situasi di mana setiap klon memiliki berat 10 data unik. Bagaimana Anda menghitung tempat ini, yaitu delta yang Anda bicarakan, tempat klon ini akan hidup?

Pertanyaan bagus. Penting untuk melacak klon tertentu di sini. Dan jika klon memiliki perubahan yang terlalu besar, itu mulai tumbuh, maka pertama-tama kita dapat mengeluarkan peringatan kepada pengguna tentang hal ini, atau segera hentikan klon ini agar kita tidak mengalami situasi gagal.

Ya, saya punya pertanyaan bersarang. Artinya, bagaimana Anda memastikan siklus hidup modul-modul ini? Kami memiliki masalah ini dan keseluruhan cerita yang terpisah. Bagaimana ini bisa terjadi?

Ada beberapa ttl untuk setiap klon. Pada dasarnya, kami memiliki ttl tetap.

Apa, jika bukan rahasia?

1 jam, yaitu menganggur - 1 jam. Kalau tidak dipakai, baru kita benturkan. Tapi tidak ada kejutan di sini, karena kita bisa menaikkan klon dalam hitungan detik. Dan jika Anda membutuhkannya lagi, silakan.

Saya juga tertarik dengan pilihan teknologi, karena, misalnya, kami menggunakan beberapa metode secara paralel karena satu dan lain hal. Mengapa ZFS? Mengapa Anda tidak menggunakan LVM? Anda menyebutkan bahwa ada masalah dengan LVM. Apa masalahnya? Menurut saya, opsi paling optimal adalah dengan penyimpanan, dalam hal performa.

Apa masalah utama dengan ZFS? Fakta bahwa Anda harus berjalan di host yang sama, yaitu semua instans akan hidup dalam OS yang sama. Dan dalam hal penyimpanan, Anda dapat menghubungkan peralatan yang berbeda. Dan hambatannya hanyalah blok-blok yang ada di sistem penyimpanan. Dan pertanyaan tentang pilihan teknologi itu menarik. Mengapa tidak LVM?

Secara khusus, kita dapat mendiskusikan LVM saat pertemuan. Tentang penyimpanan - harganya mahal. Kita bisa mengimplementasikan sistem ZFS dimana saja. Anda dapat menerapkannya di mesin Anda. Anda cukup mengunduh repositori dan menerapkannya. ZFS dipasang hampir di mana-mana jika kita berbicara tentang Linux. Artinya, kami mendapatkan solusi yang sangat fleksibel. Dan ZFS sendiri memberikan banyak hal di luar kotak. Anda dapat mengunggah data sebanyak yang Anda suka, menghubungkan disk dalam jumlah besar, ada snapshot. Dan, seperti yang saya katakan, mudah dikelola. Artinya, sepertinya sangat menyenangkan untuk digunakan. Dia diuji, dia berumur bertahun-tahun. Dia memiliki komunitas yang sangat besar yang sedang berkembang. ZFS adalah solusi yang sangat andal.

Nikolai Samokhvalov: Bolehkah saya berkomentar lebih lanjut? Nama saya Nikolay, kami bekerja sama dengan Anatoly. Saya setuju bahwa penyimpanan itu bagus. Dan beberapa pelanggan kami memiliki Penyimpanan Murni dll.

Anatoly dengan tepat mencatat bahwa kami fokus pada modularitas. Dan di masa mendatang, Anda dapat mengimplementasikan satu antarmuka - ambil snapshot, buat klon, hancurkan klon. Semuanya mudah. Dan penyimpanannya keren, jika memang demikian.

Tetapi ZFS tersedia untuk semua orang. DelPhix sudah cukup, mereka memiliki 300 klien. Dari jumlah tersebut, fortune 100 memiliki 50 klien, mis. mereka ditujukan ke NASA, dll. Saatnya semua orang mendapatkan teknologi ini. Dan itulah mengapa kami memiliki Core open source. Kami memiliki bagian antarmuka yang bukan sumber terbuka. Ini adalah platform yang akan kami tunjukkan. Tapi kami ingin itu dapat diakses oleh semua orang. Kami ingin membuat revolusi agar semua penguji berhenti menebak-nebak di laptop. Kami harus menulis SELECT dan segera melihat bahwa itu lambat. Berhentilah menunggu DBA memberi tahu Anda tentang hal itu. Inilah tujuan utamanya. Dan saya pikir kita semua akan sampai pada ini. Dan kami membuat hal ini untuk dimiliki semua orang. Oleh karena itu ZFS, karena akan tersedia dimana-mana. Terima kasih kepada komunitas untuk memecahkan masalah dan memiliki lisensi sumber terbuka, dll.*

Salam! Terima kasih atas laporannya! Nama saya Maxim. Kami telah menangani masalah yang sama. Mereka memutuskan sendiri. Bagaimana Anda berbagi sumber daya di antara klon ini? Setiap klon dapat melakukan tugasnya sendiri pada waktu tertentu: satu menguji satu hal, yang lain menguji yang lain, seseorang membuat indeks, seseorang memiliki pekerjaan yang berat. Dan jika Anda masih bisa membaginya dengan CPU, lalu dengan IO, bagaimana Anda membaginya? Ini adalah pertanyaan pertama.

Dan pertanyaan kedua adalah tentang perbedaan tribun. Katakanlah saya memiliki ZFS di sini dan semuanya keren, tetapi klien di prod tidak memiliki ZFS, tetapi ext4, misalnya. Bagaimana dalam hal ini?

Pertanyaan-pertanyaannya sangat bagus. Saya menyebutkan masalah ini sedikit dengan fakta bahwa kami berbagi sumber daya. Dan solusinya adalah ini. Bayangkan Anda sedang menguji pementasan. Anda juga dapat mengalami situasi seperti itu pada saat yang sama seseorang memberikan satu beban, orang lain. Dan sebagai hasilnya, Anda melihat metrik yang tidak dapat dipahami. Bahkan masalah yang sama bisa terjadi dengan prod. Ketika Anda ingin memeriksa beberapa permintaan dan Anda melihat ada beberapa masalah dengannya - ini bekerja lambat, maka sebenarnya masalahnya bukan pada permintaan, tetapi pada kenyataan bahwa ada semacam beban paralel.

Dan oleh karena itu, penting di sini untuk fokus pada rencana apa yang akan dibuat, langkah apa yang akan kita ambil dalam rencana tersebut dan berapa banyak data yang akan kita kumpulkan untuk ini. Fakta bahwa disk kita, misalnya, akan dimuat dengan sesuatu, secara khusus akan memengaruhi waktu. Namun kami dapat memperkirakan seberapa banyak permintaan ini dimuat berdasarkan jumlah data. Tidak begitu penting bahwa pada saat yang sama akan ada semacam eksekusi.

Saya punya dua pertanyaan. Ini barang yang sangat keren. Pernahkah ada kasus di mana data produksi sangat penting, seperti nomor kartu kredit? Apakah sudah ada yang siap atau tugas tersendiri? Dan pertanyaan kedua - apakah ada yang seperti ini untuk MySQL?

Tentang datanya. Kami akan melakukan kebingungan sampai kami melakukannya. Tetapi jika Anda menggunakan Joe dengan tepat, jika Anda tidak memberikan akses ke pengembang, maka tidak ada akses ke data. Mengapa? Karena Joe tidak menunjukkan data. Itu hanya menunjukkan metrik, rencana dan hanya itu. Ini dilakukan dengan sengaja, karena ini adalah salah satu persyaratan klien kami. Mereka ingin dapat mengoptimalkan tanpa memberikan akses kepada semua orang.

Tentang MySQL. Sistem ini dapat digunakan untuk apa pun yang menyimpan status di disk. Dan karena kami sedang mengerjakan Postgres, kami sekarang melakukan semua otomatisasi untuk Postgres terlebih dahulu. Kami ingin mengotomatiskan pengambilan data dari cadangan. Kami mengkonfigurasi Postgres dengan benar. Kami tahu bagaimana menyesuaikan rencana, dll.

Tetapi karena sistemnya dapat diperluas, sistem ini juga dapat digunakan untuk MySQL. Dan ada contoh seperti itu. Yandex memiliki hal serupa, tetapi mereka tidak menerbitkannya di mana pun. Mereka menggunakannya di dalam Yandex.Metrica. Dan hanya ada cerita tentang MySQL. Tapi teknologinya sama, ZFS.

Terima kasih atas laporannya! Saya juga punya beberapa pertanyaan. Anda menyebutkan bahwa kloning dapat digunakan untuk analitik, misalnya untuk membuat indeks tambahan di sana. Bisakah Anda memberi tahu lebih banyak tentang cara kerjanya?

Dan saya akan langsung menanyakan pertanyaan kedua tentang kesamaan tribun, kesamaan denah. Rencananya juga bergantung pada statistik yang dikumpulkan oleh Postgres. Bagaimana Anda menyelesaikan masalah ini?

Menurut analitik, tidak ada kasus khusus, karena kami belum menggunakannya, tetapi ada peluang seperti itu. Jika kita berbicara tentang indeks, bayangkan kueri mengejar tabel dengan ratusan juta catatan dan kolom yang biasanya tidak diindeks dalam prod. Dan kami ingin menghitung beberapa data di sana. Jika permintaan ini dikirim ke prod, maka ada kemungkinan permintaan akan sederhana di prod, karena permintaan akan diproses di sana sebentar.

Oke, mari kita buat tiruan tipis yang tidak mengerikan untuk berhenti selama beberapa menit. Dan agar lebih nyaman membaca analitik, kami akan menambahkan indeks untuk kolom yang datanya kami minati.

Indeks akan dibuat setiap kali?

Anda dapat membuatnya agar kami menyentuh data, membuat snapshot, lalu kami akan memulihkan dari snapshot ini dan mendorong permintaan baru. Artinya, Anda dapat membuatnya sehingga Anda dapat meningkatkan klon baru dengan indeks yang sudah ditempelkan.

Adapun pertanyaan tentang statistik, jika kami memulihkan dari cadangan, jika kami melakukan replikasi, maka statistik kami akan sama persis. Karena kami memiliki seluruh struktur data fisik, yaitu, kami akan membawa data apa adanya dengan semua metrik statistik juga.

Ini masalah lain. Jika Anda menggunakan solusi cloud, maka hanya dump logis yang tersedia di sana, karena Google, Amazon tidak mengizinkan Anda mengambil salinan fisik. Akan ada masalah.

Terima kasih atas laporannya. Ada dua pertanyaan bagus di sini tentang MySQL dan berbagi sumber daya. Namun, pada kenyataannya, semuanya bermuara pada fakta bahwa ini bukan topik DBMS tertentu, tetapi tentang sistem file secara keseluruhan. Dan, oleh karena itu, masalah berbagi sumber daya juga harus diselesaikan dari sana, bukan pada akhirnya Postgres, tetapi di sistem file, di server, misalnya.

Pertanyaan saya sedikit berbeda. Ini lebih dekat dengan basis data berlapis-lapis, di mana ada beberapa lapisan. Misalnya, kami menyiapkan pembaruan gambar sepuluh terabyte, kami mereplikasi. Dan kami secara khusus menggunakan solusi ini untuk database. Replikasi sedang berlangsung, data sedang diperbarui. Ada 100 karyawan yang bekerja secara paralel di sini, yang terus meluncurkan bidikan berbeda ini. Apa yang harus dilakukan? Bagaimana memastikan bahwa tidak ada konflik, bahwa mereka meluncurkannya, dan kemudian sistem file berubah, dan semua gambar ini hilang?

Mereka tidak akan pergi karena itulah cara kerja ZFS. Kami dapat menyimpan secara terpisah dalam satu utas perubahan sistem file yang terjadi karena replikasi. Dan pertahankan klon yang digunakan pengembang pada versi data yang lebih lama. Dan itu berhasil untuk kami, semuanya beres dengan ini.

Ternyata pembaruan akan dilakukan sebagai lapisan tambahan, dan semua gambar baru akan pergi, berdasarkan lapisan ini, bukan?

Dari lapisan sebelumnya yang berasal dari replikasi sebelumnya.

Lapisan sebelumnya akan jatuh, tetapi mereka akan merujuk ke lapisan lama, dan apakah mereka akan mengambil gambar baru dari lapisan terakhir yang diterima dalam pembaruan?

Secara umum, ya.

Kemudian sebagai konsekuensinya kita akan memiliki banyak lapisan. Dan seiring waktu mereka perlu dikompres?

Ya semuanya benar. Ada beberapa jendela. Kami menyimpan snapshot mingguan. Itu tergantung pada sumber daya apa yang Anda miliki. Jika Anda memiliki kemampuan untuk menyimpan banyak data, Anda dapat menyimpan snapshot untuk waktu yang lama. Mereka tidak akan pergi dengan sendirinya. Tidak akan ada korupsi data. Jika snapshot sudah usang, menurut kami, mis. itu tergantung pada kebijakan di perusahaan, maka kami dapat menghapusnya dan mengosongkan ruang.

Halo, terima kasih atas laporannya! Pertanyaan tentang Joe. Anda mengatakan bahwa pelanggan tidak ingin memberikan akses ke data kepada semua orang. Tegasnya, jika seseorang memiliki hasil Explain Analyse, maka dia bisa mengintip datanya.

Seperti itu. Misalnya, kita dapat menulis: "SELECT FROM WHERE email = to that". Artinya, kita tidak akan melihat datanya sendiri, tetapi kita dapat melihat beberapa tanda tidak langsung. Ini harus dipahami. Tapi di sisi lain, semuanya ada di sana. Kami memiliki audit log, kami memiliki kendali atas kolega lain yang juga melihat apa yang dilakukan pengembang. Dan jika seseorang mencoba melakukan ini, layanan keamanan akan mendatangi mereka dan menangani masalah ini.

Selamat siang Terima kasih atas laporannya! Saya punya pertanyaan singkat. Jika perusahaan tidak menggunakan Slack, apakah ada pengikatannya sekarang, atau mungkinkah pengembang menerapkan instance untuk menghubungkan aplikasi pengujian ke database?

Sekarang ada tautan ke Slack, mis. tidak ada messenger lain, tetapi saya juga ingin membuat dukungan untuk messenger lain. Apa yang bisa kau lakukan? Anda dapat menerapkan DB Lab tanpa Joe, menggunakan bantuan REST API atau dengan bantuan platform kami dan membuat klon dan terhubung dengan PSQL. Tapi ini bisa dilakukan jika Anda siap memberi pengembang Anda akses ke data, karena tidak akan ada lagi layar.

Saya tidak membutuhkan lapisan ini, tetapi saya membutuhkan kesempatan seperti itu.

Lalu ya, itu bisa dilakukan.

Sumber: www.habr.com