Analisis perbandingan mysql dan postgresql

Jujur saja, meskipun 1C Enterprise kompatibel dengan banyak DBMS, kenyataannya 99 persen berfungsi baik di MS SQL atau di PostgreSQL gratis.

Dengan kata lain, kedua "subs" ini telah menaklukkan pasar 1C client-server.

Dan kita dapat dengan aman berasumsi bahwa jika perusahaan tidak bekerja di MS SQL, maka kemungkinan besar mereka hanya menggunakan PostgreSQL.

Oleh karena itu, masuk akal untuk membandingkan Postgres hanya dengan MS SQL.

Saat ini, banyak yang ditulis tentang MS SQL dan PostgreSQL, tetapi biasanya mereka tidak membandingkannya secara objektif.

Pada artikel ini, kami akan menganalisis poin teknis utama PostgreSQL gratis, membandingkannya dengan MS SQL.

Itu akan memungkinkan Anda untuk membuat pilihan terbaik di masa depan dan bersiap untuk berbagai "kejutan" atau, lebih tepatnya, "fitur" bekerja di DBMS gratis ini.

Kami akan mengevaluasi semuanya apa adanya, tanpa menambahkan ke Postgres kelebihan yang tidak dimilikinya dan tanpa memperindah MS berbayar.

Saya akan segera menjawab pertanyaan yang mengkhawatirkan banyak pemula!

YA! MS SQL lebih cepat dari PostgreSQL, itu faktanya! Dan ada beberapa alasan untuk ini!

Mungkin saya langsung mengecewakan seseorang, dan mungkin Anda tidak setuju dengan pernyataan ini, saya minta maaf, tetapi fisika DBMS gratis ini tidak memungkinkannya untuk mendahului MS SQL, terutama jika kita berbicara tentang banyak hal seperti "Monster 1C" dan PostgreSQL.

Anda akan menemukan argumen serupa lebih dari sekali di berbagai konferensi dan seminar yang didedikasikan untuk DBMS ini. Tidak ada yang menyembunyikan atau menyangkal apa pun, fakta adalah fakta.

Namun demikian, kinerja PostgreSQL cukup bagi pengguna untuk bisa bekerja dengan nyaman di 1C.

Baik itu selusin pengguna atau bahkan beberapa ratus, secara bersamaan bekerja di 1C Enterprise.

Mengapa "Rakasa 1C"?

Sebenarnya, ini adalah cara 1C melihat PostgreSQL tanpa "tambalan" dan ekstensi khusus yang diinstal.

Ya, apa yang disebut out of the box, dengan mengunduh kit distribusi PostgreSQL di kantor. situs Anda tidak akan dapat menggunakannya untuk bekerja bersama dengan 1C. 1C-ka akan sangat melambat dan berhenti begitu saja, menolak untuk bekerja.

Mengapa ini terjadi, dan mengapa "tambalan"?

Faktanya adalah bahwa 1C Enterprise menciptakan sejumlah besar tabel sementara dalam pekerjaannya, kita dapat berbicara sekitar ribuan tabel per detik, dan jika kita mengambil, misalnya, daftar "Irisan terakhir" - "Sisa dan Perputaran", di sana mereka mungkin dan sejuta baris menjadi.

Faktanya adalah bahwa secara default (tanpa "tambalan") PostgreSQL tidak menghitung statistik pada tabel sementara yang besar ini, dengan kata lain, pengoptimal kueri yang dipandu oleh data dari statistik (dan, seperti yang kita ingat, itu kosong, tidak ada yang dihitung) secara kasar, membuat pilihan menggunakan PILIH * yang tentu saja akan bekerja sangat, sangat lambat!

Oleh karena itu rem muluk di 1C!

Tentu saja, ini tidak semua masalah yang perlu dipecahkan agar PostgreSQL bekerja bersama-sama dengan 1C secara normal. "Tambalan" lainnya akan dibutuhkan dan ekstensi khusus dan setelah 15-20 pengguna, juga tambahan. pengaturan dalam konfigurasi

Ya, pada kenyataannya, semuanya terlihat jauh lebih rumit daripada yang saya jelaskan di atas, tetapi jika Anda banyak menyederhanakannya, masalah utama dari pekerjaan 1C yang lambat dengan PostgreSQL akan terlihat seperti ini.

Hal kedua yang saya sangat tidak suka tentang PostgreSQL adalah tidak ada multithreading dalam satu permintaan dibandingkan dengan MS SQL.

(Mulai dari versi 9.6, kami melakukan upaya pertama untuk memparalelkan kueri, tetapi sejauh ini tidak berhasil, terkadang efeknya sebaliknya). tapi untuk mencoba 5!)

Yang tentu saja mempengaruhi kinerja, sehingga Anda mengerti secara sederhana -

PostgreSQL dapat menghapus server 48-core Anda dengan satu permintaan besar!

Sederhana saja, tidak ada paralelisasi utas dalam satu permintaan, dan satu permintaan besar "memuat" hanya satu inti.

Ya, jika ada banyak permintaan, maka semua inti akan dimuat, dan semuanya akan berfungsi dengan baik.

Dan aku hampir lupa kami membandingkan PostgreSQL dengan MS SQL Standard bukan Express!

Express, meskipun dapat digunakan untuk tujuan komersial, memiliki sejumlah keterbatasan

seperti 10 GB per basis, penggunaan CPU tunggal, 1 GB memori akses acak,

membuat penggunaan produk semacam itu hampir tidak realistis untuk bekerja di 1C Enterprise.

Kecuali jika Anda memiliki database yang sangat kecil dan hanya beberapa pengguna (dan itupun hanya ada sedikit rem 1 GB untuk DBMS).

Jadi mari kita bandingkan PostgreSQL dengan versi Standar yang populer.

SKRIP!!!

PostgreSQL terutama skrip dibandingkan dengan MS SQL, sebagian besar operasi harus dilakukan dengan tangan, ya, tentu saja, Anda dapat menginstal beberapa hal dasar melalui antarmuka, tetapi saya menekankan bahwa yang dasar, dan langkah ke kiri, a langkah ke kanan, dan Anda perlu menulis skrip, atau BASH di Linux atau cmd, PowerShell di Windows.

Lihat dan analisis jejak menggunakan SQL Server Profiler.

SQL Server Profiler yang terkenal hilang di PostgreSQL, dan dengan kata "hilang", maksud saya, saya akan sepenuhnya masuk, sayangnya, tidak ada yang serupa di PostgreSQL.

Tentu saja ada utilitas yang memungkinkan, jika Anda punya waktu untuk mencegat permintaan atau mengatur breakpoint 1C di debugger dan mendapatkan sesuatu dan melihat, tetapi dibandingkan dengan Profiler, seperti yang mereka katakan, itu bahkan tidak dekat.

Anda dapat mengatur log dan kemudian memeriksa semuanya - tetapi untuk waktu yang lama!

Berikut ini contohnya:

Seorang programmer 1C sedang mencoba untuk men-debug beberapa query besar, butuh waktu lama, misalnya, 30 menit, dan di PostgreSQL, agar data masuk ke log, query ini harus dijalankan! Bisakah Anda bayangkan berapa lama waktu yang dibutuhkan untuk men-debug permintaan seperti itu?

