Topp 11 öppen källkodsdatabas för ditt nästa projekt

Data är allt. Och i förlängningen, så är databaser. Här är några fantastiska open source-alternativ för ditt nästa kick-ass-projekt.


För en värld som så länge domineras av databasdräkter som Oracle och SQL Server, verkar det finnas en oändlig flurry av lösningar nu. En del av anledningen är innovation som drivs av Open Source – riktigt begåvade utvecklare som vill skrapa en klåda och skapa något som de kan njuta av.

Den andra delen är framväxten av nya affärsmodeller, där företagen upprätthåller en communityversion av sin produkt för att få mind share och traction, samtidigt som de erbjuder ett kommersiellt tilläggserbjudande.

Resultatet?

Fler databaser än man kan hålla jämna steg med. Det finns ingen officiell statistik om detta, men jag är ganska säker på att vi har över hundra alternativ tillgängliga idag om du kombinerar allt från stackspecifika objektdatabaser till icke-så populära projekt från universitet.

Jag vet, det skrämmer mig också. För många alternativ – för mycket dokumentation att gå igenom – och ett liv som är så kort. ��

Det är därför jag bestämde mig för att skriva den här artikeln och presentera tio av de bästa databaserna du kan använda för att förbättra dina lösningar, vare sig du bygger för dig själv eller andra..

Ingen MySQL

Observera: den här listan kommer inte att innehålla MySQL, även om den utan tvekan är den mest populära Open Source-databaslösningen där ute.

Varför? Bara för att MySQL finns överallt – det är vad alla lär sig först, det stöds av praktiskt taget alla CMS eller ramar där ute, och det är väldigt, mycket bra för de flesta användningsfall. Med andra ord, MySQL behöver inte “upptäckas.” ��

Som sagt, observera att följande inte nödvändigtvis är alternativ till MySQL. I vissa fall kan de vara det, medan de i andra är en helt annan lösning för ett helt annat behov. Oroa dig inte, eftersom jag också diskuterar deras användning.

Särskild anmärkning: kompatibilitet

Innan vi börjar måste jag också nämna att kompatibilitet är något du behöver komma ihåg. Om du har ett projekt som, oavsett anledning, bara stöder en viss databasmotor, kommer dina val ganska mycket igenom.

Om du till exempel kör WordPress är den här artikeln inte till någon nytta för dig. �� På samma sätt kommer de som kör statiska webbplatser på JAMStack inte att vinna någonting genom att leta efter alternativ för allvarligt.

Det är upp till dig att ta reda på kompatibilitetsekvationen. Men om du har en tom skiffer och arkitekturen är upp till dig, här är några snygga rekommendationer.

PostgreSQL

Om du är från PHP-landet (WordPress, Magento, Drupal, etc.), då PostgreSQL kommer att låta främmande för dig. Men den här relationsdatabaslösningen har funnits sedan 1997 och är det bästa valet i samhällen som Ruby, Python, Go, etc..

Faktum är att många utvecklare så småningom “examen” till PostgreSQL för de funktioner som den erbjuder, eller helt enkelt för stabiliteten. Det är svårt att övertyga någon i en kort nedskrivning som denna men tänk på PostgreSQL som en eftertänksamt produkt som aldrig låter dig svika.

Det finns många bra SQL-klienter att ansluta till PostgreSQL-databas för administration och utveckling.

Unika funktioner

PostgreSQL har flera fascinerande funktioner jämfört med andra relationsdatabaser (specifikt MySQL), såsom:

  • Inbyggda datatyper för Array, Range, UUID, Geolocation, etc..
  • Native support för dokumentlagring (JSON-stil), XML och nyckelvärde lagring (Hstore)
  • Synkron och asynkron replikering
  • Skriftligt i PL, Perl, Python och mer
  • Heltekstsökning

Mina personliga favoriter är geolokationsmotorn (som tar bort smärtan när du arbetar med platsbaserade appar – prova att hitta alla närliggande punkter manuellt, så vet du vad jag menar) och stöd för matriser (många MySQL-projekt ångras för att de inte vill matriser, istället väljer de ökända kommaseparerade strängarna).

När man ska använda PostgreSQL

