Postgres dalam retrospeksi

Kami memberi perhatian Anda terjemahan dari artikel Joseph Hellerstein "Melihat Kembali di Postgres" , yang diterbitkan di bawah Creative Commons, afirmasi hak cipta internasional versi 4.0 (CC-BY 4.0). Penulis berhak untuk mendistribusikan karya ini di situs web pribadi dan perusahaan dengan tautan yang sesuai ke sumbernya.

Terjemahan dibuat oleh Elena Indrupskaya. Saya akan menambahkan dari diri saya bahwa "seorang programmer yang sangat ingin membangun sistem dengan multi-versi" tampaknya adalah Vadim Mikheev, tetapi kita semua tahu "sukarelawan dari Rusia" yang menulis ulang GiST.

Anotasi


Ini adalah ingatan akan proyek Postgres, dijalankan di University of California di Berkeley dan dipimpin oleh Mike Stonebraker dari pertengahan 1980-an hingga pertengahan 1990-an. Sebagai salah satu dari banyak kenangan pribadi dan sejarah, artikel ini diminta untuk buku [ Bro19 ] tentang Penghargaan Turing Stonebreaker. Oleh karena itu, fokus artikel adalah pada peran utama Stonebreaker dan pemikirannya tentang desain. Tetapi Stonebreaker tidak pernah menjadi programmer dan tidak mengganggu tim pengembangannya. Basis kode Postgres adalah hasil kerja tim mahasiswa yang brilian dan kadang-kadang programmer universitas penuh waktu yang memiliki pengalaman sedikit lebih banyak (dan hanya gaji yang sedikit lebih besar) daripada mahasiswa. Saya cukup beruntung untuk bergabung dengan tim ini sebagai siswa di tahun-tahun terakhir proyek ini. Saya menerima bahan yang berguna untuk artikel ini dari beberapa siswa yang lebih tua yang terlibat dalam proyek, tetapi kesalahan atau kelalaian adalah milik saya. Jika Anda melihat ada di antara mereka, silakan hubungi saya dan saya akan mencoba memperbaikinya.

1. Pendahuluan


Postgres adalah proyek paling ambisius Michael Stonebreaker - upayanya yang serius untuk menciptakan sistem basis data universal. Selama satu dekade, proyek ini telah melahirkan lebih banyak artikel, PhD, profesor, dan perusahaan daripada aktivitas Stonebreaker lainnya. Proyek ini juga mencakup lebih banyak bidang teknis daripada sistem lain yang ia bangun. Terlepas dari risiko inheren sebesar ini, Postgres juga menjadi artefak perangkat lunak paling sukses yang keluar dari tim peneliti Stonebreaker, dan kontribusinya yang utama pada open source. Ini adalah contoh dari "sistem kedua" [ Bro75 ] yang telah berhasil. Pada saat penulisan, lebih dari tiga puluh tahun sejak awal proyek, sistem open source PostgreSQL adalah sistem basis data sumber terbuka independen paling populer di dunia dan sistem basis data keempat yang paling populer. Sementara itu, perusahaan yang dibuat dari Postgres menghasilkan total lebih dari $ 2,6 miliar (biaya perolehan). Dengan ukuran apa pun, visi Postgres Stonebreaker memiliki resonansi abadi yang besar.

1.1. Latar belakang


Stonebreaker adalah sukses besar di awal karirnya dengan proyek penelitian Ingres Berkeley [ SHWK76 ] dan startup berikutnya, yang ia dirikan bersama Larry Rowe dan Eugene Wong: Relational Technology, Inc. (RTI).

Ketika RTI dikembangkan pada awal 1980-an, Stonebreaker mulai bekerja untuk mendukung tipe data dalam DBMS yang melampaui baris dan kolom tradisional model relasional Codd (Edgar Frank Codd). Contoh yang memotivasi pada waktu itu adalah kebutuhan akan basis data untuk mendukung perangkat desain berbantuan komputer (CAD) untuk industri mikroelektronika. Dalam artikel 1983 oleh Stonebreaker dan mahasiswa, Brad Rubenstein dan Antonin Guttman menjelaskan betapa industri ini perlu mendukung "tipe data baru seperti poligon, persegi panjang, string teks, dll.", " pencarian spasial yang efektif "," kendala integritas kompleks ", serta" desain hierarki dan representasi ganda "dalam struktur fisik yang sama [ SRG83 ]. Dengan motivasi ini, kelompok mulai bekerja pada pengindeksan (termasuk menggunakan Guttman R-tree untuk pengindeksan spasial [ Gut84 ]) dan tentang menambahkan tipe data abstrak (ADT) ke sistem database relasional. Pada saat itu, ADT adalah konstruksi bahasa pemrograman baru yang populer, yang pertama kali diperkenalkan oleh Barbara Liskov, kemudian penerima hadiah Turing, dan diteliti dalam pemrograman aplikasi basis data oleh kolaborator Stonebreaker baru, Larry Rowe. Sebuah artikel dalam Catatan SIGMOD 1983 [ OFS83 ] Stonebreaker dan siswa James Ong dan Dennis Fogg menggambarkan studi konsep ini dalam ekstensi Ingres yang disebut ADT-Ingres, yang menggabungkan banyak konsep presentasi yang dipelajari lebih dalam dan dengan dukungan sistem yang lebih baik di Postgres.

2. Postgres: informasi umum


Seperti namanya, Postgres adalah Post-Ingres: sistem yang dirancang untuk mengambil apa yang bisa dilakukan Ingres dan melampauinya. Ciri khas Postgres adalah pengenalan apa yang pada akhirnya disebut sebagai objek-relasional dari basis data: dukungan untuk konsep pemrograman berorientasi objek dalam model data dan bahasa query deklaratif dari sistem basis data. Tetapi Stonebreaker juga berencana untuk memecahkan sejumlah masalah teknologi lain yang tidak bergantung pada dukungan berorientasi objek di Postgres, seperti aturan basis data aktif, data berversi, penyimpanan tersier, dan konkurensi.