Saat berada di MS SQL, Anda dapat menginterupsi eksekusi kueri dan menguraikannya di Profiler, karena sudah ada di sana, tetapi dengan status "gagal".

Postgres tidak ada bandingannya dalam hal membuat "cadangan"!

Di sini Anda memiliki "cadangan" tambahan dan lengkap cadangan dan pengarsipan WAL berkelanjutan.

Karena sebenarnya ada sebagian backup dan sebagian data recovery.

Anda dapat mengonfigurasi pengarsipan berkelanjutan dan pemulihan tepat waktu (Pemulihan Titik-dalam-Waktu (PITR)).

Juga replikasi, tersedia secara asli di PostgreSQl tanpa "tambalan" utilitas dan add-on!

• Replikasi Cascading
• Replikasi streaming
• Replikasi sinkron
• Pengarsipan berkelanjutan di server siaga

Semua ini, awalnya sudah di PostgreSQl dan tentu saja tidak dalam "ekspres" dan tidak tersedia pada versi MS SQL Standard.

Untuk mendapatkan semua yang tercantum di atas dalam MS SQL, Anda perlu membeli MS SQL Enterprise yang sangat mahal, sekarang sekitar $15.000.

Apa yang tidak bisa dibandingkan dengan MS SQL?

TANPA "cadangan" diferensial

Ya, tidak ada "cadangan" diferensial di PostgreSQl, tetapi ada berbagai analog "cadangan" tambahan.

Misalnya, "cadangan" tambahan di tingkat blok.

ADA divisi TABLESPACEs, yang sudah mendukung 1C secara default!

Yang omong-omong tidak ada di MS SQL!

Misalnya, Anda dapat mengonfigurasi di disk mana Anda akan memiliki "indeks" dan di disk mana "tabel" akan ditempatkan, sangat nyaman ketika merencanakan infrastruktur TI ketika datang ke database 1C besar. ONLINE_ANALYZE untuk menghitung ulang statistik. Hal yang sama berlaku untuk file *dt.

Dengan PostgreSQL Anda jarang membutuhkan REINDEX!

Sebenarnya, itu hanya boleh digunakan ketika ada kecurigaan bahwa integritas database telah rusak.

Anda dapat membuat "cadangan" dengan pengecualian tabel!

Misalnya, Anda memiliki beberapa programmer 1C yang bekerja di perusahaan Anda, mereka dijamin melakukannya cadangan buat "cadangan" untuk pengembangan lebih lanjut.

Akibatnya, pengguna menderita, basis data melambat selama pembuatan "cadangan" besar, terutama jika basis data ini berisi hal-hal seperti berbagai file terlampir, arsip, dokumen dari surat. Tabel file tersebut dapat dengan mudah berisi ratusan gigabyte. Dan mereka juga dapat dikecualikan di PostgreSQl dengan membuat "cadangan", dengan ukuran kecil, dan dengan semua fungsi pada saat yang bersamaan.

Jadi kami sekali lagi tidak memuat perangkat jaringan, tidak menyumbat saluran, menghabiskan lebih sedikit waktu untuk membuat "cadangan" seperti itu

Pada akhirnya, semua orang menang! Dan pengguna, dan pemrogram dan admin tidur nyenyak.

Dalam artikel ini, kami hanya menganalisis perbedaan mendasar antara PostgreSQl dan MS SQL (ada yang lain), tetapi jika Anda memutuskan untuk memilih satu atau lebih DBMS, artikel ini akan membantu!

Semoga berhasil Rekan!

P.S. Sekarang saya sedang mengerjakan kursus baru "1C dan PostgreSQL" (Sudah di tahap perekaman, tunggu, segera!)

Hormat kami, Bogdan.

Untuk mengantisipasi presentasi saya di konferensi PGCONF.RUSSIA 2015, saya akan membagikan beberapa pengamatan tentang perbedaan penting antara DBMS MySQL dan PostgreSQL. Materi ini akan berguna bagi semua orang yang tidak lagi puas dengan kemungkinan dan Fitur MySQL, serta mereka yang mengambil langkah pertama di Postgres. Tentu saja, posting ini tidak boleh dianggap sebagai daftar lengkap perbedaan, tetapi akan cukup untuk membuat keputusan yang mendukung satu atau lebih DBMS.

Masalahnya adalah banyak sistem manajemen penyimpanan… sering melakukan WAL dan PITR mereka sendiri. Beberapa melakukan manajemen buffer, penguncian, dan manajemen replikasi/muat mereka sendiri juga. Jadi, seperti yang Anda katakan, sulit untuk mengatakan di mana antarmuka seharusnya
disarikan.

Lebih dari 10 tahun telah berlalu, dan apa yang kita lihat? MySQL memiliki masalah yang mengganggu dengan transaksi antara tabel mesin penyimpanan yang berbeda dan MySQL memiliki masalah dengan replikasi. Selama sepuluh tahun ini, PostgreSQL telah menambahkan tipe data dan indeks yang dapat dicolokkan, dan juga memiliki replikasi - yaitu, keunggulan MySQL telah diratakan, sementara masalah arsitektur MySQL tetap ada dan mengganggu kehidupan. MySQL 5.7 mencoba memecahkan masalah kinerja replikasi dengan memparalelkannya. Karena proyek di tempat kerja sangat sensitif terhadap kinerja replikasi karena skalanya, saya mencoba menguji apakah itu menjadi lebih baik. Saya menemukan bahwa replikasi paralel di 5.7 lebih lambat dari replikasi single-threaded di 5.5, dan hanya dalam beberapa kasus - hampir sama. Jika saat ini Anda menggunakan MySQL 5.5 dan ingin meningkatkan ke versi yang lebih baru, harap perhatikan bahwa migrasi tidak dapat dilakukan untuk proyek dengan beban tinggi, karena replikasi akan berhenti berjalan.

Setelah laporan beban tinggi, Oracle mencatat pengujian yang saya kembangkan dan mengatakan mereka akan mencoba memperbaiki masalah; Baru-baru ini, mereka bahkan menulis kepada saya bahwa mereka dapat melihat paralelisme dalam pengujian mereka, dan mengirim pengaturan. Jika saya tidak salah, dengan 16 utas ada sedikit peningkatan dibandingkan dengan versi utas tunggal. Sayangnya, saya belum mengulangi pengujian saya pada pengaturan yang disediakan - khususnya, karena dengan hasil seperti itu masalah kami masih relevan.

Alasan pasti untuk regresi kinerja ini tidak diketahui. Ada beberapa saran - misalnya, Christian Nelsen, salah satu pengembang MariaDB, menulis di blognya bahwa mungkin ada masalah dengan skema kinerja, dengan sinkronisasi utas. Karena itu, ada regresi 40%, yang terlihat pada tes konvensional. Pengembang Oracle menyangkal ini, dan mereka bahkan meyakinkan saya bahwa itu tidak ada, tampaknya, saya melihat beberapa masalah lain (dan ada berapa banyak?).