PostgreSQL är alltid ett bättre val jämfört med någon annan relationsdatabasmotor. Det vill säga, om du startar ett nytt projekt och har bitts av MySQL tidigare, är det en bra tid att överväga PostgreSQL. Jag har vänner som gav upp kampen mot MySQL: s mystiska transaktionslåsfel och flyttade permanent. Om du bestämmer samma sak reagerar du inte.

PostgreSQL har också en tydlig fördel om du behöver delvis NoSQL-faciliteter för en hybriddatamodell. Eftersom lagring av dokument och nyckelvärden stöds naturligt, behöver du inte leta efter, installera, lära och underhålla en annan databaslösning.

När man inte ska använda PostgreSQL

PostgreSQL är inte vettigt när din datamodell inte är relationell och / eller när du har mycket specifika arkitektoniska krav. Tänk till exempel Analytics, där nya rapporter ständigt skapas från befintlig data. Sådana system är lätta tunga och drabbas när ett strikt schema påläggs dem. Visst har PostgreSQL en dokumentlagringsmotor, men saker börjar falla isär när du har att göra med stora datasätt.

Med andra ord, använd alltid PostgreSQL, såvida du inte vet 100% vad du gör! ��

Kolla in det här SQL & PostgreSQL för nybörjarkurs om du är intresserad av att lära sig mer.

mariadb

mariadb skapades som en ersättning för MySQL av samma person som utvecklade MySQL.

Förvirrad?

Tja, faktiskt, efter att MySQL togs över av Oracle 2010 (genom att förvärva Sun Microsystems, som för övrigt också är hur Oracle kom att kontrollera Java), startade skaparen av MySQL ett nytt open source-projekt som heter MariaDB.

Varför betyder all denna tråkiga detalj frågan, frågar du? Det beror på att MariaDB skapades från samma kodbas som för MySQL (i öppen källkodsvärld, detta kallas ”forking” ett befintligt projekt). Som ett resultat presenteras MariaDB som en “drop-in” ersättning för MySQL.

Det vill säga, om du använder MySQL och vill migrera till MariaDB, är processen så enkel att du bara inte tror det.

Tyvärr är en sådan migration en envägsgata. Att gå tillbaka från MariaDB till MySQL är inte möjligt, och om du försöker använda våld, garanteras permanent databaskorruption!

Unika funktioner

Medan MariaDB i huvudsak är en klon av MySQL, är det inte strikt sant. Helt sedan introduktionen av databasen har skillnaderna mellan de två ökat. Att skriva MariaDB måste från början vara ett genomtänkt beslut från din sida. Som sagt, det finns många nya saker som händer i MariaDB som kan hjälpa dig att göra denna övergång:

  • Verkligen gratis och öppen: Eftersom det inte finns någon enda företag som kontrollerar MariaDB, kan du vara fri från plötsliga rovgivningstillstånd och andra bekymmer.
  • Flera fler alternativ för lagringsmotorer för specialiserade behov: till exempel Spindermotorn för distribuerade transaktioner; ColumnStore för massiv datalagring; ColumnStore-motorn för parallell, distribuerad lagring; och många, många fler.
  • Hastighetsförbättringar jämfört med MySQL, särskilt på grund av Aria-lagringsmotorn för komplexa frågor.
  • Dynamiska kolumner för olika rader i en tabell.
  • Bättre replikationsfunktioner (till exempel replikering med flera källor)
  • Flera JSON-funktioner
  • Virtuella kolumner

. . . Och många, många fler. Det är ansträngande att hålla jämna steg med alla MariaDB-funktioner. ��

När ska man använda MariaDB

Du bör MariaDB om du vill ha en verklig ersättning av MySQL, vill stanna kvar på innovationskurvan och inte planerar att återvända till MySQL igen. Ett utmärkt användningsfall är användningen av nya lagringsmotorer i MariaDB för att komplettera den befintliga relationella datamodellen för ditt projekt.

När man inte ska använda MariaDB

Kompatibilitet med MySQL är det enda problemet här. Som sagt, det blir mindre problem eftersom projekt som WordPress, Joomla, Magento etc. har börjat stödja MariaDB. Mitt råd skulle vara att inte använda MariaDB för att lura ett CMS som inte stöder det, eftersom det finns många databasspecifika trick som kommer att krascha systemet enkelt.