Dua artikel ditulis pada desain Postgres: deskripsi desain awal pada tahun 1986 SIGMOD [ SR86 ] dan deskripsi antara dalam CACM 1991 [ SK91 ]. Proyek penelitian Postgres secara bertahap menjadi sia-sia pada tahun 1992 dengan fondasi Illustra, sebuah startup startup yang melibatkan Stonebreaker, mahasiswa pascasarjana Wei Hong dan kemudian menjadi ketua programer Jeff Meredith. Dalam daftar di bawah ini, peluang yang disebutkan dalam artikel 1986 ditandai dengan tanda bintang *, dan peluang dari artikel 1991, yang tidak ada dalam artikel 1986, ditandai dengan belati . Tugas-tugas lain yang tercantum di bawah ini diambil dalam sistem dan literatur penelitian, tetapi mereka tidak ditemukan dalam spesifikasi desain. Banyak dari topik ini dibahas di Postgres jauh sebelum dipelajari atau diciptakan kembali oleh orang lain. Dalam banyak kasus, Postgres terlalu maju dari masanya, dan minat pada topik semakin meluas, dari perspektif modern.

  1. Dukungan ADT dalam sistem basis data
    • Objek kompleks (mis., Data bersarang atau data formulir non-pertama-normal (bentuk non-pertama-normal - NF2)) *
    • Jenis dan Fungsi Data Abstrak Kustom *
    • Metode akses yang dapat diperluas untuk tipe data baru *
    • Pemrosesan query yang dioptimalkan dengan fitur yang ditentukan pengguna yang mahal
  2. Database aktif dan sistem aturan (pemicu, peringatan) *
    • Aturan diterapkan sebagai permintaan penulisan ulang
    • Aturan diterapkan sebagai pemicu tingkat perekaman
  3. Penyimpanan dan Pemulihan Berbasis Log
    • Kode pemulihan kompleksitas yang berkurang yang memperlakukan log sebagai data *, menggunakan memori yang tidak mudah menguap untuk status komit
    • Penyimpanan non-ditulis ulang dan pertanyaan temporal
  4. Dukungan untuk teknologi penyimpanan dalam yang baru, terutama disk optik *
  5. Dukungan untuk multiprosesor dan prosesor khusus *
  6. Dukungan untuk berbagai model bahasa
    • Perubahan minimal pada model relasional dan dukungan untuk pertanyaan deklaratif *
    • Akses ke "jalur cepat" dari API internal yang melewati bahasa permintaan
    • Multilingualisme

Kami akan membahas secara singkat kontribusi Postgres untuk setiap item ini sehubungan dengan pekerjaan selanjutnya di bidang komputasi.

2.1. Dukungan ADT dalam sistem basis data


Tujuan Postgres yang jelas adalah untuk mendukung properti-objek relasional baru: memperluas teknologi database untuk memberikan manfaat dari pemrosesan query relasional dan pemrograman berorientasi objek. Seiring waktu, konsep objek-relasional yang pertama kali muncul di Postgres menjadi fungsionalitas standar di sebagian besar sistem database modern.

2.1.1. Benda kompleks


Cukup sering, data direpresentasikan sebagai entitas bersarang atau "objek". Contoh klasik adalah pesanan pembelian, yang memiliki serangkaian produk tertanam, jumlah dan harganya. Agama pemodelan relasional menentukan bahwa data tersebut harus direstrukturisasi dan disimpan dalam format tanpa bersarang, menggunakan beberapa tabel objek datar (pesanan, produk) dengan menghubungkan tabel relasi datar (product_in_order). Alasan khas untuk perataan ini adalah mengurangi duplikasi data (karena produk dijelaskan secara berlebihan dalam banyak pesanan pembelian), yang, pada gilirannya, menghindari kompleksitas atau kesalahan saat memperbarui semua salinan yang berlebihan. Tetapi dalam beberapa kasus, Anda ingin menyimpan subview, karena itu wajar untuk aplikasi (misalnya, mekanisme tata letak sirkuit dalam CAD), dan pembaruan jarang terjadi. Debat tentang pemodelan data ini setidaknya setua model relasional.

Pendekatan utama Postgres adalah “duduk di dua kursi” dalam hal pemodelan data: Postgres menyimpan tabel sebagai tipe data “paling eksternal”, tetapi memungkinkan kolom memiliki tipe “kompleks”, termasuk tupel atau tabel bersarang. Salah satu implementasi yang kurang umum, pertama kali diselidiki dalam prototipe ADT-Ingres, adalah untuk memungkinkan kolom tipe tabel dideklarasikan secara deklaratif sebagai definisi kueri: "Quel sebagai tipe data" [ SAHR84 ] (Quel - bahasa permintaan Ingres. - Approx. Per. .) .

Topik dukungan "pasca-relasional" untuk pertanyaan deklaratif dan data yang disematkan telah muncul kembali selama bertahun-tahun, sering kali dihasilkan oleh perselisihan tentang mana yang lebih baik. Selama masa Postgres pada 1980-an dan 1990-an, beberapa kelompok yang terlibat dalam database berorientasi objek mengambil ide ini dan mengembangkannya ke dalam bahasa OQL standar, yang kemudian tidak lagi digunakan.

Pada pergantian milenium, pertanyaan deklaratif pada objek bersarang menjadi obsesi dengan penelitian untuk segmen komunitas pengembang basis data dalam bentuk basis data XML. Bahasa XQuery yang dihasilkan (dipimpin oleh Don Chamberlin, persona dari SQL) diperlukan untuk mendukung objek kompleks dalam bahasa Postgel Postgres. XQuery banyak digunakan dan banyak digunakan dalam industri, tetapi tidak pernah populer dengan pengguna. Saat ini, konsep-konsep ini sedang diperiksa ulang dalam proyek bahasa query untuk model data JSON, populer di aplikasi berbasis browser. Seperti OQL, dalam kelompok yang awalnya menolak permintaan deklaratif yang mendukung pemrograman berorientasi pengembang (gerakan "NoSQL"), bahasa-bahasa ini sering muncul sebagai tambahan terlambat hanya dari keinginan untuk menambahkan pertanyaan kembali ke sistem. Pada saat yang sama, ketika Postgres tumbuh selama bertahun-tahun (dan pindah dari bahasa query Postquel ke versi SQL yang memenuhi banyak tujuan yang dipertimbangkan), itu termasuk dukungan untuk data yang disematkan, seperti XML dan JSON, dalam DBMS tujuan umum, tanpa memerlukan atau desain ulang yang signifikan. Kontroversi berjalan dengan berbagai tingkat keberhasilan, dan pendekatan Postgres untuk memperluas struktur relasional menggunakan ekstensi untuk data bersarang telah berulang kali membuktikan dirinya sebagai keadaan akhir alami bagi semua pihak setelah argumen mereda.

2.1.2. Jenis dan Fungsi Data Abstrak Kustom


