Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Wawancara dengan Oren Eini dari RavenDB tentang manajemen basis data, analitik &keamanan

Baru-baru ini, saya berkesempatan untuk mewawancarai Oren Eini, CEO dan pendiri Hibernate Rhinos yang menyediakan RavenDB, sebuah NoSQL berorientasi dokumen open source yang dirancang khusus untuk platform .NET/Windows.

Oren memiliki pengalaman lebih dari 20 tahun di dunia pengembangan dengan fokus kuat pada ekosistem Microsoft dan .NET. Diakui sebagai salah satu Profesional Paling Berharga Microsoft sejak 2007, Oren juga penulis “DSLs in Boo:Domain Specific Languages ​​in .NET.” Dia sering berbicara di konferensi industri seperti DevTeach, JAOO, QCon, Oredev, NDC, Yow! dan Progressive.NET.

Anda dapat membaca wawancara lengkap di bawah ini:

1. Di dunia yang serba digital ini, data menjadi salah satu aset paling berharga. dan oleh karena itu, cara data disimpan, diatur, dan diproses sangat penting untuk kesuksesan bisnis. Ketika perusahaan dibombardir dengan semakin banyak data, penyimpanan data dan analitik tumbuh lebih kompleks. Bisakah Anda memberi tahu kami beberapa tantangan umum manajemen basis data yang dihadapi bisnis saat ini?

Masalah utama, saya percaya, hanyalah ukuran data yang tipis. Saya tidak harus berbicara tentang Big Data dan kompleksitas pengelolaan kumpulan data yang diukur dalam ratusan terabyte. Saya berbicara tentang jumlah database dan silo data yang Anda miliki dalam sebuah organisasi. Karena semuanya digital, Anda memiliki fungsionalitas penting bisnis yang berada di spreadsheet Excel di drive bersama dan data historis pembelian pelanggan di server yang tidak ingin didekati siapa pun karena takut menerima kepemilikan.

Hanya mencari tahu apa yang organisasi secara keseluruhan tahu bisa menjadi tugas yang kompleks. Sayangnya, data yang menyelinap melalui celah adalah hal biasa.

Upaya untuk membuat repositori terpusat untuk seluruh perusahaan juga pasti akan gagal. Bagian yang berbeda dari perusahaan memiliki gagasan yang sangat berbeda tentang apa yang tampak jelas. Misalnya, departemen Penagihan memiliki gagasan yang sangat berbeda tentang apa itu Pelanggan daripada departemen Pemasaran. Mencoba membuat data sesuai dengan cetakan umum merugikan semua orang.

2. Bagaimana cara kita mengatasi tantangan-tantangan ini? Apakah menurut Anda memilih solusi manajemen basis data yang efektif adalah langkah pertama? Dan mengapa?

Langkah pertama adalah mendefinisikan, di tingkat organisasi, kepemilikan data, dan aturan tanggung jawab. Pada tingkat yang paling dasar, Penagihan memiliki konsep apa pun yang dimiliki Pelanggan dalam status Jatuh Tempo Pembayaran dan Pemasaran memiliki Kepentingan Pelanggan. Idenya bukan untuk menciptakan silo informasi dalam organisasi tetapi untuk memiliki pengakuan eksplisit dari kebutuhan yang berbeda. Setelah selesai, Anda dapat menentukan aliran data yang tepat dalam organisasi.

Departemen Penagihan akan membuat pandangannya tentang Pelanggan tersedia untuk seluruh organisasi sambil mempertahankan kebebasan untuk mengubah bentuknya di dalam departemen.

Saya menggunakan departemen Penagihan dan Pemasaran serta gagasan Pelanggan sebagai contoh ini untuk dapat membicarakan bisnis terlebih dahulu, yang penting. Untuk memindahkannya ke cara yang sedikit lebih teknis, kita berbicara tentang layanan dan kontrak aliran data. Saya akan merujuk Anda ke Mandat Bezos dan bagaimana itu mengubah Amazon. Idenya sederhana:alih-alih memperlakukan seluruh organisasi sebagai satu kesatuan, yang hampir tidak mungkin melewati ukuran tertentu, perlakukan itu sebagai sekelompok organisasi yang bekerja sama yang memiliki batasan yang sangat jelas di antara mereka.

