DBA bot Joe. Anatoly Stansler (Postgres.ai)

Bagaimanakah pembangun bahagian belakang memahami bahawa pertanyaan SQL akan berfungsi dengan baik pada "prod"? Dalam syarikat besar atau berkembang pesat, tidak semua orang mempunyai akses kepada "produk". Dan dengan akses, tidak semua permintaan boleh disemak tanpa rasa sakit, dan membuat salinan pangkalan data selalunya mengambil masa berjam-jam. Untuk menyelesaikan masalah ini, kami mencipta DBA tiruan - Joe. Ia telah pun berjaya dilaksanakan di beberapa syarikat dan membantu lebih daripada sedozen pembangun.

Video:

Hai semua! Nama saya Anatoly Stansler. Saya bekerja untuk sebuah syarikat postgres.ai. Kami komited untuk mempercepatkan proses pembangunan dengan mengalih keluar kelewatan yang berkaitan dengan kerja Postgres daripada pembangun, DBA dan QA.

Kami mempunyai pelanggan yang hebat dan hari ini sebahagian daripada laporan itu akan ditumpukan kepada kes yang kami temui semasa bekerja dengan mereka. Saya akan bercakap tentang cara kami membantu mereka menyelesaikan masalah yang agak serius.

Apabila kami sedang membangun dan melakukan migrasi beban tinggi yang kompleks, kami bertanya kepada diri sendiri soalan: "Adakah penghijrahan ini akan berlaku?". Kami menggunakan semakan, kami menggunakan pengetahuan rakan sekerja yang lebih berpengalaman, pakar DBA. Dan mereka boleh tahu sama ada ia akan terbang atau tidak.

Tetapi mungkin lebih baik jika kita boleh mengujinya sendiri pada salinan saiz penuh. Dan hari ini kita hanya akan bercakap tentang pendekatan untuk ujian sekarang dan bagaimana ia boleh dilakukan dengan lebih baik dan dengan alat apa. Kami juga akan bercakap tentang kebaikan dan keburukan pendekatan sedemikian, dan perkara yang boleh kami perbaiki di sini.

Siapa yang pernah membuat indeks secara langsung pada prod atau membuat sebarang perubahan? Agak agak. Dan untuk siapa ini membawa kepada fakta bahawa data telah hilang atau terdapat masa henti? Kemudian anda tahu kesakitan ini. Alhamdulillah ada sandaran.

Pendekatan pertama adalah menguji dalam prod. Atau, apabila pemaju duduk pada mesin tempatan, dia mempunyai data ujian, terdapat beberapa jenis pemilihan terhad. Dan kami melancarkan prod, dan kami mendapat situasi ini.

Sakit, mahal. Mungkin lebih baik tidak.

Dan apakah cara terbaik untuk melakukannya?

Mari kita pementasan dan pilih beberapa bahagian prod di sana. Atau paling baik, mari kita ambil prod sebenar, semua data. Dan selepas kami membangunkannya secara tempatan, kami juga akan menyemak pementasan.

Ini akan membolehkan kami mengalih keluar beberapa ralat, iaitu menghalangnya daripada berada di prod.

Apakah masalahnya?

• Masalahnya ialah kami berkongsi pementasan ini dengan rakan sekerja. Dan selalunya ia berlaku bahawa anda membuat beberapa jenis perubahan, bam - dan tidak ada data, kerja itu sia-sia. Pementasan ialah berbilang terabait. Dan anda perlu menunggu lama untuk ia naik semula. Dan kami memutuskan untuk memuktamadkannya esok. Itu sahaja, kita ada perkembangan.
• Dan, sudah tentu, kami mempunyai ramai rakan sekerja yang bekerja di sana, banyak pasukan. Dan ia perlu dilakukan secara manual. Dan ini menyusahkan.

Dan patut dikatakan bahawa kita hanya mempunyai satu percubaan, satu pukulan, jika kita ingin membuat beberapa perubahan pada pangkalan data, sentuh data, ubah struktur. Dan jika berlaku kesilapan, jika terdapat kesilapan dalam penghijrahan, maka kami tidak akan cepat berpatah balik.

Ini lebih baik daripada pendekatan sebelumnya, tetapi masih terdapat kebarangkalian tinggi bahawa beberapa jenis ralat akan pergi ke pengeluaran.

Apakah yang menghalang kami daripada memberikan setiap pembangun bangku ujian, salinan bersaiz penuh? Saya rasa sudah jelas apa yang menghalang.

Siapa yang mempunyai pangkalan data lebih besar daripada terabait? Lebih daripada separuh bilik.

Dan adalah jelas bahawa menyimpan mesin untuk setiap pemaju, apabila terdapat pengeluaran yang begitu besar, adalah sangat mahal, dan selain itu, ia mengambil masa yang lama.

