Sharding database vs partisi

Saya telah membaca tentang arsitektur yang skalabel baru-baru ini. Dalam konteks itu, dua kata yang terus muncul berkaitan dengan database adalah sharding dan partisi . Saya mencari deskripsi tetapi masih bingung.

Bisakah para ahli di stackoverflow membantu saya mendapatkan dasar-dasar yang benar?

• Apa perbedaan antara sharding dan partisi ?
• Apakah benar bahwa 'semua database yang di-shard pada dasarnya dipartisi (lebih dari node yang berbeda), tetapi semua database yang dipartisi tidak selalu terbelenggu' ?

Partisi lebih merupakan istilah umum untuk membagi data di seluruh tabel atau database. Sharding adalah satu jenis partisi khusus, bagian dari apa yang disebut partisi horisontal.

Di sini Anda mereplikasi skema di (biasanya) beberapa instance atau server, menggunakan semacam logika atau pengidentifikasi untuk mengetahui instance atau server mana untuk mencari data. Identifier semacam ini sering disebut "Kunci Shard".

Logika tanpa kunci yang umum adalah menggunakan alfabet untuk membagi data. AD adalah instance 1, EG adalah instance 2 dll. Data pelanggan cocok untuk ini, tetapi akan agak salah diartikan dalam ukuran di seluruh instance jika partisi tidak memperhitungkan bahwa beberapa huruf lebih umum daripada yang lain.

Teknik umum lainnya adalah dengan menggunakan sistem sinkronisasi logika atau kunci yang memastikan kunci unik di seluruh instance.

Contoh terkenal yang bisa Anda pelajari adalah bagaimana Instagram memecahkan partisi mereka di masa-masa awal (lihat tautan di bawah). Mereka mulai dipartisi pada beberapa server, menggunakan Postgres untuk membagi data dari awal. Saya percaya itu beberapa ribu pecahan logis pada beberapa pecahan fisik itu. Baca artikel lengkap mereka dari 2012 di sini: Instagram Engineering - Sharding & IDs

Lihat di sini juga: http://www.quora.com/Whats-the-difference-between-sharding-and-partition

Sepertinya ini menjawab kedua pertanyaan Anda:

Partisi horizontal membagi satu atau lebih tabel per baris, biasanya dalam satu contoh skema dan server database. Ini dapat menawarkan keuntungan dengan mengurangi ukuran indeks (dan dengan demikian upaya pencarian) asalkan ada beberapa cara yang jelas, kuat, dan implisit untuk mengidentifikasi di mana tabel baris tertentu akan ditemukan, tanpa terlebih dahulu perlu mencari indeks, misalnya, klasik contoh tabel 'CustomersEast' dan 'CustomersWest', di mana kode pos mereka sudah menunjukkan di mana mereka akan ditemukan.

Sharding melampaui ini: ia mem-partisi tabel-tabel yang bermasalah dengan cara yang sama, tetapi melakukan hal ini di beberapa contoh skema yang berpotensi. Keuntungan yang jelas adalah bahwa beban pencarian untuk tabel dipartisi besar sekarang dapat dibagi di beberapa server (logis atau fisik), bukan hanya beberapa indeks pada server logis yang sama.

Sumber: Wiki-Shard .

Sharding adalah proses menyimpan catatan data di beberapa mesin dan merupakan pendekatan MongoDB untuk memenuhi tuntutan pertumbuhan data. Dengan meningkatnya ukuran data, satu mesin mungkin tidak cukup untuk menyimpan data atau menyediakan throughput baca dan tulis yang dapat diterima. Sharding memecahkan masalah dengan penskalaan horizontal. Dengan sharding, Anda menambahkan lebih banyak mesin untuk mendukung pertumbuhan data dan tuntutan operasi baca dan tulis.

Sumber: MongoDB .

Saya telah menyelami ini juga dan meskipun saya sejauh ini referensi tentang masalah ini, ada beberapa fakta kunci yang saya kumpulkan dan poin yang ingin saya bagikan:

Sebuah partisi adalah sebuah divisi dari database logis atau elemen penyusunnya menjadi bagian-bagian independen yang berbeda. Database partisi biasanya dilakukan untuk pengelolaan, kinerja atau ketersediaan alasan, seperti untuk load balancing.

https://en.wikipedia.org/wiki/Partition_(database)

Sharding adalah jenis partisi, seperti Horizontal Partitioning (HP)

Ada juga Vertical Partitioning (VP) di mana Anda membagi tabel menjadi bagian-bagian kecil yang berbeda. Normalisasi juga melibatkan pemisahan kolom di seluruh tabel, tetapi partisi vertikal melampaui itu dan mem-partisi kolom bahkan ketika sudah dinormalisasi.

https://en.wikipedia.org/wiki/Shard_(database_architecture)

Saya sangat suka jawaban Tony Baco di Quora di mana dia membuat Anda berpikir dalam hal skema (daripada kolom dan baris). Dia menyatakan bahwa ...

" Partisi horizontal ", atau beling, mereplikasi [menyalin] skema, dan kemudian membagi data berdasarkan pada kunci beling.

" Partisi vertikal " melibatkan pembagian skema (dan data berjalan untuk perjalanan).

