Mengapa anda memerlukan sokongan instrumental untuk penomboran pada kekunci?

Hai semua! Saya seorang pembangun bahagian belakang yang menulis perkhidmatan mikro dalam Java + Spring. Saya bekerja dalam salah satu pasukan pembangunan produk dalaman di Tinkoff.

Dalam pasukan kami, persoalan mengoptimumkan pertanyaan dalam DBMS sering timbul. Anda sentiasa mahu menjadi lebih pantas sedikit, tetapi anda tidak sentiasa boleh bertahan dengan indeks yang dibina dengan teliti—anda perlu mencari beberapa penyelesaian. Semasa salah satu pengembaraan di web ini untuk mencari pengoptimuman yang munasabah apabila bekerja dengan pangkalan data, saya mendapati Blog Marcus Wynand yang tidak berkesudahan membantu, pengarang SQL Performance Explained. Ini adalah jenis blog yang jarang berlaku di mana anda boleh membaca semua artikel berturut-turut.

Saya ingin menterjemahkan artikel pendek oleh Marcus untuk anda. Ia boleh dipanggil sedikit sebanyak manifesto yang bertujuan untuk menarik perhatian kepada masalah lama, tetapi masih relevan prestasi operasi mengimbangi mengikut standard SQL.

Di beberapa tempat saya akan menambah penulis dengan penjelasan dan komen. Saya akan merujuk kepada semua tempat seperti "anggaran." untuk lebih jelas

Pengenalan kecil

Saya rasa ramai orang tahu betapa bermasalah dan lambat bekerja dengan pilihan halaman melalui offset. Adakah anda tahu bahawa ia boleh digantikan dengan mudah dengan reka bentuk yang lebih cekap?

Jadi, kata kunci offset memberitahu pangkalan data untuk melangkau n rekod pertama dalam permintaan. Walau bagaimanapun, pangkalan data masih perlu membaca n rekod pertama ini dari cakera, dalam susunan yang diberikan (nota: gunakan pengisihan jika ia dinyatakan), dan selepas itu barulah mungkin untuk mengembalikan rekod dari n+1 dan seterusnya. Perkara yang paling menarik ialah masalahnya bukan dalam pelaksanaan khusus dalam DBMS, tetapi dalam definisi asal mengikut standard:

…baris disusun terlebih dahulu mengikut dan kemudian dihadkan dengan menjatuhkan bilangan baris yang dinyatakan dalam dari permulaan…
-SQL:2016, Bahagian 2, 4.15.3 Jadual terbitan (nota: pada masa ini standard yang paling banyak digunakan)

Perkara utama di sini ialah mengimbangi mengambil satu parameter - bilangan rekod untuk dilangkau, dan itu sahaja. Mengikut definisi ini, DBMS hanya boleh mendapatkan semula semua rekod dan kemudian membuang yang tidak diperlukan. Jelas sekali, takrifan offset ini memaksa kita melakukan kerja tambahan. Dan ia tidak kira sama ada SQL atau NoSQL.

Cuma sakit sikit lagi

Masalah dengan offset tidak berakhir di situ, dan inilah sebabnya. Jika, antara membaca dua muka surat data daripada cakera, operasi lain memasukkan rekod baharu, apakah yang akan berlaku dalam kes ini?

Apabila offset digunakan untuk melangkau rekod dari halaman sebelumnya, dalam situasi menambah rekod baharu antara bacaan halaman yang berbeza, kemungkinan besar anda akan mendapat pendua (nota: ini mungkin apabila kita membaca halaman demi halaman menggunakan susunan mengikut binaan, kemudian di tengah-tengah output kita mungkin mendapat entri baru).

Angka itu jelas menggambarkan keadaan ini. Pangkalan membaca 10 rekod pertama, selepas itu rekod baharu dimasukkan, yang mengimbangi semua rekod bacaan sebanyak 1. Kemudian pangkalan itu mengambil halaman baharu daripada 10 rekod seterusnya dan bermula bukan dari ke-11, seperti yang sepatutnya, tetapi dari ke-10, menduplikasi rekod ini. Terdapat anomali lain yang dikaitkan dengan penggunaan ungkapan ini, tetapi ini adalah yang paling biasa.

Seperti yang telah kita ketahui, ini bukan masalah DBMS tertentu atau pelaksanaannya. Masalahnya ialah dalam menentukan penomboran mengikut piawaian SQL. Kami memberitahu DBMS halaman mana yang hendak diambil atau berapa banyak rekod untuk dilangkau. Pangkalan data tidak dapat mengoptimumkan permintaan sedemikian, kerana terdapat terlalu sedikit maklumat untuk ini.

Perlu dijelaskan juga bahawa ini bukan masalah dengan kata kunci tertentu, sebaliknya dengan semantik pertanyaan. Terdapat beberapa lagi sintaks yang serupa dengan sifat bermasalahnya:

• Kata kunci offset adalah seperti yang dinyatakan sebelum ini.
• Pembinaan dua kata kunci had [offset] (walaupun had itu sendiri tidak begitu teruk).
• Menapis mengikut sempadan bawah, berdasarkan penomboran baris (contohnya, row_number(), rownum, dsb.).

Semua ungkapan ini hanya memberitahu anda berapa banyak baris untuk dilangkau, tiada maklumat atau konteks tambahan.

Kemudian dalam artikel ini, kata kunci offset digunakan sebagai ringkasan semua pilihan ini.

Hidup tanpa OFFSET