CockroachDB

Teamet bakom CockroachDB verkar vara sammansatt av masochister. Med ett sådant produktnamn vill de säkert vända alla odds mot dem och fortfarande vinna?

Tja, inte riktigt.

Tanken bakom “kackerlacka” är att det är ett insekt som är byggt för överlevnad. Oavsett vad som händer – rovdjur, översvämningar, evigt mörker, ruttnande mat, bombning, kackerlackan hittar ett sätt att överleva och föröka sig.

Tanken är att teamet bakom CockroachDB (sammansatt av tidigare Google-ingenjörer) var frustrerad över begränsningarna i traditionella SQL-lösningar när det gäller stor skala. Det beror på att historiskt SQL-lösningar skulle vara värd på en enda maskin (data var inte så stora). Under lång tid fanns det inget sätt att bygga ett kluster av databaser som kör SQL, varför MongoDB fick så mycket uppmärksamhet.

Även när replikering och klustering kom ut i MySQL, PostgreSQL och MariaDB, var det i bästa fall smärtsamt. CoackroachDB vill förändra det, medföra enkel skärning, kluster och hög tillgänglighet till SQL-världen.

När man ska använda CockroachDB

CockroachDB är systemarkitektens dröm. Om du svär vid SQL och har pratat över skalfunktionerna hos MongoDB, kommer du att älska CockroachDB. Nu kan du snabbt ställa in ett kluster, kasta frågor på det och sova lugnt på natten. ��

När man inte ska använda CockroachDB

Bättre djävulen du känner än den du inte gör. Med det menar jag, om din befintliga RDBMS fungerar bra för dig och du tror att du kan hantera skalningsvärk som det medför, håll dig fast vid den. För alla inblandade genier är CockroachDB en ny produkt, och du vill inte kämpa mot det senare. En annan viktig orsak är SQL-kompatibilitet – om du gör exotiska SQL-grejer och litar på det för kritiska saker kommer CockroachDB att presentera för många kantfall för din smak.

Från och med nu kommer vi att överväga icke-SQL (eller NoSQL, som det heter) databaslösningar för högt specialiserade behov.

Neo4j

En av de viktigaste utvecklingen under det senaste decenniet är anslutna data. Världen omkring oss är inte uppdelade i bord och rader och lådor – det är ett jättebrack med allt kopplat till nästan allt annat.

Sociala nätverk är ett utmärkt exempel, och att bygga en liknande datamodell med SQL eller till och med dokumentbaserade databaser är en mardröm.

Det beror på att den ideala datastrukturen för dessa lösningar är grafen, som är ett helt annat odjur. Och för det behöver du en grafdatabas som Neo4j.

Exemplet ovan togs direkt från Neo4j-webbplatsen och visar hur universitetsstudenter är anslutna till sina institutioner och kurser. En sådan datamodell är helt omöjlig med SQL, eftersom det kommer att vara svårt att undvika oändliga slingor och minnesöverskridanden.

Unika funktioner

Grafdatabaser är unika i sig själva, och Neo4j är ganska mycket det enda alternativet för att arbeta med grafer. Som ett resultat är de funktioner som den har unika. ��

  • Stöd för transaktionsapplikationer och grafanalys.
  • Förmåga att omvandla data för att smälta tabelldata i stor skala till diagram.
  • Specialiserat frågespråk (Cypher) för frågning av grafdatabasen
  • Visualisering och upptäcktsfunktioner

Det är en viktig punkt att diskutera när man ska använda Neo4j och när inte. Om du behöver grafbaserade förhållanden mellan dina data, behöver du Neo4j. ��

MongoDB

MongoDB var den första icke-relationella databasen som gjorde stora vågor i teknikindustrin och fortsätter att dominera en rättvis andel uppmärksamhet.

Till skillnad från relationsdatabaser är MongoDB en “dokumentdatabas”, vilket innebär att den lagrar data i bitar, med relaterade data klumpade samman i samma del. Detta förstås bäst genom att föreställa oss en sammanställning av JSON-strukturer som denna:

