Bagaimana menangani pertanyaan 500 juta + item

8

Struktur data saya adalah sebagai berikut:

date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very important

Saya perlu melakukan pertanyaan berikut:

Pertama:

Filter data dengan date, filter_a, filter_b, filter_cdan lain-lain

Kedua, dengan data yang difilter:

hitung semua catatan
dapatkan rata - ratavariable_a , variable_bdanvariable_c
mendapatkan standar deviasi dari variable_a, variable_bdanvariable_c
dapatkan kuartil dari variable_a, variable_bdanvariable_c
kelompokkan data dengan groupatau second_groupdan agregat (Hitung, Rta, Std, ..)

Jumlah pengguna sistem adalah sekitar 10 atau 15, tetapi jumlah item sangat besar, saat ini adalah 70 juta tetapi akan menjadi 500 juta dalam beberapa minggu dan akan menjadi 1.000 juta dalam waktu sekitar satu tahun.

Jumlah pertanyaan kecil, tidak lebih dari 10 pengguna secara bersamaan, masalah saya adalah bagaimana menangani pertanyaan-pertanyaan dengan jumlah data yang sangat besar ini.

Apa yang sudah saya coba sejauh ini?

Saya mulai dengan mongodb, pada awalnya itu cepat tetapi menjadi lambat ketika menghitung kuartil dengan 10M +. Itu membaik ketika saya menambahkan indeks tetapi tidak banyak membantu ketika saya harus menanyakan semua data. Saya mulai menggunakan mongodb karena data sangat dinamis tetapi untungnya format data "tidak akan berubah lagi".
Seperti filter_adan filter_bdapat dilihat seperti node, saya mencoba neo4j. Saya sangat menyukainya, tetapi grafik saya memiliki BANYAK tepi sehingga permintaan tidak terlalu cepat.
Akhirnya, karena format data tidak akan berubah dan itu hanya satu koleksi / tabel jadi tidak perlu bergabung dalam SQL, saya memeriksa postgresql. Tes saya lebih cepat dengan postgresql, tetapi saya khawatir tes ini tidak dapat mengukur dengan benar di masa mendatang.

Apa yang saya butuhkan?

Apakah postgresql pilihan yang baik untuk kasus ini?
Apakah ada jenis database lain yang bisa saya gunakan? mana yang terbaik untuk kasus ini?
Apa lagi yang bisa saya lakukan untuk memperbaikinya?

Edit

Sekitar 1M elemen dimasukkan setiap hari dan "tidak boleh berubah" sepanjang waktu.
Kecepatan menulis tidak penting
Syarat sulitnya adalah membaca / agregat cepat

Terima kasih!

— Andres
sumber

1

Bagaimana dengan pandangan yang diindeks di SQL Server / pandangan metastasis di Oracle? Itu adalah agregat berjalan dari tabel dasar sehingga tabel dasar dapat dimodifikasi indeks juga dimodifikasi dengan cepat. Kemudian Anda selalu dapat meminta agregat yang sudah dihitung untuk Anda.

— Ali Razeghi

@AliRazeghi diindeks tampilan adalah ide bagus. Pokoknya pertama saya ingin memilih database / desain terbaik sebelum mengoptimalkan permintaan itu sendiri

— Andres

1

Untuk mengoptimalkan murni di Postgres, saya ingin mengatakan bahwa indeks BRIN dapat membantu di sini, tetapi saya belum melakukan apa pun selain membaca tentang mereka. postgresql.org/docs/9.5/static/brin-intro.html

— Erik Darling

1

Secara pribadi saya mewarisi multi-miliar baris pelaporan DB pada server OLTP tanpa banyak memori. Untungnya bagian yang paling dipertanyakan darinya adalah bergulir '3 minggu terakhir' tetapi pemindaian meja tidak pernah terjadi. Jujur dengan menggunakan kompresi yang sangat baik, partisi, penghapusan partisi, skema partisi, optimasi cache SAN, dan menghapus indeks yang tidak terpakai kami mendapat kinerja yang sangat baik pada MS SQL 2008 Ent. 1 milyar tidak akan terlalu sulit untuk PGSQL. Berapa lebar setiap baris atau kira-kira berapa banyak ruang yang menurut Anda akan diambil setiap baris, dan berapa banyak indeks yang akan ada per tabel atau proses input?

— Ali Razeghi

2