Dalam replikasi MySQL, masalah dengan mesin penyimpanan diperburuk oleh tingkat replikasi yang dipilih - mereka logis, sedangkan di PostgreSQL masalah fisik. Pada prinsipnya, replikasi logis memiliki kelebihan, memungkinkan Anda melakukan hal-hal yang lebih menarik, saya juga akan menyebutkan ini dalam laporan. Tapi PostgreSQL, bahkan sebagai bagian dari replikasi fisiknya, sudah meniadakan semua keuntungan ini. Dengan kata lain, hampir semua yang ada di MySQL sudah bisa dilakukan di PostgreSQL (atau akan mungkin dalam waktu dekat).

Anda tidak dapat berharap untuk menerapkan replikasi fisik tingkat rendah di MySQL. Masalahnya adalah bahwa alih-alih satu log (seperti di PostgreSQL), ada dua atau empat log - tergantung pada cara Anda menghitung. PostgreSQL hanya melakukan kueri, mereka masuk ke log, dan log ini digunakan dalam replikasi. Replikasi PostgreSQL sangat stabil karena menggunakan log yang sama dengan operasi failover. Mekanisme ini telah lama ditulis, diuji dengan baik, dan dioptimalkan.

Di MySQL situasinya berbeda. Kami memiliki log InnoDB dan log replikasi terpisah, dan kami perlu melakukan keduanya di sana dan di sana. Dan ini adalah komit dua fase antara log, yang menurut definisi lambat. Artinya, kita tidak bisa begitu saja mengambil dan mengatakan bahwa kita mengulangi transaksi dari log InnoDB - kita harus mencari tahu apa permintaannya dan memulainya lagi. Bahkan jika ini adalah replikasi logis, pada tingkat baris, maka baris-baris ini perlu dicari dalam indeks. Dan Anda tidak hanya harus melakukan banyak pekerjaan untuk mengeksekusi kueri - pada saat yang sama akan ditulis lagi ke log InnoDB-nya yang sudah ada di replika, yang jelas tidak baik untuk kinerja.

Di PostgreSQL, dalam pengertian ini, arsitektur adalah urutan besarnya yang lebih bijaksana dan diimplementasikan dengan lebih baik. Baru-baru ini, ia mengumumkan fitur yang disebut Decoding Logis - yang memungkinkan Anda melakukan segala macam hal menarik yang sangat sulit dilakukan dalam kerangka jurnal fisik. Di PostgreSQL, ini adalah add-on dari atas, decoding logis memungkinkan Anda untuk bekerja dengan log fisik seolah-olah log logis. Fungsionalitas inilah yang akan segera menghilangkan semua keuntungan replikasi MySQL, kecuali mungkin ukuran log - replikasi MySQL berbasis pernyataan akan menang - tetapi replikasi MySQL berbasis pernyataan memiliki masalah yang benar-benar liar di tempat yang paling tidak terduga, dan Anda seharusnya tidak menghitungnya keputusan yang bagus(Saya juga akan membicarakan semua ini dalam laporan).

Selain itu, ada replikasi yang dipicu untuk PostgreSQL - ini adalah Tungsten, yang memungkinkan Anda melakukan hal yang sama. Replikasi yang dipicu bekerja sebagai berikut: pemicu diatur, mereka mengisi tabel atau menulis file, hasilnya dikirim ke replika dan diterapkan di sana. Melalui Tungsten, sejauh yang saya tahu, mereka bermigrasi dari MySQL ke PostgreSQL dan sebaliknya. Di MySQL, replikasi logis bekerja langsung di tingkat mesin, dan sekarang tidak mungkin lagi melakukannya secara berbeda.

Sebagai contoh, ini adalah bagaimana Percona menembak: mereka menjalankan Blog Kinerja MySQL, dan ada banyak artikel di blog ini yang membahas aspek-aspek tertentu dari operasi MySQL. Ini membawa popularitas liar, mengarahkan klien ke konsultasi, memungkinkan untuk menarik sumber daya untuk meluncurkan pengembangan garpu Percona-Server mereka sendiri. Keberadaan dan relevansi Blog Kinerja MySQL membuktikan bahwa dokumentasi resmi saja tidak cukup.

PostgreSQL memiliki hampir semua jawaban dalam dokumentasi. Di sisi lain, saya telah mendengar banyak kritik ketika membandingkan dokumentasi PostgreSQL dengan Oracle "dewasa". Tetapi, pada kenyataannya, ini adalah indikator yang sangat penting. Tidak ada yang mencoba membandingkan MySQL dengan Oracle yang lebih lama - itu akan menjadi konyol dan konyol - tetapi PostgreSQL sudah mulai dibandingkan dengan cukup serius, komunitas PostgreSQL mendengar kritik ini dan bekerja untuk meningkatkan produk. Ini menunjukkan bahwa, dalam hal kemampuan dan kinerjanya, ia mulai bersaing dengan sistem yang kuat seperti Oracle tempat mereka bekerja operator seluler dan bank, sementara MySQL tetap berada di ceruk situs web. Dan proyek raksasa yang telah berkembang menjadi sejumlah besar data dan pengguna menyeruput kesedihan dengan MySQL dengan sendok besar, terus-menerus bertumpu pada keterbatasan dan masalah arsitektur yang tidak dapat diperbaiki dengan menghabiskan banyak waktu dan usaha.

Contoh proyek besar seperti itu di PostgreSQL adalah 1C: PostgreSQL hadir sebagai opsi alih-alih Microsoft SQL, dan Microsoft SQL benar-benar DBMS yang fantastis, salah satu yang paling kuat. PostgreSQL dapat menggantikan MS SQL, dan mencoba untuk menggantikan MySQL ... mari kita kasihan pada adegan ini, seperti yang ditulis Mark Twain.

MySQL memiliki masalah dengan kueri yang kompleks. Misalnya, MySQL tidak tahu bagaimana menurunkan pengelompokan menjadi bagian-bagian yang terpisah dari serikat semua. Perbedaan antara dua kueri adalah bahwa dalam contoh kami, pengelompokan berdasarkan tabel terpisah dan penyatuan semua dari atas bekerja 15 kali lebih cepat daripada penyatuan semua dan kemudian pengelompokan, meskipun pengoptimal harus membawa kedua kueri ke dalam rencana eksekusi kueri yang sama dan efisien. Kita harus membuat permintaan semacam itu dengan tangan - yaitu, menghabiskan waktu pengembang untuk apa yang harus dilakukan database.

"Kesederhanaan" MySQL berasal, seperti dapat dilihat di atas, dari fitur yang sangat buruk - MySQL hanya berkinerja lebih buruk dan membutuhkan lebih banyak waktu dan usaha selama pengembangan. Sebaliknya, PostrgreSQL memiliki histogram dan pengoptimal normal dan akan mengeksekusi kueri tersebut secara efisien. Tetapi jika ada histogram, maka ada pengaturannya - setidaknya ukuran ember. Anda perlu tahu tentang pengaturan dan mengubahnya dalam beberapa kasus - oleh karena itu, Anda perlu memahami jenis pengaturannya, apa yang menjadi tanggung jawabnya, dapat mengenali situasi seperti itu, melihat dan memilih parameter yang optimal.