Selain menyarankan tipe bersarang, Postgres mengajukan gagasan untuk memperkenalkan ADT yang buram dan dapat diperluas yang disimpan dalam database tetapi tidak diinterpretasikan oleh kernel. Pada dasarnya, ini selalu menjadi bagian dari model relasional Codd: bilangan bulat dan string bersifat tradisional, tetapi pada kenyataannya model relasional mencakup semua tipe data atom dengan predikat. Tugasnya adalah untuk menyediakan fleksibilitas matematis dalam perangkat lunak. Untuk menggunakan kueri yang menafsirkan objek-objek ini dan memanipulasinya, seorang programmer aplikasi harus dapat mendaftarkan fungsi-fungsi yang didefinisikan pengguna (UDF) untuk tipe-tipe ini dalam sistem dan memanggil fungsi-fungsi ini dalam kueri. Juga diinginkan bahwa fungsi agregat yang ditentukan pengguna (UDA) merangkum koleksi objek-objek ini dalam query. Sistem database Postgres telah inovatif, secara komprehensif mendukung fitur-fitur ini.

Mengapa menempatkan fungsi seperti itu dalam DBMS, daripada di aplikasi tingkat tinggi? Jawaban khas untuk pertanyaan ini adalah keuntungan yang signifikan dalam kinerja kode yang ditempatkan pada data daripada "menarik" data ke kode. Postgres menunjukkan bahwa ini cukup alami dalam lingkungan relasional: hanya perubahan kecil yang diperlukan dalam katalog metadata relasional dan mekanisme panggilan kode pihak ketiga yang dibuat, tetapi sintaks kueri, semantik, dan arsitektur sistem bekerja dengan sederhana dan elegan.

Postgres sedikit lebih maju dalam mengeksplorasi fungsi ini. Secara khusus, pada saat itu, komunitas riset basis data tidak terlalu khawatir tentang implikasi keamanan mengunduh kode tidak aman ke server. Ini mulai dianggap sebagai masalah ketika teknologi diperhatikan dalam industri. Stonebreaker membawa Postgres ke pasaran dalam startupnya Illustra, yang diperoleh Informix sebagian besar karena kemampuannya untuk mendukung paket ekstensi DataBlade, termasuk UDF. Informix, dengan teknologi berbasis Postgres dan penawaran basis data paralel yang kuat, telah menjadi ancaman signifikan bagi Oracle. Oracle telah banyak berinvestasi dalam pemasaran negatif risiko yang terkait dengan kemampuan Informix untuk menjalankan kode C pengguna yang "tidak aman". Beberapa atribut kematian Informix untuk kampanye ini, meskipun penipuan keuangan Informix (dan penuntutan federal berikutnya CEO saat itu) tentu menghadirkan masalah yang lebih serius. Sekarang, beberapa dekade kemudian, semua penyedia basis data utama mendukung fungsi kustom dalam satu atau beberapa bahasa, menggunakan teknologi baru untuk melindungi dari kerusakan server atau kerusakan data.

Sementara itu, tumpukan teknologi dari data besar tahun 2000-an, termasuk fenomena MapReduce, yang “banyak sekali darahnya” oleh Stonebreaker dan David DeWitt [ DS08 ], adalah implementasi ulang gagasan Postgres - kode pengguna yang diposting sebagai bagian dari permintaan. Tampaknya MapReduce sebagian besar menggabungkan ide pengembangan perangkat lunak Postgres dengan ide konkurensi dari sistem seperti Gamma dan Teradata, dengan beberapa inovasi kecil seputar memulai kembali proses permintaan beban kerja dengan skalabilitas yang ekstrem. Startup berdasarkan Postgres, Greenplum dan Aster, sekitar 2007, menunjukkan bahwa paralelisasi Postgres dapat mengarah pada sesuatu yang jauh lebih fungsional dan praktis daripada MapReduce untuk sebagian besar pelanggan, tetapi pada tahun 2008 pasar masih belum siap untuk teknologi ini. . Sekarang, pada tahun 2018, hampir setiap tumpukan data besar pada dasarnya menangani beban kerja SQL paralel dengan UDF, yang sangat mirip dengan desain yang pertama kali digunakan oleh Stonebreaker dan tim di Postgres.

2.1.3. Metode Akses yang Dapat Diperpanjang untuk Jenis Data Baru


Database relasional dikembangkan sekitar waktu yang sama dengan pohon B pada awal 1970-an, dan pohon B membantu memberi Codd mimpi "kebebasan dari penyimpanan data fisik": pengindeksan dengan pohon B memberikan tingkat tipuan yang Adaptasi menata ulang penyimpanan fisik tanpa memerlukan perubahan aplikasi. Keterbatasan utama B-tree dan struktur yang terkait adalah bahwa mereka hanya mendukung pencarian kesetaraan dan pertanyaan dalam rentang satu dimensi. Tetapi bagaimana jika Anda memiliki kueri rentang 2 dimensi yang khas untuk aplikasi pemetaan dan CAD? Masalah ini diketahui selama Postgres, dan R-tree [ Gut84 ], yang dikembangkan oleh Antonin Guttman dalam kelompok Stonebreaker, adalah salah satu indeks baru paling sukses yang dirancang untuk memecahkan masalah ini dalam praktiknya. Namun, penemuan struktur indeks tidak memecahkan masalah mendukung rentang multidimensi dalam DBMS untuk sistem yang kompleks. Ada banyak pertanyaan. Bisakah Anda dengan mudah menambahkan metode akses, seperti R-tree, ke DBMS Anda? Bisakah Anda mengajarkan pengoptimal untuk memahami bahwa metode akses yang ditentukan akan berguna untuk pertanyaan tertentu? Bisakah Anda mencapai pemulihan yang benar dan akses simultan? Ini adalah titik yang sangat berani dalam rencana aksi Postgres: masalah arsitektur perangkat lunak yang mempengaruhi sebagian besar mesin basis data, dari pengoptimal ke tingkat penyimpanan, serta sistem penjurnalan dan pemulihan. Postgres R-tree telah menjadi kekuatan pendorong yang kuat dan contoh utama dari ekstensibilitas yang elegan dari lapisan metode akses dan integrasinya ke dalam optimizer permintaan. Postgres menunjukkan, menggunakan ADT buram, bagaimana mendaftarkan metode akses yang dijelaskan secara abstrak (dalam hal ini pohon-R), dan bagaimana pengoptimal query dapat mengenali predikat seleksi abstrak (dalam hal ini, pilihan rentang) dan mencocokkannya dengan metode akses yang dijelaskan secara abstrak ini. Kurang perhatian diberikan untuk kontrol akses bersamaan dalam pekerjaan awal: kurangnya pemesanan satu dimensi kunci membuat kunci yang digunakan dalam B-tree dalam kasus ini tidak dapat diterapkan.

