Pertanyaan Penyimpanan data terbaik untuk miliaran baris


Saya harus mampu menyimpan data-data kecil (sekitar 50-75 byte) untuk milyaran rekaman (~ 3 miliar / bulan selama setahun).

Satu-satunya persyaratan adalah penyisipan cepat dan pencarian cepat untuk semua catatan dengan GUID yang sama dan kemampuan untuk mengakses penyimpanan data dari .net.

Saya seorang pria SQL server dan saya pikir SQL Server bisa melakukan ini, tetapi dengan semua pembicaraan tentang BigTable, CouchDB, dan solusi nosql lainnya, itu terdengar lebih dan lebih seperti alternatif untuk RDBS tradisional mungkin yang terbaik karena optimisasi untuk kueri terdistribusi dan penskalaan. Saya mencoba cassandra dan pustaka .net saat ini tidak dikompilasi atau semuanya dapat berubah sewaktu-waktu (bersama dengan cassandra sendiri).

Saya telah melihat ke banyak toko data nosql yang tersedia, tetapi tidak dapat menemukan satu yang memenuhi kebutuhan saya sebagai platform siap produksi yang kuat.

Jika Anda harus menyimpan 36 miliar catatan kecil, sehingga mereka dapat diakses dari .net, apa yang akan dipilih dan mengapa?


76
2018-05-08 16:11


asal


Jawaban:


Menyimpan ~ 3,5TB data dan memasukkan sekitar 1K / detik 24x7, dan juga query pada tingkat yang tidak ditentukan, mungkin dengan SQL Server, tetapi ada lebih banyak pertanyaan:

  • apa persyaratan ketersediaan yang Anda miliki untuk ini? Uptime 99,999%, atau cukup 95%?
  • apa persyaratan keandalan yang Anda miliki? Apakah hilang sisipan biaya $ 1 juta?
  • apa persyaratan pemulihan yang Anda miliki? Jika Anda kehilangan satu hari data, apakah itu penting?
  • apa persyaratan konsistensi yang Anda miliki? Apakah sebuah tulisan harus dijamin agar terlihat pada pembacaan berikutnya?

Jika Anda membutuhkan semua persyaratan yang saya soroti, beban yang Anda usulkan akan menghabiskan biaya jutaan dalam perangkat keras dan lisensi pada sistem relasional, sistem apa pun, apa pun gimmicks yang Anda coba (sharding, partisi, dll). Sistem nosql, menurut definisinya, tidak akan bertemu semua persyaratan ini.

Jadi jelas Anda sudah melonggarkan beberapa persyaratan ini. Ada panduan visual yang bagus yang membandingkan penawaran nosql berdasarkan paradigma 'pilih 2 dari 3' Panduan Visual untuk Sistem NoSQL:

nosql comparisson

Setelah pembaruan komentar OP

Dengan SQL Server ini akan menjadi implementasi langsung ke depan:

  • satu meja tunggal bergerombol (GUID, waktu) kunci. Ya, akan didapat terfragmentasi, tetapi fragmentasi mempengaruhi membaca-depan dan membaca-depan diperlukan hanya untuk berbagai pemindaian yang signifikan. Karena Anda hanya meminta GUID dan rentang tanggal tertentu, fragmentasi tidak terlalu penting. Ya, adalah kunci yang lebar, sehingga halaman non-daun akan memiliki kepadatan kunci yang buruk. Ya, itu akan menyebabkan faktor pengisian yang buruk. Dan ya, perpecahan halaman dapat terjadi. Meskipun masalah ini, mengingat persyaratan, masih merupakan pilihan kunci terbaik.
  • partisi tabel dengan waktu sehingga Anda dapat menerapkan penghapusan yang efisien dari catatan kadaluarsa, melalui jendela geser otomatis. Tambahkan ini dengan membangun kembali partisi indeks online pada bulan lalu untuk menghilangkan faktor pengisian yang buruk dan fragmentasi yang diperkenalkan oleh pengelompokan GUID.
  • aktifkan kompresi halaman. Karena kelompok kunci yang dikelompokkan oleh GUID pertama, semua catatan GUID akan bersebelahan, memberi kompresi halaman kesempatan bagus untuk menyebarkan kompresi kamus.
  • Anda akan membutuhkan jalur IO cepat untuk file log. Anda tertarik pada throughput yang tinggi, bukan pada latensi rendah untuk log untuk mengikuti 1K insert / sec, jadi pengupasan Adalah sebuah keharusan.