Kadang-kadang terjadi bahwa keterampilan PostrgreSQL dapat menghambat daripada membantu. 95% dari waktu semuanya bekerja dengan baik - lebih baik daripada MySQL - dan satu permintaan bodoh jauh lebih lambat. Atau semuanya bekerja dengan baik, dan kemudian tiba-tiba (dari sudut pandang pengguna) ketika proyek berkembang, beberapa kueri mulai bekerja dengan buruk (ada lebih banyak data, rencana eksekusi kueri yang berbeda mulai dipilih). Kemungkinan besar, untuk memperbaikinya, cukup dengan menjalankan analisis atau sedikit mengubah pengaturan. Tetapi Anda perlu tahu apa yang harus dilakukan dan bagaimana melakukannya. Minimal, Anda perlu membaca dokumentasi PostgreSQL tentang topik ini, tetapi untuk beberapa alasan mereka tidak suka membaca dokumentasi. Mungkin karena ada sedikit bantuan darinya di MySQL? :)

Saya menekankan bahwa PostgreSQL tidak lebih buruk dalam pengertian ini, itu hanya memungkinkan Anda untuk menunda masalah, dan MySQL segera membuangnya dan Anda harus menghabiskan waktu dan uang untuk menyelesaikannya. Dalam hal ini, MySQL selalu bekerja dengan buruk secara konsisten, dan bahkan pada tahap pengembangan, orang-orang mempertimbangkan fitur-fitur ini: mereka melakukan segalanya dengan maksimal secara sederhana. Ini hanya berlaku untuk kinerja, lebih tepatnya, untuk cara mencapainya dan untuk prediktabilitasnya. Dalam hal kebenaran dan kenyamanan, PostgreSQL adalah kepala dan bahu di atas MySQL.

Pertama, pengalaman apa yang dimiliki tim? Jika seluruh tim memiliki 10 tahun pengalaman dengan MySQL dan perlu memulai secepat mungkin, maka itu bukan fakta bahwa perlu mengubah alat yang sudah dikenal menjadi alat yang tidak dikenal. Tetapi jika waktunya tidak kritis, maka Anda harus mencoba PostgreSQL.

Kedua, kita tidak boleh melupakan masalah operasi. Jika Anda tidak memiliki proyek dengan beban tinggi, maka dalam hal kinerja tidak ada perbedaan antara kedua DBMS ini. Tetapi PostgreSQL memiliki keuntungan penting lainnya: lebih ketat, lebih banyak memeriksa Anda, memberi Anda lebih sedikit ruang untuk kesalahan, dan ini adalah keuntungan besar dalam jangka panjang. Misalnya, MySQL harus menulis alatnya sendiri untuk memverifikasi integritas referensial normal dari database. Dan bahkan itu bisa menjadi masalah. Dalam hal ini, alat PostgreSQL lebih kuat, lebih fleksibel, dan lebih menyenangkan untuk dikembangkan. Tetapi ini sangat tergantung pada pengalaman pengembang.

Kesimpulannya: jika Anda memiliki toko online sederhana, tidak ada uang untuk admin, tidak ada ambisi serius untuk tumbuh menjadi proyek besar dan memiliki pengalaman dengan MySQL, maka ambil MySQL. Jika Anda mengharapkan proyek menjadi populer, jika besar, akan sulit untuk menulis ulang, jika memiliki logika yang kompleks dan hubungan antar tabel - ambil PostgreSQL. Bahkan di luar kotak, itu akan bekerja untuk Anda, membantu dalam pengembangan, menghemat waktu, dan akan lebih mudah bagi Anda untuk tumbuh.

Sulit untuk menemukan organisasi yang tidak menggunakan sistem akuntansi dari 1C - bahkan di mega-holding di mana SAP atau OEBS telah lama diterapkan, mereka hampir selalu digunakan di satu area atau lainnya. Sangat menyenangkan bahwa perangkat lunak aplikasi Rusia telah menjadi standar de facto untuk perusahaan kami, tetapi ada satu kehalusan: standar de facto yang sama untuk 1C: Perusahaan itu sendiri telah menjadi Microsoft menggunakan SQL Server sebagai DBMS.

Di antara mempraktekkan nama panggilan 1C, pendapat paling umum adalah bahwa tanpa DBMS komersial, tidak ada hal baik yang akan datang dari pabrikan Amerika, kata mereka, beberapa ratus pengguna pasti memerlukan instalasi database pada MS SQL, Oracle Database atau IBM DB2 dalam kasus ini. Tentang pekerjaan di bawah kendali kebebasan DBMS PostgreSQL, pendapat para praktisi yang kami kenal berbeda, tetapi dalam kisaran dari "tidak berfungsi sama sekali" hingga "cocok untuk beberapa lusin pengguna, tidak lebih".

Ada sejumlah penjelasan yang masuk akal untuk perkiraan sederhana seperti itu: baik penggunaan aktif mekanisme tabel sementara oleh platform 1C (yang diterapkan terlalu "jujur" di Postgres - dengan DDL transaksional, semua kemampuan pemulihan), dan kekhasan bekerja dengan teks data (sementara di bidang teks multibahasa vanilla Postgres, sekali lagi, terlalu konservatif, tidak menggunakan perpustakaan sistem berkinerja paling tinggi), dan sejumlah aspek lain yang kurang signifikan.

Tapi kami diam-diam percaya pada Postgres, terutama karena majelis mengklaim menyelesaikan semua masalah yang digunakan oleh para skeptis untuk membenarkan memilih DBMS komersial. Selain itu, penting bagi kami untuk mendapatkan indikator target untuk perangkat keras dan perangkat lunak yang kompleks - mesin database untuk DBMS yang dibangun berdasarkan perangkat keras dan perangkat lunak yang aman dari sanksi, yang dikembangkan oleh IBS bersama dengan Postgres Professional.

Dari aplikasi yang direplikasi, aplikasi yang paling jelas untuk mesin seperti itu, tentu saja, adalah sistem 1C. Dan hasil dari tolok ukur yang dilakukan sepenuhnya memindahkan kami dari kategori "pepercaya rahasia" (dan bahkan peragu) ke kategori "yakin": sekarang kami dapat dengan aman mengatakan bahwa 1C: Enterprise versi 8.3 pada build Postgres Pro EE 1.5 untuk Skala-SR / Postgres Pro bekerja lebih baik daripada di MS SQL 2012 pada perangkat keras yang sama dengan semua kemungkinan optimasi.

Jadi, beberapa rincian percobaan. Dalam hal pengujian kinerja, 1C memiliki segalanya secara sistematis dan ilmiah - ada konfigurasi tipikal"Uji beban standar", di mana tolok ukur diluncurkan, secara bertahap menambahkan pengguna baru ke beban hingga aplikasi cukup responsif untuk pekerjaan yang nyaman. (Lebih tepatnya, pengguna ditambahkan hingga skor kinerja aplikasi Apdex standar turun di bawah ambang batas 0,85, dan jumlah maksimum pengguna efektif tersebut dianggap sebagai hasil benchmark.)