Fitur yang menjanjikan dari metode akses extensible Postgres menginspirasi salah satu proyek penelitian pertama saya di akhir sekolah pascasarjana: Generalized Search Trees - GiST [ HNP95 ] dan konsep selanjutnya dari teori pengindeksan [ HKM + 02 ]. Saya menerapkan GiST di Postgres selama satu semester setelah menyelesaikan gelar doktor saya, yang membuat menambahkan logika pengindeksan baru untuk Postgres lebih mudah. Disertasi Marcel Kornacker dari Berkeley (Marcel Kornacker) memecahkan masalah kompleks pemulihan dan akses simultan, yang ditimbulkan oleh tipe "templat" indeks GiST [ KMH97 ] yang dapat diperluas .

Hari ini, PostgreSQL menggabungkan arsitektur perangkat lunak asli dari metode akses yang dapat diperluas (memiliki indeks B-tree, GiST, SP-GiST, dan Gin) dengan ekstensibilitas dan akses kompetitif yang intens dari antarmuka Generalized Search Tree (GiST). Indeks GiST mendukung sistem geo-informasi PostGIS yang populer berdasarkan PostgreSQL. Indeks Gin menyediakan dukungan pengindeksan teks internal di PostgreSQL.

2.1.4. Pengoptimal Permintaan dengan UDF Mahal


Dalam optimisasi kueri tradisional, tugasnya adalah meminimalkan jumlah aliran tuple (dan karenanya operasi I / O) yang dibuat saat memproses permintaan. Ini berarti bahwa pernyataan yang memfilter tupel (fetch) bagus di awal rencana kueri, sedangkan pernyataan yang dapat menghasilkan tupel baru (gabung) perlu dieksekusi nanti. Akibatnya, pengoptimal permintaan akan "mendorong" operator pengambilan di bawah koneksi dan mengaturnya secara acak, sebagai gantinya berfokus pada optimasi koneksi dan akses disk yang cerdas. UDF telah mengubah pendekatan: jika Anda memiliki UDF mahal dalam laporan sampel Anda, urutan pelaksanaan UDF dapat menjadi penting untuk mengoptimalkan kinerja. Selain itu, jika UDF dalam operator seleksi benar-benar membutuhkan banyak waktu, ada kemungkinan bahwa pemilihan harus dilakukan setelah koneksi (yaitu, pemilihan harus "menarik" - pemilihan "menarik"). Mempertimbangkan faktor-faktor ini telah mempersulit ruang pencarian pengoptimal. Saya menganggap masalah ini sebagai tugas sulit pertama di sekolah pascasarjana, dan akhirnya menjadi subjek pekerjaan master saya dengan Stonebreaker di Berkeley dan gelar Ph.D saya di Wisconsin di bawah arahan Jeff Naughton, tetapi dengan bantuan terus-menerus dari Stonebreaker. Postgres adalah DBMS pertama yang menyimpan biaya dan selektivitas fungsi yang ditentukan pengguna dalam direktori basis data. Kami mendekati masalah pengoptimalan, setelah menghasilkan urutan operasi pengambilan sampel yang optimal, dan kemudian pergantian operasi pengambilan sampel yang optimal di sepanjang cabang masing-masing pohon koneksi yang dipertimbangkan dalam pencarian rencana. System R .

, , . , , .

PostgreSQL , . , , , , 2018 . , , , , , . , Postgres .

, , , PostgreSQL (Neil Conway), « » .

2.2.


Postgres . : , « », 1990- .

. — Datalog. « » : , , .

Datalog , - . Datalog — « » . , , .

, , , , . .

(Eric Hanson), Ingres, Postgres. (Spyros Potamianos) PRS2: Postgres Rules System 2. . — . , Ingres. « » « ». , « » « 10%». , « », . ( ), .

PRS2 , , . Postgres (, ) Postgres 3.1 1991 ( ):

 
*        :
*     .        
*  (. .        
* "" )    .   -  
*   () .        .
*   .    .     
*   .  ...
* ,  , ? ,    ,  .
*         , 
*  ... 

Postgres , «» — . PostgreSQL, - .

Postgres « » IBM Starburst MCC HiPAC. SQL . . , , , , « »: , . , - , , , , . , , , , Postgres.

2.3. X


Postgres :
Postgres, - . (write-ahead log — WAL), , . , Ingres 1970- , . [ SK91 ]
, , . , IBM Tandem . : - , , , .

X Postgres . , , , — « » « » . , , — . , «» . : , . Postgres, , , , [ Sto87 ]. Postgres .

« » , , . . , , , , Postgres. Postgres . PostgreSQL .

, PostgreSQL : . , PostgreSQL , Postgres, , Postgres . , (snapshot isolation) Oracle -, .

(Mike Olson) , , B- Postgres B- Berkeley DB, Postgres. . Berkeley DB Sleepycat Corp., () PostgreSQL « ». : , (MVCC), , .

PostgreSQL . Greenplum PostgreSQL . (Matt McCline)— (Jim Gray) Tandem. .

. , NoSQL ( , WAL), (MMDB — main memory databases, ). , . , .

2.4.


Di tengah-tengah proyek Postgres, Stonebreaker mendaftar sebagai salah satu eksekutif untuk hibah ilmu tanah digital besar yang disebut Project Sequoia. Bagian dari proposal hibah adalah pemrosesan jumlah citra satelit digital yang belum pernah terjadi sebelumnya, yang membutuhkan memori hingga 100 terabyte, yaitu jumlah data yang jauh lebih besar daripada yang sebaiknya disimpan pada disk magnetik pada waktu itu. Dasar dari solusi yang diusulkan adalah untuk menyelidiki ide untuk menciptakan DBMS (yaitu Postgres), yang memfasilitasi akses ke penyimpanan "tersier" semi-otonom yang disediakan oleh drive robot dengan penggantian disk otomatis untuk mengelola disk optik atau tape library.