Kami mempunyai pelanggan yang menyedari bahawa adalah sangat penting untuk menguji semua perubahan pada salinan bersaiz penuh, tetapi pangkalan data mereka kurang daripada satu terabait, dan tiada sumber untuk menyimpan bangku ujian bagi setiap pembangun. Oleh itu, mereka perlu memuat turun pembuangan secara tempatan ke mesin mereka dan menguji dengan cara ini. Ia memerlukan banyak masa.

Walaupun anda melakukannya di dalam infrastruktur, maka memuat turun satu terabait data sejam sudah sangat baik. Tetapi mereka menggunakan pembuangan logik, mereka memuat turun secara tempatan dari awan. Bagi mereka, kelajuannya adalah kira-kira 200 gigabait sejam. Dan masih memerlukan masa untuk berpatah balik dari longgokan logik, menggulung indeks, dsb.

Tetapi mereka menggunakan pendekatan ini kerana ia membolehkan mereka memastikan prod boleh dipercayai.

Apa yang boleh kita lakukan di sini? Mari jadikan bangku ujian murah dan berikan setiap pemaju bangku ujian mereka sendiri.

Dan ini mungkin.

Dan dalam pendekatan ini, apabila kami membuat klon nipis untuk setiap pembangun, kami boleh berkongsinya pada satu mesin. Sebagai contoh, jika anda mempunyai pangkalan data 10TB dan ingin memberikannya kepada 10 pembangun, anda tidak perlu mempunyai pangkalan data XNUMX x XNUMXTB. Anda hanya memerlukan satu mesin untuk membuat salinan terpencil nipis untuk setiap pembangun menggunakan satu mesin. Saya akan memberitahu anda bagaimana ia berfungsi sedikit kemudian.

Contoh sebenar:

• DB - 4,5 terabait.

• Kita boleh mendapatkan salinan bebas dalam masa 30 saat.

Anda tidak perlu menunggu tempat ujian dan bergantung pada saiznya. Anda boleh mendapatkannya dalam beberapa saat. Ia akan menjadi persekitaran terpencil sepenuhnya, tetapi yang berkongsi data sesama mereka.

Ini bagus. Di sini kita bercakap tentang sihir dan alam semesta selari.

Dalam kes kami, ini berfungsi menggunakan sistem OpenZFS.

OpenZFS ialah sistem fail copy-on-write yang menyokong syot kilat dan klon di luar kotak. Ia boleh dipercayai dan berskala. Dia sangat mudah diurus. Ia benar-benar boleh digunakan dalam dua pasukan.

Terdapat pilihan lain:

• lvm,

• Storan (contohnya, Storan Tulen).

Makmal Pangkalan Data yang saya maksudkan adalah modular. Boleh dilaksanakan menggunakan pilihan ini. Tetapi buat masa ini, kami telah memberi tumpuan kepada OpenZFS, kerana terdapat masalah dengan LVM secara khusus.

Bagaimana ia berfungsi? Daripada menulis ganti data setiap kali kami menukarnya, kami menyimpannya dengan hanya menandakan bahawa data baharu ini adalah dari titik masa baharu, petikan baharu.

Dan pada masa hadapan, apabila kami ingin membuat gulung balik atau kami ingin membuat klon baharu daripada beberapa versi lama, kami hanya berkata: "OK, berikan kami blok data ini yang ditandakan seperti ini."

Dan pengguna ini akan bekerja dengan set data sedemikian. Dia akan mengubahnya secara beransur-ansur, membuat syot kilat sendiri.

Dan kami akan bercabang. Setiap pembangun dalam kes kami akan mempunyai peluang untuk mempunyai klon sendiri yang dieditnya, dan data yang dikongsi akan dikongsi antara semua orang.

Untuk menggunakan sistem sedemikian di rumah, anda perlu menyelesaikan dua masalah:

• Yang pertama ialah sumber data, dari mana anda akan mengambilnya. Anda boleh menyediakan replikasi dengan pengeluaran. Anda sudah boleh menggunakan sandaran yang telah anda konfigurasikan, saya harap. WAL-E, WAL-G atau Barman. Dan walaupun anda menggunakan beberapa jenis penyelesaian Awan seperti RDS atau Cloud SQL, maka anda boleh menggunakan pembuangan logik. Tetapi kami masih menasihati anda untuk menggunakan sandaran, kerana dengan pendekatan ini anda juga akan mengekalkan struktur fizikal fail, yang akan membolehkan anda lebih dekat dengan metrik yang anda akan lihat dalam pengeluaran untuk menangkap masalah yang wujud.

• Yang kedua ialah tempat anda ingin menjadi hos Makmal Pangkalan Data. Ia boleh jadi Awan, boleh jadi Di premis. Adalah penting untuk menyatakan di sini bahawa ZFS menyokong pemampatan data. Dan ia melakukannya dengan baik.