Kami menggunakan versi 8.3.9.1850 dari 1C:Enterprise, uji beban standar di versi 2.0.17.36. Awalnya, diputuskan untuk tidak memberikan diskon apa pun ke Postgres: kami membuat optimasi maksimum pada MS SQL pada node dari kompleks Skala-SR / Postgres Pro (kami menempatkan Windows pada bare metal, kami mengaturnya sesuai dengan semua kanon, untuk kecepatan kami membuat ramdisk untuk tabel sementara), dan kemudian - kami mengembalikan node yang sama ke kompleks Skala-SR, kami menggulung Linux dan Postgres Pro EE, dan di atasnya saja (tanpa chip cluster tersedia di kompleks) - kami menjalankan tes yang sama.

Uji satu: kita mulai dengan 100 pekerjaan, bebannya 50/50 - setengahnya menghasilkan dokumen, setengahnya menghasilkan laporan. Uji dua: mulai dengan 400, muat 70/30. MS SQL "berakhir" dalam pengujian pertama pada 360 pengguna, pada yang kedua - pada 540, apalagi, pembatas di kedua peluncuran adalah pekerjaan dengan I / O lokal, meskipun faktanya prosesor hanya dimuat rata-rata 30%. Postgres Pro pada pengujian pertama mencapai 440 pekerjaan, dan pada pengujian kedua - hingga 660, dan semua yang ada di server database bertumpu pada prosesor, yang memuat lebih dari 90% pada "pengguna maksimum".

Untuk 1C, di mana jumlah pengguna bersamaan adalah faktor pembatas yang paling bermasalah, ini adalah hasil yang luar biasa, dan yang paling penting, ini menunjukkan bahwa sistem aplikasi Rusia yang paling penting ini tidak hanya dapat berfungsi tanpa DBMS komersial Barat, tetapi bahkan melakukannya dengan lebih baik. .

Seri konten:

1. Sejarah perkembangan MySQL dan PostgreSQL

Sejarah MySQL dimulai pada tahun 1979 dengan sebuah perusahaan kecil yang dipimpin oleh Monty Widenius. Pada tahun 1996, rilis pertama 3.11 muncul di bawah Solaris dengan lisensi publik. Kemudian MySQL di-porting ke yang lain Sistem operasi, lisensi komersial khusus muncul. Pada tahun 2000, setelah menambahkan antarmuka yang mirip dengan Berkeley DB, database menjadi transaksional. Sekitar waktu yang sama, replikasi ditambahkan. Pada tahun 2001, versi 4.0 menambahkan mesin InnoDB ke MyISAM yang sudah ada, menghasilkan caching dan peningkatan kinerja. Pada tahun 2004, versi 4.1 dirilis, yang memperkenalkan subqueries, pengindeksan parsial untuk MyISAM, Unicode. Versi 5.0 pada tahun 2005 memperkenalkan prosedur tersimpan, kursor, pemicu, dan tampilan. MySQL sedang mengembangkan tren komersial: pada tahun 2009, MySQL menjadi merek dagang dari Oracle.

Sejarah postgres dimulai pada tahun 1977 dengan database Ingress.

Pada tahun 1986 di University of Berkeley, California, namanya diubah menjadi PostgreSQL.

Pada tahun 1995, postgres menjadi database open source. Psql interaktif muncul.

Pada tahun 1996, Postgres95 diubah namanya menjadi PostgreSQL versi 6.0.

Postgres memiliki beberapa ratus pengembang di seluruh dunia.

2. Arsitektur MySQL dan PostgreSQL

PostgreSQL- server database terpadu dengan mesin tunggal - mesin penyimpanan. Postgres menggunakan model client-server.

Untuk setiap klien, server membuat proses baru(bukan aliran!). Untuk bekerja dengan proses klien seperti itu, server menggunakan semaphore.

Permintaan klien melewati tahapan berikut.

1. Menghubung.
2. Parsing: kebenaran permintaan diperiksa dan pohon kueri dibuat. Parser didasarkan pada utilitas dasar Unix yacc dan lex.
3. Penulisan ulang: pohon kueri diambil dan keberadaan aturan (aturan) di dalamnya, yang terletak di direktori sistem, diperiksa. Setiap kali kueri pengguna ditulis ulang ke kueri yang mengakses tabel database.
4. Pengoptimal: untuk setiap kueri, rencana kueri dibuat - rencana kueri, yang diteruskan ke pelaksana - pelaksana. Arti dari rencana adalah bahwa setiap orang bergerak melaluinya opsi yang memungkinkan mendapatkan hasilnya (apakah akan menggunakan indeks, bergabung, dll.), dan opsi tercepat dipilih.
5. Eksekusi kueri: Pelaksana melintasi pohon secara rekursif dan mendapatkan hasilnya menggunakan pengurutan, penggabungan, dll. dan mengembalikan baris. Postgres adalah database objek-relasional, setiap tabel di dalamnya mewakili kelas, pewarisan diimplementasikan di antara tabel. Standar SQL92 dan SQL99 diimplementasikan.

Model transaksional didasarkan pada apa yang disebut kontrol konkurensi multi-versi (MVCC), yang memberikan: penampilan maksimal. Integritas referensial dipastikan dengan adanya kunci primer dan sekunder.

MySQL memiliki dua lapisan - lapisan sql eksternal dan satu set mesin internal, di mana mesin InnoDb paling sering digunakan, karena paling mendukung ACID.

Standar SQL92 diimplementasikan.

Dari sudut pandang modular, kode MySQL dapat dibagi menjadi beberapa modul berikut.

1. Inisialisasi server.
2. Manajer koneksi.
3. Manajer aliran.
4. Pengendali perintah.
5. Autentikasi.
6. Pengurai.
7. Pengoptimal.
8. Manajer meja.
9. Mesin (MyISAM, InnoDB, MEMORY, Berkeley DB).
10. Masuk.
11. Replikasi.
12. API jaringan.
13. kernel API.

Urutan modul adalah sebagai berikut: pertama, modul pertama dimuat, yang membaca opsi garis komando, mengonfigurasi file, mengalokasikan memori, menginisialisasi struktur global, memuat tabel sistem, dan mentransfer kontrol ke manajer koneksi.

Ketika klien terhubung ke database, kontrol diteruskan ke manajer utas, yang membuat utas (bukan proses!) untuk klien, dan memeriksa otentikasinya.

Permintaan klien tergantung pada jenisnya pada level tertinggi diproses oleh modul keempat (dispatcher). Permintaan akan dicatat oleh modul ke-11. Perintah diteruskan ke parser, cache diperiksa. Selanjutnya, kueri dapat masuk ke pengoptimal, modul tabel, modul replikasi, dll. Akibatnya, data dikembalikan ke klien melalui pengelola aliran.

Kode yang paling penting ada di file sql/mysqld.cc. Ini berisi fungsi dasar yang tidak berubah sejak versi 3.22: init_common_variables() init_thread_environment() init_server_components() grant_init() // sql/sql_acl.cc init_slave() // sql/slave.cc get_options() handle_connections_sockets() create_new_thread() handle_one_connection() check_connection() acl_check_host() // sql/sql_acl.cc create_random_string() // sql/password.cc check_user() // sql/sql_parse.cc mysql_parse() // sql/sql_parse.cc dispatch_command( ) Query_cache ::store_query() // sql/sql_cache.cc GABUNG::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update.cc mysql_check_table() // sql/sql_table.cc

Header sql/sql_class.h mendefinisikan kelas dasar: Query_arena, Statement, Security_context, kelas Open_tables_state, THD. Objek kelas THD adalah deskriptor utas dan merupakan argumen untuk sejumlah besar fungsi.