Ini menyebabkan beberapa penelitian berbeda. Salah satunya adalah sistem file Inversion - upaya untuk memberikan abstraksi dari sistem file UNIX melalui DBMS relasional. Dalam sebuah artikel ulasan untuk Sequoia, Stonebreaker menggambarkannya dalam gaya yang biasa digunakannya untuk “latihan sederhana” [ Sto95 ]. Bahkan, Mike Olson, seorang siswa di Stonebreaker (dan pendiri Cloudera berikutnya), telah sibuk dengan hal ini selama beberapa tahun, dan hasil akhirnya tidak terlalu mudah [ Ols93 ] dan tidak bertahan dalam praktik.

Beberapa tahun kemudian, Inversion Bill Gates "bertarung melawan kincir angin yang sama" di WinFS - sebuah upaya untuk menciptakan kembali sistem file yang paling banyak digunakan di dunia di bagian belakang database relasional. WinFS dikirim dalam versi pengembangan Windows, tetapi tidak pernah masuk pasar. Gates kemudian menyebutnya kekecewaan terbesarnya pada Microsoft.

Bidang utama lain dari penelitian pada bagian depan ini adalah dimasukkannya repositori tersier pada tumpukan database relasional yang lebih tipikal, yang merupakan subjek dari tesis PhD oleh Sunita Sarawagi. Topik utama adalah mengubah skala di mana Anda berpikir tentang mengelola ruang (mis., Data dalam penyimpanan dan hierarki memori) dan waktu (mengoordinasikan penjadwalan kueri dan cache untuk meminimalkan I / O yang tidak diinginkan). Salah satu masalah utama dalam pekerjaan ini adalah menyimpan array multidimensi besar dalam penyimpanan tersier dan mengambilnya, yang menggemakan pekerjaan di bidang pengindeksan multidimensi. Ide-ide kunci termasuk membagi array menjadi bagian-bagian dan menyimpan bersama bagian-bagian yang dipilih bersama, serta mereplikasi bagian-bagian sehingga bagian data dapat memiliki beberapa "tetangga" fisik. Masalah kedua adalah memikirkan bagaimana disk menjadi cache untuk penyimpanan tersier. Akhirnya, optimisasi dan penjadwalan kueri harus memperhitungkan waktu pengambilan data yang lama dari penyimpanan tersier dan pentingnya klik (hit) dari cache disk. Ini memengaruhi paket yang dipilih oleh pengoptimal kueri dan waktu yang diperlukan untuk menyelesaikan paket.

Robot pada kaset dan disk optik saat ini tidak banyak digunakan. Tetapi masalah penyimpanan tersier sangat umum di cloud, yang pada tahun 2018 memiliki hierarki penyimpanan yang dalam: dari SSD yang terpasang ke layanan penyimpanan seperti disk yang dapat diandalkan (misalnya, AWS EBS), ke penyimpanan arsip (misalnya, dalam AWS S3), ke penyimpanan dalam (misalnya, di AWS S3), ke penyimpanan dalam (misalnya, di AWS S3). , Gletser AWS). Saat ini, tingkatan penyimpanan ini masih relatif terpisah, dan alasan tentang penyimpanan ujung ke ujung yang mencakup tingkatan ini secara praktis tidak didukung oleh basis data. Saya tidak akan terkejut jika pertanyaan yang diselidiki di bagian depan Postgres ini akan segera ditinjau.

2.5. Dukungan Banyak Prosesor: XPRS


Stonebreaker tidak pernah menciptakan sistem database paralel besar, tetapi dia memimpin banyak diskusi yang menantang di bidang ini. Artikelnya "Case for Shared Nothing" [ Sto86 ] mendokumentasikan solusi arsitektur modular besar di bidang ini. Dia mempopulerkan terminologi yang digunakan dalam industri dan membingungkan dukungan arsitektur tanpa sumber daya bersama, seperti Gamma dan Teradata, yang ditemukan kembali pada tahun 2000 oleh komunitas big data.

Ironisnya, kontribusi Stonebreaker yang paling signifikan terhadap bidang database paralel adalah arsitektur "memori bersama" yang disebut XPRS, yang berarti "Postgres eXtended pada RAID dan Sprite". Pada awal 1990-an, XPRS adalah "liga keadilan" untuk sistem Berkeley: ia menggabungkan sistem Postgres Stonebreaker yang disingkat, John Ousterhout, OS Sprite yang didistribusikan, dan arsitektur Dave Patterson dan Randy Katz RAID ) Seperti banyak pekerjaan antar fakultas, implementasi proyek XPRS sebenarnya ditentukan oleh mahasiswa pascasarjana yang bekerja di sana. Ternyata kontribusi utama dibuat oleh Wei Hong, yang menulis tesis Ph.D tentang optimasi kueri paralel di XPRS. Dengan demikian, kontribusi utama XPRS untuk literatur dan industri adalah untuk mengoptimalkan permintaan bersamaan tanpa secara signifikan mengatasi masalah yang terkait dengan RAID atau Sprite.

Dari ketiga proyek ini, Postgres dan RAID memiliki dampak besar di masa depan. Sprite paling diingat oleh disertasi Mendel Rosenblum Ph.D tentang Log Structured File Systems (LFS), yang tidak ada hubungannya dengan sistem operasi terdistribusi. Ketiga proyek berisi ide-ide baru untuk penyimpanan disk, selain memodifikasi salinan individual di tempat. LFS dan manajer repositori Postgres sangat mirip dalam perlakuan baru mereka terhadap jurnal sebagai repositori utama dan kebutuhan untuk reorganisasi latar belakang yang mahal. Suatu kali, saya dengan hati-hati memeriksa Stonebreaker tentang persaingan antara LFS dan Postgres atau "fakta-fakta goreng" akademik tentang hubungan mereka, tetapi saya tidak pernah belajar sesuatu yang menarik darinya. Mungkin pada waktu itu di Berkeley seseorang "sedang mengaduk air."

Pada prinsipnya, concurrency “meledak” ruang dari rencana optimizer kueri, mengalikan pilihan tradisional yang dibuat selama optimasi kueri (akses data, algoritma koneksi, urutan koneksi) dengan semua cara yang memungkinkan untuk memparalelkan setiap pilihan. Gagasan utama dari "pengoptimal Wei Hong" yang disebut oleh Stonebreaker adalah untuk membagi masalah menjadi dua: meluncurkan pengoptimal permintaan tradisional dalam semangat Sistem R untuk satu node, dan kemudian "memparalelkan" rencana yang dihasilkan, merencanakan tingkat paralelisme dan penempatan masing-masing operator berdasarkan pada representasi konfigurasi data dan sistem. Pendekatan ini heuristik, tetapi di dalamnya konkurensi meningkatkan biaya optimisasi kueri tradisional, daripada multiplikatif.

