Recentemente, ho avuto l'opportunità di intervistare Oren Eini, CEO e fondatore di Hibernating Rhinos che fornisce RavenDB, un open source document-oriented NoSQL progettato appositamente per la piattaforma .NET / Windows.
Oren ha più di 20 anni di esperienza nel mondo dello sviluppo, con una forte attenzione alla Microsoft e .NET ecosistema. Riconosciuto come uno dei Most Valuable Professional di Microsoft dal 2007, Oren è anche l'autore di “DSL a Boo:dominio specifico lingue in .NET.” Si parla spesso a conferenze di settore come DevTeach, JAOO, QCon, Oredev, NDC, Yow! e Progressive.NET.
Potete leggere l'intervista completa qui di seguito:
1. In questo mondo digitalizzato, i dati è diventato uno dei beni più preziosi. e di conseguenza, i dati vengono memorizzati modo, organizzato, e il processo è fondamentale per il successo del business’. Dato che le imprese sono bombardati con sempre più dati, la memorizzazione dei dati e analisi sono sempre più complessa. Puoi dirci alcune delle gestione comune del database sfide aziende devono affrontare oggi
Il problema principale, a mio avviso, è proprio la vastità dei dati. Non sto necessariamente parlando di Big Data e la complessità di gestione di un insieme di dati misurati in centinaia di terabyte. Sto parlando del numero di database e di silos di dati che si dispone di un'organizzazione. Dal momento che tutto è digitale, si dispone di funzionalità di business-critical che risiede in un foglio di calcolo Excel su un'unità condivisa e dati storici del cliente acquista in un server che nessuno vuole avvicinarsi per paura di accettare proprietà su.
Proprio per capire ciò che l'organizzazione nel suo complesso sa può essere un compito complesso. I dati scivolando attraverso le fessure è tristemente comune.
I tentativi di creare un repository centralizzato per l'intera azienda è anche destinato a fallire. Diverse porzioni della società hanno idee molto diverse su ciò che sembra che le cose ovvie sono. Ad esempio, il reparto di fatturazione ha una diversa idea di ciò che un cliente è che il reparto Marketing. Cercando di rendere i dati in forma di uno stampo comune fa un cattivo servizio a tutti.
2. Come facciamo a superare queste sfide? Pensi che la scelta di una soluzione efficace di gestione di database è il primo passo? E perché?
Il primo passo è quello di definire, a livello organizzativo, la proprietà dei dati, e le regole di responsabilità. Al livello più elementare, fatturazione possiede il concetto di ciò che un cliente è in uno stato di OverduePayment e Marketing possiede gli interessi di un cliente. L'idea non è quella di creare silos di informazioni nell'organizzazione, ma di avere un esplicito riconoscimento delle diverse esigenze. Una volta fatto ciò, è possibile definire il flusso di dati corretti per l'organizzazione.
Il reparto di fatturazione farà il suo punto di vista di un cliente a disposizione del resto dell'organizzazione, pur mantenendo la libertà di cambiare come si forma all'interno del reparto.
Io uso di fatturazione e marketing e la nozione di un cliente come questo esempio per essere in grado di parlare del primo business, che è importante. Per spostarlo in una maniera un po 'più tecnico, stiamo parlando di servizi e dati di flusso contratti. Vi rimando al mandato Bezos’ e come si trasforma Amazon. L'idea è semplice:. Invece di trattare l'intera organizzazione come un tutto unico, che è quasi impossibile oltre una certa dimensione, trattarlo come un gruppo di organizzazioni cooperanti con stacchi molto chiare tra loro
Una volta che si hanno quei confini, e si dispone di una buona idea del flusso dei dati all'interno dell'organizzazione, è possibile avere i vostri idraulici entrare e fare cose ad esso come reindirizzare il flusso di dati in una posizione centrale per l'analisi.
Avendo tali interfacce pubblicate aiuta molto quando arriva il momento di cambiare il modo in alcune cose si comportano. Finché il comportamento esterno è lo stesso, siamo liberi di cambiare modalità di elaborazione medesima.
3. Negli ultimi anni, le imprese hanno adottato vari tipi di database NoSQL. Con i dati sempre più sensibili vengano memorizzati nei database NoSQL, i problemi di sicurezza sono diventati crescenti preoccupazioni. Qual è la vostra opinione su questo?
In generale, la ragione più comune per la mancanza di sicurezza nei database NoSQL è operatore negligenza. Voglio separare nettamente due questioni distinte qui. Abbiamo database NoSQL, come Redis, il cui modello di sicurezza è esplicitamente di esecuzione in un ambiente di fiducia. Ci sono alcuni di sicurezza rudimentali caratteristiche per Redis, ma il presupposto generale è che essi sono destinati a servire solo come la terza o la quarta linea di difesa.
Altri database NoSQL, come MongoDB, sono attesi per funzionare su reti ostili (vale a dire, l'Internet). Tuttavia, è facile da installare su MongoDB, senza alcun tipo di protezione. Sulla faccia di esso, MongoDB è disponibile in una configurazione protetta, permettendo così di ascoltare solo la macchina locale.
La prima cosa che troverete quando si cerca di connettersi a MongoDB è a distanza una guida che spiega come abilitare l'accesso remoto a MongoDB, senza alcuna sicurezza di sorta.
In una certa misura, questo è operatore negligenza. Ma dato il gran numero di database MongoDB che sono lasciato aperto, credo che questo è spaccare il capello. In Cina un database MongoDB aperta ha avuto più di 200 milioni di CV che aspettano solo che qualcuno snoop; una banca dati messa a punto con noncuranza ha esposto backdoor della Russia in oltre 2.000 aziende.
Con la sicurezza, non si ottiene una seconda possibilità.
RavenDB, al contrario, sarà semplicemente si rifiutano di funzionare in una configurazione vulnerabile. È possibile eseguire RavenDB senza sicurezza sulla macchina locale, ma se si tenta di esporre il database per Internet senza le debite garanzie, il database restituirà un errore che spiega come si dovrebbe impostare correttamente in su.
Riempiamo per un importo massimo di lacune assumendo che la maggior parte delle persone farà la minima quantità di lavoro richiesto e fare in modo che quando questo accade, lo stato finale è buono, così abbiamo abbiamo coperto.
4. Parlando di RavenDB, si può citare alcuni dei più importanti caratteristiche che aggiungono più valore ai clienti? Come fa RavenDB spiccano tra gli altri vendor in termini di funzionalità e prestazioni?
RavenDB è stato in esecuzione nei sistemi di produzione per oltre un decennio. Alcune delle caratteristiche più potenti abbiamo di nuovo datato alla nostra versione originale. La capacità di reagire dinamicamente per l'ambiente operativo è la più ovvia. RavenDB analizza continuamente cosa sta succedendo (query in arrivo, carico del server, ecc) e reagisce a che cambiando l'allocazione delle risorse, strutture interne, ecc L'idea è che invece di avere un tempo pieno DBA babysitter vostra base di dati, il database in grado di gestire i suoi propri affari.
Quando abbiamo iniziato a lavorare su RavenDB, volevamo un database che ha avuto tutti i vantaggi di un database relazionale (veloce, ACID, affidabili), ma nessuno degli svantaggi (schema rigido, manutenzione continua, ad alta complessità).
Quando abbiamo iniziato, non avevo idea di quanto grande un compito questo era. Negli ultimi 10 anni, abbiamo guadagnato un sacco di esperienza nella costruzione di un database che può solo lavoro, senza che sia necessario prestare molta attenzione ad esso. Abbiamo progettato RavenDB per rendere più facile per noi per implementare le cose con un focus sulle prestazioni. Un recente benchmark su un Raspberry Pi (25 $, 1 GHz, 1 GB di RAM) macchina ci clock a oltre 5.000 scrive un secondo. Su hardware commodity, siamo in grado di arrivare a oltre 100.000 operazioni di scrittura al secondo e oltre 1.000.000 di letture al secondo.
Tutto ciò è su un singolo nodo, ma RavenDB è stato un database distribuito dal get-go. Ciò significa che è possibile impostare un cluster in pochi minuti (e farlo in modo sicuro, naturalmente) e dispone di un sistema ad alta disponibilità e robusto.
Offriamo alcune caratteristiche uniche che non sono disponibili altrove. ETL è built-in all'interno di RavenDB ed è fortemente utilizzato dai nostri clienti per consentire ricco flusso di dati. Non è necessario per cucire insieme una soluzione da pezzi disparati, è tutto lì nella casella e funziona da solo.
La funzione di abbonamento è uno che io sono particolarmente orgoglioso. Esso consente di eseguire una query in corso. La banca dati sarà inizialmente vi darà tutti i risultati che corrispondono alla tua ricerca. Dal momento che non si è ancora iscritto a questa query, il database invierà su qualsiasi nuovi documenti che corrispondono alla tua query in cui sono inseriti o aggiornati per adattarsi a quella query. Questo permette di costruire robusti processi di business e sistemi back-end con facilità.
Abbiamo messo a fuoco un sacco di impegno nel rendere RavenDB in un database multi-modello in grado di gestire documenti, di valori-chiave, dati binari, contatori distribuiti e le query grafico.
5. E, infine, qual è il futuro dei sistemi di gestione di database? Come sta andando a cambiare nei prossimi 3-4 anni?
Si sta andando a vedere molto di più attenzione per i database multi-modello. Invece di dover implementare una soluzione dedicata per ogni tipo di dati che si desidera e affrontare il complesso integrazione tra ciascuno dei pezzi, il mercato si sta muovendo ad una soluzione integrata che propone una suite completa di opzioni in un unico pacchetto.
La nube continuerà ad essere più importante, ma non sarebbe affrettato a dire addio a on-premise e sistemi distribuiti. Stiamo vedendo un sacco di nostri clienti fare l'elaborazione sul bordo e sui sistemi connessi occasionalmente. Penso che si vedrà uno spostamento della messa a fuoco, in cui i data center del passato avrebbero passare al cloud, ma un sacco di trattamento vero e proprio sarebbe stato distribuito sul bordo e su dispositivi mobili. Ciò richiede un modo diverso di pensare la distribuzione dei dati e il modo di spingere i dati per i dati delle nuvole e tirare dal cloud.
Ci sta per essere molto più enfasi sul tipo di dati distribuiti trattamento che una volta era l'esclusiva gamma dei sistemi di fascia alta.
E 'certamente sarà molto interessante vedere come il paesaggio cambia e come costruire gli strumenti e le metodologie per gestire sempre crescente complessità e funzionalità.