3. Perbandingan MySQL dan PostgreSQL: persamaan dan perbedaan

standar asam

Standar ACID didasarkan pada atomisitas, integritas, isolasi, dan keandalan. Model ini digunakan untuk menjamin integritas data. Ini diimplementasikan berdasarkan transaksi. PostgreSQL sepenuhnya sesuai dengan standar ACID. Untuk dukungan penuh ACID di MySQL dalam konfigurasi Anda perlu mengatur default-storage-engine=innodb.

Pertunjukan

Database sering dioptimalkan untuk lingkungan di mana mereka beroperasi. Kedua basis memiliki teknologi yang berbeda untuk meningkatkan kinerja. Secara historis, MySQL dikembangkan dengan mempertimbangkan kecepatan, sementara PostgreSQL dikembangkan sejak awal sebagai database yang sangat dapat disesuaikan dan sesuai standar. PostgreSQL memiliki sejumlah pengaturan yang meningkatkan kecepatan akses:

• indeks parsial;
• kompresi data;
• alokasi memori;
• cache yang ditingkatkan.

MySQL memiliki dukungan parsial untuk indeks parsial di InnoDB. Jika kita mengambil mesin MySQL ISAM, ternyata lebih cepat pada kueri datar, sementara tidak ada kunci pada sisipan, tidak ada dukungan untuk transaksi, kunci asing.

Kompresi

PostgreSQL lebih baik dalam mengompresi dan mendekompresi data, memungkinkan lebih banyak data disimpan di ruang disk. Dalam hal ini, data kompresi dibaca lebih cepat dari disk.

Kompresi MySQL untuk mesin yang berbeda didukung sebagian, sebagian tidak, dan itu tergantung pada versi spesifik dari mesin tertentu.

Pada multi-prosesor PostgreSQL memiliki keunggulan dibandingkan MySQL. Bahkan pengembang MySQL sendiri mengakui bahwa mesin mereka tidak begitu bagus dalam hal ini.

Tipe data

MySQL: menggunakan tipe TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB untuk menyimpan data biner yang ukurannya berbeda-beda (hingga 4 GB).

Karakter: empat jenis - TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

PostgreSQL: mendukung mesin data pengguna dengan perintah CREATE TYPE, tipe BOOLEAN, tipe geometri.

Karakter: TEXT (batas - ukuran baris maks).

Untuk menyimpan data biner, ada tipe BLOB, yang disimpan di berkas sistem. Kolom tabel dapat didefinisikan sebagai array multidimensi dengan panjang variabel. Ekstensi relasional objek: Struktur tabel dapat diwarisi dari tabel lain.

Prosedur tersimpan

Baik PostgreSQL dan MySQL mendukung prosedur tersimpan. PostgreSQL mengikuti standar Oracle PL/SQL, MySQL mengikuti standar IBM DB2. MySQL mendukung perluasan SQL untuk menulis fungsi C/C++ sejak versi 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C untuk menulis prosedur tersimpan.

Kunci

Baik PostgreSQL dan MySQL mendukung keunikan Primary Key dan Foreign Key. MySQL tidak mendukung batasan pemeriksaan ditambah kunci sekunder diimplementasikan sebagian. PostgreSQL: implementasi penuh ditambah dukungan untuk ON DELETE CASCADE dan ON UPDATE CASCADE.

pemicu

MySQL: dukungan dasar. PostgreSQL: pemicu deklaratif: SELECT, INSERT, DELETE, UPDATE, BUKAN; pemicu prosedural: PEMICU CONSTRAINT. Acara: SEBELUM atau SETELAH pada INSERT, DELETE, UPDATE.

kenaikan otomatis

MySQL: Hanya ada satu kolom seperti itu dalam tabel yang perlu diindeks. PostgreSQL: tipe data SERIAL.

Replikasi

Didukung oleh MySQL dan PostgreSQL. PostgreSQL memiliki arsitektur modular dan replikasi hadir dalam modul terpisah:

• Slony-I - mekanisme replikasi utama di postgres, kinerja turun dalam ketergantungan kuadrat pada jumlah server;

Replikasi di PostgreSQL didasarkan pada pemicu dan lebih lambat daripada di MySQL. Replikasi direncanakan akan ditambahkan ke kernel mulai dari versi 8.4.

Di MySQL, replikasi adalah bagian dari inti dan memiliki dua rasa sejak versi 5.1:

• SBR - replikasi berdasarkan pernyataan;
• RBR - replikasi berbasis baris.

Tipe pertama didasarkan pada entri logging ke log biner, tipe kedua didasarkan pada perubahan logging. Dimulai dengan versi 5.5, MySQL mendukung apa yang disebut replikasi semi-sinkron, di mana server utama (master) mem-flush data ke server lain (slave) di setiap komit. Mesin NDB melakukan replikasi dua fase sinkron penuh.

Transaksi

MySQL: Hanya untuk InnoDB. SAVEPOINT, ROLLBACK KE SAVEPOINT dukungan. Tingkat kunci: tingkat tabel (MyISAM). PostgreSQL: didukung plus tingkat komitmen baca dan isolasi. ROLLBACK, ROLLBACK TO SAVEPOINT dukungan. Tingkat kunci: tingkat baris, tingkat tabel.

Tingkat hak istimewa

PostgreSQL: Hak istimewa dapat diberikan kepada pengguna atau grup pengguna.

Ekspor-impor data

MySQL: kumpulan utilitas ekspor: mysqldump, mysqlhotcopy, mysqlsnapshot. Di impor dari file teks, html, dbf. PostgreSQL: ekspor - utilitas pg_dump. Impor antara database dan sistem file.

Subkueri

Ada MySQL dan PostgreSQL, tetapi MySQL bisa jadi tidak produktif.

Pengindeksan

Indeks hashing: parsial di MySQL, penuh di PostgreSQL. Pencarian teks lengkap: di MySQL - sebagian, di PostgreSQL - penuh. Indeks parsial: tidak didukung di MySQL, didukung di PostgreSQL. Indeks multi-kolom: di MySQL, batasnya adalah 16 kolom, di PostgreSQL - 32. Indeks ekspresi: di MySQL - emulasi, di PostgreSQL - penuh. Non-blocking create index: parsial di MySQL, penuh di PostgreSQL.

Partisi

MySQL mendukung partisi horizontal: rentang, daftar, hash, kunci, partisi komposit. PostgreSQL mendukung RANGE dan LIST. Partisi otomatis untuk tabel dan indeks.

Kegagalan otomatis

MySQL: parsial untuk InnoDB - Anda perlu membuat cadangan secara manual. PostgreSQL: Write Ahead Logging (WAL).

Mesin Penyimpanan Data

PostgreSQL mendukung satu mesin - Sistem Penyimpanan Postgres. Ada beberapa di MySQL 5.1:

• MyISAM - digunakan untuk menyimpan tabel sistem;
• InnoDB – kepatuhan ACID maksimum, menyimpan data dengan kunci utama, menyisipkan cache, mendukung kompresi sejak versi 5.1 – lihat atribut ROW_FORMAT=COMPRESSED;
• NDB Cluster adalah mesin berorientasi memori, arsitektur cluster menggunakan replikasi sinkron;
• ARCHIVE - mendukung kompresi, tidak menggunakan indeks;
• dan juga: MERGE, MEMORY (HEAP), CSV.