Mempartisi dan kompresi halaman masing-masing memerlukan Enterprise Edition SQL Server, mereka tidak akan bekerja pada Edisi Standar dan keduanya cukup penting untuk memenuhi persyaratan.

Sebagai catatan tambahan, jika catatan berasal dari server web front-end, saya akan menempatkan Express pada setiap server web dan alih-alih INSERT di bagian belakang, saya akan SEND info ke bagian belakang, menggunakan koneksi / transaksi lokal pada Express yang ditempatkan bersama dengan server web. Ini memberikan cerita ketersediaan jauh lebih baik untuk solusi.

Jadi ini adalah bagaimana saya akan melakukannya di SQL Server. Kabar baiknya adalah bahwa masalah yang akan Anda hadapi dipahami dengan baik dan solusi diketahui. itu tidak berarti ini lebih baik dari apa yang dapat Anda capai dengan Cassandra, BigTable atau Dynamo. Aku akan membiarkan seseorang lebih tahu dalam hal-hal yang tidak ada alasan untuk memperdebatkan kasus mereka.

Perhatikan bahwa saya tidak pernah menyebutkan model pemrograman, dukungan .Net dan semacamnya. Sejujurnya saya pikir mereka tidak relevan dalam penyebaran besar. Mereka membuat perbedaan besar dalam proses pengembangan, tetapi setelah digunakan tidak peduli seberapa cepat pengembangan itu, jika overhead ORM membunuh kinerja :)


94
2018-05-08 17:27



Bertentangan dengan kepercayaan populer, NoSQL bukan tentang kinerja, atau bahkan skalabilitas. Ini terutama tentang meminimalkan apa yang disebut mismatch impedansi Object-Relational, tetapi juga tentang horisontal skalabilitas vs yang lebih khas vertikal skalabilitas dari RDBMS.

Untuk persyaratan sederhana dari fasts insert dan pencarian cepat, hampir semua produk database akan dilakukan. Jika Anda ingin menambahkan data relasional, atau bergabung, atau memiliki logika transaksional kompleks atau kendala yang perlu Anda terapkan, maka Anda menginginkan database relasional. Tidak ada produk NoSQL yang bisa dibandingkan.

Jika Anda membutuhkan data schemaless, Anda akan ingin pergi dengan database berorientasi dokumen seperti MongoDB atau CouchDB. Skema lepas adalah gambar utama ini; Saya pribadi suka MongoDB dan menggunakannya dalam beberapa sistem pelaporan kustom. Saya merasa ini sangat berguna ketika kebutuhan data terus berubah.

Opsi NoSQL utama lainnya didistribusikan Toko-Toko Nilai-Utama seperti BigTable atau Cassandra. Ini sangat berguna jika Anda ingin skala database Anda di banyak mesin yang menjalankan perangkat keras komoditas. Mereka juga bekerja dengan baik di server, tetapi tidak memanfaatkan perangkat keras kelas atas seperti SQL Server atau Oracle atau basis data lain yang dirancang untuk vertikal scaling, dan jelas, mereka tidak relasional dan tidak baik untuk menegakkan normalisasi atau kendala. Juga, seperti yang Anda perhatikan,. Dukungan NET cenderung menjadi jerawatan terbaik.

