Database / Operating System Co-Desig

n
ROSEMARIE NURMALASARI KASUMAPUTRI
201110370311280

OUTLINE

PAPER PROFILE
Diterbitkan di bawah Lisensi Creative Commons Attrib
ution (http://creativecommons.org/licenses/by/3.0 /)
karya asli penulis (s) dan CIDR 2013.
Jana Giceva, Tudor-Ioan Salomie, Adrian Schpbach
Gustavo Alonso, Timothy Roscoe
Systems Group, Department of Computer Science
ETH Zurich, Switzerland
www.systems.ethz.ch
6th Biennial Conference on Innovative Data Systems R
esearch (CIDR 13)
06-09 Januari 2013, Asilomar, California, Amerika Seri
kat.

ABSTRACT

Tren prosesor multicore dan virtualisasi hardware menimbulkan

tantangan struktural pada umumnya untuk sistem software dan
DB pada khususnya. Di satu sisi, mesin menjadi semakin hetero
gen (dalam hal hirarki cache, prosesor interkoneksi, set instruks
i, dll) sehingga membuatnya semakin sulit untuk mengembangk
an software yang optimal untuk semua platform mungkin. Di sisi
lain, virtualisasi memaksa DB untuk berbagi sumber daya denga
n aplikasi lain tanpa DB memiliki pengetahuan apapun tentang
kondisi runtime.

Tujuan adalah untuk mengintegrasikan DB ekstensif pengetahu

an internal sumber daya sendiri persyaratan-termasuk biaya mo
del-ke dalam system-wyde dan run-time pandangan dari konfig
urasi hardware dan aplikasi bauran tersedia di dalam OS.

INTRODUCTION

Masalah struktural Penggunaan sumber daya yang optimal memb

utuhkan pengetahuan tentang hardware (afinitas memori, hierarki cac
he, jarak interkoneksi, CPU/- core/die layout, dll) masalah diperparah
oleh meningkatnya keragaman mesin di pasaran.

Tujuan Sistem yang dihasilkan COD menggabungkan mesin penyi

mpanan DB didesain ulang untuk beroperasi dengan baik pada mesin
multi-core dengan tingkat OS mesin kebijakan yang bertanggung jawa
b membuat saran dan keputusan mengenai semua aspek penyebaran
DB.

Keunggulan Disisi hardware, peningkatan jumlah inti bertentanga

n dengan pendekatan synchronization-heavy untuk concurrency digu
nakan di kedua DB dan OS. Selain itu, meningkatkan heterogenitas ba
ik di dalam ataupun antara sistem.

BACKGROUND

1.

2.

COD dimotivasi oleh implikasi untuk kedua DB dan OS menggab

ungkan beberapa ide terbaru dari OS dan DBMS communities.
Database on Multycore: Column stores dan shared scans untu
k mengatasi masalah di desain database, khususnya untuk Onlin
e Analytical Processing (OLAP) dan Operational Business Intellig
ence (BI) beban kerja. COD menggunakan kedua teknik tersebu
t.
Opening Up The OS: menghilangkan abstraksi dari kernel dan
sebagai gantinya menerapkan banyak fungsi OS mungkin dalam
user-space library terhubung ke aplikasi - pendekatan yang digu
nakan dalam Exokernel dan Nemesis. Hal ini membuka ruang ba
gi application-specific tertentu, tetapi dengan sendirinya tidak
memecahkan masalah bagaimana setiap aplikasi dapat memeta
kan persyaratan ke sumber daya yang tersedia .

SYSTEM OVERVIEW

Fitur utama dari COD adalah interface antara database dan OS

sehingga database dapat memanfaatkan secara optimal sistem
yang tersedia sumber daya bahkan dalam dinamis, lingkungan y
ang bising mana saham mesin dengan aplikasi / tugas-tugas lai
n.
Gambar1

Karena database engine system yang kompleks dengan banya

k komponen, dalam makalah ini fokus pada storage engine. Th
e second building block adalah Kebijakan OS engine, layanan
disediakan oleh sistem operasi.
Ini menyatukan pengetahuan OS sumber daya perangkat kera
s yang tersedia (core dan NUMAdomain) dengan informasi ya
ng diberikan oleh aplikasi berjalan di atas. Hal ini memungkin
kan OS untuk mengatur lebih baik alokasi sumber daya baik di
antara menjalankan tugas dan dalam tertentu aplikasi.
Antara keduanya adalah query-based interface berbasis yang t
idak hanya memungkinkan untuk pertukaran informasi sistem
tingkat tetapi juga menyediakan sarana untuk membuat prose
dur tersimpan aplikasi-spesifik, mampu mengeksploitasi baik
pemecah kendala dan optimasi serta keseluruhan pengetahua
n yang ada di sisi OS. Ini ditandai dalam Gambar 1 (Arsitektur
COD. Blok Berbayang menunjukkan komponen utama)

INTERFACE

RUANG LINGKUP
Saat ini interface antara DB dan OS hanya meliputi komunikasi antara DB storage engine
(CSCS) dan OS policy engine. Sehingga memberikan dukungan untuk tindakan seperti: me
ngambil informasi tentang mendasari arsitektur dan sumber daya, menekan sifat applicatio
n-specific dan fungsi biaya dengan cara bahwa OS policy engine beberapa fungsi dasar ya
ng memungkinkan untuk arus informasi selama runtime.

IMPLEMENTASI
Pelaksanaan interface sangat tergantung pada OS policy engine karena diimplementasikan
sebagai user- space library, ditulis di Prolog dan menggunakan Eclipse bahasa CLP, sebagi
an besar core-functions interface menyerupai format Prolog.

EVALUASI
Applicability: Bagaimana hal itu dapat digunakan, di mana concrete scenario dan use-cas
e.
Overhead: Menyelidiki biaya untuk membuat setiap panggilan yang mempengaruhi laten
cy ; itu ukuran setiap pesan dan frekuensi terjadinya, baik dari yang mempengaruhi beba
n tambahan dikenakan pada bus sistem.

1.
2.

Article Reading@Hirota/Sakurai lab.

1/22/16

9
/39

EXPERIMENTS

COD dapat menyebarkan efisien pada berbagai konfigurasi mesin yang berbeda tanpa pen
getahuan sebelumnya dari hardware dan bereaksi terhadap beban tambahan pada sistem
untuk mempertahankan kinerja.

Setup percobaan: Dataset dan workload dalam percobaan ini adalah salah satu yang digun
akan oleh Unterbrunner et al. Hal ini dihasilkan dari jejak dari Amadeus sistem pemesanan
penerbangan online.

Menggunakan empat platform hardware yang berbeda untuk keragaman :

AMD Shanghai : Supermicro H8QM3 - 2 board dengan 4 quadcore 2.5GHzAMDOpteron 8
380 prosesor , dan RAM 16GB , diatur sebagai 4GB per NUMA simpul .
AMD Barcelona : . Papan TyanThunder S4985 dengan M4985 daughtercard dan 8 quad -c
ore 2GHz AMD Opteron 8350 prosesor dan RAM 16GB di 8 node NUMA .
Intel Nehalem - EX : . Supermicro X8Q86 papan dengan 4 8 core 1.87GHz prosesor Intel
Xeon L7555 dan RAM 128GB dengan ukuran simpul NUMA 32GB . Hyperthreading dinon
aktifkan .
AMDMagnyCours : papan Dell 06JC9T dengan 4 2.2GHzAMD Opteron 6174 prosesor dan
128GB RAMwith a NUMA ukuran node 16GB . Setiap prosesor memiliki dua meninggal 6 core .

1.
2.
3.

4.

Percobaan deployment pada mesin yang berbeda

Bagaimana COD dapat beradaptasi penyebaran CSCS untuk platform hardware yang berbeda menggunaka
n OS policy engine, memenuhi persyaratan kinerja SLA.
Tujuan utama use-case: untuk CSCS adalah menentukan penyebaran yang paling strategi yang sesuai pada
mesin tertentu sehingga memenuhinya waktu respon SLA. Dalam rangka untuk melakukan itu CSCS perlu u
ntuk memperoleh jumlah core untuk menjalankan scan threads dan ukuran yang benar dari data partisi.
Rincian Pelakdanaan: Sekarang menggambarkan interaksi antara CSCS dan OS policy engine dan bagaiman
a pertukaran informasi datang ke tempatnya. Sebagai diberikan pada Listing 1, di startup CSCS mengikat O
S policy engine dengan mendaftar untuk kedua RM dan SKB (baris 1-4); dan kemudian register sifat sistem-l
evel dengan SKB, yaitu bahwa adalah tugas CPU-bound yang bisa menggunakan semua core pada mesin da
n sangat cache dan NUMA-sensitif (baris 6-9).
Listing1: Menggunakan Interface

Kemudian System Knowladge Base (SKB) dengan fakta application-specific seperti ukuran dataset dalam tu
pel, ukuran sebuah tuple, ukuran bets dari permintaan yang dibutuhkan untuk menangani, waktu respon SL
A dan biaya fungsi (baris11-17). Akhirnya, register prosedur yang tersimpan (line 19) untuk mendapatkan ha
sil yang dibutuhkan: Nomor partisi, dan ukuran yang sesuai setiap partisi (lebih Rincian disediakan pada List
ing 3).

Listing2 berisi kode Prolog yang mengambil fakta sistem tingkat: daftar semua core yang tersedia, dan daftar ukuran semua NUMA
node '. kedua fungsi ini digunakan dalam prosedur yang tersimpan pada Listing3.
Listing2: Contoh untuk mengambil system-level facts

Listing 3: Prosedur penyebaran disimpan Initial CSCS

Awal penyebaran disimpan prosedur CSCS (Listing3) beroperasi dengan terlebih dahulu mengambil CSCS-spesifik facts (baris 4-6)
maka system-level facts yang diperlukan dengan menggunakan fungsi contoh diberikan pada Listing2 (baris 8-10). Hal ini terus die
ksekusi dengan menghitung total ukuran dataset (baris12) dan menghitung jumlah minimum core, seperti yang diminta oleh fungsi
biaya, asalkan selama fase inisialisasi (baris14). Karena CSCS adalah NUMA-sensitive, dataset perlu dipartisi dan didistribusikan di
node NUMA tersedia , dan setidaknya satu inti per NUMA simpul harus digunakan untuk menjamin akses data lokalitas. Akibatnya,
masing-masing ukuran partisi tidak boleh melebihi ukuran node NUMA.
Dengan demikian , prosedur yang tersimpan menghitung jumlah min core sehingga setiap partisi terkecil dari semua NUMA node
(baris 16-17). Jumlah akhir dari core/partisi yang dibutuhkan adalah maks dari kedua persyaratan (baris 18). Setelah ditentukan, ju
mlah akhir dari core digunakan untuk menghitung ukuran yang tepat dari partisi yang akan digunakan (baris 20). Akhirnya, cek pros
edur yang tersimpan apakah ukuran total dataset cocok ke memori utama dan jika jumlah core yang dibutuhkan sebenarnya tersed
ia dalam mesin .
Jika salah satu dari ini tidak benar, query gagal, memberitahu CSCS bahwa mesin ini tidak dapat memenuhi batasan yang diinginka
n (baris22-24) CSCS kemudian beroperasi pada hasil yang diperoleh dan partisi data yang sesuai.

Selama runtime , beberapa sifat - aplikasi tertentu dapat berubah : misalnya , ukuran batch
permintaan yang perlu untuk ditangani . Dalam hal CSCS hanya memodifikasi nilai-nilai ini
dalam mesin kebijakan OS , dan memicu re - perhitungan yang disimpan prosedur.
Hasil dari prosedur yang tersimpan hasil - aplikasi spesifik di CSCS ' sifat sistem - tingkat ba
ru yang ditambahkan dalam SKB . Dengan desain , setiap kali beberapa sifat sistem - spesifi
k mengubah atau ditambahkan / dihapus, RM memanggil fungsi alokasi global dalam mesi
n kebijakan untuk menghitung ID inti beton yang akan dialokasikan untuk semua aplikasi t
erdaftar .
Dalam penggunaan - kasus khusus ini, CSCS ' disimpan TSJ menghitung prosedur persyarat
an minimum jumlah inti dan ukuran partisi , yang keduanya ditambahkan sebagai sifat siste
m - tingkat di SKB . Setelah rencana alokasi global yang melengkapi perhitungan tersebut ,
RM mengirimkan CSCS sebuah upcall berisi ID inti beton untuk gunakan . Berdasarkan itu,
CSCS dapat pin benang pemindaian dan mengalokasikan memori dari node NUMA yang se
suai .
Kesimpulan dan kemungkinan ekstensi: Hasil menegaskan bahwa bahkan memiliki model
biaya lebih sederhana untuk operasi scan dapat mengakibatkan penyebaran baik ketika
mengetahui arsitektur yang mendasari . Idealnya , fungsi biaya harus juga mempertimbang
kan sifat prosesor lainnya ( seperti CPU frekuensi ) dan tata letak tembolok sehingga kita m
endapatkan hasil yang lebih akurat ketika deploying pada mesin yang berbeda .
Skenario ini dapat dengan mudah diperluas untuk operasi lain DBMS , terlepas dari meja p
enuh scan , selama kita mengembangkan sesuai fungsi biaya yang paling tepat menggamb
arkan dependensi operasi ini pada sumber daya sistem yang tersedia

CONCLUSION

Interaksi antara OS dan DB engine telah menjadi masalah sistem yang s

ulit selama beberapa dekade. Keduanya mencoba mengendalikan dan
mengelola sumber daya yang sama tetapi memiliki tujuan yang sangat b
erbeda.
Dengan munculnya multicore dan virtualisasi, DB tidak akan lagi berjala
n sendirian di server dan hardwere yang mendasari menjadi signifikan l
ebih kompleks dan heterogen. Bahkan karena perubahan ini, baik DB d
an OS yang meninjau arsitektur internal untuk mengakomodasi paraleli
sme skala besar. Menggunakan COD sebagai contoh, bahwa upaya des
ain ulang pada kedua sisi harus termasuk interface antara DB dan OS .
COD adalah bukti dari konsep yang dibangun dari beberapa prototipe
dan sistem eksperimental. Namun, COD menggambarkan dengan sang
at baik apa yang perlu diubah dalam kedua DB dan OS untuk mencapai
integrasi yang lebih baik serta bagaimana integrasi tersebut dapat terlih
at sejenisnya.

MY OPINION
GOOD OPINION:
Studi kasus dan rincian pelaksanaan percobaan sudah lengkap.
Disisi hardware, peningkatan jumlah inti bertentangan dengan
pendekatan synchronization-heavy untuk concurrency digunak
an di kedua DB dan OS. Selain itu, meningkatkan heterogenitas
baik di dalam ataupun antara sistem.

BAD OPINION:
Interaksi antara OS dan DB engine mencoba mengendalikan da
n mengelola sumber daya yang sama tetapi memiliki tujuan yan
g sangat berbeda sehingga menjadi masalah sistem yang sulit s
elama beberapa dekade.