Här, till skillnad från en tabellbaserad struktur, ligger kontaktinformationen och åtkomstnivåerna för en användare i samma objekt. Att hämta användarobjektet hämtar tillhörande data automatiskt och det finns inget begrepp om en koppling. Här är en mer detaljerad introduktion till MongoDB.

Unika funktioner

MongoDB har några allvarliga (jag vill nästan skriva “kick-ass” för att förmedla påverkan, men det skulle inte vara lämpligt på en offentlig webbplats, kanske) funktioner som har fått flera rutinerade arkitekter att överge det relationella landet för alltid:

  • Ett flexibelt schema för specialiserade / oförutsägbara fall.
  • Löjligt enkel skärning och kluster. Du behöver bara konfigurera konfigurationen för ett kluster och glömma det.
  • Det är enkelt att lägga till eller ta bort en nod från ett kluster.
  • Distribuerade transaktionslås. Denna funktion saknades i de tidigare versionerna men introducerades så småningom.
  • Den är optimerad för mycket snabba skrivningar, vilket gör den mycket lämplig för analysdata som ett cachingsystem.

Om jag låter som en talesman för MongoDB ber jag om ursäkt, men det är svårt att sälja fördelarna med MongoDB. Visst, NoSQL-datamodellering är konstigt till en början, och vissa får aldrig ta hand om det, men för många arkitekter vinner det nästan alltid över ett tabellbaserat schema.

När ska jag använda MongoDB

MongoDB är en stor övergångsbro från den strukturerade, strikta världen av SQL till den amorfa, nästan förvirrande av NoSQL. Det är utmärkt att utveckla prototyper, eftersom det helt enkelt inte finns något schema att oroa dig för och när du verkligen behöver skala. Ja, du kan använda en moln SQL-tjänst för att bli av med DB-skalningsproblem, men pojke är det dyrt!

Slutligen finns det användningsfall där SQL-baserade lösningar bara inte gör. Om du till exempel skapar en produkt som Canva, där användaren kan skapa godtyckligt komplexa mönster och kunna redigera dem senare, lycka till med en relationsdatabas!

När man inte ska använda MongoDB

Den fullständiga bristen på schema som MongoDB tillhandahåller kan fungera som en tjärgrop för dem som inte vet vad de gör. Datamissanpassning, döda data, tomma fält som inte bör vara tomma – allt detta och mycket mer är möjligt. MongoDB är i huvudsak ett “dumt” datalager, och om du väljer det måste applikationskoden ta ett stort ansvar för att upprätthålla dataintegritet.

Om du är en utvecklare hittar du det detta användbart.

RethinkDB

Som namnet går, RethinkDB ”Tänker om” på en databas idé och funktioner när det gäller appar i realtid.

När en databas uppdateras finns det inget sätt för applikationen att veta. Det accepterade tillvägagångssättet är att appen avfyrar ett meddelande så snart det finns en uppdatering, som pressas till frontend genom en komplex bro (PHP) -> Redis -> Nod -> Socket.io är ett exempel).

Men vad händer om uppdateringarna kunde skjutas direkt från databasen till frontend?!

Ja, det är RethinkDBs löfte. Så om du vill skapa en riktig realtidsapplikation (spel, marknadsplats, analys osv.) Är Rethink DB värt att titta.

Redis

När det gäller databaser är det nästan för lätt att förbise existensen av Redis. Det beror på att Redis är en databas i minnet och används mest i supportfunktioner som cache.

Lära sig denna databas är ett tio minuters jobb (bokstavligen!), och det är en enkel butik med nyckelvärde som lagrar strängar med en giltighetstid (som naturligtvis kan ställas in på oändlighet). Vad Redis förlorar i funktioner som den kompenserar för i verktyg och prestanda. Eftersom det lever helt och hållet i RAM, är läsning och skrivning vansinnigt snabbt (några hundra tusen operationer per sekund är inte okänt).

Redis har också en sofistikerad pub-sub-system, vilket gör denna “databas” dubbelt så attraktiv.

Med andra ord, om du har ett projekt som kan dra nytta av cache eller har några distribuerade komponenter, är Redis det första valet.