Semua produk database relasional mendukung partisi semacam terbatas. Mereka tidak sefleksibel sistem BigTable atau DKVS lainnya, mereka tidak mudah dipartisi ratusan server, tetapi tidak terdengar seperti itulah yang Anda cari. Mereka cukup pandai menangani jumlah catatan dalam miliaran, selama Anda mengindeks dan menormalkan data dengan benar, jalankan database pada perangkat keras yang kuat (terutama SSD jika Anda dapat membelinya), dan partisi di 2 atau 3 atau 5 disk fisik jika perlu.

Jika Anda memenuhi kriteria di atas, jika Anda bekerja di lingkungan perusahaan dan memiliki uang untuk dibelanjakan pada perangkat keras yang layak dan pengoptimalan basis data, saya akan tetap menggunakan SQL Server untuk saat ini. Jika Anda mencubit recehan dan perlu menjalankan ini pada perangkat lunak cloud computing EC2 low-end, Anda mungkin ingin memilih Cassandra atau Voldemort sebagai gantinya (dengan asumsi Anda bisa bekerja dengan .NET).


15
2018-05-08 17:25



Sangat sedikit orang yang bekerja di set ukuran multi-miliar baris, dan sering kali saya melihat permintaan seperti ini di stack overflow, data tidak ada di mana dekat ukuran yang sedang dilaporkan sebagai.

36 miliar, 3 miliar per bulan, itu kira-kira 100 juta per hari, 4,16 juta per jam, ~ 70k baris per menit, 1.1k baris kedua datang ke dalam sistem, secara berkelanjutan selama 12 bulan, dengan asumsi tidak ada waktu istirahat.

Angka-angka itu bukan tidak mungkin dengan margin yang panjang, saya telah melakukan sistem yang lebih besar, tetapi Anda ingin memeriksa ulang yang benar-benar jumlah yang Anda maksud - sangat sedikit aplikasi yang benar-benar memiliki kuantitas ini.

Dalam hal menyimpan / mengambil dan cukup aspek penting yang belum Anda sebutkan adalah penuaan data lama - penghapusan tidak gratis.

Teknologi normal adalah melihat partisi, namun, pencarian / retrieval yang berbasis GUID akan menghasilkan kinerja yang buruk, dengan asumsi Anda harus mendapatkan setiap nilai yang cocok di seluruh periode 12 bulan. Anda dapat menempatkan indeks berkerumun di kolom GUID akan mendapatkan data clusterd terkait untuk membaca / menulis, tetapi pada kuantitas dan kecepatan penyisipan, fragmentasi akan terlalu tinggi untuk mendukung, dan akan jatuh ke lantai.

Saya juga menyarankan bahwa Anda akan membutuhkan anggaran perangkat keras yang sangat layak jika ini adalah aplikasi serius dengan kecepatan respon jenis OLTP, yaitu dengan beberapa perkiraan perkiraan, dengan asumsi sangat sedikit pengindeksan overhead yang bijaksana, sekitar 2,7TB data.

Di kamp SQL Server, satu-satunya hal yang mungkin ingin Anda lihat adalah edisi gudang data pararel baru (madison) yang dirancang lebih untuk membuang data dan menjalankan kueri paralel terhadapnya untuk menyediakan kecepatan tinggi terhadap datamart besar.


11
2018-05-08 17:10



"Saya harus bisa menyimpan data kecil (sekitar 50-75 byte) untuk miliaran rekaman (~ 3 miliar / bulan selama setahun).

Satu-satunya persyaratan adalah penyisipan cepat dan pencarian cepat untuk semua rekaman dengan GUID yang sama dan kemampuan untuk mengakses penyimpanan data dari .net. "

Saya dapat memberi tahu Anda dari pengalaman bahwa ini mungkin dalam SQL Server, karena saya telah melakukannya pada awal 2009 ... dan masih beroperasi hingga hari ini dan cukup cepat.

Tabel dipartisi dalam 256 partisi, perlu diingat ini adalah versi SQL 2005 ... dan kami melakukan persis apa yang Anda katakan, dan itu adalah untuk menyimpan sedikit info oleh GUID dan mengambil oleh GUID dengan cepat.