Bayangkan bahawa untuk setiap klon sedemikian, bergantung pada operasi yang kita lakukan dengan pangkalan, beberapa jenis pembangun akan berkembang. Untuk ini, dev juga memerlukan ruang. Tetapi disebabkan fakta bahawa kami mengambil asas 4,5 terabait, ZFS akan memampatkannya kepada 3,5 terabait. Ini boleh berbeza-beza bergantung pada tetapan. Dan kami masih mempunyai ruang untuk dev.

Sistem sedemikian boleh digunakan untuk kes yang berbeza.

• Ini adalah pembangun, DBA untuk pengesahan pertanyaan, untuk pengoptimuman.

• Ini boleh digunakan dalam ujian QA untuk menguji penghijrahan tertentu sebelum kami melancarkannya ke prod. Dan kami juga boleh meningkatkan persekitaran khas untuk QA dengan data sebenar, di mana mereka boleh menguji kefungsian baharu. Dan ia akan mengambil beberapa saat dan bukannya waktu menunggu, dan mungkin beberapa hari dalam beberapa kes lain di mana salinan nipis tidak digunakan.

• Dan satu lagi kes. Jika syarikat itu tidak mempunyai sistem analitis yang disediakan, maka kami boleh mengasingkan klon nipis asas produk dan memberikannya kepada pertanyaan panjang atau indeks khas yang boleh digunakan dalam analitik.

Dengan pendekatan ini:

1. Kebarangkalian ralat yang rendah pada "prod", kerana kami menguji semua perubahan pada data bersaiz penuh.

2. Kami mempunyai budaya ujian, kerana kini anda tidak perlu menunggu berjam-jam untuk pendirian anda sendiri.

3. Dan tiada halangan, tiada menunggu antara ujian. Anda sebenarnya boleh pergi dan menyemak. Dan ia akan menjadi lebih baik dengan cara ini kerana kita mempercepatkan pembangunan.

• Akan ada kurang pemfaktoran semula. Lebih sedikit pepijat akan berakhir dalam prod. Kami akan memfaktorkannya lebih sedikit kemudian.

• Kita boleh membalikkan perubahan yang tidak dapat dipulihkan. Ini bukan pendekatan standard.

1. Ini bermanfaat kerana kami berkongsi sumber bangku ujian.

Sudah bagus, tetapi apa lagi yang boleh dipercepatkan?

Terima kasih kepada sistem sedemikian, kami boleh mengurangkan ambang untuk memasuki ujian sedemikian.

Kini terdapat lingkaran setan, apabila pembangun, untuk mendapatkan akses kepada data bersaiz penuh sebenar, mesti menjadi pakar. Dia mesti dipercayai dengan akses sedemikian.

Tetapi bagaimana untuk berkembang jika ia tidak ada. Tetapi bagaimana jika anda hanya mempunyai set data ujian yang sangat kecil yang tersedia untuk anda? Kemudian anda tidak akan mendapat pengalaman sebenar.

Bagaimana untuk keluar dari kalangan ini? Sebagai antara muka pertama, mudah untuk pembangun dari mana-mana peringkat, kami memilih bot Slack. Tetapi ia boleh menjadi antara muka lain.

Apakah yang membolehkan anda lakukan? Anda boleh mengambil pertanyaan khusus dan menghantarnya ke saluran khas untuk pangkalan data. Kami akan menggunakan klon nipis secara automatik dalam beberapa saat. Mari jalankan permintaan ini. Kami mengumpul metrik dan pengesyoran. Mari tunjukkan visualisasi. Dan kemudian klon ini akan kekal supaya pertanyaan ini boleh dioptimumkan, menambah indeks, dsb.

Dan juga Slack memberi kami peluang untuk bekerjasama di luar kotak. Memandangkan ini hanyalah saluran, anda boleh mula membincangkan permintaan ini di sana dalam urutan untuk permintaan sedemikian, ping rakan sekerja anda, DBA yang berada di dalam syarikat.

Tetapi sudah tentu ada masalah. Kerana ini adalah dunia sebenar, dan kami menggunakan pelayan yang mengehos banyak klon sekaligus, kami perlu memampatkan jumlah memori dan kuasa CPU yang tersedia untuk klon.

Tetapi untuk ujian ini munasabah, anda perlu menyelesaikan masalah ini.

Adalah jelas bahawa perkara penting adalah data yang sama. Tetapi kita sudah memilikinya. Dan kami mahu mencapai konfigurasi yang sama. Dan kita boleh memberikan konfigurasi yang hampir sama.

Memang bagus untuk mempunyai perkakasan yang sama seperti dalam pengeluaran, tetapi ia mungkin berbeza.

Mari kita ingat bagaimana Postgres berfungsi dengan ingatan. Kami mempunyai dua cache. Satu daripada sistem fail dan satu Postgres asli, iaitu Shared Buffer Cache.