Sekarang mari kita bayangkan bagaimana dunia kita tanpa semua masalah ini. Ternyata kehidupan tanpa offset tidak begitu sukar: dengan pilihan, anda boleh memilih hanya baris yang belum kita lihat (nota: iaitu, yang tidak ada pada halaman sebelumnya), menggunakan keadaan di mana.

Dalam kes ini, kita bermula dari fakta bahawa pilihan dilaksanakan pada set yang dipesan (perintah lama yang baik oleh). Memandangkan kami mempunyai set tertib, kami boleh menggunakan penapis yang agak mudah untuk mendapatkan hanya data yang berada di belakang rekod terakhir halaman sebelumnya:

    SELECT ...
    FROM ...
    WHERE ...
    AND id < ?last_seen_id
    ORDER BY id DESC
    FETCH FIRST 10 ROWS ONLY

Itulah keseluruhan prinsip pendekatan ini. Sudah tentu, perkara menjadi lebih menyeronokkan apabila mengisih mengikut banyak lajur, tetapi ideanya masih sama. Adalah penting untuk ambil perhatian bahawa reka bentuk ini boleh digunakan untuk banyak orang NoSQL-keputusan.

Pendekatan ini dipanggil kaedah cari atau penomboran set kekunci. Ia menyelesaikan masalah hasil terapung (nota: situasi dengan menulis antara bacaan halaman yang diterangkan sebelum ini) dan, sudah tentu, apa yang kita semua suka, ia berfungsi lebih pantas dan lebih stabil daripada offset klasik. Kestabilan terletak pada fakta bahawa masa pemprosesan permintaan tidak meningkat mengikut kadar bilangan jadual yang diminta (nota: jika anda ingin mengetahui lebih lanjut tentang kerja pendekatan berbeza untuk penomboran, anda boleh lihat melalui pembentangan penulis. Anda juga boleh mencari penanda aras perbandingan untuk kaedah yang berbeza di sana).

Salah satu slaid bercakap tentang itupenomboran dengan kekunci, sudah tentu, tidak maha kuasa - ia mempunyai hadnya. Perkara yang paling penting ialah dia tidak mempunyai keupayaan untuk membaca halaman rawak (nota: tidak konsisten). Walau bagaimanapun, dalam era penatalan yang tidak berkesudahan (nota: pada bahagian hadapan), ini bukanlah masalah sedemikian. Menentukan nombor halaman untuk mengklik adalah keputusan yang tidak baik dalam reka bentuk UI (nota: pendapat pengarang artikel).

Bagaimana dengan alatan?

Penomboran pada kekunci selalunya tidak sesuai kerana kekurangan sokongan instrumental untuk kaedah ini. Kebanyakan alat pembangunan, termasuk pelbagai rangka kerja, tidak membenarkan anda memilih dengan tepat cara penomboran akan dilakukan.

Keadaan ini diburukkan lagi oleh fakta bahawa kaedah yang diterangkan memerlukan sokongan hujung ke hujung dalam teknologi yang digunakan - daripada DBMS kepada pelaksanaan permintaan AJAX dalam penyemak imbas dengan tatal yang tidak berkesudahan. Daripada menyatakan hanya nombor halaman, anda kini perlu menentukan satu set kunci untuk semua halaman sekaligus.

Walau bagaimanapun, bilangan rangka kerja yang menyokong penomboran pada kekunci semakin meningkat secara beransur-ansur. Inilah yang kami ada pada masa ini:

• jOOQ untuk Jawa;
• pesanan_pertanyaan untuk Ruby;
• chunkator и Penomboran Tatal Infinite Django untuk Django;
• SQL Alchemy sqlakeyset untuk Python;
• berkobar-kobar — API kriteria untuk pelaksanaan JPA;
• DBIx::Kelas::Pembungkus untuk Perl;
• Massive.js, pemeta untuk Node.js Dokumentasi Set Kekunci.

(Nota: beberapa pautan telah dialih keluar kerana fakta bahawa pada masa terjemahan beberapa perpustakaan tidak dikemas kini sejak 2017-2018. Jika anda berminat, anda boleh melihat sumber asal.)

Pada masa inilah bantuan anda diperlukan. Jika anda membangunkan atau menyokong rangka kerja yang menggunakan sebarang penomboran, maka saya bertanya, saya menggesa, saya memohon anda untuk memberikan sokongan asli untuk penomboran pada kekunci. Jika anda mempunyai soalan atau memerlukan bantuan, saya dengan senang hati akan membantu (forum, Twitter, Borang hubungan) (nota: dari pengalaman saya dengan Marcus, saya boleh katakan bahawa dia sangat bersemangat untuk menyebarkan topik ini).

Jika anda menggunakan penyelesaian siap pakai yang anda fikir layak mendapat sokongan untuk penomboran dengan kunci, buat permintaan atau tawarkan penyelesaian siap sedia, jika boleh. Anda juga boleh memaut ke artikel ini.

Kesimpulan

Sebab mengapa pendekatan yang mudah dan berguna seperti penomboran dengan kunci tidak meluas bukanlah kerana ia sukar untuk dilaksanakan secara teknikal atau memerlukan sebarang usaha yang hebat. Sebab utama ialah ramai yang terbiasa melihat dan bekerja dengan offset - pendekatan ini ditentukan oleh standard itu sendiri.

Akibatnya, beberapa orang berfikir tentang menukar pendekatan kepada penomboran, dan kerana ini, sokongan instrumental daripada rangka kerja dan perpustakaan berkembang dengan buruk. Oleh itu, jika idea dan matlamat penomboran bebas offset hampir dengan anda, bantu sebarkan!

Sumber: https://use-the-index-luke.com/no-offset
Pengarang: Markus Winand

Sumber: www.habr.com