Ketika saya meninggalkan kami memiliki sekitar 2-3 miliar catatan, dan pengambilan data masih cukup baik (1-2 detik jika melewati UI, atau kurang jika di RDBMS) meskipun kebijakan retensi data baru akan dipakai.

Jadi, panjang cerita pendek, saya mengambil char 8 (yaitu di suatu tempat di tengah-tengah) dari string GUID dan SHA1 hashed dan dilemparkan sebagai int kecil (0-255) dan disimpan di partisi yang sesuai dan menggunakan fungsi panggilan yang sama ketika mendapatkan data kembali.

ping saya jika Anda butuh info lebih lanjut ...


2
2018-03-27 19:24



Ada fakta yang tidak biasa yang kelihatannya terlewatkan.

"Pada dasarnya setelah memasukkan 30Mil baris dalam sehari, saya harus mengambil semua baris dengan GUID yang sama (mungkin 20 baris) dan cukup yakin saya akan mendapatkannya kembali"

Hanya membutuhkan 20 kolom, indeks non-cluster pada GUID akan bekerja dengan baik. Anda bisa mengelompokkan di kolom lain untuk penyebaran data di seluruh partisi.

Saya memiliki pertanyaan tentang penyisipan data: Bagaimana cara disisipkan?

  • Apakah ini memasukkan massal pada jadwal tertentu (per menit, per jam, dll)?
  • Apa sumber data ini ditarik dari (file datar, OLTP, dll)?

Saya pikir ini perlu dijawab untuk membantu memahami satu sisi persamaan.


1
2018-05-09 00:18



Artikel berikut membahas impor dan penggunaan a 16 milyar


1
2018-04-24 19:48



Amazon Redshift adalah layanan hebat. Itu tidak tersedia ketika pertanyaan itu awalnya diposting pada tahun 2010, tetapi sekarang menjadi pemain utama pada tahun 2017. Ini adalah database berbasis kolom, bercabang dari Postgres, sehingga pustaka konektor SQL dan Postgres standar akan bekerja dengannya.

Paling baik digunakan untuk tujuan pelaporan, terutama agregasi. Data dari satu tabel disimpan di server yang berbeda di awan Amazon, didistribusikan oleh pada tabel distorsi yang ditentukan, sehingga Anda bergantung pada kekuatan CPU terdistribusi.

Jadi, PILIHAN dan terutama SELECT agregat sangat cepat. Memuat data besar sebaiknya dilakukan dengan perintah COPY dari file csv Amazon S3. Kekurangannya adalah DELETE dan UPDATEs lebih lambat dari biasanya, tetapi itu sebabnya Redshift bukan hanya database transnasional, tetapi lebih dari platform data warehouse.


0
2018-02-08 00:31



Anda dapat mencoba menggunakan Cassandra atau HBase, meskipun Anda perlu membaca tentang cara mendesain keluarga kolom sesuai kasus penggunaan Anda. Cassandra menyediakan bahasa query sendiri tetapi Anda perlu menggunakan Java API dari HBase untuk mengakses data secara langsung. Jika Anda perlu menggunakan Hbase maka saya sarankan query data dengan Apache Drill dari Map-R yang merupakan proyek Open Source. Bahasa query Drill adalah SQL-Compliant (kata kunci dalam bor memiliki arti yang sama yang akan mereka miliki dalam SQL).


0
2017-08-07 05:21



Menyimpan catatan dalam file biner biasa, satu file per GUID, tidak akan lebih cepat dari itu.


-2
2018-05-08 16:18



Anda dapat menggunakan MongoDB dan menggunakan panduan sebagai kunci sharding, ini berarti Anda dapat mendistribusikan data Anda melalui beberapa mesin tetapi data yang ingin Anda pilih hanya pada satu mesin karena Anda memilih oleh tombol sharding.

Sharding in MongoDb belum siap produksi.


-2
2018-05-10 07:32