Adalah penting untuk ambil perhatian bahawa Shared Buffer Cache diperuntukkan apabila Postgres bermula, bergantung pada saiz yang anda tentukan dalam konfigurasi.

Dan cache kedua menggunakan semua ruang yang ada.

Dan apabila kita membuat beberapa klon pada satu mesin, ternyata kita secara beransur-ansur mengisi memori. Dan dengan cara yang baik, Shared Buffer Cache ialah 25% daripada jumlah memori yang tersedia pada mesin.

Dan ternyata jika kita tidak mengubah parameter ini, maka kita akan dapat menjalankan hanya 4 contoh pada satu mesin, iaitu, 4 daripada klon nipis ini secara keseluruhan. Dan ini, sudah tentu, adalah buruk, kerana kita mahu mempunyai lebih banyak daripada mereka.

Tetapi sebaliknya, Buffer Cache digunakan untuk melaksanakan pertanyaan untuk indeks, iaitu, pelan bergantung pada seberapa besar cache kami. Dan jika kita hanya mengambil parameter ini dan mengurangkannya, maka rancangan kita boleh berubah banyak.

Sebagai contoh, jika kita mempunyai cache yang besar pada prod, maka Postgres akan memilih untuk menggunakan indeks. Dan jika tidak, maka akan ada SeqScan. Dan apa gunanya jika rancangan kita tidak bertepatan?

Tetapi di sini kita sampai pada kesimpulan bahawa sebenarnya pelan dalam Postgres tidak bergantung pada saiz khusus yang dinyatakan dalam Penampan Dikongsi dalam pelan, ia bergantung pada effective_cache_size.

Effective_cache_size ialah anggaran jumlah cache yang tersedia kepada kami, iaitu jumlah Cache Penampan dan cache sistem fail. Ini ditetapkan oleh konfigurasi. Dan ingatan ini tidak diperuntukkan.

Dan disebabkan parameter ini, kami boleh menipu Postgres, dengan mengatakan bahawa kami sebenarnya mempunyai banyak data yang tersedia, walaupun kami tidak mempunyai data ini. Dan dengan itu, rancangan itu akan sepenuhnya bertepatan dengan pengeluaran.

Tetapi ini boleh menjejaskan masa. Dan kami mengoptimumkan pertanyaan mengikut masa, tetapi adalah penting bahawa masa bergantung pada banyak faktor:

• Ia bergantung kepada beban yang sedang di prod.

• Ia bergantung kepada ciri-ciri mesin itu sendiri.

Dan ini adalah parameter tidak langsung, tetapi sebenarnya kita boleh mengoptimumkan dengan tepat dengan jumlah data yang akan dibaca oleh pertanyaan ini untuk mendapatkan hasilnya.

Dan jika anda mahu masa yang hampir dengan apa yang akan kita lihat dalam prod, maka kita perlu mengambil perkakasan yang paling serupa dan, mungkin, lebih-lebih lagi supaya semua klon sesuai. Tetapi ini adalah kompromi, iaitu anda akan mendapat rancangan yang sama, anda akan melihat berapa banyak data yang akan dibaca oleh pertanyaan tertentu dan anda akan dapat membuat kesimpulan sama ada pertanyaan ini baik (atau migrasi) atau buruk, ia masih perlu dioptimumkan .

Mari kita lihat cara Joe dioptimumkan secara khusus.

Mari kita ambil permintaan daripada sistem sebenar. Dalam kes ini, pangkalan data ialah 1 terabait. Dan kami mahu mengira bilangan siaran baharu yang mempunyai lebih daripada 10 suka.

Kami sedang menulis mesej kepada saluran, klon telah digunakan untuk kami. Dan kami akan melihat bahawa permintaan sedemikian akan selesai dalam masa 2,5 minit. Ini adalah perkara pertama yang kita perhatikan.

B Joe akan menunjukkan kepada anda pengesyoran automatik berdasarkan pelan dan metrik.

Kami akan melihat bahawa pertanyaan memproses terlalu banyak data untuk mendapatkan bilangan baris yang agak kecil. Dan beberapa jenis indeks khusus diperlukan, kerana kami mendapati terdapat terlalu banyak baris yang ditapis dalam pertanyaan.

Mari kita lihat lebih dekat apa yang berlaku. Sesungguhnya, kami melihat bahawa kami telah membaca hampir satu setengah gigabait data dari cache fail atau bahkan dari cakera. Dan ini tidak bagus, kerana kami hanya mendapat 142 baris.

Dan, nampaknya, kami mempunyai imbasan indeks di sini dan sepatutnya berjaya dengan cepat, tetapi memandangkan kami menapis terlalu banyak baris (kami terpaksa mengiranya), permintaan itu perlahan-lahan berjaya.