@Andres juga tergantung pada mesin apa yang ada di dalamnya dan berapa ukuran maksimal dari setiap baris sehingga kita dapat menghitung. Misalnya PostgreSQL memiliki varchar dan hanya char, char mudah dihitung, varchar kita harus menebak panjang rata-rata. Jika kita bisa tahu jenis bidang apa itu (kecuali itu Mongo atau sesuatu yang menyimpannya dalam dokumen dengan formatnya sendiri), kira-kira berapa banyak karakter yang kita harapkan di masing-masing, dan # indeks dengan kolom. 8GB RAM sepertinya terlalu rendah untuk secara efisien menariknya keluar dari memori, terutama jika RAM itu dibagi dengan tabel dan sumber daya lain di server.

— Ali Razeghi

5

Alih-alih bersandar pada database relasional untuk melakukan perhitungan statistik ini pada data time-series, saya sarankan Anda memindahkan matematika ini dan pekerjaan post-processing di luar database ke dalam aplikasi klien.

Menggunakan bahasa skrip seperti Python atau Ruby, Anda dapat secara bertahap menyelesaikan masalah dengan meminta "potongan" data selama periode waktu tetap lebar, menghitung ringkasan statistik menengah, dan kemudian menggabungkan hasil di beberapa potongan, saat Anda mengulangi seluruh sejarah. Beberapa ukuran statistik sulit untuk digabungkan antar bongkahan, tetapi sesuatu seperti Rata-rata () hanya perlu jumlah () dan hitung () per bongkahan, O (1) vs O (bungkusan), sehingga penggabungan bongkahan dapat berskala baik.

— Jpierc
sumber

Saya mencoba sesuatu seperti itu menggunakan python / panda . kalkulus lebih cepat (beberapa detik) tetapi mengambil semua data lambat. Mungkin yang lebih baik chunksizebisa membantu. +1

— Andres

1

Karena data Anda tidak berubah, dan hanya ditambahkan, saya akan menyimpan data di mana pun Anda suka; Amazon S3 misalnya, tetapi basis data yang membaca cepat tidak masalah. Tidak ada indeks. Basis data / FS yang Anda pilih harus memiliki opsi untuk membaca data dalam ember: Anda dapat, misalnya, satu file per hari dengan catatan 1M Anda.

Kemudian saya akan menggunakan Spark untuk melakukan penyaringan / analisis. Berbasis cluster, Anda dapat menyesuaikannya dengan kebutuhan Anda.

— Leo
sumber

Saya setuju, saya sudah memisahkan dataset saya per hari. Saya juga memikirkan HDFS dan HBase

— Andres

0

Respons tergantung dari cara Anda akan menggunakan data setelah ini. Jika untuk pemrosesan lebih baik gunakan Cassandra, jika untuk analisis lebih baik gunakan Hive.

— Artemy Prototyping
sumber

Saya mengerti sarang tidak bisa menjadi pilihan terbaik real time. Apakah aku salah?

— Andres

1

Ya, HBase adalah untuk baca / tulis waktu nyata. Tapi Cassandra juga bisa melakukan hal yang sama. Tapi saya pikir HBase lebih baik.

— Artemy Prototyping

0

Situasi semacam ini sangat ideal untuk pergudangan data, menggunakan teknik yang disempurnakan oleh Ralph Kimball dan rekan, pada platform seperti SQL Server (yang saya paling akrab dengan). Mereka dirancang khusus dengan jenis skenario ini dalam pikiran: sejumlah besar catatan data yang relatif statis, untuk itu Anda perlu menghitung agregat jenis ini. Tidakteknik relasional akan cocok untuk data pergudangan yang diimplementasikan dengan benar dalam aplikasi semacam ini, meskipun beberapa tentu akan lebih baik daripada yang lain jika organisasi Anda tidak mampu membeli lisensi untuk paket perangkat lunak (seperti SQL Server Analysis Services) yang mengimplementasikannya. Ada juga kurva belajar untuk mengimplementasikan bahasa seperti MDX yang dibuat khusus untuk akses data semacam ini. Jika pergudangan data merupakan opsi yang layak untuk organisasi Anda, maka jangan buang waktu mencari solusi relasional; ini bukan masalah basis data relasional. Saya dapat memposting beberapa referensi dasar ke Kimball dll. Dan tautan ke SSAS dan MDX (maaf saya tidak bisa membantu dengan Oracle dan kompetitor lain yang saya tidak kenal) dokumentasi jika perlu. Saya harap itu membantu.

— SQLServerSteve
sumber