InnoDB dikembangkan oleh InnoBase, anak perusahaan Oracle. Dalam versi ke-6, dua mesin akan muncul - Maria dan Falcon. Falcon adalah mesin berdasarkan transaksi ACID.

Lisensi

PostgreSQL: BSD (Distribusi Perangkat Lunak Berkeley) sumber terbuka. MySQL: GPL (Gnu General Public License) atau Komersial. MySQL adalah produk open source. Postgres adalah proyek sumber terbuka.

Kesimpulan

Ringkasnya, kita dapat mengatakan sebagai berikut: MySQL dan PostgreSQL adalah dua database open-source paling populer di dunia. Setiap basis memiliki karakteristik dan perbedaannya sendiri. Jika Anda membutuhkan penyimpanan cepat untuk kueri sederhana dengan pengaturan minimal, saya akan merekomendasikan MySQL. Jika Anda membutuhkan penyimpanan yang andal untuk sejumlah besar data dengan kemampuan untuk memperluas, mereplikasi, sepenuhnya mematuhi standar bahasa SQL modern, saya sarankan menggunakan PostgreSQL.

Kami akan membahas masalah konfigurasi MySQL dan PostgreSQL.

Unduh sumber daya

static.content.url=http://www.website/developerworks/js/artrating/

Zone=Sumber terbuka, Linux

ID Artikel=779830

ArticleTitle=MySQL & PostgreSQL: Bagian 1 Pembandingan

Database relasional telah ada sejak lama. Mereka menjadi populer berkat sistem kontrol yang mengimplementasikan model relasional dengan sangat baik dengan cara yang terbaik bekerja dengan data, terutama untuk aplikasi dan layanan penting.

MySQL telah ada sejak lama dan telah membuktikan dirinya sebagai solusi hebat, Postgresql hadir di pasaran pada waktu yang hampir bersamaan, tetapi menyediakan cukup banyak fitur menarik dan peluang, berkat yang dengan cepat mendapatkan popularitas. Pada artikel ini, kami akan mencoba membandingkan MySQL vs Postgresql, membandingkan perbedaan utama antara sistem ini, mencari tahu cara kerjanya, dan mencoba memahami sistem mana yang terbaik untuk proyek Anda.

Database dirancang untuk penyimpanan terstruktur dan akses cepat ke berbagai data. Setiap basis data, kecuali data itu sendiri, harus memiliki model kerja tertentu, yang dengannya pemrosesan data akan dilakukan. Untuk mengelola database, DBMS atau sistem manajemen database digunakan, program tersebut termasuk MySQL dan Postgresql.

Sistem manajemen basis data relasional memungkinkan data ditempatkan dalam tabel dengan menghubungkan baris dari tabel yang berbeda dan dengan demikian menghubungkan data yang berbeda dan digabungkan secara logis. Sebelum Anda dapat menyimpan data, Anda harus membuat tabel dengan ukuran tertentu dan menentukan tipe data untuk setiap kolom. Kolom mewakili bidang data, dan data itu sendiri ditempatkan dalam baris. Baik sistem manajemen basis data dan MySQL vs Postgresql bersifat relasional. Selanjutnya, kami akan mempertimbangkan secara lebih rinci bagaimana kedua program berbeda. Dan sekarang mari kita beralih ke pertimbangan yang lebih rinci.

Cerita pendek

MySQL

Pengembangan MySQL dimulai pada tahun 90-an. Rilis internal pertama dari database terjadi pada tahun 1995. Selama ini, beberapa perusahaan terlibat dalam pengembangan program. Pengembangan dimulai oleh perusahaan Swedia MySQL AB, yang diakuisisi oleh Sun Microsystems, yang sebenarnya menjadi milik Oracle. Saat ini, sejak 2010, Oracle telah berkembang.

postgresql

Pengembangan Postgresql dimulai pada tahun 1986 di University of California, Berkeley. Pengembangan berlangsung hampir delapan tahun, kemudian proyek ini dibagi menjadi dua bagian, database komersial IIlustra dan proyek Postrgesql gratis, yang dikembangkan oleh para penggemar.

Penyimpanan data

MySQL

MySQL adalah database relasional, berbagai mesin digunakan untuk menyimpan data dalam tabel, tetapi bekerja dengan mesin tersembunyi di sistem itu sendiri. Mesin tidak memengaruhi sintaks kueri dan eksekusinya. Mesin utama yang didukung adalah MyISAM, InnoDB, MEMORY, Berkeley DB. Mereka berbeda satu sama lain dalam cara data ditulis ke disk, serta dalam metode membaca.

postgresql

Postgresql adalah database relasional objek yang berjalan hanya pada satu mesin - mesin penyimpanan. Semua tabel direpresentasikan sebagai objek, mereka dapat diwariskan, dan semua tindakan dengan tabel dilakukan menggunakan fungsi berorientasi objektif. Seperti di MySQL, semua data disimpan di disk dalam file yang diurutkan secara khusus, tetapi struktur file ini dan catatan di dalamnya sangat berbeda.

standar SQL

Terlepas dari sistem manajemen basis data yang digunakan, SQL adalah bahasa eksekusi kueri standar. Dan itu didukung oleh semua solusi, bahkan MySQL atau Postgresql. Standar SQL dikembangkan pada tahun 1986 dan sejak itu beberapa versi telah dirilis.

MySQL

MySQL tidak mendukung semua fitur baru dari standar SQL. Pengembang memilih jalur pengembangan ini agar MySQL tetap mudah digunakan. Perusahaan berusaha memenuhi standar, tetapi tidak mengorbankan kesederhanaan. Jika suatu fitur dapat meningkatkan kegunaan, maka pengembang dapat mengimplementasikannya sebagai ekstensi mereka sendiri tanpa memperhatikan standar.

postgresql

Postgresql adalah proyek open source, dikembangkan oleh tim penggemar, dan pengembang berusaha untuk mematuhi standar SQL sebanyak mungkin dan menerapkan semua standar terbaru. Tetapi semua ini datang dengan mengorbankan kesederhanaan. Postgresql sangat kompleks dan karena itu tidak sepopuler MySQL.

Kemampuan Pemrosesan

Perbedaan lain antara postgresql dan mysql muncul dari paragraf sebelumnya, ini adalah kemampuan dan keterbatasan pemrosesan data. Secara alami, kepatuhan terhadap standar yang lebih baru memberikan peluang yang lebih baru.

MySQL

Saat menjalankan kueri, MySQL memuat seluruh respons server ke dalam memori klien; untuk data dalam jumlah besar, ini mungkin tidak terlalu nyaman. Secara umum, Postgresql lebih unggul dari Mysql dalam hal fungsi, kami akan mempertimbangkan lebih lanjut di mana.

postgresql

