Di masa depan yang jauh, penghapusan otomatis data yang tidak perlu akan menjadi salah satu tugas penting DBMS [1]. Sementara itu, kami sendiri perlu berhati-hati dalam menghapus atau memindahkan data yang tidak perlu ke sistem penyimpanan yang lebih murah. Katakanlah Anda memutuskan untuk menghapus beberapa juta baris. Tugas yang cukup sederhana, terutama jika kondisinya diketahui dan ada indeks yang sesuai. "HAPUS DARI table1 WHERE col1 = :value" - apa yang bisa lebih sederhana, bukan?
Video:
-
Saya sudah menjadi panitia program Highload sejak tahun pertama, yaitu sejak tahun 2007.
-
Dan saya sudah bersama Postgres sejak 2005. Digunakan dalam banyak proyek.
-
Grup dengan RuPostges juga sejak 2007.
-
Kami telah berkembang menjadi 2100+ peserta di Meetup. Itu adalah yang kedua di dunia setelah New York, diambil alih oleh San Francisco untuk waktu yang lama.
-
Saya telah tinggal di California selama beberapa tahun. Saya lebih banyak berurusan dengan perusahaan Amerika, termasuk yang besar. Mereka adalah pengguna aktif Postgres. Dan ada berbagai macam hal yang menarik.
adalah perusahaan saya. Kami berada dalam bisnis mengotomatiskan tugas yang menghilangkan perlambatan pengembangan.
Jika Anda melakukan sesuatu, terkadang ada semacam colokan di sekitar Postgres. Katakanlah Anda harus menunggu admin menyiapkan dudukan pengujian untuk Anda, atau Anda harus menunggu DBA merespons Anda. Dan kami menemukan kemacetan seperti itu dalam proses pengembangan, pengujian, dan administrasi dan mencoba menghilangkannya dengan bantuan otomatisasi dan pendekatan baru.
Saya baru-baru ini berada di VLDB di Los Angeles. Ini adalah konferensi database terbesar. Dan ada laporan bahwa di masa mendatang DBMS tidak hanya menyimpan, tetapi juga menghapus data secara otomatis. Ini adalah topik baru.
Ada semakin banyak data di dunia zettabytes - yaitu 1 petabyte. Dan sekarang diperkirakan kita memiliki lebih dari 000 zettabytes data yang disimpan di dunia. Dan jumlahnya semakin banyak.
Dan apa yang harus dilakukan dengan itu? Jelas itu perlu dihilangkan. Berikut tautan ke laporan menarik ini. Namun sejauh ini belum diimplementasikan di DBMS.
Mereka yang bisa menghitung uang menginginkan dua hal. Mereka ingin kami menghapusnya, jadi secara teknis kami harus bisa melakukannya.
Apa yang akan saya ceritakan selanjutnya adalah beberapa situasi abstrak yang mencakup sekumpulan situasi nyata, yaitu semacam kompilasi dari apa yang sebenarnya terjadi pada saya dan database di sekitarnya berkali-kali, bertahun-tahun. Garu ada di mana-mana dan semua orang menginjaknya sepanjang waktu.
Katakanlah kita memiliki basis atau beberapa basis yang sedang tumbuh. Dan beberapa catatan jelas sampah. Misalnya, pengguna mulai melakukan sesuatu di sana, tetapi tidak menyelesaikannya. Dan setelah beberapa waktu kami tahu bahwa yang belum selesai ini tidak dapat disimpan lagi. Artinya, kami ingin membersihkan beberapa sampah untuk menghemat ruang, meningkatkan kinerja, dll.
Secara umum, tugasnya adalah mengotomatiskan penghapusan hal-hal tertentu, baris tertentu di beberapa tabel.
Dan kami memiliki permintaan seperti itu, yang akan kami bicarakan hari ini, yaitu tentang pembuangan sampah.
Kami meminta pengembang berpengalaman untuk melakukannya. Dia menerima permintaan ini, memeriksanya sendiri - semuanya berfungsi. Diuji pada pementasan - semuanya baik-baik saja. Diluncurkan - semuanya bekerja. Sekali sehari kami menjalankannya - semuanya baik-baik saja.
Basis data tumbuh dan berkembang. DELETE harian mulai bekerja sedikit lebih lambat.
Kemudian kami memahami bahwa kami sekarang memiliki perusahaan pemasaran dan lalu lintas akan menjadi beberapa kali lebih besar, jadi kami memutuskan untuk menghentikan sementara hal-hal yang tidak perlu. Dan lupa untuk kembali.
Beberapa bulan kemudian mereka ingat. Dan pengembang itu berhenti atau sibuk dengan hal lain, menginstruksikan yang lain untuk mengembalikannya.
Dia memeriksa dev, pada pementasan - semuanya baik-baik saja. Secara alami, Anda masih perlu membersihkan apa yang menumpuk. Dia memeriksa semuanya bekerja.
Apa yang terjadi selanjutnya? Kemudian semuanya berantakan bagi kita. Itu turun sehingga pada titik tertentu semuanya jatuh. Semua orang kaget, tidak ada yang mengerti apa yang sedang terjadi. Dan ternyata masalahnya ada di HAPUS ini.
Ada yang salah? Berikut adalah daftar kesalahan yang mungkin terjadi. Manakah dari ini yang paling penting?
-
Misalnya tidak ada review, yaitu pakar DBA tidak melihatnya. Dia akan segera menemukan masalah dengan mata yang berpengalaman, dan selain itu, dia memiliki akses ke prod, di mana beberapa juta baris telah terkumpul.
-
Mungkin mereka memeriksa sesuatu yang salah.
-
Mungkin perangkat kerasnya sudah usang dan Anda perlu memutakhirkan pangkalan ini.
-
Atau ada yang salah dengan database itu sendiri, dan kita perlu berpindah dari Postgres ke MySQL.
-
Atau mungkin ada yang salah dengan operasinya.
-
Mungkin ada beberapa kesalahan dalam mengatur pekerjaan dan Anda perlu memecat seseorang dan mempekerjakan orang terbaik?
Tidak ada pemeriksaan DBA. Jika ada DBA, dia akan melihat beberapa juta baris ini dan bahkan tanpa eksperimen apa pun akan berkata: "Mereka tidak melakukannya." Misalkan jika kode ini ada di GitLab, GitHub dan akan ada proses peninjauan kode dan tidak ada yang tanpa persetujuan DBA operasi ini akan dilakukan pada prod, maka jelas DBA akan berkata: βIni tidak dapat dilakukan .β
Dan dia akan mengatakan bahwa Anda akan memiliki masalah dengan disk IO dan semua proses akan menjadi gila, mungkin ada kunci, dan Anda juga akan memblokir autovacuum selama beberapa menit, jadi ini tidak baik.
Kesalahan kedua - mereka memeriksa di tempat yang salah. Kami melihat setelah fakta bahwa banyak data sampah terakumulasi pada prod, tetapi pengembang tidak mengumpulkan data dalam database ini, dan tidak ada yang membuat sampah ini selama pementasan. Karenanya, ada 1 baris yang berhasil dengan cepat.
Kami memahami bahwa pengujian kami lemah, yaitu proses yang dibangun tidak menangkap masalah. Eksperimen DB yang memadai tidak dilakukan.
Eksperimen yang ideal lebih disukai dilakukan pada peralatan yang sama. Tidak selalu mungkin untuk melakukan ini pada peralatan yang sama, tetapi sangat penting bahwa ini adalah salinan database ukuran penuh. Inilah yang telah saya khotbahkan selama beberapa tahun sekarang. Dan setahun yang lalu saya membicarakan hal ini, Anda dapat menonton semuanya di YouTube.
Mungkin peralatan kita buruk? Jika Anda perhatikan, latensi melonjak. Kami telah melihat bahwa pemanfaatannya adalah 100%. Tentu saja, jika ini adalah drive NVMe modern, mungkin akan jauh lebih mudah bagi kami. Dan mungkin kita tidak akan menyerah karenanya.
Jika Anda memiliki cloud, maka pemutakhiran mudah dilakukan di sana. Mengangkat replika baru pada perangkat keras baru. pindah. Dan semuanya baik-baik saja. Sangat mudah.
Apakah mungkin untuk menyentuh disk yang lebih kecil? Dan di sini, hanya dengan bantuan DBA, kami menyelami topik tertentu yang disebut penyetelan pos pemeriksaan. Ternyata kami tidak memiliki penyetelan pos pemeriksaan.
Apa itu pos pemeriksaan? Itu ada di DBMS apa pun. Ketika Anda memiliki data dalam memori yang berubah, itu tidak segera ditulis ke disk. Informasi bahwa data telah berubah pertama kali ditulis ke log tulis-depan. Dan pada titik tertentu, DBMS memutuskan bahwa sudah waktunya untuk membuang halaman asli ke disk, sehingga jika kita mengalami kegagalan, kita dapat melakukan lebih sedikit REDO. Ini seperti mainan. Jika kita terbunuh, kita akan memulai permainan dari pos pemeriksaan terakhir. Dan semua DBMS mengimplementasikannya.
Pengaturan di Postgres tertinggal. Mereka dirancang untuk volume data dan transaksi berusia 10-15 tahun. Dan pos pemeriksaan tidak terkecuali.
Berikut adalah informasi dari laporan pemeriksaan Postgres kami, yaitu pemeriksaan kesehatan otomatis. Dan ini beberapa database beberapa terabyte. Dan dapat dilihat dengan baik bahwa pos pemeriksaan paksa di hampir 90% kasus.
Apa artinya? Ada dua pengaturan di sana. Checkpoint bisa datang dengan timeout, misalnya dalam 10 menit. Atau mungkin datang ketika data yang diisi cukup banyak.
Dan secara default max_wal_saze diatur ke 1 gigabyte. Nyatanya, ini benar-benar terjadi di Postgres setelah 300-400 megabita. Anda telah mengubah begitu banyak data dan pos pemeriksaan Anda terjadi.
Dan jika tidak ada yang menyetelnya, dan layanan berkembang, dan perusahaan menghasilkan banyak uang, memiliki banyak transaksi, maka pos pemeriksaan datang satu menit sekali, terkadang setiap 30 detik, dan terkadang bahkan tumpang tindih. Ini cukup buruk.
Dan kita perlu memastikan bahwa itu datang lebih jarang. Artinya, kita bisa menaikkan max_wal_size. Dan itu akan datang lebih jarang.
Tetapi kami telah mengembangkan keseluruhan metodologi tentang bagaimana melakukannya dengan lebih benar, yaitu bagaimana membuat keputusan tentang memilih pengaturan, jelas berdasarkan data tertentu.
Karenanya, kami melakukan dua rangkaian percobaan pada basis data.
Seri pertama - kami mengubah max_wal_size. Dan kami sedang melakukan operasi besar-besaran. Pertama, kami melakukannya pada pengaturan default 1 gigabyte. Dan kami melakukan DELETE besar-besaran jutaan baris.
Anda dapat melihat betapa sulitnya bagi kami. Kami melihat bahwa disk IO sangat buruk. Kami melihat berapa banyak WAL yang telah kami hasilkan, karena ini sangat penting. Mari kita lihat berapa kali pos pemeriksaan terjadi. Dan kami melihat bahwa itu tidak baik.
Selanjutnya kita tingkatkan max_wal_size. Kami mengulangi. Kami meningkat, kami ulangi. Dan berkali-kali. Pada prinsipnya, 10 poin bagus, di mana 1, 2, 4, 8 gigabyte. Dan kami melihat perilaku sistem tertentu. Jelas di sini perlengkapannya harus seperti di prod. Anda harus memiliki disk yang sama, jumlah memori yang sama, dan pengaturan Postgres yang sama.
Dan dengan cara ini kami akan menukar sistem kami, dan kami tahu bagaimana DBMS akan berperilaku jika terjadi DELETE massal yang buruk, bagaimana pos pemeriksaannya.
Pos pemeriksaan dalam bahasa Rusia adalah pos pemeriksaan.
Contoh: HAPUS beberapa juta baris berdasarkan indeks, baris "tersebar" di seluruh halaman.
Ini sebuah contoh. Ini adalah beberapa dasar. Dan dengan pengaturan default 1 gigabyte untuk max_wal_size, sangat jelas bahwa disk kami masuk ke rak untuk merekam. Gambaran ini adalah gejala khas dari pasien yang sangat sakit, yaitu dia benar-benar merasa tidak enak. Dan ada satu operasi, hanya ada DELETE dari beberapa juta baris.
Jika operasi seperti itu diizinkan di prod, maka kami hanya akan berbaring, karena jelas satu DELETE membunuh kami di rak.
Selanjutnya, di mana 16 gigabyte, jelas giginya sudah hilang. Gigi sudah lebih baik, yaitu kita mengetuk langit-langit, tapi tidak terlalu buruk. Ada sedikit kebebasan di sana. Di sebelah kanan adalah catatannya. Dan jumlah operasi - grafik kedua. Dan jelas bahwa kami sudah bernafas sedikit lebih mudah ketika 16 gigabytes.
Dan di mana 64 gigabyte dapat dilihat bahwa itu menjadi lebih baik. Gigi sudah diucapkan, ada lebih banyak peluang untuk bertahan dari operasi lain dan melakukan sesuatu dengan disk.
Mengapa begitu?
Saya akan sedikit menyelami detailnya, tetapi topik ini, bagaimana melakukan penyetelan pos pemeriksaan, dapat menghasilkan laporan yang lengkap, jadi saya tidak akan memuat banyak, tetapi saya akan menguraikan sedikit kesulitan apa yang ada.
Jika pos pemeriksaan terjadi terlalu sering, dan kami memperbarui baris kami tidak secara berurutan, tetapi menemukan berdasarkan indeks, yang bagus, karena kami tidak menghapus seluruh tabel, maka mungkin saja kami menyentuh halaman pertama, lalu halaman pertama yang keseribu, dan kemudian kembali ke yang pertama. Dan jika di antara kunjungan ini ke halaman pertama, pos pemeriksaan telah menyimpannya ke disk, maka itu akan menyimpannya lagi, karena kami mengotorinya untuk kedua kalinya.
Dan kami akan memaksa pos pemeriksaan untuk menyimpannya berkali-kali. Bagaimana akan ada operasi yang berlebihan untuknya.
Tapi itu belum semuanya. Halaman berukuran 8 kilobyte di Postgres dan 4 kilobyte di Linux. Dan ada pengaturan full_page_writes. Ini diaktifkan secara default. Dan ini benar, karena jika kita mematikannya, maka ada bahaya hanya separuh halaman yang akan disimpan jika macet.
Perilaku menulis ke WAL dari log penerusan sedemikian rupa sehingga ketika kami memiliki pos pemeriksaan dan kami mengubah halaman untuk pertama kalinya, seluruh halaman, yaitu, semua 8 kilobyte, masuk ke log penerusan, meskipun kami hanya mengubah baris, yang beratnya 100 byte . Dan kita harus menuliskan seluruh halaman.
Pada perubahan selanjutnya, hanya akan ada tuple tertentu, tetapi untuk pertama kalinya kami menuliskan semuanya.
Dan, karenanya, jika pos pemeriksaan terjadi lagi, maka kita harus memulai semuanya dari awal lagi dan mendorong seluruh halaman. Dengan pos pemeriksaan yang sering, saat kita menelusuri halaman yang sama, full_page_writes = on akan lebih dari yang seharusnya, yaitu kita menghasilkan lebih banyak WAL. Lebih banyak dikirim ke replika, ke arsip, ke disk.
Dan, karenanya, kami memiliki dua redudansi.
Jika kita meningkatkan max_wal_size, ternyata kita membuatnya lebih mudah baik untuk checkpoint maupun wal writer. Dan itu bagus.
Mari masukkan terabyte dan jalani saja. Apa yang buruk tentang itu? Ini buruk, karena jika terjadi kegagalan, kami akan mendaki berjam-jam, karena pos pemeriksaan sudah lama sekali dan banyak yang sudah berubah. Dan kita perlu melakukan semua REDO ini. Jadi kami melakukan percobaan seri kedua.
Kami melakukan operasi dan melihat kapan pos pemeriksaan akan selesai, kami sengaja membunuh -9 Postgres.
Dan setelah itu kita mulai lagi, dan lihat berapa lama itu akan meningkat pada peralatan ini, yaitu berapa banyak yang akan REDO dalam situasi buruk ini.
Dua kali saya perhatikan bahwa situasinya buruk. Pertama, kami jatuh tepat sebelum pos pemeriksaan selesai, jadi kami harus kehilangan banyak hal. Dan kedua, kami melakukan operasi besar-besaran. Dan jika pos pemeriksaan berada pada batas waktu, kemungkinan besar, lebih sedikit WAL yang dihasilkan sejak pos pemeriksaan terakhir. Artinya, itu adalah pecundang ganda.
Kami mengukur situasi seperti itu untuk ukuran max_wal_size yang berbeda dan memahami bahwa jika max_wal_size adalah 64 gigabyte, maka dalam kasus terburuk ganda kami akan mendaki selama 10 menit. Dan kami berpikir apakah itu cocok untuk kami atau tidak. Ini pertanyaan bisnis. Kita perlu menunjukkan gambar ini kepada mereka yang bertanggung jawab atas keputusan bisnis dan bertanya, βBerapa lama kita bisa berbaring jika ada masalah? Bisakah kita berbaring dalam situasi terburuk selama 3-5 menit? Dan Anda membuat keputusan.
Dan inilah poin yang menarik. Kami memiliki beberapa laporan tentang Patroni di konferensi. Dan mungkin Anda menggunakannya. Ini adalah autofailover untuk Postgres. GitLab dan Data Egret membicarakan hal ini.
Dan jika Anda memiliki autofailover yang muncul dalam 30 detik, mungkin kita bisa berbaring selama 10 menit? Karena kita akan beralih ke replika saat ini, dan semuanya akan baik-baik saja. Ini adalah titik diperdebatkan. Saya tidak tahu jawaban yang jelas. Saya hanya merasa bahwa topik ini tidak hanya seputar pemulihan kerusakan.
Jika kita memiliki pemulihan yang lama setelah kegagalan, maka kita akan merasa tidak nyaman dalam banyak situasi lainnya. Misalnya, dalam percobaan yang sama, ketika kita melakukan sesuatu dan terkadang harus menunggu selama 10 menit.
Saya masih tidak akan melangkah terlalu jauh, bahkan jika kita memiliki autofailover. Biasanya, nilai seperti 64, 100 gigabyte adalah nilai yang baik. Kadang-kadang bahkan ada baiknya memilih lebih sedikit. Secara umum, ini adalah ilmu yang halus.
Untuk melakukan iterasi, misalnya max_wal_size =1, 8, Anda perlu mengulang operasi massal berkali-kali. Kau berhasil. Dan atas dasar yang sama Anda ingin melakukannya lagi, tetapi Anda telah menghapus semuanya. Apa yang harus dilakukan?
Saya akan berbicara nanti tentang solusi kami, apa yang kami lakukan untuk mengulang dalam situasi seperti itu. Dan ini adalah pendekatan yang paling benar.
Tetapi dalam hal ini, kami beruntung. Jika, seperti yang tertulis di sini "BEGIN, DELETE, ROLLBACK", maka kita dapat mengulangi DELETE. Artinya, jika kita membatalkannya sendiri, maka kita bisa mengulanginya. Dan secara fisik pada Anda data akan berada di tempat yang sama. Anda bahkan tidak kembung. Anda dapat mengulangi DELETE tersebut.
HAPUS dengan ROLLBACK ini sangat ideal untuk penyetelan pos pemeriksaan, bahkan jika Anda tidak memiliki laboratorium basis data yang diterapkan dengan benar.
Kami membuat piring dengan satu kolom "i". Postgres memiliki kolom utilitas. Mereka tidak terlihat kecuali diminta secara khusus. Ini adalah: ctid, xmid, xmax.
Ctid adalah alamat fisik. Halaman nol, tuple pertama di halaman.
Dapat dilihat bahwa setelah ROOLBACK tuple tetap berada di tempat yang sama. Artinya, kita bisa mencoba lagi, itu akan berperilaku sama. Ini adalah hal utama.
Xmax adalah waktu kematian tuple. Itu dicap, tetapi Postgres tahu bahwa transaksi dibatalkan, jadi tidak masalah apakah itu 0 atau transaksi dibatalkan. Ini menunjukkan bahwa dimungkinkan untuk mengulangi DELETE dan memeriksa operasi massal dari perilaku sistem. Anda dapat membuat laboratorium basis data untuk orang miskin.
Ini tentang programmer. Tentang DBA juga, mereka selalu memarahi programmer untuk ini: "Mengapa Anda melakukan operasi yang begitu lama dan sulit?". Ini adalah topik tegak lurus yang sama sekali berbeda. Dulu ada administrasi, dan sekarang akan ada pembangunan.
Jelas, kami tidak hancur berkeping-keping. Itu sudah jelas. Tidak mungkin untuk tidak memecah DELETE seperti itu untuk tumpukan jutaan baris menjadi beberapa bagian. Itu akan dilakukan selama 20 menit, dan semuanya akan berbaring. Namun, sayangnya, bahkan pengembang berpengalaman pun membuat kesalahan, bahkan di perusahaan yang sangat besar.
Mengapa penting untuk istirahat?
-
Jika kita melihat disknya keras, mari kita perlambat. Dan jika kita rusak, maka kita bisa menambahkan jeda, kita bisa memperlambat pelambatan.
-
Dan kami tidak akan memblokir orang lain untuk waktu yang lama. Dalam beberapa kasus, tidak masalah, jika Anda menghapus sampah asli yang tidak dikerjakan siapa pun, kemungkinan besar Anda tidak akan memblokir siapa pun kecuali pekerjaan autovacuum, karena akan menunggu transaksi selesai. Tetapi jika Anda menghapus sesuatu yang dapat diminta oleh orang lain, maka mereka akan diblokir, akan ada semacam reaksi berantai. Transaksi panjang harus dihindari di situs web dan aplikasi seluler.
Ini menarik. Saya sering melihat pengembang bertanya: "Ukuran paket apa yang harus saya pilih?".
Jelas bahwa semakin besar ukuran bundel, semakin kecil biaya transaksi, yaitu biaya tambahan dari transaksi. Tetapi pada saat yang sama, waktu transaksi ini bertambah.
Saya memiliki aturan yang sangat sederhana: ambil sebanyak yang Anda bisa, tetapi jangan melebihi executable per detik.
Kenapa sebentar? Penjelasannya sangat sederhana dan dapat dimengerti oleh semua orang, bahkan orang non-teknis. Kami melihat reaksi. Mari kita ambil 50 milidetik. Jika ada yang berubah, maka mata kita akan bereaksi. Jika kurang, maka lebih sulit. Jika sesuatu merespons setelah 100 milidetik, misalnya, Anda mengklik mouse, dan itu menjawab Anda setelah 100 milidetik, Anda sudah merasakan sedikit penundaan ini. Sedetik sudah dianggap sebagai rem.
Karenanya, jika kami memecah operasi massal kami menjadi semburan 10 detik, maka kami berisiko memblokir seseorang. Dan itu akan bekerja selama beberapa detik, dan orang akan menyadarinya. Oleh karena itu, saya memilih untuk tidak melakukan lebih dari satu detik. Tetapi pada saat yang sama, jangan memecahnya terlalu halus, karena overhead transaksi akan terlihat. Basis akan lebih sulit, dan masalah lain yang berbeda mungkin muncul.
Kami memilih ukuran paket. Dalam setiap kasus, kita dapat melakukannya secara berbeda. Bisa otomatis. Dan kami yakin akan efisiensi pemrosesan satu paket. Artinya, kami melakukan HAPUS satu paket atau PEMBARUAN.
Omong-omong, semua yang saya bicarakan bukan hanya tentang DELETE. Seperti yang Anda duga, ini adalah operasi massal pada data.
Dan kami melihat bahwa rencananya sangat bagus. Anda dapat melihat pemindaian indeks, pemindaian hanya indeks bahkan lebih baik. Dan kami memiliki sejumlah kecil data yang terlibat. Dan kurang dari satu detik terpenuhi. Super.
Dan kita masih perlu memastikan bahwa tidak ada degradasi. Kebetulan paket pertama berhasil dengan cepat, dan kemudian menjadi lebih buruk, lebih buruk dan lebih buruk. Prosesnya sedemikian rupa sehingga Anda perlu banyak menguji. Inilah gunanya laboratorium basis data.
Dan kami masih harus menyiapkan sesuatu agar memungkinkan kami mengikuti ini dengan benar dalam produksi. Misalnya, kita dapat menulis waktu di log, kita dapat menulis di mana kita sekarang dan siapa yang telah kita hapus. Dan ini akan memungkinkan kita untuk memahami apa yang terjadi nanti. Dan jika terjadi kesalahan, segera temukan masalahnya.
Jika kita perlu memeriksa efisiensi permintaan dan kita perlu mengulang berkali-kali, maka ada yang namanya sesama bot. Dia sudah siap. Ini digunakan oleh puluhan pengembang setiap hari. Dan dia tahu bagaimana memberikan database terabyte besar berdasarkan permintaan dalam 30 detik, salinan Anda sendiri. Dan Anda dapat menghapus sesuatu di sana dan mengatakan RESET, dan menghapusnya lagi. Anda dapat bereksperimen dengan cara ini. Saya melihat masa depan untuk hal ini. Dan kami sudah melakukannya.
Apa itu strategi partisi? Saya melihat 3 strategi pemartisian berbeda yang digunakan oleh pengembang pada paket.
Yang pertama sangat sederhana. Kami memiliki ID numerik. Dan mari kita pisahkan menjadi interval yang berbeda dan bekerja dengan itu. Kelemahannya jelas. Di segmen pertama, kita mungkin memiliki 100 baris sampah nyata, di 5 baris kedua atau tidak sama sekali, atau semua 1 baris akan berubah menjadi sampah. Pekerjaan yang sangat tidak merata, tetapi mudah patah. Mereka mengambil ID maksimum dan menghancurkannya. Ini adalah pendekatan yang naif.
Strategi kedua adalah pendekatan yang seimbang. Ini digunakan di Gitlab. Mereka mengambil dan memindai meja. Kami menemukan batasan paket ID sehingga setiap paket memiliki tepat 10 rekaman. Dan menempatkan mereka dalam antrian. Dan kemudian kami proses. Anda dapat melakukan ini di banyak utas.
Omong-omong, dalam strategi pertama, Anda dapat melakukan ini di beberapa utas. Tidak sulit.
Tapi ada pendekatan yang lebih keren dan lebih baik. Ini adalah strategi ketiga. Dan bila memungkinkan, lebih baik memilihnya. Kami melakukan ini berdasarkan indeks khusus. Dalam hal ini, kemungkinan besar akan menjadi indeks sesuai dengan kondisi dan ID sampah kita. Kami akan menyertakan ID sehingga hanya indeks yang memindai sehingga kami tidak pergi ke heap.
Secara umum, pemindaian hanya indeks lebih cepat daripada pemindaian indeks.
Dan kami dengan cepat menemukan ID kami yang ingin kami hapus. BATCH_SIZE kami pilih terlebih dahulu. Dan kami tidak hanya mendapatkannya, kami mendapatkannya dengan cara khusus dan segera meretasnya. Tapi kami mengunci agar jika sudah terkunci, kami tidak menguncinya, tetapi melanjutkan dan mengambil yang berikutnya. Ini untuk pembaruan lewati terkunci. Fitur super Postgres ini memungkinkan kita bekerja di beberapa utas jika kita mau. Itu mungkin dalam satu aliran. Dan di sini ada CTE - ini adalah satu permintaan. Dan kami memiliki penghapusan nyata yang terjadi di lantai dua CTE ini - returning *. Anda dapat mengembalikan id, tetapi lebih baik *jika Anda tidak memiliki banyak data di setiap baris.
Mengapa kita membutuhkannya? Ini yang perlu kami laporkan kembali. Kami sekarang telah menghapus begitu banyak baris sebenarnya. Dan kami memiliki batas berdasarkan ID atau dengan create_at seperti ini. Anda dapat melakukan min, max. Sesuatu yang lain bisa dilakukan. Anda dapat banyak hal di sini. Dan sangat nyaman untuk pemantauan.
Ada satu catatan lagi tentang index. Jika kami memutuskan bahwa kami memerlukan indeks khusus untuk tugas ini, maka kami perlu memastikan bahwa itu tidak merusak tumpukan hanya pembaruan tupel. Artinya, Postgres memiliki statistik seperti itu. Ini bisa dilihat di pg_stat_user_tables untuk tabel Anda. Anda dapat melihat apakah hot update sedang digunakan atau tidak.
Ada situasi ketika indeks baru Anda dapat dengan mudah memotongnya. Dan Anda memiliki semua pembaruan lain yang sudah berfungsi, perlambat. Bukan hanya karena indeks muncul (setiap indeks memperlambat pembaruan sedikit, tetapi sedikit), tetapi di sini masih merusaknya. Dan tidak mungkin membuat pengoptimalan khusus untuk tabel ini. Ini terkadang terjadi. Ini adalah kehalusan yang hanya sedikit orang yang ingat. Dan penggaruk ini mudah diinjak. Terkadang Anda perlu menemukan pendekatan dari sisi lain dan tetap melakukannya tanpa indeks baru ini, atau membuat indeks lain, atau dengan cara lain, misalnya, Anda dapat menggunakan metode kedua.
Tapi ini adalah strategi yang paling optimal, bagaimana membagi menjadi beberapa batch dan memotret batch dengan satu permintaan, menghapus sedikit, dll.
Transaksi panjang
Vakum otomatis yang diblokir -
masalah pemblokiran -
Kesalahan #5 adalah kesalahan besar. Nikolai dari Okmeter berbicara tentang pemantauan Postgres. Pemantauan Postgres yang ideal, sayangnya, tidak ada. Ada yang lebih dekat, ada yang lebih jauh. Okmeter hampir sempurna, tetapi banyak yang hilang dan perlu ditambahkan. Anda harus siap untuk ini.
Misalnya, tupel mati paling baik dipantau. Jika Anda memiliki banyak benda mati di meja, maka ada yang salah. Lebih baik bereaksi sekarang, kalau tidak mungkin ada degradasi, dan kita bisa berbaring. Itu terjadi.
Jika ada IO besar, maka jelas itu tidak baik.
Transaksi lama juga. Transaksi panjang seharusnya tidak diizinkan di OLTP. Dan berikut ini tautan ke cuplikan yang memungkinkan Anda mengambil cuplikan ini dan sudah melakukan pelacakan transaksi lama.
Mengapa transaksi lama buruk? Karena semua kunci hanya akan dibuka di bagian akhir. Dan kami mengacaukan semua orang. Plus, kami memblokir autovacuum untuk semua tabel. Itu tidak bagus sama sekali. Bahkan jika Anda mengaktifkan hot standby di replika, itu masih buruk. Secara umum, tidak ada tempat yang lebih baik untuk menghindari transaksi panjang.
Jika kita memiliki banyak tabel yang tidak disedot, maka kita perlu waspada. Di sini situasi seperti itu mungkin terjadi. Kami secara tidak langsung dapat mempengaruhi pengoperasian autovacuum. Ini adalah cuplikan dari Avito, yang sedikit saya tingkatkan. Dan ternyata menjadi alat yang menarik untuk melihat apa yang kita miliki dengan autovacuum. Misalnya, beberapa meja menunggu di sana dan tidak akan menunggu giliran. Anda juga perlu memasukkannya ke dalam pemantauan dan memiliki peringatan.
Dan masalah blok. Hutan pohon balok. Saya suka mengambil sesuatu dari seseorang dan memperbaikinya. Di sini saya mengambil CTE rekursif keren dari Data Egret yang menunjukkan hutan pohon kunci. Ini adalah alat diagnostik yang bagus. Dan atas dasar itu, Anda juga dapat membangun pemantauan. Tetapi ini harus dilakukan dengan hati-hati. Anda perlu membuat statement_timeout kecil untuk diri Anda sendiri. Dan lock_timeout diinginkan.
Terkadang semua kesalahan ini terjadi secara keseluruhan.
Menurut saya, kesalahan utama di sini adalah organisasi. Itu organisasi, karena tekniknya tidak menarik. Ini nomor 2 - mereka memeriksa di tempat yang salah.
Kami memeriksa di tempat yang salah, karena kami tidak memiliki tiruan produksi, yang mudah untuk diperiksa. Pengembang mungkin tidak memiliki akses ke produksi sama sekali.
Dan kami memeriksa tidak ada. Jika kami telah memeriksa di sana, kami akan melihatnya sendiri. Pengembang melihat semuanya bahkan tanpa DBA jika dia memeriksanya di lingkungan yang baik, di mana terdapat jumlah data yang sama dan lokasi yang identik. Dia akan melihat semua degradasi ini dan dia akan malu.
Lebih lanjut tentang vakum otomatis. Setelah kita melakukan sweep besar-besaran beberapa juta baris, kita masih perlu melakukan REPACK. Ini sangat penting untuk indeks. Mereka akan merasa tidak enak setelah kita membersihkan semua yang ada di sana.
Dan jika Anda ingin mengembalikan pekerjaan pembersihan harian, saya sarankan melakukannya lebih sering, tetapi lebih kecil. Bisa satu menit sekali atau bahkan lebih sering sedikit. Dan Anda perlu memantau dua hal: bahwa benda ini tidak memiliki kesalahan dan tidak ketinggalan. Trik yang saya tunjukkan hanya akan menyelesaikan ini.
Apa yang kami lakukan adalah open source. Itu diposting di GitLab. Dan kami membuatnya agar orang dapat memeriksa bahkan tanpa DBA. Kami sedang melakukan lab basis data, yaitu, kami memanggil komponen dasar tempat Joe bekerja saat ini. Dan Anda dapat mengambil salinan produksi. Sekarang ada implementasi Joe untuk kendur, Anda dapat mengatakan di sana: "jelaskan permintaan ini dan itu" dan segera dapatkan hasilnya untuk salinan database Anda. Anda bahkan dapat MENGHAPUS di sana, dan tidak ada yang akan menyadarinya.
Katakanlah Anda memiliki 10 terabyte, kami membuat lab database juga 10 terabyte. Dan dengan database simultan 10 terabyte, 10 pengembang dapat bekerja secara bersamaan. Setiap orang dapat melakukan apa yang mereka inginkan. Dapat menghapus, menjatuhkan, dll. Itu fantasi yang luar biasa. Kami akan membicarakan hal ini besok.
Ini disebut penyediaan tipis. Ini adalah penyediaan yang halus. Ini adalah semacam fantasi yang sangat menghilangkan keterlambatan dalam pengembangan, dalam pengujian dan menjadikan dunia tempat yang lebih baik dalam hal ini. Artinya, ini memungkinkan Anda menghindari masalah dengan operasi massal.
Contoh: database 5 terabyte, mendapatkan salinan dalam waktu kurang dari 30 detik. Dan itu bahkan tidak tergantung pada ukurannya, yaitu tidak peduli berapa terabyte.
Hari ini Anda bisa pergi ke dan gali alat kami. Anda dapat mendaftar untuk melihat apa yang ada di sana. Anda dapat menginstal bot ini. Gratis. Menulis.
pertanyaan
Sangat sering dalam situasi nyata ternyata data yang harus tetap ada di tabel jauh lebih sedikit daripada yang perlu dihapus. Artinya, dalam situasi seperti itu, seringkali lebih mudah untuk mengimplementasikan pendekatan seperti itu, ketika lebih mudah membuat objek baru, salin hanya data yang diperlukan di sana, dan simpan tabel lama. Jelas bahwa pendekatan terprogram diperlukan untuk saat ini, saat Anda akan beralih. Bagaimana pendekatan ini?
Ini adalah pendekatan yang sangat bagus dan tugas yang sangat bagus. Ini sangat mirip dengan apa yang dilakukan pg_repack, sangat mirip dengan apa yang harus Anda lakukan saat membuat ID 4 byte. Banyak kerangka kerja melakukan ini beberapa tahun yang lalu, dan hanya pelat yang tumbuh, dan perlu diubah menjadi 8 byte.
Tugas ini cukup sulit. Kita berhasil. Dan Anda harus sangat berhati-hati. Ada kunci, dll. Tapi sedang dilakukan. Artinya, pendekatan standar adalah menggunakan pg_repack. Anda mendeklarasikan label seperti itu. Dan sebelum Anda mulai mengunggah data snapshot ke dalamnya, Anda juga mendeklarasikan satu pelat yang melacak semua perubahan. Ada trik yang Anda bahkan tidak dapat melacak beberapa perubahan. Ada kehalusan. Dan kemudian Anda beralih dengan menggulirkan perubahan. Akan ada jeda singkat saat kami mematikan semua orang, tetapi secara umum hal ini sedang dilakukan.
Jika Anda melihat pg_repack di GitHub, lalu ada tugas untuk mengubah ID dari int 4 menjadi int 8, maka ada ide untuk menggunakan pg_repack itu sendiri. Ini juga mungkin, tetapi ini sedikit peretasan, tetapi ini juga akan berhasil. Anda dapat mengintervensi pemicu yang digunakan pg_repack dan mengatakan di sana: "Kami tidak membutuhkan data ini", yaitu kami hanya mentransfer apa yang kami butuhkan. Dan kemudian dia hanya beralih dan hanya itu.
Dengan pendekatan ini, kami masih mendapatkan salinan tabel kedua, di mana datanya sudah diindeks dan ditumpuk sangat merata dengan indeks yang indah.
Kembung tidak ada, ini pendekatan yang bagus. Tetapi saya tahu bahwa ada upaya untuk mengembangkan otomatisasi untuk ini, yaitu membuat solusi universal. Saya dapat menghubungkan Anda dengan otomatisasi ini. Itu ditulis dengan Python, yang merupakan hal yang baik.
Saya hanya sedikit dari dunia MySQL, jadi saya datang untuk mendengarkan. Dan kami menggunakan pendekatan ini.
Tapi itu hanya jika kita memiliki 90%. Jika kita memiliki 5%, maka tidak baik untuk menggunakannya.
Terima kasih atas laporannya! Jika tidak ada sumber daya untuk membuat salinan prod yang lengkap, apakah ada algoritme atau rumus untuk menghitung beban atau ukuran?
Pertanyaan bagus. Sejauh ini, kami dapat menemukan database multi-terabyte. Kalaupun hardware disana tidak sama, misalnya memori kurang, prosesor kurang dan disk tidak persis sama, tapi tetap kita lakukan. Jika sama sekali tidak ada tempat, maka Anda perlu berpikir. Biarkan saya berpikir sampai besok, Anda datang, kita akan bicara, ini pertanyaan yang bagus.
Terima kasih atas laporannya! Anda pertama kali memulai tentang fakta bahwa ada Postgres keren, yang memiliki keterbatasan ini dan itu, tetapi sedang berkembang. Dan ini semua adalah kruk pada umumnya. Bukankah ini semua bertentangan dengan perkembangan Postgres itu sendiri, di mana beberapa DELETE deferent akan muncul atau sesuatu yang lain yang seharusnya menjaga pada level rendah apa yang kita coba olesi dengan beberapa cara aneh kita di sini?
Jika kami mengatakan dalam SQL untuk menghapus atau memperbarui banyak catatan dalam satu transaksi, lalu bagaimana Postgres dapat mendistribusikannya di sana? Kami secara fisik terbatas dalam operasi. Kami masih akan melakukannya untuk waktu yang lama. Dan kami akan mengunci saat ini, dll.
Selesai dengan indeks.
Saya dapat berasumsi bahwa penyetelan pos pemeriksaan yang sama dapat diotomatisasi. Suatu hari nanti mungkin. Tapi kemudian saya tidak begitu mengerti pertanyaannya.
Pertanyaannya adalah, apakah ada vektor perkembangan yang berjalan di sana-sini, dan di sini milik Anda sejajar? Itu. Apa mereka belum memikirkannya?
Saya berbicara tentang prinsip-prinsip yang dapat digunakan sekarang. Ada bot lain , dengan ini Anda dapat melakukan penyetelan pos pemeriksaan otomatis. Apakah suatu hari nanti akan ada di Postgres? Saya tidak tahu, itu bahkan belum dibahas. Kita masih jauh dari itu. Tapi ada ilmuwan yang membuat sistem baru. Dan mereka memasukkan kami ke dalam indeks otomatis. Ada perkembangan. Misalnya, Anda dapat melihat penyetelan otomatis. Ini memilih parameter secara otomatis. Tapi dia belum akan melakukan penyetelan pos pemeriksaan untuk Anda. Artinya, itu akan mengambil kinerja, buffer shell, dll.
Dan untuk penyetelan pos pemeriksaan, Anda dapat melakukan ini: jika Anda memiliki seribu cluster dan perangkat keras berbeda, mesin virtual berbeda di cloud, Anda dapat menggunakan bot kami melakukan otomatisasi. Dan max_wal_size akan dipilih sesuai dengan pengaturan target Anda secara otomatis. Tapi sejauh ini bahkan tidak mendekati intinya, sayangnya.
Selamat siang Anda berbicara tentang bahaya transaksi panjang. Anda mengatakan bahwa autovacuum diblokir jika dihapus. Bagaimana lagi itu merugikan kita? Karena kita berbicara lebih banyak tentang membebaskan ruang dan dapat menggunakannya. Apa lagi yang kita lewatkan?
Autovacuum mungkin bukan masalah terbesar di sini. Dan faktanya transaksi yang panjang bisa mengunci transaksi lainnya, kemungkinan ini lebih berbahaya. Dia mungkin atau mungkin tidak bertemu. Jika dia bertemu, maka itu bisa sangat buruk. Dan dengan autovacuum - ini juga menjadi masalah. Ada dua masalah dengan transaksi panjang di OLTP: kunci dan vakum otomatis. Dan jika Anda mengaktifkan umpan balik siaga panas pada replika, maka kunci vakum otomatis juga akan tiba di master, itu akan datang dari replika. Tapi setidaknya tidak akan ada kunci. Dan akan ada lok. Kami berbicara tentang perubahan data, jadi kunci adalah poin penting di sini. Dan jika ini semua untuk waktu yang sangat lama, maka semakin banyak transaksi yang dikunci. Mereka bisa mencuri orang lain. Dan pohon lok muncul. Saya memberikan tautan ke cuplikan. Dan masalah ini menjadi lebih cepat terlihat daripada masalah dengan autovacuum, yang hanya dapat menumpuk.
Terima kasih atas laporannya! Anda memulai laporan dengan mengatakan bahwa Anda melakukan pengujian yang salah. Kami melanjutkan ide kami bahwa kami perlu mengambil peralatan yang sama, dengan alas yang sama. Katakanlah kita memberi pengembang basis. Dan dia menuruti permintaan itu. Dan sepertinya dia baik-baik saja. Tapi dia tidak mengecek live, tapi live, misalnya kita load 60-70%. Dan bahkan jika kita menggunakan penyetelan ini, itu tidak bekerja dengan baik.
Memiliki pakar dalam tim dan menggunakan pakar DBA yang dapat memprediksi apa yang akan terjadi dengan beban latar belakang yang sebenarnya adalah penting. Saat kami baru saja melakukan perubahan bersih, kami melihat gambarnya. Tetapi pendekatan yang lebih maju, ketika kami melakukan hal yang sama lagi, tetapi dengan beban yang disimulasikan dengan produksi. Ini cukup keren. Sampai saat itu, Anda harus tumbuh dewasa. Ini seperti orang dewasa. Kami hanya melihat apa yang kami miliki dan juga melihat apakah kami memiliki sumber daya yang cukup. Itu pertanyaan yang bagus.
Saat kita sudah melakukan pemilihan sampah dan kita memiliki, misalnya, bendera yang dihapus
Inilah yang dilakukan autovacuum secara otomatis di Postgres.
Oh, apakah dia melakukannya?
Autovacuum adalah pengumpul sampah.
Terima kasih!
Terima kasih atas laporannya! Apakah ada opsi untuk segera mendesain database dengan partisi sedemikian rupa sehingga semua sampah menjadi kotor dari tabel utama di suatu tempat di samping?
Tentu saja ada.
Apakah mungkin untuk melindungi diri kita sendiri jika kita telah mengunci meja yang tidak boleh digunakan?
Tentu saja. Tapi ini seperti pertanyaan ayam dan telur. Jika kita semua tahu apa yang akan terjadi di masa depan, maka tentunya kita akan melakukan semuanya dengan keren. Tapi bisnisnya berubah, ada kolom baru, permintaan baru. Dan kemudian β ups, kami ingin menghapusnya. Tetapi situasi ideal ini terjadi dalam hidup, tetapi tidak selalu. Tapi secara keseluruhan itu ide yang bagus. Potong saja dan hanya itu.
Sumber: www.habr.com