Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik terbaik untuk memodelkan data relasional di DynamoDB

Bagian ini menyediakan praktik terbaik untuk memodelkan data relasional di Amazon DynamoDB. Pertama, kami memperkenalkan konsep pemodelan data tradisional. Kemudian, kami menjelaskan keuntungan menggunakan DynamoDB dibandingkan sistem manajemen basis data relasional tradisional—bagaimana menghilangkan kebutuhan akan operasi dan mengurangi overhead. JOIN

Kami kemudian menjelaskan cara menyusun tabel DynamoDB yang menskalakan secara efisien. Terakhir, kami memberikan contoh cara memodelkan data relasional di DynamoDB.

Model basis data relasional traditional

Sistem manajemen basis data relasional tradisional (RDBMS) menyimpan data dalam struktur relasional yang dinormalisasi. Tujuan dari model data relasional adalah untuk mengurangi duplikasi data (melalui normalisasi) untuk mendukung integritas referensial dan mengurangi anomali data.

Skema berikut adalah contoh dari model data relasional untuk penerapan urutan-entri generik. Penerapan ini mendukung skema sumber daya manusia yang mendukung sistem pendukung operasional dan bisnis dari produsen teoretis.

Sebagai layanan basis data non-relasional, DynamoDB menawarkan banyak keunggulan dibandingkan sistem manajemen basis data relasional tradisional.

Bagaimana DynamoDB menghilangkan kebutuhan akan operasi JOIN

An RDBMS menggunakan bahasa query struktur (SQL) untuk mengembalikan data ke aplikasi. Karena normalisasi model data, kueri semacam ini biasanya memerlukan penggunaan operator JOIN untuk menggabungkan data dari satu atau beberapa tabel.

Misalnya, untuk menghasilkan daftar item pesanan pembelian yang diurutkan berdasarkan jumlah stok di semua gudang yang dapat mengirimkan setiap item, Anda dapat mengeluarkan SQL kueri berikut terhadap skema sebelumnya.

SELECT * FROM Orders
  INNER JOIN Order_Items ON Orders.Order_ID = Order_Items.Order_ID
  INNER JOIN Products ON Products.Product_ID = Order_Items.Product_ID
  INNER JOIN Inventories ON Products.Product_ID = Inventories.Product_ID
  ORDER BY Quantity_on_Hand DESC

SQLkueri semacam ini dapat memberikan fleksibilitas API untuk mengakses data, tetapi mereka membutuhkan sejumlah besar pemrosesan. Setiap gabungan dalam kueri meningkatkan kompleksitas runtime kueri karena data untuk setiap tabel harus ditahapkan dan kemudian dikumpulkan untuk mengembalikan set hasil.

Faktor lain yang dapat memengaruhi durasi yang dibutuhkan untuk menjalankan kueri adalah ukuran tabel dan apakah kolom yang digabungkan memiliki indeks. Kueri sebelumnya memulai kueri kompleks di beberapa tabel, lalu mengurutkan set hasilnya.

Menghilangkan kebutuhan JOINs adalah inti dari No SQL data modeling. Inilah sebabnya kami membangun DynamoDB untuk mendukung Amazon.com, dan mengapa DynamoDB dapat memberikan performa yang konsisten di semua skala. Mengingat kompleksitas runtime SQL kueri danJOINs, RBDMS kinerja tidak konstan pada skala. Hal ini menyebabkan masalah performa seiring berkembangnya aplikasi pelanggan.

Sementara normalisasi data memang mengurangi jumlah data yang disimpan ke disk, seringkali sumber daya yang paling dibatasi yang memengaruhi kinerja adalah latensi CPU waktu dan jaringan.

DynamoDB dibangun untuk meminimalkan kendala tersebut dengan menghilangkan JOINs (dan mendorong denormalisasi data) dan mengoptimalkan arsitektur basis data untuk sepenuhnya menjawab kueri aplikasi dengan satu permintaan ke item. Kualitas ini memungkinkan DynamoDB untuk menghadirkan performa milidetik satu digit di semua skala. Ini karena kompleksitas runtime untuk operasi DynamoDB konstan, terlepas dari ukuran data, untuk pola akses umum.

Bagaimana transaksi DynamoDB menghilangkan overhead ke proses tulis

Faktor lain yang dapat memperlambat RDBMS adalah penggunaan transaksi untuk menulis ke skema yang dinormalisasi. Seperti yang ditunjukkan dalam contoh, struktur data relasional yang digunakan oleh sebagian besar aplikasi pemrosesan transaksi online (OLTP) harus dipecah dan didistribusikan di beberapa tabel logis ketika disimpan dalam fileRDBMS.

Oleh karena itu, kerangka kerja transaksi yang ACID sesuai diperlukan untuk menghindari kondisi balapan dan masalah integritas data yang dapat terjadi jika aplikasi mencoba membaca objek yang sedang dalam proses penulisan. Kerangka transaksi semacam itu, jika digabungkan dengan skema relasional, dapat menambah overhead yang signifikan untuk proses tulis.

Implementasi transaksi di DynamoDB melarang masalah penskalaan umum yang ditemukan dengan file. RDBMS DynamoDB melakukan ini dengan mengeluarkan transaksi sebagai panggilan API tunggal dan membatasi jumlah item yang dapat diakses dalam transaksi tunggal itu. Transaksi yang berjalan lama dapat menyebabkan masalah operasional karena mengunci data dalam jangka waktu yang lama, atau terus-menerus, karena transaksi tidak pernah ditutup.

Untuk mencegah masalah seperti itu di DynamoDB, transaksi diimplementasikan dengan dua operasi API berbeda: dan. TransactWriteItems TransactGetItems APIOperasi ini tidak memiliki semantik awal dan akhir yang umum di. RDBMS Selanjutnya, DynamoDB memiliki batas akses 100 item dalam transaksi untuk mencegah transaksi yang berjalan lama. Untuk mempelajari selengkapnya tentang transaksi DynamoDB, lihat Bekerja dengan transaksi.

Untuk alasan ini, ketika bisnis Anda memerlukan respons latensi rendah terhadap permintaan lalu lintas tinggi, memanfaatkan SQL sistem No umumnya masuk akal secara teknis dan ekonomi. Amazon DynamoDB membantu memecahkan masalah yang membatasi skalabilitas sistem relasional dengan menghindari masalah tersebut.

Kinerja sebuah biasanya RDBMS tidak berskala baik karena alasan berikut:

DynamoDB menskalakan dengan baik karena alasan berikut:

Kueri terhadap penyimpanan data menjadi jauh lebih sederhana, sering kali dalam bentuk berikut:

SELECT * FROM Table_X WHERE Attribute_Y = "somevalue"

DynamoDB melakukan pekerjaan yang jauh lebih sedikit untuk mengembalikan data yang diminta dibandingkan dengan contoh RDBMS sebelumnya.