SQLite

Ja, jag lovade att vi var klara med relationsdatabaser, men SQLite är för söt för att ignorera.

SQLite är ett lätt C-bibliotek som tillhandahöll en relationell databaslagringsmotor. Allt i denna databas lever i en enda fil (med en .sqlite-förlängning) som du kan placera var som helst i ditt filsystem. Och det är allt du behöver för att använda det! Ja, ingen “server” -programvara att installera och ingen tjänst att ansluta till.

Användbara funktioner

Även om SQLite är ett lätt alternativ till en databas som MySQL, så packar den en hel del. Några av dess chockerande funktioner är:

  • Fullt stöd för transaktioner med COMMIT, ROLLBACK och BEGIN.
  • Stöd för 32 000 kolumner per tabell
  • JSON-stöd
  • 64-vägs JOIN-stöd
  • Underfrågor, fulltextsökning osv.
  • Maximal databasstorlek på 140 terabyte!
  • Maximal radstorlek på 1 gigabyte!
  • 35% snabbare än fil I / O

När SQLite ska användas

SQLite är en extremt specialiserad databas som fokuserar på ett icke-nonsens, get-shit-done tillvägagångssätt. Om din app är relativt enkel och du inte vill ha besväret med en fullständig databas är SQLite en allvarlig kandidat. Det är särskilt vettigt för små till medelstora CMS och demoapplikationer.

När man inte ska använda SQLite

Även om det är imponerande täcker SQLite inte alla funktioner i standard SQL eller din favoritdatabasmotor. Clustering, lagrade procedurer och script-tillägg saknas. Det finns inte heller någon klient som kan ansluta, fråga och utforska databasen. Slutligen, när applikationsstorleken växer, försämras prestandan.

Cassandra

Medan många förkunnar att slutet är nära för Java, släpper gemenskapen då och då ett bombskal och tystar kritikerna. Cassandra är ett sådant exempel.

Cassandra tillhör det som kallas den “kolumnera” databasfamiljen. Lagringsabstraktionen i Cassandra är en kolumn snarare än en rad. Tanken här är att lagra all data i en kolumn fysiskt tillsammans på disken, vilket minimerar söktiden.

Unika funktioner

Cassandra designades med ett specifikt användningsfall i åtanke – hanterade skrivtunga laster och nolltolerans för drifttid. Dessa blir dess unika försäljningsställen.

  • Extremt snabb skrivprestanda. Cassandra är utan tvekan den snabbaste databasen där ute när det gäller hantering av tunga skrivbelastningar.
  • Linjär skalbarhet. Det vill säga, du kan fortsätta lägga till så många noder i ett kluster som du vill, och det kommer att bli en noll ökning av komplexiteten eller sprödheten i klustret.
  • Oöverträffad partitionstolerans. Det vill säga, även om flera noder i ett Cassandra-kluster går ner, är databasen utformad för att fortsätta att prestera utan förlust av integritet.
  • Statisk maskinskrivning

När ska man använda Cassandra

Loggning och analys är två av de bästa användningsfallen för Cassandra. Men det är inte allt – den söta platsen är när du behöver hantera riktigt stora datamängder (Apple har en Cassandra-distribuering som hanterar 400+ petabyte data medan den på Netflix hanterar 1 biljon begär en dag) med bokstavligen noll driftstopp. Hög tillgänglighet är ett av kännetecknen för Cassandra.

När man inte ska använda Cassandra

Kolonnlagringsschemat för Cassandra har också sina nackdelar. Datamodellen är ganska platt, och om du behöver aggregeringar, då kommer Cassandra till kort. Dessutom uppnår den hög tillgänglighet genom att offra konsistens (kom ihåg CAP-teoremet för distribuerade system), vilket gör det mindre lämpligt för system där hög läsnoggrannhet behövs.

Tidsskala

Ny utveckling kräver nya typer av databaser, och Internet of Things (IoT) är ett sådant fenomen. En av de bästa open source-databaserna för det är Tidsskala.