Meskipun pengoptimal Wei Hong dikembangkan dalam konteks Postgres, ini telah menjadi pendekatan standar bagi banyak pengoptimal permintaan bersamaan di industri.

2.6. Dukungan untuk berbagai model bahasa


Di antara kepentingan Stonebreaker, berulang kali diperbarui sejak zaman Ingres, adalah antarmuka pemrograman aplikasi sistem basis data (API). Dalam kuliahnya di seri Sistem Basis Data, ia sering memasukkan bahasa GEM, Carlo Zaniolo sebagai topik yang penting untuk dipahami oleh para pendukung sistem basis data. Ketertarikan pada bahasa ini tidak diragukan lagi membawanya ke bermitra dengan Larry Rowe di Postgres, yang pada gilirannya sangat mempengaruhi desain model data Postgres dan pendekatan objek-relasionalnya. Pekerjaan mereka terutama difokuskan pada aplikasi untuk bekerja dengan volume data yang besar dari ruang komersial, termasuk memproses informasi bisnis dan aplikasi baru seperti CAD / CAM dan GIS.

Salah satu masalah yang dikenakan pada Stonebreaker pada waktu itu adalah gagasan "menyembunyikan" batas-batas antara konstruksi bahasa pemrograman dan repositori basis data. Berbagai proyek penelitian yang bersaing dan perusahaan yang meneliti Object-Oriented Databases (OODBs) telah menargetkan apa yang disebut "hilangnya kesesuaian" antara bahasa pemrograman berorientasi objek yang penting seperti Smalltalk, C ++, dan Java, dan relasional deklaratif model. Gagasan OODB adalah untuk membuat objek dari bahasa pemrograman, jika diinginkan, ditandai sebagai "permanen" dan diproses secara otomatis oleh DBMS bawaan. Postgres mendukung penyimpanan objek bersarang dan tipe data abstrak, tetapi interface-nya, berdasarkan permintaan deklaratif dalam gaya relasional, mengasumsikan akses basis data yang tidak wajar untuk programmer (diperlukan penggunaan query deklaratif), yang juga mahal (mereka membutuhkan parsing dan optimasi). Untuk bersaing dengan penyedia OODB, Postgres menyediakan apa yang disebut antarmuka Jalur Cepat: intinya C / C ++ API untuk penyimpanan basis data internal. Hal ini memungkinkan Postgres untuk memiliki kinerja tolok ukur akademik OODB rata-rata, tetapi tidak pernah memecahkan masalah membiarkan programmer dalam bahasa yang berbeda menghindari masalah kehilangan kepatuhan. Sebagai gantinya, Stonebreaker memberi label Postgres sebagai label "objek-relasional" dan hanya memotong penggunaan database berorientasi objek sebagai pasar nol-miliar dolar. Saat ini, hampir semua sistem basis data relasional komersial adalah sistem basis data "objek-relasional".

Ini ternyata menjadi solusi yang masuk akal. Saat ini, tidak ada produk OODB yang ada dalam bentuk yang dimaksudkan, dan gagasan "objek persisten" dalam bahasa pemrograman sebagian besar telah dibuang. Sebaliknya, penggunaan layer object-relational mapping (ORM) tersebar luas, didorong oleh pekerjaan awal seperti Java Hibernate dan Ruby on Rails, yang memungkinkan untuk "menyesuaikan" database deklaratif dengan hampir semua objek imperatif bahasa pemrograman berorientasi sebagai perpustakaan. Pendekatan tingkat aplikasi ini berbeda dari database objek-relasional OODB dan Stonebreaker. Selain itu, penyimpanan nilai kunci yang ringan juga digunakan dengan sukses dalam bentuk non-transaksional dan transaksional. Penemu mereka adalah mahasiswa pascasarjana Stonebreaker Margo Seltzer, yang bekerja pada database Berkeley DB sebagai bagian dari disertasi Ph.D-nya pada saat yang sama dengan kelompok Postgres, yang mengantisipasi pertumbuhan repositori nilai kunci NoSQL yang didistribusikan seperti Dynamo , MongoDB dan Cassandra.

3. Dampak pada perangkat lunak


3.1. Sumber terbuka


Postgres selalu menjadi proyek sumber terbuka dengan rilis yang konsisten, tetapi pada awalnya itu dimaksudkan untuk digunakan untuk penelitian daripada produksi.

Karena proyek penelitian Postgres dibatasi, dua siswa Stonebreaker Andrew Yu dan Jolly Chen memodifikasi parser sistem untuk menggantikan bahasa Postquel asli dengan varian SQL yang dapat diperluas. Rilis Postgres pertama yang mendukung SQL adalah Postgres95, dan selanjutnya disebut PostgreSQL.

Tim pengembangan sumber terbuka menjadi tertarik pada PostgreSQL dan “menerimanya” bahkan ketika minat dari tim Berkeley lainnya berubah. Tim inti PostgreSQL tetap relatif stabil dari waktu ke waktu, dan proyek open source telah menjadi sangat berkembang. Awalnya, upaya difokuskan pada stabilitas kode dan fungsionalitas yang terlihat oleh pengguna, tetapi seiring waktu, komunitas perangkat lunak sumber terbuka telah secara signifikan mengubah dan meningkatkan inti sistem, dari pengoptimal ke metode akses dan sistem transaksi dan penyimpanan utama. Sejak pertengahan 1990-an, sebagian kecil dari komponen internal PostgreSQL berasal dari tim akademik Berkeley. Kontribusi terakhirnya mungkin adalah implementasi GiST saya pada paruh kedua tahun 1990-an, tetapi bahkan secara substansial ditulis ulang dan dibersihkan oleh sukarelawan dari komunitas open source (dalam hal ini, Rusia). Bagian dari komunitas open source yang bekerja pada PostgreSQL layak mendapatkan pujian terbesar untuk prosesnya yang efisien, yang selama beberapa dekade telah berperan menciptakan proyek yang sangat efisien dan jangka panjang.

Meskipun banyak yang telah berubah selama 25 tahun, arsitektur PostgreSQL yang mendasarinya tetap sangat mirip dengan rilis universitas Postgres pada awal 1990-an, dan pengembang yang akrab dengan kode sumber PostgreSQL saat ini akan merasa mudah untuk membaca kode sumber Postgres 3.1 (1991). Segala sesuatu dari struktur direktori kode sumber ke struktur proses dan struktur data tetap sangat mirip. Kode dari tim Postgres di Berkeley memiliki tulang punggung yang bagus.