Dan ini berlaku dalam rancangan kerana keadaan dalam pertanyaan dan syarat dalam indeks sebahagiannya tidak sepadan.

Mari cuba jadikan indeks lebih tepat dan lihat bagaimana pelaksanaan pertanyaan berubah selepas itu.

Penciptaan indeks mengambil masa yang agak lama, tetapi kini kami menyemak pertanyaan dan melihat bahawa masa bukannya 2,5 minit hanyalah 156 milisaat, yang cukup baik. Dan kami hanya membaca 6 megabait data.

Dan kini kami menggunakan imbasan indeks sahaja.

Satu lagi kisah penting ialah kami ingin membentangkan rancangan itu dengan cara yang lebih mudah difahami. Kami telah melaksanakan visualisasi menggunakan Graf Api.

Ini adalah permintaan yang berbeza, lebih sengit. Dan kami membina Graf Nyala mengikut dua parameter: ini ialah jumlah data yang dikira oleh nod tertentu dalam pelan dan pemasaan, iaitu masa pelaksanaan nod.

Di sini kita boleh membandingkan nod tertentu antara satu sama lain. Dan ia akan menjadi jelas yang mana antara mereka mengambil lebih atau kurang, yang biasanya sukar dilakukan dalam kaedah pemaparan lain.

Sudah tentu, semua orang tahu explain.depesz.com. Ciri yang baik bagi visualisasi ini ialah kami menyimpan pelan teks dan juga meletakkan beberapa parameter asas ke dalam jadual supaya kami boleh mengisih.

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

Terdapat pendekatan baharu untuk visualisasi - ini adalah explain.dalibo.com. Mereka melakukan visualisasi pokok, tetapi sangat sukar untuk membandingkan nod antara satu sama lain. Di sini anda boleh memahami struktur dengan baik, bagaimanapun, jika terdapat permintaan yang besar, maka anda perlu menatal ke depan dan ke belakang, tetapi juga pilihan.

kerjasama

Dan, seperti yang saya katakan, Slack memberi kami peluang untuk bekerjasama. Sebagai contoh, jika kami menemui pertanyaan kompleks yang tidak jelas cara mengoptimumkan, kami boleh menjelaskan isu ini dengan rakan sekerja kami dalam urutan dalam Slack.

Nampaknya kepada kami adalah penting untuk menguji data bersaiz penuh. Untuk melakukan ini, kami membuat alat Makmal Pangkalan Data Kemas Kini, yang tersedia dalam sumber terbuka. Anda juga boleh menggunakan bot Joe. Anda boleh mengambilnya sekarang dan melaksanakannya di tempat anda. Semua panduan ada di sana.

Ia juga penting untuk ambil perhatian bahawa penyelesaian itu sendiri tidak revolusioner, kerana terdapat Delphix, tetapi ia adalah penyelesaian perusahaan. Ia ditutup sepenuhnya, ia sangat mahal. Kami khusus pakar dalam Postgres. Ini semua adalah produk sumber terbuka. Sertai kami!

Di sinilah saya berakhir. Terima kasih!

soalan

hello! Terima kasih atas laporan itu! Sangat menarik, terutamanya kepada saya, kerana saya telah menyelesaikan masalah yang sama suatu ketika dahulu. Jadi saya mempunyai beberapa soalan. Mudah-mudahan saya akan mendapat sekurang-kurangnya sebahagian daripadanya.

Saya tertanya-tanya bagaimana anda mengira tempat untuk persekitaran ini? Teknologi ini bermaksud bahawa dalam keadaan tertentu, klon anda boleh membesar ke saiz maksimum. Secara kasarnya, jika anda mempunyai pangkalan data sepuluh terabait dan 10 klon, maka mudah untuk mensimulasikan situasi di mana setiap klon mempunyai berat 10 data unik. Bagaimanakah anda mengira tempat ini, iaitu delta yang anda perkatakan, di mana klon ini akan hidup?

Soalan yang baik. Adalah penting untuk menjejaki klon tertentu di sini. Dan jika klon mempunyai perubahan yang terlalu besar, ia mula berkembang, maka kita boleh mula-mula mengeluarkan amaran kepada pengguna tentang perkara ini, atau segera menghentikan klon ini supaya kita tidak mengalami situasi gagal.

Ya, saya ada soalan bersarang. Iaitu, bagaimana anda memastikan kitaran hayat modul ini? Kami mempunyai masalah ini dan cerita yang berasingan. Bagaimana ini berlaku?

Terdapat beberapa ttl untuk setiap klon. Pada asasnya, kami mempunyai ttl tetap.

Bagaimana, jika bukan rahsia?

1 jam, iaitu melahu - 1 jam. Jika tidak digunakan, barulah kita hentam. Tetapi tidak ada kejutan di sini, kerana kita boleh menaikkan klon dalam beberapa saat. Dan jika anda memerlukannya lagi, silakan.