Setelah Anda memiliki batasan tersebut, dan Anda memiliki gagasan yang baik tentang aliran data dalam organisasi, Anda dapat meminta tukang ledeng masuk dan melakukan hal-hal seperti mengarahkan aliran data ke lokasi pusat untuk dianalisis.

Memiliki antarmuka yang dipublikasikan seperti itu sangat membantu ketika saatnya tiba untuk mengubah perilaku beberapa hal. Selama perilaku eksternalnya sama, kita bebas mengubah cara kita memprosesnya.

3. Dalam beberapa tahun terakhir, perusahaan telah mengadopsi berbagai jenis database NoSQL. Dengan data yang semakin sensitif disimpan dalam database NoSQL, masalah keamanan telah menjadi perhatian yang berkembang. Apa pendapat Anda tentang ini?

Pada umumnya, alasan paling umum untuk kurangnya keamanan dalam database NoSQL adalah kelalaian operator. Saya ingin dengan jelas memisahkan dua masalah yang berbeda di sini. Kami memiliki database NoSQL seperti Redis, yang model keamanannya secara eksplisit dijalankan di lingkungan tepercaya. Ada beberapa fitur keamanan dasar untuk Redis, tetapi asumsi umum adalah bahwa fitur tersebut hanya berfungsi sebagai garis pertahanan ketiga atau keempat.

Basis data NoSQL lainnya, seperti MongoDB, diharapkan berjalan di jaringan yang tidak bersahabat (mis., Internet). Namun, mudah untuk menyiapkan MongoDB tanpa keamanan apa pun. MongoDB hadir dalam konfigurasi yang aman, yang memungkinkannya hanya mendengarkan mesin lokal.

Hal pertama yang akan Anda temukan saat mencoba menyambung ke MongoDB dari jarak jauh adalah panduan yang menjelaskan cara mengaktifkan akses jarak jauh ke MongoDB, tanpa keamanan apa pun.

Sampai tingkat tertentu, ini adalah kelalaian operator. Tetapi mengingat banyaknya database MongoDB yang dibiarkan terbuka lebar, saya percaya bahwa ini adalah rambut yang membelah. Di China, database MongoDB yang terbuka memiliki lebih dari 200 juta CV hanya menunggu seseorang untuk mengintip; database pengaturan yang ceroboh telah mengekspos pintu belakang Rusia ke lebih dari 2.000 perusahaan.

Dengan keamanan, Anda tidak mendapatkan kesempatan kedua.

RavenDB, sebaliknya, hanya akan menolak untuk berjalan dalam konfigurasi yang rentan. Anda dapat menjalankan RavenDB tanpa keamanan di mesin lokal, tetapi jika Anda mencoba mengekspos database ke Internet tanpa perlindungan yang tepat, database akan menampilkan kesalahan yang menjelaskan bagaimana Anda harus mengaturnya dengan benar.

Kami mengisi kesenjangan maksimum dengan mengasumsikan bahwa kebanyakan orang akan melakukan jumlah minimum pekerjaan yang diperlukan dan memastikan bahwa ketika ini terjadi, keadaan akhirnya baik, jadi kami membantu Anda.

4. Berbicara tentang RavenDB, dapatkah Anda menyebutkan beberapa fitur terpenting yang menambah nilai lebih bagi pelanggan? Bagaimana RavenDB menonjol di antara vendor lain dalam hal fitur dan kinerja?

RavenDB telah berjalan dalam sistem produksi selama lebih dari satu dekade. Beberapa fitur paling canggih yang kami miliki berasal dari versi asli kami. Kemampuan untuk bereaksi secara dinamis terhadap lingkungan operasional adalah yang paling jelas. RavenDB terus-menerus menganalisis apa yang sedang terjadi (kueri yang masuk, beban server, dll.) dan bereaksi terhadapnya dengan mengubah alokasi sumber daya, struktur internal, dll. Idenya adalah bahwa alih-alih memiliki DBA penuh waktu menjaga database Anda, database Anda dapat mengelola urusannya sendiri.

