sql >> Databasteknik >  >> RDS >> Database

Relationella vs icke-relationella databaser – Del 1

Under de senaste åren har NoSQL eller icke-relationella databasverktyg vunnit mycket popularitet när det gäller att lagra enorma mängder data och skala dem lätt. Det finns debatter om huruvida icke-relationella databaser kommer att ersätta relationsdatabaser i framtiden. Med det ökande antalet sociala data och annan ostrukturerad data är följande några av de frågor som ställs om relationsdatabaser.
Kan relationsdatabaser hantera big data?
Kan relationsdatabaser skala ut en massiv mängd data?
Är relationsdatabaser lämpade för dagens data?
Innan du svarar på dessa frågor, låt oss veta några grunder om både relationella och icke-relationella databaser.

Grunderna i relationella och icke-relationella databaser

Relationsdatabaser: Konceptet med relationsdatabas utvecklades på 1970-talet. Den viktigaste egenskapen hos alla relationsdatabaser är dess stöd för ACID-egenskaper (Automicity, Consistency, Isolation and Durability) som säkerställer att alla transaktioner bearbetas på ett tillförlitligt sätt.
Automaticitet: Varje transaktion är unik och ser till att om en logisk del av en transaktion misslyckas återställs allt så att data är oförändrade.
Konsistens: All data som skrivs till databasen är föremål för reglerna som definieras (begränsningar, utlösare, etc.)
Isolering: Ändringar som görs i en transaktion är inte synliga för andra transaktioner förrän de har genomförts.
Hålbarhet: Ändringar som genomförts i en transaktion lagras och är tillgängliga i databasen även om det blir strömavbrott eller om databasen plötsligt går offline.
Strikt strukturerad: Objekten i relationsdatabaserna är strikt strukturerade. All data i tabellen lagras i rader och kolumner. Varje kolumn har en datatyp. Det är mestadels normaliserat. Structured Query Language (SQL) är lämplig för relationsdatabaser för att lagra och hämta data på ett strukturerat sätt. Frågor är vanliga engelska kommandon. Det finns alltid ett fast antal kolumner även om ytterligare kolumner kan läggas till senare. De flesta av tabellerna är relaterade till varandra med primära och främmande nycklar vilket ger "referensintegritet" bland objekten. De största leverantörerna är ORACLE, SQL Server, MySQL, PostgreSQL, etc.
Icke-relationella databaser: Konceptet med icke-relationella databaser kom in i bilden för att hantera den snabba tillväxten av ostrukturerad data och lätt skala ut dem. Detta ger ett flexibelt schema så det finns inget som heter "referensintegritet" som vi ser i relationsdatabaser. Datan är mycket denormaliserad och kräver inte JOINs mellan objekt. Detta minskar ACID-egenskapen för relationsdatabaser och stöder CAP (Consistency, Availability och Partitioning). Men av dessa tre är bara två garanterade när som helst. Så till skillnad från ACID kommer den bara att stödja BASE (Basically Available Soft State, Eventuell konsistens). De första databaserna som skapats utifrån dessa koncept är BigTable av Google, HBase av Yahoo, Cassandra av Facebook, etc.
Kategorier av icke-relationella databaser: Icke-relationella databaser kan klassificeras i fyra huvudkategorier, såsom nyckel-värdesdatabas, kolumndatabas, dokumentdatabas och grafdatabas.
Nyckelvärdesdatabas: Detta är den enklaste formen av NoSQL-databas där varje värde är associerat med den unika nyckeln.(ex Redis)
Kolumndatabas: Denna databas kan lagra och bearbeta en stor mängd data med hjälp av en pekare som pekar på många kolumner som är fördelade över ett kluster. (ex HBase)
Dokumentdatabas: Denna databas kan innehålla många nyckel-värden dokument med många kapslade nivåer. Effektiv sökning är möjlig med denna databas. Dokumenten lagras i JSON-format.(ex MongoDB)
Grafdatabas: Istället för traditionella rader och kolumner använder den här databasen noder och kanter för att representera grafstrukturer och lagra data. (ex Neo4J)


  1. Android SQLite Databas Unit Testing

  2. Hur man ändrar färg och teckensnitt i SQL Server Management Studio (SSMS) - SQL Server / TSQL självstudie del 12

  3. Hur man proaktivt samlar in SQL Server Index Fragmenteringsinformation

  4. Infogar i Oracle och hämtar det genererade sekvens-ID:t