Postgresql mendukung penggunaan kursor untuk menelusuri data yang diterima. Anda hanya mendapatkan pointer, seluruh respons disimpan dalam memori server database. Pointer ini dapat disimpan di antara sesi. Ini mendukung indeks bangunan untuk beberapa kolom tabel sekaligus. Selain itu, indeks dapat menjadi berbagai jenis, selain hash dan b-tree, GiST dan SP-GiST tersedia untuk bekerja dengan kota, GIN untuk pencarian teks, BRIN dan Bloom.

Postgresql mendukung ekspresi reguler dalam kueri, kueri rekursif, dan pewarisan tabel. Tetapi ada beberapa batasan di sini, misalnya, Anda hanya dapat menambahkan bidang baru ke akhir tabel.

Pertunjukan

Database harus dioptimalkan untuk lingkungan di mana Anda akan bekerja. Secara historis, MySQL telah dirancang untuk kinerja maksimum, sementara Postgresql telah dirancang agar sangat dapat disesuaikan dan sesuai standar mungkin. Namun seiring berjalannya waktu, Postgresql telah menerima banyak peningkatan dan optimasi.

MySQL

Dalam kebanyakan kasus, tabel InnoDB digunakan untuk mengatur pekerjaan dengan database di MySQL; tabel ini adalah B-tree dengan indeks. Indeks memungkinkan Anda untuk mengambil data dari disk dengan sangat cepat, dan ini akan membutuhkan lebih sedikit operasi disk. Tetapi memindai pohon membutuhkan menemukan dua indeks, yang sudah lambat. Semua ini berarti MySQL akan lebih cepat dari Postgresql hanya jika menggunakan kunci utama.

postgresql

Semua informasi header tabel Postgresql berada di RAM. Anda tidak dapat membuat tabel yang kehabisan memori. Catatan tabel diurutkan berdasarkan indeks, sehingga Anda dapat mengambilnya dengan sangat cepat. Untuk kenyamanan lebih, Anda dapat menerapkan beberapa indeks ke tabel yang sama.

Secara umum, PostgreSQL lebih cepat, kecuali untuk penggunaan kunci utama. Mari kita lihat beberapa tes dengan operasi yang berbeda:

Tipe data

Salah satu yang menarik dari kedua database adalah tipe data yang didukung yang dapat Anda gunakan. Karena kedua solusi mencoba mencocokkan sintaks SQL, mereka memiliki set yang serupa, tetapi masih berbeda dalam beberapa hal.

MySQL

MySQL mendukung tipe data berikut:

• kecil: bilangan bulat yang sangat kecil.;
• KECIL: keseluruhan kecil;
• SEDANG: bilangan bulat berukuran sedang;
• masuk: bilangan bulat ukuran normal;
• BIGINT: keseluruhan besar;
• MENGAMBANG: nomor floating-point bertanda presisi tunggal;
• GANDA, PRESISI GANDA, NYATA: nomor floating-point bertanda presisi ganda
• DESIMAL, NUMERIK: nomor floating point yang ditandatangani;
• TANGGAL: tanggal;
  TANGGAL WAKTU: kombinasi tanggal dan waktu;
• KETENTUAN WAKTU: stempel waktu;
• WAKTU: waktu;
  TAHUN: tahun dalam format YY atau YYYY;
• ARANG: string ukuran tetap, diisi dengan spasi hingga panjang maksimum;
• VARCHAR: string panjang variabel;
• TINYBLOB, TINYTEXT: data biner atau teks dengan panjang maksimum 255 karakter;
• BLOB, TEKS: data biner atau teks dengan panjang maksimum 65535 karakter;
• MEDIUMBLOB, MEDIUMTEXT: teks atau data biner;
• LONGBLOB, TEKS PANJANG: teks atau data biner dengan panjang maksimum 4294967295 karakter;
• ENUM: pencacahan;
• MENGATUR: set.

postgresql

Jenis bidang yang didukung di Postgresql sangat berbeda, tetapi memungkinkan Anda untuk menulis data yang sama persis:

• besar: bilangan bulat 8-byte yang ditandatangani;
• serial besar: bilangan bulat 8-byte yang bertambah secara otomatis;
• sedikit: string biner dengan panjang tetap;
• sedikit bervariasi: string biner panjang variabel;
• boolean: bendera;
• kotak: persegi panjang di pesawat;
• byte: data biner;
• karakter bervariasi: string karakter dengan panjang tetap;
• karakter:
• asam: alamat jaringan IPv4 atau IPv6;
• lingkaran: lingkaran di pesawat;
• tanggal: tanggal kalender;
• presisi ganda: nomor floating-point presisi ganda;
• tidak ada: Alamat IPv4 atau IPv6 Internet;
• bilangan bulat: bilangan bulat 4-byte yang ditandatangani;
• selang: Titik;
• garis: garis lurus tak terbatas pada bidang;
• lsg: segmen di pesawat;
• macaddr: Alamat MAC;
• uang: nilai moneter;
• jalur: jalur geometris di pesawat;
• titik: titik geometris pada bidang;
• poligon: poligon di pesawat;
• nyata: nomor floating point presisi tunggal;
• kecil: bilangan bulat dua byte;
• serial: bilangan bulat empat bit yang bertambah secara otomatis;
• teks: string karakter panjang variabel;
• waktu: Waktu dalam Sehari;
• stempel waktu: tanggal dan waktu;
• tsquery: permintaan pencarian teks;
• vektor: dokumen pencarian teks;
• uid: pengenal unik;
• xml: data XML.

Seperti yang Anda lihat, ada lebih banyak tipe data di Postgresql dan lebih beragam, ada tipe bidang untuk tipe data tertentu yang tidak dimiliki MySQL. Perbedaan antara MySQL dan Postgresql sudah jelas.

Perkembangan

Kedua proyek adalah open source, tetapi berkembang dengan cara yang berbeda. Tidak semua orang menyukai pengembangan MySQL. Dan dalam perbandingan ini mysql dan postgresql memberikan banyak perbedaan.

MySQL

Database MySQL sedang dikembangkan oleh Oracle dan ada desas-desus bahwa perusahaan bermaksud untuk memperlambat pengembangan mesin. Banyak fork proyek telah dibuat, termasuk fork MariaDB dari pengembang MySQL asli. Namun perkembangannya tetap lambat.

postgresql

Seperti disebutkan di awal artikel, pengembangan dimulai di Universitas Berkeley. Kemudian dia pindah ke perusahaan komersial. Sekarang program ini sedang dikembangkan oleh sekelompok pemrogram independen dan dewan dari beberapa perusahaan. Versi baru dirilis dengan cukup aktif dan mendapatkan lebih banyak fitur baru.

kesimpulan

Pada artikel ini, kami membandingkan mysql dan postgresql, melihat perbedaan utama antara kedua sistem manajemen basis data, dan mencoba memahami mana yang lebih baik daripada postgresql atau mysql. Secara umum, Postgresql adalah yang terbaik dalam hal kemampuan, tetapi kompleks dan tidak berlaku di mana-mana. MySQL lebih sederhana tetapi tidak memiliki beberapa fitur keren. Dan database apa yang akan Anda pilih untuk proyek Anda? Mengapa dia? Tulis di komentar!

Apa perbedaan MySQL dan PostgreSQL?

Apa kelebihan PostgreSQL?

Apa saja keunggulan yang dimiliki MySQL?

Apakah yang dimaksud dengan database PostgreSQL?