Saat kami mulai bekerja di RavenDB, kami menginginkan database yang memiliki semua keunggulan database relasional (cepat, ACID, andal) tetapi tidak ada kekurangannya (skema kaku, pemeliharaan berkelanjutan, kompleksitas tinggi).

Ketika kami mulai, saya tidak tahu seberapa besar tugas ini. Selama 10 tahun terakhir, kami telah memperoleh banyak pengalaman dalam membangun database yang dapat berfungsi tanpa Anda harus terlalu memperhatikannya. Kami merancang RavenDB untuk memudahkan kami mengimplementasikan berbagai hal dengan fokus pada kinerja. Tolok ukur terbaru pada mesin Raspberry Pi (25$, 1 GHz, 1 GB RAM) mencatat kami lebih dari 5.000 penulisan per detik. Pada perangkat keras komoditas, kami dapat mencapai lebih dari 100.000 penulisan per detik dan lebih dari 1.000.000 pembacaan per detik.

Semua itu ada di satu node, tetapi RavenDB telah menjadi database terdistribusi sejak awal. Ini berarti Anda dapat menyiapkan cluster dalam beberapa menit (dan melakukannya dengan cara yang aman, tentu saja) dan memiliki sistem yang sangat tersedia dan kuat.

Kami menawarkan beberapa fitur unik yang tidak tersedia di tempat lain. ETL terintegrasi di dalam RavenDB dan banyak digunakan oleh pelanggan kami untuk memungkinkan aliran data yang kaya. Anda tidak perlu menyatukan solusi dari bagian-bagian yang berbeda, semuanya sudah ada di dalam kotak dan Cukup Berfungsi.

Fitur Berlangganan adalah salah satu yang sangat saya banggakan. Ini memungkinkan Anda untuk melakukan kueri yang sedang berlangsung. Basis data awalnya akan memberi Anda semua hasil yang cocok dengan kueri Anda. Karena Anda masih berlangganan kueri ini, database Anda akan mengirimkan semua dokumen baru yang cocok dengan kueri Anda saat dimasukkan atau diperbarui agar sesuai dengan kueri tersebut. Ini memungkinkan Anda membangun proses bisnis dan sistem backend yang kuat dengan mudah.

Kami telah memfokuskan banyak upaya untuk membuat RavenDB menjadi database multi-model yang mampu menangani dokumen, nilai kunci, data biner, penghitung terdistribusi, dan kueri grafik.

5. Dan akhirnya, bagaimana masa depan sistem manajemen basis data? Bagaimana perubahannya dalam 3-4 tahun ke depan?

Anda akan melihat lebih banyak fokus pada database multi-model. Alih-alih harus menerapkan solusi khusus untuk setiap jenis data yang Anda inginkan dan berurusan dengan integrasi kompleks antara masing-masing bagian, pasar beralih ke solusi terintegrasi yang dapat menawarkan rangkaian opsi lengkap dalam satu kotak.

Cloud akan terus menjadi lebih penting, tetapi saya tidak akan terburu-buru untuk mengucapkan selamat tinggal pada sistem lokal dan terdistribusi. Kami melihat banyak pelanggan kami melakukan pemrosesan di tepi dan pada sistem yang kadang-kadang terhubung. Saya pikir Anda akan melihat pergeseran fokus, di mana pusat data di masa lalu akan pindah ke cloud, tetapi banyak pemrosesan yang sebenarnya akan didistribusikan di edge dan di perangkat seluler. Hal ini memerlukan cara berpikir yang berbeda tentang distribusi data dan cara mendorong data ke cloud dan menarik data dari cloud.

Akan ada lebih banyak penekanan pada jenis pemrosesan data terdistribusi yang dulunya merupakan rangkaian eksklusif sistem kelas atas.

Tentu akan sangat menarik untuk melihat bagaimana lanskap berubah dan bagaimana kami membangun alat dan metodologi untuk menangani kompleksitas dan fungsionalitas yang terus berkembang.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Pertandingan Terdekat, Bagian 1

  2. Pengantar Basis Data Deret Waktu

  3. 7 pekerjaan teratas yang menuntut SQL

  4. Beberapa Paket untuk Kueri Identik

  5. Tingkat Isolasi Baca Berkomitmen