Hari ini, PostgreSQL tidak diragukan lagi merupakan sistem manajemen basis data open source dengan kinerja tertinggi, dan mendukung fungsionalitas yang sering tidak ditemukan dalam produk komersial. Ini juga (menurut salah satu situs peringkat berpengaruh) DBMS open source independen paling populer di dunia, dan pengaruhnya terus bertambah: pada 2017 dan 2018, itu adalah basis data dengan popularitas yang tumbuh paling cepat di dunia [ DE19c ]. PostgreSQL digunakan dalam berbagai industri dan tugas, yang tidak mengejutkan, mengingat fokusnya pada banyak peluang.

Menurut DB-Engine, PostgreSQL hari ini adalah DBMS paling populer keempat di dunia, setelah Oracle, MySQL dan MS SQL Server, ketiganya ditawarkan oleh perusahaan tertentu (MySQL diakuisisi oleh Oracle bertahun-tahun yang lalu) [ DE19a ]. Aturan pemeringkatan dibahas dalam deskripsi metodologi pemeringkatan DB-Engine [ DE19b ].

Heroku adalah penyedia cloud SaaS yang sekarang menjadi bagian dari Salesforce. Postgres diperkenalkan di Heroku pada 2010 sebagai database default untuk platformnya. Heroku memilih Postgres untuk keandalan. Dengan dukungan Heroku, platform pengembangan aplikasi yang lebih besar seperti Ruby on Rails dan Python untuk Django mulai merekomendasikan Postgres sebagai database default.

Hari ini, PostgreSQL mendukung infrastruktur ekstensi yang membuatnya mudah untuk menambahkan fitur tambahan ke sistem melalui fungsi yang ditentukan pengguna dan modifikasi terkait. Sekarang ada ekosistem ekstensi PostgreSQL, mirip dengan konsep llustra paket ekstensi DataBlade, tetapi dengan kode sumber terbuka. Ekstensi yang paling menarik termasuk, misalnya, pustaka Apache MADlib untuk pembelajaran mesin di antarmuka SQL dan pustaka Citus untuk eksekusi permintaan paralel.

Salah satu aplikasi open source paling menarik yang dibangun di Postgres adalah sistem informasi geografis PostGIS, menggunakan banyak fitur Postgres yang awalnya menginspirasi Stonebreaker untuk memulai proyek.

3.2. Implementasi komersial


PostgreSQL telah lama menjadi titik awal yang menarik untuk menciptakan sistem basis data komersial, mengingat penggunaannya di bawah lisensi perangkat lunak sumber terbuka "semua diizinkan", kode yang dapat diandalkan, fleksibilitas, dan fungsionalitas yang luas. Merangkum biaya akuisisi yang tercantum di bawah ini, kita melihat bahwa Postgres menerima lebih dari $ 2,6 miliar biaya akuisisi.

Harap dicatat bahwa ini adalah ukuran dalam dolar dari transaksi keuangan nyata dan jauh lebih signifikan daripada nilai-nilai yang sering digunakan dalam teknologi tinggi. Angka dalam miliaran sering digunakan untuk menggambarkan nilai estimasi blok saham, tetapi sering dibesar-besarkan 10 kali atau lebih dibandingkan dengan nilai sekarang dengan harapan signifikansi di masa depan. Dolar transaksi akuisisi perusahaan mengukur nilai pasar aktualnya pada saat akuisisi. Adalah adil untuk mengatakan bahwa Postgres telah menciptakan lebih dari $ 2,6 miliar nilai komersial nyata.

Banyak upaya komersial yang terkait dengan PostgreSQL berfokus pada apa yang mungkin menjadi batasan utamanya: kemampuan untuk menskala arsitektur paralel tanpa berbagi sumber daya.

Paralelisasi PostgreSQL membutuhkan banyak pekerjaan, tetapi sangat layak dilakukan oleh tim kecil yang berpengalaman. Hari ini, cabang-cabang industri open source PostgreSQL seperti Greenplum dan CitusDB memberikan kesempatan seperti itu. Sangat disayangkan bahwa PostgreSQL tidak diparalelkan dengan benar dalam open source jauh lebih awal. Jika PostgreSQL telah diperluas di open source dengan dukungan untuk arsitektur tanpa berbagi sumber daya di awal 2000-an, mungkin saja arah big data open source akan dikembangkan dengan cara yang benar-benar berbeda dan lebih efisien.

  1. Illustra adalah startup Stonebreaker terbesar kedua, yang didirikan pada tahun 1992 untuk mengkomersialkan Postgres, ketika RTI meluncurkan Ingres di pasar.

    Illustra sebenarnya adalah nama ketiga yang diusulkan untuk perusahaan. Melanjutkan tema melukis, diberi nama Ingres, Illustra awalnya disebut Miro. Karena masalah merek dagang, nama diubah menjadi Montage, tetapi juga mengalami masalah merek dagang.

    Tim pendiri termasuk beberapa inti dari tim Postgres, termasuk mahasiswa pascasarjana baru-baru ini Wei Hong dan kemudian ketua programer Jeff Meredith, serta lulusan dari Ingres Paula Hawthorn dan Michael Ubell. Mahasiswa pascasarjana Postgres, Mike Olson, bergabung tidak lama setelah didirikan, dan saya bekerja di Illustra untuk mengoptimalkan fitur-fitur mahal sebagai bagian dari Ph.D. Illustra : SQL92 , Postquel, Postgres DataBlade — . Illustra Informix 1997 400 . . [ Mon96 ], DataBlade Informix Informix Universal Server.
  2. Netezza , 1999 , PostgreSQL FPGA. Netezza , 2007 . IBM 1,7 . . [ IBM10 ].
  3. Greenplum PostgreSQL . 2003 , Greenplum PostgreSQL, API PostgreSQL, API . , Greenplum PostgreSQL , , Orca. Greenplum EMC 2010 300 . . [ Mal10 ], 2012 EMC Greenplum Pivotal. 2015 Pivotal Greenplum Orca . Greenplum Postgres API MADlib SQL [ HRS+12 ]. MADlib Apache. , Greenplum, Apache HAWQ, Pivotal, « » Greenplum (. . PostgreSQL) , Hadoop.
  4. EnterpriseDB 2004 , PostgreSQL , . EnterpriseDB Advanced Server Oracle, Oracle.
  5. Aster Data 2005 , . PostgreSQL. Aster , SQL MapReduce. Aster Data Teradata 2011 263 . . [ Sho11 ]. Teradata Aster , - Aster Teradata.
  6. ParAccel 2006 , PostgreSQL . ParAccel Postgres . 2011 Amazon ParAccel, 2012 AWS Redshift — ParAccel. 2013 ParAccel Actian ( Ingres) , , Actian. AWS Redshift Amazon — Amazon, , , Teradata Oracle Exadata. Postgres .
  7. CitusDB (CitusDB — ; Citus Data. — . .) 2010 , PostgreSQL . PostgreSQL, 2016 CitusDB API PostgreSQL PostgreSQL. 2016 CitusDB .