Saya juga berminat dengan pilihan teknologi, kerana, sebagai contoh, kami menggunakan beberapa kaedah secara selari untuk satu sebab atau yang lain. Mengapa ZFS? Mengapa anda tidak menggunakan LVM? Anda menyebut bahawa terdapat masalah dengan LVM. Apakah masalahnya? Pada pendapat saya, pilihan yang paling optimum adalah dengan penyimpanan, dari segi prestasi.

Apakah masalah utama dengan ZFS? Hakikat bahawa anda mesti dijalankan pada hos yang sama, iaitu semua keadaan akan hidup dalam OS yang sama. Dan dalam kes penyimpanan, anda boleh menyambungkan peralatan yang berbeza. Dan kesesakan hanyalah blok yang terdapat pada sistem storan. Dan persoalan pemilihan teknologi adalah menarik. Mengapa tidak LVM?

Secara khusus, kita boleh membincangkan LVM semasa pertemuan. Mengenai penyimpanan - ia hanya mahal. Kami boleh melaksanakan sistem ZFS di mana-mana sahaja. Anda boleh menggunakan ia pada mesin anda. Anda hanya boleh memuat turun repositori dan gunakannya. ZFS dipasang hampir di mana-mana jika kita bercakap tentang Linux. Iaitu, kami mendapat penyelesaian yang sangat fleksibel. Dan ZFS sendiri memberikan banyak perkara di luar kotak. Anda boleh memuat naik seberapa banyak data yang anda suka, sambungkan sejumlah besar cakera, terdapat syot kilat. Dan, seperti yang saya katakan, ia mudah untuk ditadbir. Iaitu, ia kelihatan sangat menyenangkan untuk digunakan. Dia diuji, dia berumur bertahun-tahun. Dia mempunyai komuniti yang sangat besar yang sedang berkembang. ZFS ialah penyelesaian yang sangat boleh dipercayai.

Nikolai Samokhvalov: Bolehkah saya mengulas lanjut? Nama saya Nikolay, kami bekerjasama dengan Anatoly. Saya bersetuju bahawa storan adalah hebat. Dan sesetengah pelanggan kami mempunyai Storan Tulen dsb.

Anatoly betul menyatakan bahawa kami memberi tumpuan kepada modulariti. Dan pada masa hadapan, anda boleh melaksanakan satu antara muka - ambil gambar, buat klon, musnahkan klon. Semuanya mudah. Dan penyimpanan adalah sejuk, jika ada.

Tetapi ZFS tersedia untuk semua orang. DelPhix sudah cukup, mereka mempunyai 300 pelanggan. Daripada jumlah ini, fortune 100 mempunyai 50 pelanggan, iaitu mereka ditujukan kepada NASA, dll. Sudah tiba masanya untuk semua orang mendapatkan teknologi ini. Dan itulah sebabnya kami mempunyai Teras sumber terbuka. Kami mempunyai bahagian antara muka yang bukan sumber terbuka. Inilah platform yang akan kami tunjukkan. Tetapi kami mahu ia boleh diakses oleh semua orang. Kami mahu membuat revolusi supaya semua penguji berhenti meneka pada komputer riba. Kita perlu menulis SELECT dan segera melihat bahawa ia perlahan. Berhenti menunggu DBA memberitahu anda mengenainya. Berikut adalah matlamat utama. Dan saya fikir kita semua akan datang ke sini. Dan kami membuat perkara ini untuk dimiliki oleh semua orang. Oleh itu ZFS, kerana ia akan tersedia di mana-mana. Terima kasih kepada komuniti kerana menyelesaikan masalah dan mempunyai lesen sumber terbuka, dsb.*

salam sejahtera! Terima kasih atas laporan itu! Nama saya Maxim. Kami telah menangani isu yang sama. Mereka membuat keputusan sendiri. Bagaimanakah anda berkongsi sumber antara klon ini? Setiap klon boleh melakukan perkaranya sendiri pada bila-bila masa: satu menguji satu perkara, satu lagi yang lain, seseorang membina indeks, seseorang mempunyai pekerjaan yang berat. Dan jika anda masih boleh membahagi dengan CPU, maka dengan IO, bagaimana anda membahagikan? Ini adalah soalan pertama.

Dan persoalan kedua ialah tentang perbezaan pendirian. Katakan saya mempunyai ZFS di sini dan semuanya sejuk, tetapi pelanggan pada prod tidak mempunyai ZFS, tetapi ext4, sebagai contoh. Bagaimana dalam kes ini?