https://www.quora.com/Whats-the-difference-between-sharding-DB-tables-and-partitioning-them

Panduan Partisi Basis Data Oracle memiliki beberapa angka yang bagus. Saya telah menyalin beberapa kutipan dari artikel tersebut.

https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm

Kapan Partisi Tabel

Berikut adalah beberapa saran untuk kapan harus mempartisi tabel:

• Tabel yang lebih besar dari 2 GB harus selalu dianggap sebagai kandidat untuk partisi.
• Tabel yang berisi data historis, di mana data baru ditambahkan ke partisi terbaru. Contoh khas adalah tabel historis di mana hanya data bulan saat ini yang dapat diperbarui dan 11 bulan lainnya hanya dibaca.
• Ketika isi tabel perlu didistribusikan di berbagai jenis perangkat penyimpanan.

Pemangkasan Partisi

Pemangkasan partisi adalah cara paling sederhana dan juga paling substansial untuk meningkatkan kinerja menggunakan partisi. Pemangkasan partisi seringkali dapat meningkatkan kinerja kueri dengan beberapa urutan besarnya. Misalnya, anggap aplikasi berisi tabel Pesanan yang berisi catatan riwayat pesanan, dan bahwa tabel ini telah dipartisi berdasarkan minggu. Kueri yang meminta pesanan selama satu minggu hanya akan mengakses satu partisi dari tabel Pesanan. Jika tabel Pesanan memiliki 2 tahun data historis, maka kueri ini akan mengakses satu partisi, bukan 104 partisi. Kueri ini berpotensi mengeksekusi 100 kali lebih cepat hanya karena pemangkasan partisi.

Strategi Pemisahan

• Jarak
• Hash
• Daftar

Anda dapat membaca teks mereka dan memvisualisasikan gambar mereka yang menjelaskan semuanya dengan cukup baik.

Dan terakhir, penting untuk dipahami bahwa basis data sangat intensif sumber daya:

• CPU
• Disk
• I / O
• Penyimpanan

Banyak DBA akan mempartisi pada mesin yang sama, di mana partisi akan berbagi semua sumber daya tetapi memberikan peningkatan dalam disk dan I / O dengan memisahkan data dan / atau indeks.

Sementara strategi lain akan menggunakan arsitektur "tidak berbagi" di mana pecahan akan berada pada unit komputasi yang terpisah dan berbeda (node), memiliki 100% dari CPU, disk, I / O dan memori untuk dirinya sendiri. Memberikan keunggulan dan kompleksitasnya sendiri.

https://en.wikipedia.org/wiki/Shared_nothing_architecture

Pertimbangkan Tabel dalam basis data dengan 1 Juta baris dan 100 kolom Dalam Pemartisian, Anda dapat membagi tabel menjadi 2 atau lebih tabel yang memiliki properti seperti:

1. 0,4 Juta baris (table1), 0,6 juta baris (table2)

2. 1 Juta baris & 60 kolom (table1) dan 1 Juta baris & 40 kolom (table2)

   Mungkin ada banyak kasus seperti itu

Ini adalah partisi umum

Tapi Sharding merujuk pada kasus ke-1 hanya di mana kami membagi data berdasarkan baris. Jika kita membagi tabel menjadi beberapa tabel, kita perlu mempertahankan beberapa salinan skema serupa karena sekarang kita memiliki beberapa tabel.

Sharding dalam kasus khusus partisi horizontal , ketika partisi membentang di beberapa contoh database. Jika suatu database terbagi, itu berarti dipartisi berdasarkan definisi.

Ketika berbicara tentang partisi, jangan gunakan istilah replikasi atau replikasi. Replikasi adalah konsep yang berbeda dan di luar cakupan halaman ini. Ketika kita berbicara tentang pemartisian maka kata yang lebih baik adalah bagi dan ketika kita berbicara tentang sharding maka kata yang lebih baik didistribusikan. Dalam partisi (biasanya dan dalam pemahaman yang sama tidak selalu), deretan tabel kumpulan data besar dibagi menjadi dua atau lebih kelompok yang terpisah (tidak berbagi baris apa pun). Anda dapat memanggil setiap grup sebagai partisi. Grup-grup ini atau semua partisi tetap di bawah kendali RDMB sekali contoh dan ini semua logis. Basis setiap grup dapat berupa hash atau range atau dll. Jika Anda memiliki data sepuluh tahun dalam sebuah tabel, maka Anda dapat menyimpan data masing-masing tahun dalam partisi terpisah dan ini dapat dicapai dengan menetapkan batas-batas partisi berdasarkan kolom non-null CREATE_DATE. Setelah Anda query db maka jika Anda menentukan tanggal buat antara 01-01-1999 dan 31-12-2000 maka hanya dua partisi yang akan dipukul dan itu akan berurutan. Saya melakukan hal yang sama pada DB untuk catatan miliaran + dan waktu sql mencapai 50 juta dari 30 detik menggunakan indeks dll semua. Sharding adalah Anda meng-host setiap partisi pada node / mesin yang berbeda. Sekarang mencari di dalam partisi / pecahan dapat terjadi secara paralel.

Partisi horizontal ketika dipindahkan ke instance basis data lain * menjadi basis data .

Contoh basis data dapat berada di mesin yang sama atau di komputer lain.