Bekerja dengan basis data adalah apa yang secara signifikan mempengaruhi kinerja layanan web apa pun. Jika Anda
mencoba , Anda dapat mengatur beban tinggi tanpa beban sama sekali.
Dan jika Anda melakukan semuanya dengan bijak, itu akan berubah untuk memproses permintaan ribuan pengguna. Oleh karena itu, jadwal
HighLoad ++ secara tradisional memiliki banyak laporan tentang database. Kami memiliki trek di PostgreSQL, MySQL dan ClickHouse, ada beberapa laporan tentang MongoDB (dalam tradisi terbaik, pembicara adalah insinyur kinerja di MongoDB). Selain itu, ada pidato tentang perbandingan berbagai pendekatan atau mempertimbangkan solusi khusus. Dan secara umum, mari tambahkan Tarantool dan memori di sini. Sebanyak 33 laporan secara langsung terkait dengan bagian "Database dan sistem penyimpanan" dan setidaknya 10 secara tidak langsung. Dan ini belum termasuk
mitaps , yang jumlahnya tidak kurang dari sepuluh, dan yang baru akan ditambahkan di sepanjang jalan.
Kami akan mencoba membantu Anda menavigasi dalam semua keragamannya dan tidak ketinggalan laporan yang benar-benar unik. Untuk keandalan, kami meminta pendapat anggota Komite Program yang bertanggung jawab untuk bagian ini, Nikolay Samokhvalov. Dan jangan melihat bahwa Nikolai adalah pendiri Postgres.ai dan umumnya postgresmen - ia berpengalaman dalam dunia basis data, ia tahu cerita dan tren di belakang panggung yang menarik.
Tinjauan ini disusun sesederhana mungkin: kami membuka
daftar laporan dan beralih dari atas ke bawah, membahas topik-topik yang harus diperhatikan.
Profil Profil Permintaan ClickHouse
Query profiler dalam database analitik adalah hal yang sangat menarik. Pendekatannya harus sangat berbeda dari database OLTP, karena, sebagai aturan, query dilakukan dalam database analitik untuk waktu yang lama. Jika dalam PostgreSQL rencana eksekusi query adalah statis, maka masuk akal untuk hampir memonitor satu query.
Dalam
laporan ini
, Nikita Lapkov akan berbicara tentang perangkat profiler seperti itu untuk permintaan ClickHouse, yang memungkinkan Anda untuk menentukan
bagian mana dari kode yang melambat untuk permintaan tertentu . Dan lakukan tindakan yang tepat untuk menerapkan "ClickHouse yang terkenal tidak melambat."
Cadangkan dalam infrastruktur modern
Laporan ini hanya dari seri "di sebelah database", ia memeriksa masalah sistem, tetapi sebagian besar dikhususkan untuk masalah cadangan di MySQL. Kisah Anton Turetsky tentu akan menarik, karena ini adalah pengalaman Badoo, yaitu,
pertanyaan tentang sejumlah besar server . Pada skala seperti itu, membuat cadangan dan, yang paling penting, memeriksa semuanya adalah tugas yang tidak sepele. Selain itu, mereka berhasil berteman dengan tren modern dan paradigma merancang sistem dengan cadangan agar tidak kehilangan kepercayaan bahwa data yang diperlukan dapat diperoleh dalam kasus apa pun, bahkan yang paling kritis sekalipun.
NB: Pencadangan tanpa verifikasi otomatis bukanlah pencadangan.
Pindah ke ClickHouse: 3 tahun kemudian
ClickHouse dengan percaya diri menaklukkan posisinya, tetapi beberapa pengembang pihak ketiga berhasil mengumpulkan pengalaman yang solid dalam bekerja dengannya. Alexander Zaitsev dan Altinity adalah pelopor menggunakan ClickHouse, sejak 3 tahun yang lalu di HighLoad ++ mereka berbicara tentang
memindahkan sistem analitik multi-petabyte ke ClickHouse.
Apa yang telah berubah sejak saat itu? Alexander
akan berbagi pengalaman dan pengetahuannya, yang tidak dapat ditemukan dalam dokumentasi.
MongoDB vs. Tolok ukur postgres
Dua tamu akan berbicara tentang MongoDB di HighLoad ++. Laporan Álvaro Hernández memiliki latar belakang yang menarik, bahkan memalukan. Ketika Alvaro membuat dan memperkenalkan tolok ukur yang membandingkan MongoDB dan PostgreSQL, pertempuran kecil terjadi di Internet. MongoDB kemudian memperkenalkan tolok ukur mereka.
Akibatnya, masing-masing dunia hanya memiliki filosofi sendiri. Penganut PostgreSQL kesulitan menerima sikap yang tidak jelas terhadap data, tetapi solusi MongoDB sangat diminati di pasar. Membandingkan mereka secara langsung hampir tidak mungkin, dan ini membuat
laporan Alvaro sangat menarik. Sangat mudah untuk membabi buta mematuhi satu sudut pandang, tetapi jauh lebih baik untuk mengetahui dan memahami keduanya.
Ini adalah fakta yang menyenangkan bagi semua orang - Michael Stonebreaker berpartisipasi. Dia menarik perhatian pada perselisihan antara Postgres dan Mongo dan menerbitkan beberapa artikel tentang masalah model ini. Yaitu, pendiri Postgres, yang pada suatu waktu mengatakan bahwa satu ukuran tidak cocok untuk semua orang, dan sebagai hasilnya meluncurkan pembuatan database khusus, termasuk NoSQL, sekarang pada dasarnya kembali ke Postgres. Dia menulis masalah apa yang ada, menyarankan untuk menikah dengan model data, dan umumnya mengatakan bahwa semuanya baik-baik saja dengan Postgres. Sangat menarik untuk menyaksikan siklus dua puluh tahun ini.
MongoDB mendistribusikan transaksi dari atas ke bawah
Laporan kedua tentang MongoDB akan dibuat oleh Henrik Ingo, arsitek solusi MongoDB, yang mengkhususkan diri dalam meningkatkan kinerja MongoDB dan menyediakan ketersediaan tinggi. Tapi Henrik, sebelum MongoDB, bekerja di dunia MySQL selama bertahun-tahun, jadi dia tahu persis argumen berbagai kubu.
Di HighLoad ++, Henrik
akan memberi tahu Anda cara melakukan transaksi dalam basis data NoSQL yang didistribusikan memuaskan ACID, dan mengapa Anda mungkin memerlukannya sama sekali.
Peta jalan Odyssey: apa lagi yang kita inginkan dari penarik koneksi
Tiga minggu lalu, batasan utama PgBouncer, yang sering ditemui perusahaan, telah dihapus, tetapi sudah berhasil mengganggu semua orang. Misalnya, karena tidak mungkin untuk melakukan perbaikan pada open source - patch Yandex dan Avito belum diterima selama bertahun-tahun.
Yandex tidak menunggu perubahan ini dan membuat penarik koneksi mereka - Odyssey. Ini multi-utas, memiliki chip tambahan, dan Andrei Borodin akan memberi tahu lebih detail dalam
laporannya . Selain itu, akan mungkin untuk membahas peta jalan - fitur apa yang ingin dilihat penarik di versi baru komunitas.
DBA bot Joe. Meringankan rasa sakit perkembangan backend
Dengan laporan ini, Postgres.ai mengusulkan untuk secara fundamental mengubah pendekatan untuk pengembangan backend. Alih-alih memeriksa kode dan kueri pada basis data kecil, periksa basis data besar dan segera lihat hasilnya. Kedengarannya logis - jika permintaan lambat, maka akan segera terdeteksi. Hal lain adalah apa yang harus dilakukan untuk ini, misalnya, salinan lengkap dari database tempur sangat tidak nyaman. Di sinilah bot DBA buatan Joe datang untuk menyelamatkan
Joe dapat menulis permintaan atau meminta untuk membuat indeks, dan dia akan melakukan semua tindakan pada salinan database pertempuran ukuran penuh. Kapan saja, Anda dapat memulai kembali, membatalkan semua perubahan dalam beberapa detik, menjatuhkan cache OS dan DBMS. Dan untuk pekerjaan sepuluh pengembang tidak perlu ruang disk x10. Bagaimana sulap ini bekerja, dan dari komponen sumber terbuka mana Anda dapat mencoba mengumpulkannya dari diri Anda sendiri, Anatoly Stansler
akan memberi tahu .
HAPUS DELETE. Kesalahan umum ketika melakukan operasi besar-besaran di database PostgreSQL yang sangat dimuat
Dan jika tampaknya seseorang tidak ada yang salah dengan menghapus beberapa juta baris dengan satu DELETE, ketika kondisinya diketahui dan ada indeks yang sesuai, maka Anda perlu mendengarkan
laporan Nikolai Samokhvalov. Jika Anda mencoba melakukan operasi dalam kondisi seperti itu, layanan kemungkinan besar akan jatuh, dan ada banyak alasan untuk itu segera: DBA tidak bekerja, pengembang tidak berperilaku dengan benar, dan pendekatan organisasi salah.
Nikolay akan menunjukkan bagaimana Postgres.ai membantu menyelesaikan masalah ini dan cara mengkonfigurasi perlindungan tanpa menggunakannya dan selalu bertindak andal tanpa menjatuhkan prod. Semua ini
didasarkan pada pengalaman nyata dari rasa sakit dan kerugian finansial yang sangat besar . Karena tampaknya jelas bahwa Anda tidak dapat langsung menghapus, tetapi, misalnya, tandai data untuk dihapus terlebih dahulu, tetapi memblokir operasi pada sejuta baris semuanya ditemui.
Patroni di GitLab.com
GitLab menggunakan PostgreSQL ke MySQL penuh yang baru saja ditinggalkan, dan untuk memastikan HA beralih dari REPMGR ke Patroni. Patroni dikembangkan oleh Zalando, tugasnya adalah untuk secara otomatis beralih jika sesuatu terjadi pada penyihir, dan untuk memastikan ketersediaan layanan.
Sekarang
Patroni adalah standar de facto , dan GitLab telah mengimplementasikannya pada solusi cloud mereka - untuk yang kedua, 25,000,000 operasi git pull per hari - dan sedang mempersiapkan solusi untuk memeriksa instalasi. Jose Cores Finotto
akan membagikan pengalaman super menarik ini di HighLoad ++ pada 7 November.
StackGres: Cloud-Native PostgreSQL di Kubernetes
Álvaro Hernández, dibandingkan dengan PostgreSQL dan MongoDB, juga
akan memperkenalkan produk StackGres - yang pada dasarnya merupakan pengganti RDS. Tetapi memungkinkan untuk menggunakan RDS di Kubernetes jauh lebih murah, membuat cadangan dikonfigurasi dengan upaya minimum dengan trailer, Patroni untuk failover otomatis, pemeriksaan kesehatan, dan banyak alat yang berbeda.
Ini adalah usaha yang menjanjikan dalam arah yang mirip dengan kisah Linux. Ada kernel Linux, dan banyak majelis berbeda di sekitarnya. Kami melihat hal yang sama sehubungan dengan PostgreSQL, yang dapat dianggap sebagai kernel untuk DBMS, dan rakitan akan muncul di sekitarnya. StackGres memiliki peluang bagus untuk mendapatkan popularitas, karena ada tim yang ramai, dan pelanggan di mana Anda dapat menjalankan keputusan Anda.
PostgreSQL mengunci
Kunci pada dasarnya adalah topik yang harus didengarkan oleh semua orang yang bekerja dengan PostgreSQL. Selain itu, Yegor Rogov, yang telah memantapkan dirinya sebagai dosen yang akan mati, akan berbicara tentang mereka. Dia sangat mengetahui materi dan akan membantu Anda memahami jenis kunci dan memahami cara membaca pg_locks dan pg_stat_activity dan menghindari sejumlah kesalahan dalam desain sistem.
Laporan Egor tentang HighLoad ++ adalah peluang besar tidak hanya untuk mendengarkan, tetapi untuk berbicara dengan seorang ahli, mengajukan pertanyaan Anda kepadanya, dan mungkin mendiskusikan masalah yang sama sekali berbeda.
Mencadangkan DBMS yang dimuat
Andrey Borodin dan Georgy Rylov bekerja di Yandex dan sedang mengembangkan WAL-G, alat cadangan sumber terbuka.
Awalnya, WAL-G adalah alat untuk PostgreSQL yang dikembangkan oleh Citus (sangat aneh bahwa Microsoft baru-baru ini menyerap Citus, yang sebenarnya membeli sepotong PostgreSQL). Tetapi ternyata gagasan mengorganisir pekerjaan dengan WAL-G sangat cocok untuk database lain. Andrew dan George hanya akan
berbicara tentang fungsionalitas untuk MySQL, Redis, MongoDB dan prospek yang terbuka sehubungan dengan ini.
Vitess: Scaling Feareless in the Cloud
Sugu Sougoumarane adalah pendiri PlanetScale. Anda mungkin belum pernah mendengar tentang perusahaan ini, tetapi baru-baru ini menerima dana $ 25 juta untuk mengembangkan produk Vitess terbuka. Anda mungkin belum pernah mendengar tentang Vitess. Jadi
Vitess adalah sistem MySQL sharding , dan Anda pasti tahu lebih dari satu perusahaan besar yang menggunakan Vitess untuk database yang sangat banyak dimuat.
Semuanya dimulai dengan YouTube. Di sanalah Sugu dan timnya menciptakan apa yang kemudian menjadi sistem sumber terbuka Vitess. Ngomong-ngomong, mereka memilih Go - bahasa yang sangat muda saat itu. Sugu dapat menceritakan banyak kisah menarik tentang tahun-tahun pertama Go dan tentang perkembangannya secara umum - di Google timnya menjadi pengguna utama bahasa yang pertama.
Nah, sekarang, selain YouTube, Vitess digunakan oleh perusahaan seperti GitHub, Pinterest, Slack, Square. Setelah meninggalkan Google, Sugu mendirikan PlanetScale dan terus mengembangkan Vitess, menjaga kode tetap terbuka. Ayo
dengarkan tentang pecahan pada skala planet dan tentang menggunakan Go in Highload nyata. Dan jangan lupa untuk bertanya tentang rencana untuk versi Postgres dari Vitess - Sugu sangat menyukai pertanyaan ini.
Patroni Failure Stories atau Cara menabrak cluster PostgreSQL Anda
Sangat lucu bahwa kami akan mendengarkan pengelola Patroni utama pada
topik yang berbeda , karena dia sudah memberi tahu kami tentang Patroni. Tetapi Aleksey Lesovsky dapat
mengetahui bagaimana Patroni dieksploitasi di luar Zalando dan kerucut apa yang dimasukkan. Karena kerucut ini bisa sangat berbeda, dan Alex berjanji untuk berbagi
rincian kasus kecelakaan nyata . Kami akan belajar dari
laporan masalah apa yang ada, pelajaran apa yang telah dipelajari dalam Data Egret dan cara mengkonfigurasi Patroni (dan, mungkin, PostgreSQL) dengan benar. Dan, tentu saja, kami mendapat ide tentang cara mengidentifikasi masalah yang muncul dengan cepat dan memperbaikinya dengan cepat.
SQL / JSON: kami menerapkan standar dan tidak berhenti di situ
Baru-baru ini, batas antara DBMS yang berorientasi dan berorientasi dokumen telah kabur. Standar SQL memiliki fungsi untuk bekerja dengan JSON, dan
PostgreSQL adalah pelopor dukungan JSON yang efektif di antara DBMS relasional . Sebagian besar terima kasih kepada Postgres Professional, standarnya telah diimplementasikan sebagian.
Laporan Alexander Korotkov adalah akun tangan pertama implementasi SQL / JSON dan jsonpath "hati" di PostgreSQL. Itu adalah kesempatan untuk belajar tentang fitur internal, pengalaman operasi, dan rencana untuk masa depan.
PostgreSQL pada K8s di Zalando: dua tahun dalam pertempuran
Alexander Kukushkin adalah rekan penulis Patroni, tetapi tahun ini ia akan
berbicara tentang perkembangan lain yang menarik dari Zalando. Dua tahun lalu, mereka mulai mengembangkan Postgres-Operator, dan saat ini, dengan bantuannya, operator DBA melayani lebih dari 1000 cluster Postgres yang berjalan di Kubernetes.
Sementara beberapa masih meragukan apakah basis data dimungkinkan di Kubernetes, perusahaan besar sudah bekerja dengan semua ini. Akan sangat menyenangkan untuk mengenal dan belajar dari tempat lain.
Panggilan perusahaan untuk Postgres
Perusahaan-perusahaan besar semakin banyak menggunakan PostgreSQL, sangat sering mengharapkan apa yang mereka gunakan dalam perusahaan. Contoh khas - kita membutuhkan solusi untuk replikasi logis - kita beralih ke vendor. Dan beberapa vendor bahkan membuat dukungan seperti itu - ada Oracle, sekarang PostgreSQL telah muncul. Tetapi kita mulai mengerti, dan ternyata, banyak yang bekerja secara berbeda.
Kami menyaksikan tabrakan dunia open source dan perusahaan. Andreessen Horowitz baru-baru ini menerbitkan sebuah penelitian yang mengatakan bahwa minat investor terhadap open source telah tumbuh secara substansial dan akan terus tumbuh. Oleh karena itu, vendor perlu beralih ke open source dan model monetisasi baru - ini akan lebih baik karena sejumlah alasan.
Ivan Panchenko
akan memberi tahu Anda dengan pasti kesulitan migrasi ke PostgreSQL untuk perusahaan yang subyektif dan termasuk tipe "tangan bengkok", dan kapan tantangan penting yang harus dihadapi PostgreSQL selama pengembangannya. Abstrak menjanjikan diskusi tentang topik-topik seperti itu: faktor penskalaan (ukuran tabel, jumlah objek, memori, koneksi, replikasi), fitur penyimpanan (Heap, penyimpanan Pluggable), tabel sementara, vakum, interaksi dengan OS.
Dan pada catatan ini -
masa depan adalah open source - kami akan menyelesaikan studi rinci dari laporan. Sayangnya, di balik layar MySQL hampir sepenuhnya tertinggal. Jika ini adalah topik Anda, lihat
Vittorio Cioe dan
Alkin Tezuysal .
ClickHouse juga terwakili dalam jumlah laporan yang lebih besar, dan seperti biasa,
mitap memiliki nilai tertentu, di mana Anda dapat mengajukan pertanyaan tentang ClickHouse, bersama dengan pengembang menemukan solusi untuk masalah, mendiskusikan peluang dan rencana.
Kami juga tidak menyentuh Tarantool, karena ini adalah database dan server aplikasi dalam satu botol. Dan laporan dalam program HighLoad ++ 2019 fokus pada multifungsi ini. Vasily Tyubek akan berbicara tentang
Tarantool Kubernetes Operator untuk menjalankan basis data di Kubernetes, Yaroslav Dynnikov akan menunjukkan kenyamanan membangun sistem terdistribusi menggunakan Tarantool. Dan jangan lewatkan kesempatan untuk mengklarifikasi semua detail dengan pengembangnya sendiri - ini jauh lebih produktif dan menarik daripada membaca dokumentasi.
Secara umum, kami mempertimbangkan pertanyaan untuk pembicara, diskusi di belakang panggung dan jaringan - bagian yang sangat, jika bukan yang paling, penting dari konferensi. Oleh karena itu, kami menciptakan semua kondisi untuk komunikasi informal dan
berusaha bersenang-senang.
Pada tanggal 7 dan 8 November, HighLoad ++ akan mengisi SKOLKOVO hingga penuh dan mengeluarkannya. Di Novosibirsk dan St. Petersburg akan ada cabang HighLoad ++ mereka dengan telekonferensi ke Aula Utama dan semua manfaat jaringan di konferensi. Di youtube, kami akan meluncurkan siaran video terbuka dari laporan yang paling dinantikan dan Penghargaan HighLoad ++ , dan di saluran telegram di sepanjang jalur lain kami akan meluncurkan agen terjemahan teks. Singkatnya, bahkan jika Anda tidak masuk ke HighLoad ++ (sia-sia - Anda masih bisa berubah pikiran, mendapatkan tiket dan lepas landas), Anda masih bisa mendapatkan banyak hal baik dan menyenangkan melalui jaringan kami.