Mana yang lebih cepat: PostgreSQL vs MongoDB pada dataset JSON besar?


10

Saya memiliki dataset besar dengan objek JSON 9m masing-masing ~ 300 byte. Mereka adalah posting dari agregator tautan: pada dasarnya tautan (URL, judul dan id penulis) dan komentar (teks dan ID penulis) + metadata.

Mereka bisa menjadi catatan relasional dalam sebuah tabel, kecuali fakta bahwa mereka memiliki satu bidang array dengan ID yang menunjuk ke catatan anak.

Implementasi apa yang terlihat lebih solid?

  1. Objek JSON pada database PostgreSQL (hanya satu tabel besar dengan satu kolom, yaitu objek JSON)
  2. Objek JSON pada MongoDB
  3. Meledakkan objek JSON menjadi kolom dan menggunakan array di PostgreSQL

Saya ingin memaksimalkan kinerja dalam gabungan, sehingga saya dapat memijat data dan menjelajahinya sampai saya menemukan analisis yang menarik, pada titik mana saya pikir akan lebih baik untuk mengubah data menjadi bentuk khusus untuk setiap analisis.


mungkin ingin checkout kepingan salju. Ini dapat menangani data terstruktur dan semi-terstruktur secara bersamaan. www.snowflake.net

Saya pikir Anda perlu memperluas arti "memaksimalkan kinerja dalam gabungan" bagi Anda. Bergabung dengan apa?
Spacedman

Jawaban:


10

Untuk memuat data, Postgre mengungguli MongoDB. MongoDB hampir selalu lebih cepat saat mengembalikan jumlah permintaan. PostgreSQL hampir selalu lebih cepat untuk permintaan menggunakan indeks.

Lihat situs web ini dan yang ini juga untuk info lebih lanjut. Mereka memiliki penjelasan yang sangat rinci.


Tautan yang sangat bagus, khususnya yang pertama yang terlihat lebih detail dan teliti. Saat mencari tahun (string) dan mengembalikan record id (int), potgresql sekitar 4x lebih cepat, tetapi ketika mengembalikan penulis, urutan besarnya sama. MongoDB hanya sekitar 20% lebih lambat ketika mengembalikan penulis. Apakah ada perbedaan mendasar antara mengembalikan int dan mengembalikan string yang dapat menjelaskan hal ini? Artinya, jika recid adalah string, akankah keuntungan postgresql menghilang dan keduanya berada di sekitar yang sama seperti dalam kasus penulis?
MASL

1

Anda bisa mendapatkan manfaat lebih dari desain schodaless Mongodb. Ini berarti sangat mudah untuk memodifikasi struktur data dengan cepat.

Tidak ada yang namanya bergabung dalam Mongodb. Jadi bagaimana seseorang berpikir tentang data dan bagaimana menggunakannya perlu dimodifikasi untuk memperhitungkan lingkungan berbasis dokumen dan schemaless db.

Mungkin kecepatan menjadi kurang penting ketika perspektif dan prioritas berubah.

Saya harap itu membantu.

-Todd


Dalam tolok ukur terbaru, PostgreSQL benar-benar memiliki MongoDB ...
Memiliki QUIT - Anony-Mousse

@ Anony-Mousse: Menarik. Apakah Anda tahu sumber apa pun?
Isaac

misalnya tiborsimko.org/postgresql-mongodb-json-select-speed.html dan enterprisedb.com/postgres-plus-edb-blog/marc-linster/… dari jawaban lain. Alasan utamanya adalah: Postgres memiliki indeks yang baik, sedangkan indeks di MongoDB tidak layak. Selain itu, Postgres mendapat dukungan BSON dan tambahan lainnya untuk menangani JSON, yang memang meningkatkan kinerja secara signifikan. Itu sebabnya ia mendapat jauh lebih cepat daripada di versi pertama.
Memiliki QUIT - Anony-Mousse

0

Untuk angka yang Anda sebutkan, saya pikir semua alternatif harus berfungsi (baca: Anda akan dapat menyelesaikan analisis Anda dalam waktu yang wajar). Saya merekomendasikan desain yang dapat menghasilkan hasil yang jauh lebih cepat.

Seperti yang dijawab sebelumnya, secara umum postgresql lebih cepat daripada mongo, beberapa kali lebih dari 4 kali lebih cepat. Lihat misalnya: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality

Anda mengatakan bahwa Anda tertarik untuk meningkatkan kinerja bergabung. Saya berasumsi bahwa Anda tertarik untuk menghitung kesamaan di antara entitas (misalnya, pos, penulis) sehingga Anda akan terutama bergabung dengan tabel itu sendiri (misalnya, melalui pos atau penulis) dan agregat.

Tambahkan ke fakta bahwa setelah memuat awal database Anda hanya akan dibaca, apa yang membuat masalah sangat cocok untuk mengindeks penggunaan. Anda tidak akan membayar untuk pembaruan indeks karena Anda tidak akan memilikinya dan saya kira Anda memiliki penyimpanan ekstra untuk indeks.

Saya akan menggunakan postgres dan menyimpan data dalam dua tabel:

buat posting tabel (integer post_id, url varchar (255), integer author_id);

- Muat data dan kemudian buat indeksnya. - Itu akan menyebabkan pemuatan yang lebih cepat dan indeks yang lebih baik mengubah posting tabel menambahkan kunci primer posts_pk constraint (post_id); buat indeks post_author pada posting (author_id);

buat komentar tabel (integer comment_id, integer post_id, integer author_id, comment varchar (255)); ubah komentar tabel tambahkan constraint comments_pk primary key (comment_id); buat indeks comment_author pada komentar (author_id); buat indeks comment_post pada komentar (post_id);

Kemudian Anda dapat menghitung kesamaan penulis berdasarkan komentar dalam kueri seperti pilih m. author_id sebagai m_author_id, a. author_id sebagai a_author_id, hitung (m.post_id berbeda) sebagai posting dari komentar sebagai m gabung komentar sebagai grup menggunakan (post_id) oleh m.author_id, a. author_id

Jika Anda tertarik tokenzing kata-kata dalam komentar untuk nlp, tambahkan tabel lain untuk itu tetapi ingat bahwa itu akan meningkatkan volume data Anda secara signifikan. Biasanya lebih baik tidak mewakili seluruh tokenization dalam database.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.