Soalannya sangat bagus. Saya menyebut masalah ini sedikit dengan fakta bahawa kita berkongsi sumber. Dan penyelesaiannya adalah ini. Bayangkan anda sedang menguji pementasan. Anda juga boleh mengalami situasi sedemikian pada masa yang sama bahawa seseorang memberi satu beban, orang lain. Dan akibatnya, anda melihat metrik yang tidak dapat difahami. Malah masalah yang sama boleh berlaku dengan prod. Apabila anda ingin menyemak beberapa permintaan dan melihat bahawa terdapat beberapa masalah dengannya - ia berfungsi dengan perlahan, maka sebenarnya masalahnya bukan dalam permintaan itu, tetapi pada hakikatnya terdapat beberapa jenis beban selari.

Oleh itu, adalah penting di sini untuk memberi tumpuan kepada rancangan itu, apakah langkah yang akan kami ambil dalam rancangan itu dan berapa banyak data yang akan kami kumpulkan untuk ini. Fakta bahawa cakera kami, sebagai contoh, akan dimuatkan dengan sesuatu, ia secara khusus akan menjejaskan masa. Tetapi kami boleh menganggarkan sejauh mana permintaan ini dimuatkan dengan jumlah data. Ia tidak begitu penting bahawa pada masa yang sama akan ada beberapa jenis pelaksanaan.

Saya ada dua soalan. Ini adalah perkara yang sangat keren. Adakah terdapat kes di mana data pengeluaran adalah kritikal, seperti nombor kad kredit? Adakah sudah ada sesuatu yang sedia atau adakah ia tugas yang berasingan? Dan soalan kedua - adakah terdapat sesuatu seperti ini untuk MySQL?

Mengenai data. Kami akan melakukan kekeliruan sehingga kami melakukannya. Tetapi jika anda menggunakan Joe tepat, jika anda tidak memberikan akses kepada pembangun, maka tiada akses kepada data. kenapa? Kerana Joe tidak menunjukkan data. Ia hanya menunjukkan metrik, rancangan dan itu sahaja. Ini dilakukan dengan sengaja, kerana ini adalah salah satu keperluan pelanggan kami. Mereka mahu dapat mengoptimumkan tanpa memberi semua orang akses.

Mengenai MySQL. Sistem ini boleh digunakan untuk apa sahaja yang menyimpan keadaan pada cakera. Dan kerana kami melakukan Postgres, kami kini melakukan semua automasi untuk Postgres terlebih dahulu. Kami mahu mengautomasikan mendapatkan data daripada sandaran. Kami sedang mengkonfigurasi Postgres dengan betul. Kami tahu cara membuat rancangan sepadan, dsb.

Tetapi kerana sistem ini boleh diperluaskan, ia juga boleh digunakan untuk MySQL. Dan terdapat contoh sedemikian. Yandex mempunyai perkara yang serupa, tetapi mereka tidak menerbitkannya di mana-mana. Mereka menggunakannya di dalam Yandex.Metrica. Dan hanya ada cerita tentang MySQL. Tetapi teknologinya sama, ZFS.

Terima kasih atas laporan itu! Saya juga mempunyai beberapa soalan. Anda menyebut bahawa pengklonan boleh digunakan untuk analisis, contohnya untuk membina indeks tambahan di sana. Bolehkah anda memberitahu sedikit lagi tentang cara ia berfungsi?

Dan saya akan segera bertanya soalan kedua tentang persamaan pendirian, persamaan rancangan. Pelan ini juga bergantung pada statistik yang dikumpul oleh Postgres. Bagaimana anda menyelesaikan masalah ini?

Menurut analisis, tidak ada kes khusus, kerana kami belum menggunakannya lagi, tetapi ada peluang sedemikian. Jika kita bercakap tentang indeks, maka bayangkan bahawa pertanyaan sedang mengejar jadual dengan ratusan juta rekod dan lajur yang biasanya tidak diindeks dalam prod. Dan kami ingin mengira beberapa data di sana. Jika permintaan ini dihantar kepada prod, maka ada kemungkinan ia akan menjadi mudah pada prod, kerana permintaan akan diproses di sana selama satu minit.

Ok, mari kita buat klon nipis yang tidak mengerikan untuk berhenti selama beberapa minit. Dan untuk menjadikannya lebih selesa untuk membaca analitis, kami akan menambah indeks untuk lajur yang kami minati dengan data.

Indeks akan dibuat setiap kali?

Anda boleh membuatnya supaya kami menyentuh data, membuat syot kilat, kemudian kami akan pulih daripada syot kilat ini dan memacu permintaan baharu. Iaitu, anda boleh membuatnya supaya anda boleh menaikkan klon baharu dengan indeks yang telah dilekatkan.

Bagi soalan tentang statistik, jika kita memulihkan dari sandaran, jika kita melakukan replikasi, maka statistik kita akan sama. Kerana kami mempunyai keseluruhan struktur data fizikal, iaitu, kami akan membawa data seperti yang ada dengan semua metrik statistik juga.