Tidsskalan är en typ av vad som kallas en ”tidsserie” -databas. Det skiljer sig från en traditionell databas då den tiden är den primära oroen, och analys och visualisering av massiva datamängder är högsta prioritet. Tidsseriedatabaser ser sällan en förändring i befintliga data; ett exempel är temperaturavläsningar som skickas av en sensor i ett växthus – nya data hämtas varje sekund, vilket är av intresse för analys och rapportering.

Varför inte bara använda en traditionell databas med ett tidsstämpelfält? Det finns två huvudsakliga skäl till det:

  • Allmänna databaser är inte optimerade för att arbeta med tidsbaserad data. För samma mängder data kommer en allmän databas att gå mycket långsammare.
  • Databasen måste hantera enorma mängder data eftersom nya data fortsätter att strömma in och ta bort data eller ändra schema; senare är inte ett alternativ.

Unika funktioner

Timescale DB har några spännande funktioner som skiljer den från andra databaser i samma kategori:

  • Det är byggt på PostgreSQL, utan tvekan den bästa relationsdatabasen med öppen källkod där ute. Om ditt projekt redan kör PostgreSQL kommer Timescale att glida rätt in.
  • Frågor görs genom den välbekanta SQL-syntaxen, vilket minskar inlärningskurvan.
  • Löjligt snabba skrivhastigheter – miljontals insatser per sekund är inte okända.
  • Miljarder rader eller petabyte med data – det är inte så bra för Timescale.
  • Sann flexibilitet med schema – välj från relation eller schemaless enligt dina behov.

Det är inte vettigt att prata om när man ska använda eller inte använda Timescale DB. Om IoT är din domän eller om du har liknande databasegenskaper är Timescale värt en titt.

CouchDB

CouchDB är en snygg liten databaslösning som sitter tyst i ett hörn och har ett litet men dedikerat följande. Det skapades för att hantera problemen med nätverksförlust och eventuell upplösning av data, vilket råkar vara ett problem så smutsigt att utvecklarna istället skulle byta jobb än hantera det.

I huvudsak kan du tänka på ett CouchDB-kluster som en distribuerad samling av stora och små noder, av vilka vissa förväntas vara offline. Så snart en nod kommer online sänder den data tillbaka till klustret, som sakta och försiktigt smälts och så småningom blir tillgängligt för hela klustret.

Unika funktioner

CouchDB är något av en unik ras när det gäller databaser.

  • Offline-första datasynkroniseringsfunktioner
  • Specialiserade versioner för mobil- och webbläsare (PouchDB, CouchDB Lite, etc.)
  • Kraschbeständig, stridstestad tillförlitlighet
  • Enkel gruppering med redundant datalagring

När ska CouchDB användas

CouchDB byggdes för offline-tolerans och förblir oöverträffad i detta avseende. Ett typiskt fall är mobilappar där en del av dina data finns i en CouchDB-instans på användarens telefon (eftersom det är där den genererades). Det spännande är att du inte kan lita på att användarens enhet ska vara ansluten hela tiden, vilket innebär att databasen måste vara opportunistisk och vara redo att lösa motstridiga uppdateringar senare. Detta uppnås med hjälp av det imponerande Protokoll för soffreplikation.

När du inte ska använda CouchDB

Att försöka använda CouchDB utanför det avsedda fallet kommer att leda till katastrof. Det använder mycket mer lagringsutrymme än något annat där ute, helt enkelt för att det måste hålla redundanta kopior av data och resultat av konfliktlösning. Som ett resultat är skrivhastigheterna också smärtsamt långsamma. Slutligen är CouchDB inte lämplig som schemamotor av allmänt syfte, eftersom den inte spelar bra med schematändringar.

Slutsats

Jag var tvungen att utelämna många intressanta kandidater som Riak, så denna lista ska tas som en guide snarare än ett bud. Jag hoppas att jag kunde uppnå mitt mål med den här artikeln – presentera inte bara en samling av databasrekommendationer, men också kort diskutera var och hur de måste användas (och undvikas!).

Om du är nyfiken på att lära dig databas så kolla in Udemy för några av de lysande onlinekurser.

TAGGAR:

  • Databas

  • Öppen källa

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Комментариев нет, будьте первым кто его оставит

    Комментарии закрыты.

    Adblock
    detector