4.


Postgres, .

, , , Postgres « » (Second System Effect) (Fred Brooks) [ Bro75 ]. , , - . Postgres , , , . , , . — Postgres , . : , . , « » . , , . «-» , «-» .

, , « », , . ( 2001 (). — . .) 2000- « ». , Postgres. , , .

(Ralph Waldo Emerson), « — ».

, « » ( ), , , , , . , . , , - . , . , .

, Postgres, — , . « » PostgreSQL, , . , :
, , , 1995 . Postgres, , . , , , . [ Sto14 ]
, , , , « » . « ». , , , , Postgres. - , : « - ». ( ), .

5.


Postgres , , (Craig Kerstiens) PostgreSQL.

Sastra


  • [Bro75] Frederick P Brooks. The mythical man-month, 1975.
  • [Bro19] Michael L. Brodie, editor. Making Databases Work. Morgan & Claypool, 2019.
  • [DE19a] DB-Engines. DB-Engines ranking, 2019. db-engines.com/en/ranking . (Last accessed January 4, 2019).
  • [DE19b] DB-Engines. Method of calculating the scores of the DB-Engines ranking, 2019. db-engines.com/en/ranking_definition (Last accessed January 4, 2019).
  • [DE19c] DB-Engines. PostgreSQL is the DBMS of the year 2018, January 2019. db-engines.com/en/blog_post/79 (Last accessed January 4, 2019).
  • [DS08] David DeWitt and Michael Stonebraker. Mapreduce: A major step backwards. The Database Column, 1:23, 2008.
  • [Gut84] Antonin Guttman. R-trees: A dynamic index structure for spatial searching. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, SIGMOD '84, pages 47–57, New York, NY, USA, 1984. ACM.
  • [HKM + 02] Joseph M. Hellerstein, Elias Koutsoupias, Daniel P. Miranker, Christos H. Papadimitriou, and Vasilis Samoladas. On a model of indexability and its bounds for range queries. J. ACM, 49(1):35–55, January 2002.
  • [HNP95] Joseph M. Hellerstein, Jeffrey F. Naughton, and Avi Pfeffer. Generalized search trees for database systems. In Proceedings of the 21th International Conference on Very Large Data Bases, VLDB '95, pages 562–573, San Francisco, CA, USA, 1995. Morgan Kaufmann Publishers Inc.
  • [HRS + 12] Joseph M Hellerstein, Christoper Re, Florian Schoppmann, Daisy Zhe Wang, Eugene Fratkin, Aleksander Gorajek, Kee Siong Ng, Caleb Welton, Xixuan Feng, Kun Li, et al. The MADlib analytics library: or MAD skills, the SQL. Proceedings of the VLDB Endowment, 5(12):1700–1711, 2012.
  • [IBM10] IBM to acquire Netezza, September 2010. www-03.ibm.com/press/us/en/pressrelease/32514.wss#release (Last accessed January 22, 2018).
  • [KMH97] Marcel Kornacker, C. Mohan, and Joseph M. Hellerstein. Concurrency and recovery in generalized search trees. In Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data, SIGMOD '97, pages 62–72, New York, NY, USA, 1997. ACM.
  • [Mal10] Om Malik. Big Data = Big Money: EMC Buys Greenplum. In GigaOm, July 2010. gigaom.com/2010/07/06/emc-buys-greenplum .
  • [Mon96] John Monroe. Informix acquires illustra for complex data management. In Federal Computer Week, January 1996.
  • [OFS83] James Ong, Dennis Fogg, and Michael Stonebraker. Implementation of data abstraction in the relational database system ingres. ACM Sigmod Record, 14(1):1–14, 1983.
  • [Ols93] Michael A. Olson. The design and implementation of the inversion file system. 1993.
  • [SAHR84] Michael Stonebraker, Erika Anderson, Eric Hanson, and Brad Rubenstein. Quel as a data type. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, SIGMOD '84, pages 208–214, New York, NY, USA, 1984. ACM.
  • [Sho11] Erick Shonfeld. Big pay day for big data. teradata buys aster data for $263 million. In TechCrunch, May 2011. techcrunch.com/2011/03/03/teradata-buys-aster-data-263-million (Last accessed January 22, 2018).
  • [SHWK76] Michael Stonebraker, Gerald Held, Eugene Wong, and Peter Kreps. The design and implementation of ingres. ACM Transactions on Database Systems (TODS), 1(3):189–222, 1976.
  • [SK91] Michael Stonebraker and Greg Kemnitz. The postgres next generation database management system. Commun. ACM, 34(10):78–92, October 1991.
  • [SR86] Michael Stonebraker and Lawrence A. Rowe. The design of postgres. In Proceedings of the 1986 ACM SIGMOD International Conference on Management of Data, SIGMOD '86, pages 340–355, New York, NY, USA, 1986. ACM.
  • [SRG83] M Stonebraker, B Rubenstein, and A Guttman. Application of abstract data types and abstract indices to cad bases. IEEE Trans, on Software Engineering, 1983.
  • [Sto86] Michael Stonebraker. The case for shared nothing. IEEE Database Eng. Bull., 9(1):4–9, 1986.
  • [Sto87] Michael Stonebraker. The design of the postgres storage system. In Proceedings of the 13th International Conference on Very Large Data Bases, VLDB '87, pages 289–300, San Francisco, CA, USA, 1987. Morgan Kaufmann Publishers Inc.
  • [Sto95] Michael Stonebraker. An overview of the sequoia 2000 project. Digital Technical Journal, 7(3):39–49, 1995.
  • [Sto14] Michael Stonebraker. The land sharks are on the squawk box, 2014. www.acm.org/turing-lecture-stonebraker (Last accessed January 4, 2019).

Source: https://habr.com/ru/post/id438890/


All Articles