Ini satu lagi masalah. Jika anda menggunakan penyelesaian awan, maka hanya pembuangan logik yang tersedia di sana, kerana Google, Amazon tidak membenarkan anda mengambil salinan fizikal. Akan ada masalah.

Terima kasih atas laporan itu. Terdapat dua soalan bagus di sini tentang MySQL dan perkongsian sumber. Tetapi, sebenarnya, semuanya datang kepada fakta bahawa ini bukan topik DBMS tertentu, tetapi sistem fail secara keseluruhan. Dan, oleh itu, isu perkongsian sumber juga harus diselesaikan dari sana, bukan pada akhirnya ia adalah Postgres, tetapi dalam sistem fail, dalam pelayan, misalnya.

Soalan saya sedikit berbeza. Ia lebih dekat dengan pangkalan data berbilang lapisan, di mana terdapat beberapa lapisan. Sebagai contoh, kami menyediakan kemas kini imej sepuluh terabait, kami sedang mereplikasi. Dan kami secara khusus menggunakan penyelesaian ini untuk pangkalan data. Replikasi sedang dijalankan, data sedang dikemas kini. Terdapat 100 pekerja yang bekerja selari di sini, yang sentiasa melancarkan tangkapan yang berbeza ini. Apa nak buat? Bagaimana untuk memastikan bahawa tidak ada konflik, bahawa mereka melancarkan satu, dan kemudian sistem fail berubah, dan gambar-gambar ini semua pergi?

Mereka tidak akan pergi kerana itulah cara ZFS berfungsi. Kita boleh menyimpan secara berasingan dalam satu utas perubahan sistem fail yang disebabkan oleh replikasi. Dan simpan klon yang digunakan oleh pembangun pada versi data yang lebih lama. Dan ia berfungsi untuk kami, semuanya teratur dengan ini.

Ternyata kemas kini akan berlaku sebagai lapisan tambahan, dan semua gambar baru akan pergi sudah, berdasarkan lapisan ini, bukan?

Dari lapisan sebelumnya yang berasal dari replikasi sebelumnya.

Lapisan sebelumnya akan jatuh, tetapi mereka akan merujuk kepada lapisan lama, dan adakah mereka akan mengambil imej baharu daripada lapisan terakhir yang diterima dalam kemas kini?

Secara umum, ya.

Kemudian sebagai akibatnya kita akan mempunyai sehingga satu ara lapisan. Dan lama kelamaan mereka perlu dimampatkan?

Ya semuanya betul. Terdapat beberapa tingkap. Kami menyimpan gambar mingguan. Ia bergantung kepada sumber yang anda ada. Jika anda mempunyai keupayaan untuk menyimpan banyak data, anda boleh menyimpan syot kilat untuk masa yang lama. Mereka tidak akan pergi sendiri. Tidak akan ada rasuah data. Jika syot kilat itu sudah lapuk, seperti yang dilihat oleh kami, iaitu ia bergantung pada dasar dalam syarikat, maka kami boleh memadamkannya dan mengosongkan ruang.

Hello, terima kasih atas laporan itu! Soal Joe. Anda berkata bahawa pelanggan tidak mahu memberikan semua orang akses kepada data. Tegasnya, jika seseorang mempunyai hasil Explain Analyze, maka dia boleh mengintip data.

memang macam tu. Sebagai contoh, kita boleh menulis: "SELECT FROM WHERE email = to that". Iaitu, kita tidak akan melihat data itu sendiri, tetapi kita boleh melihat beberapa tanda tidak langsung. Ini mesti difahami. Tetapi sebaliknya, semuanya ada. Kami mempunyai audit log, kami mempunyai kawalan ke atas rakan sekerja lain yang juga melihat apa yang dilakukan oleh pemaju. Dan jika seseorang cuba melakukan ini, maka perkhidmatan keselamatan akan datang kepada mereka dan menyelesaikan masalah ini.

Selamat petang Terima kasih atas laporan itu! Saya ada soalan ringkas. Jika syarikat tidak menggunakan Slack, adakah terdapat apa-apa yang mengikatnya sekarang, atau adakah mungkin bagi pembangun untuk menggunakan contoh untuk menyambungkan aplikasi ujian ke pangkalan data?

Kini terdapat pautan ke Slack, iaitu tiada messenger lain, tetapi saya benar-benar ingin membuat sokongan untuk messenger lain juga. Apa yang kau boleh buat? Anda boleh menggunakan DB Lab tanpa Joe, pergi dengan bantuan REST API atau dengan bantuan platform kami dan buat klon dan berhubung dengan PSQL. Tetapi ini boleh dilakukan jika anda bersedia untuk memberikan pembangun anda akses kepada data, kerana tidak akan ada lagi skrin.

Saya tidak memerlukan lapisan ini, tetapi saya memerlukan peluang sedemikian.

Kemudian ya, ia boleh dilakukan.

Sumber: www.habr.com