Data is alles. En in die verlenging, so is ook databasisse. Hier is 'n paar fantastiese open source-opsies vir u volgende kick-ass-projek.
Vir 'n wêreld wat so lank oorheers word deur databasispakke soos Oracle en SQL Server, lyk dit asof daar nou 'n eindelose vlaag van oplossings is. Een deel van die rede hiervoor is innovasie wat aangevuur word deur Open Source – regtig talentvolle ontwikkelaars wat 'n jeuk wil krap en iets kan skep waarin hulle kan ontspan.
Die ander deel is die opkoms van nuwe sakemodelle, waarin ondernemings 'n gemeenskapsweergawe van hul produk handhaaf om gedagtes en traksie te bekom, terwyl hulle ook 'n kommersiële aanbieding aanbied.
Meer databasisse as wat u kan byhou. Daar is geen amptelike inligting hieroor nie, maar ek is redelik seker dat ons vandag meer as honderd opsies beskikbaar het as u alles kombineer van stapelspesifieke objekdatabasisse tot nie-gewilde projekte van universiteite..
Ek weet, dit maak my ook bang. Te veel opsies – te veel dokumentasie om deur te gaan – en 'n lewe wat so kort is. ��
Daarom het ek besluit om hierdie artikel te skryf, met tien van die beste databasisse wat u kan gebruik om u oplossings te verbeter, of dit nou vir uself of ander is..
Geen MySQL nie
Let wel: hierdie lys gaan nie MySQL bevat nie, selfs al is dit waarskynlik die gewildste Open Source-databasisoplossing daar buite.
Hoekom? Net omdat MySQL oral is – dit is wat almal eerste leer, dit word ondersteun deur feitlik elke CMS of raamwerk daar buite, en dit is baie, baie goed vir die meeste gebruiksgevalle. Met ander woorde, MySQL hoef nie 'ontdek' te word nie. ��
Dit gesê, let daarop dat die volgende nie noodwendig alternatiewe vir MySQL is nie. In sommige gevalle is dit miskien, terwyl hulle in ander 'n heeltemal ander oplossing het vir 'n heel ander behoefte. Moenie bekommerd wees nie, want ek sal ook die gebruike hiervan bespreek.
Spesiale opmerking: verenigbaarheid
Voordat ons begin, moet ek ook noem dat versoenbaarheid iets is wat u in gedagte moet hou. As u 'n projek het wat om watter rede ook al, slegs 'n spesifieke databasis-enjin ondersteun, word u keuses deurgaans deurgewerk.
Byvoorbeeld, as u WordPress gebruik, is hierdie artikel vir u van geen nut nie. �� Net so sal diegene wat statiese terreine op JAMStack bestuur, niks kry deur te ernstig na alternatiewe te soek nie.
Dit is aan jou om die verenigbaarheidsvergelyking uit te vind. As u egter 'n leë leisteen het en die argitektuur aan u hang, is hier 'n paar netjiese aanbevelings.
As u van die PHP-land af kom (WordPress, Magento, Drupal, ens.), Dan PostgreSQL sal vreemd vir jou klink. Hierdie relasionele databasisoplossing bestaan ​​egter al sedert 1997 en is die beste keuse in gemeenskappe soos Ruby, Python, Go, ens..
In werklikheid "gradueer" baie ontwikkelaars na PostgreSQL vir die funksies wat dit bied, of bloot vir die stabiliteit. Dit is moeilik om iemand te oortuig in 'n kort opskrywing soos hierdie, maar dink aan PostgreSQL as 'n deurdagte ontwerp wat jou nooit in die steek laat nie.
Daar is baie goeie SQL-kliënte beskikbaar om aan te sluit op PostgreSQL-databasis vir administrasie en ontwikkeling.
PostgreSQL het verskillende fassinerende funksies in vergelyking met ander verhoudingsdatabasisse (spesifiek MySQL), soos:
Ingeboude datatipes vir skikking, reeks, UUID, ligging, ens.
Inheemse ondersteuning vir dokumentberging (JSON-styl), XML en sleutelwaarde-berging (Hstore)
Sinchrone en asinchroniese replikasie
Oorsigbaar in PL, Perl, Python en meer
Volle teks soek
My persoonlike gunstelinge is die geoligging-enjin (wat die pyn wegneem wanneer u met plekgebaseerde apps werk – probeer om al die nabygeleë punte met die hand te vind, en u sal weet wat ek bedoel) en ondersteuning vir skikkings (baie MySQL-projekte word ongedaan gemaak omdat u nie wil nie) skikkings, kies eerder die berugte komma-geskeide snare).
Wanneer om PostgreSQL te gebruik
PostgreSQL is altyd 'n beter keuse bo enige ander relasionele databasis-enjin. Dit is, as u 'n nuwe projek begin en al voorheen deur MySQL gebyt is, is dit 'n goeie tyd om PostgreSQL te oorweeg. Ek het vriende wat opgehou het om MySQL se raaiselagtige mislukkings in die transaksie te beveg en permanent aangegaan het. As u dieselfde besluit, sal u nie oorreageer nie.
PostgreSQL het ook 'n duidelike voordeel as u gedeeltelike NoSQL-fasiliteite benodig vir 'n basterdatamodel. Aangesien dokumente en sleutelwaarde-berging van nature ondersteun word, hoef u nie na 'n ander databasisoplossing te soek, te installeer, te leer en te onderhou nie.
Wanneer nie PostgreSQL gebruik word nie
PostgreSQL maak nie sin as u datamodel nie verwant is nie en / of as u baie spesifieke argitektoniese vereistes het. Oorweeg byvoorbeeld Analytics, waar daar voortdurend nuwe verslae uit bestaande data geskep word. Sulke stelsels is swaar gelees en ly onder 'n streng skema. Natuurlik, PostgreSQL het 'n dokumentopbergingsenjin, maar dinge begin uitmekaar val as u met groot datastelle te doen het.
Met ander woorde, gebruik altyd PostgreSQL, tensy u 100% weet wat u doen! ��
Kyk hierna SQL & PostgreSQL vir beginners kursus as u belangstel om meer te leer.
MariaDB is geskep as 'n plaasvervanger vir MySQL, deur dieselfde persoon wat MySQL ontwikkel het.
Nou ja, nadat MySQL in 2010 deur Oracle oorgeneem is (deur die verkryging van Sun Microsystems, wat terloops ook is hoe Oracle Java beheer het), het die skepper van MySQL 'n nuwe open source-projek met die naam MariaDB begin.
Waarom maak al hierdie vervelige detail saak, vra jy? Dit is omdat MariaDB geskep is uit dieselfde kodebasis as die van MySQL (in die open source-wêreld staan ​​dit bekend as 'n bestaande projek 'vals'). As gevolg hiervan word MariaDB aangebied as 'n "drop-in" vervanging vir MySQL.
Dit wil sê, as u MySQL gebruik en na MariaDB wil migreer, is die proses so maklik dat u dit net nie sal glo nie.
Ongelukkig is so 'n migrasie 'n eenrigtingstraat. Om van MariaDB na MySQL terug te keer is nie moontlik nie, en as u probeer om geweld te gebruik, word permanente korrupsie van die databasis verseker!
Terwyl MariaDB in wese 'n kloon van MySQL is, is dit nie streng waar nie. Sedert die bekendstelling van die databasis het die verskille tussen die twee al hoe groter geword. Die skryf van MariaDB moet van u kant 'n deurdagte besluit wees. Dit gesê, daar is baie nuwe dinge aan die gang in MariaDB wat u kan help om hierdie oorgang te maak:
Voorwaar gratis en oop: aangesien daar geen enkele korporatiewe entiteit is wat MariaDB beheer nie, kan u vry wees van skielike roofdierlisensies en ander bekommernisse.
Verskeie meer opsies vir opbergmotoren vir gespesialiseerde behoeftes: byvoorbeeld die Spider-enjin vir verspreide transaksies; ColumnStore vir massiewe datapakhuise; die ColumnStore-enjin vir parallel verspreide berging; en baie, baie meer.
Spoedverbeterings bo MySQL, veral as gevolg van die Aria-opbergingsenjin vir komplekse navrae.
Dinamiese kolomme vir verskillende rye in 'n tabel.
Beter replikasievermoëns (byvoorbeeld replikasie met meerdere bronne)
. . . En baie, baie meer. Dit is uitputtend om tred te hou met al die MariaDB-funksies. ��
Wanneer om MariaDB te gebruik
MariaDB moet u hê as u 'n ware vervanging van MySQL wil hê, op die innovasiekurwe wil bly en nie van plan is om weer na MySQL terug te keer nie. 'N Uitstekende gebruiksgeval is die gebruik van nuwe stoormotors in MariaDB om die bestaande relasionele datamodel van u projek aan te vul.
Wanneer nie MariaDB gebruik word nie
Verenigbaarheid met MySQL is die enigste probleem hier. Dit gesê, dit word minder 'n probleem omdat projekte soos WordPress, Joomla, Magento, ens. MariaDB begin ondersteun het. My raad sou wees om nie MariaDB te gebruik om 'n CMS te bedrieg wat dit nie ondersteun nie, aangesien daar baie databasisspesifieke truuks is wat die stelsel maklik sal verongeluk.
Dit lyk asof die span agter CockroachDB uit masochiste bestaan. Met 'n produknaam soos dit, wil hulle sekerlik alle kans op hulle draai en steeds wen?
Wel, nie heeltemal nie.
Die idee agter "kakkerlak" is dat dit 'n insek is wat gebou is om te oorleef. Maak nie saak wat gebeur nie – roofdiere, oorstromings, ewige duisternis, verrottende kos, bomaanval, die kakkerlak vind 'n manier om te oorleef en vermeerder.
Die idee is dat die span agter CockroachDB (bestaande uit voormalige Google-ingenieurs) gefrustreerd was oor die beperkinge van tradisionele SQL-oplossings as dit op groot skaal kom. Dit is omdat histories SQL-oplossings veronderstel was om op 'n enkele masjien gehuisves te word (data was nie so groot nie). Vir 'n lang tyd was daar geen manier om 'n groep databasisse met SQL te bou nie, en daarom het MongoDB soveel aandag getrek.
Selfs toe replikasie en groepering in MySQL, PostgreSQL en MariaDB uitgekom het, was dit op die beste pynlik. CoackroachDB wil dit verander, wat moeiteloos afskerming, groepering en hoë beskikbaarheid in die wêreld van SQL bring.
Wanneer om CockroachDB te gebruik
CockroachDB is die droom van die stelselargitek. As u by SQL sweer en geklink het oor die skaalvermoë van MongoDB, sal u van CockroachDB hou. Nou kan u vinnig 'n groep opstel, vrae daaroor gooi en snags rustig slaap. ��
Wanneer u nie CockroachDB gebruik nie
Beter die duiwel wat jy ken, as die wat jy nie ken nie. Daarmee bedoel ek, as u bestaande RDBMS goed vir u werk en u dink dat u die skaalpyn wat dit oplewer, kan bestuur, hou daarby. Vir al die geniale wat betrokke is, is CockroachDB 'n nuwe produk, en u wil nie later daarteen sukkel nie. 'N Ander hoofrede is SQL-verenigbaarheid – as u eksotiese SQL-dinge doen en daarop vertrou vir kritieke dinge, sal CockroachDB te veel voorwaardes vir u smaak bied.
Van nou af sal ons nie-SQL (of NoSQL, soos dit genoem word) databasisoplossings vir hoogs gespesialiseerde behoeftes oorweeg.
Gekoppelde data is een van die belangrikste ontwikkelings in die afgelope dekade. Die wêreld rondom ons word nie in tabelle en rye en bokse verdeel nie – dit is 'n reuse-gemors met alles wat byna alles gekoppel is.
Sosiale netwerke is 'n uitstekende voorbeeld, en die bou van 'n soortgelyke datamodel met behulp van SQL of selfs op databasisse gebaseerde databasisse is 'n nagmerrie.
Dit is omdat die ideale datastruktuur vir hierdie oplossings die grafiek is, wat 'n heeltemal ander dier is. En daarvoor het u 'n grafiese databasis nodig Neo4j.
Die voorbeeld hierbo is direk van die Neo4j-webwerf geneem en toon hoe universiteitstudente aan hul departemente en kursusse gekoppel is. So 'n datamodel is onmoontlik met SQL, want dit sal moeilik wees om oneindige lusse en geheueoorskryding te vermy.
Grafiekdatabasisse is op sigself uniek, en Neo4j is amper die enigste opsie om met grafieke te werk. As gevolg hiervan is al die eienskappe wat dit besit uniek. ��
Ondersteuning vir transaksionele toepassings en grafiese analise.
Data transformasie vermoëns vir die vertering van grootskaalse data in grafieke.
Gespesialiseerde navraagtaal (Cypher) vir die navraag van die grafiese databasis
Visualisering en ontdekkingskenmerke
Dit is 'n belangrike punt om te bespreek wanneer Neo4j gebruik moet word, en wanneer nie. As u verhoudings tussen u data benodig, moet u Neo4j hê. ��
MongoDB was die eerste databasis wat nie relasioneel was nie, wat groot golwe in die tegnologiebedryf gemaak het en steeds 'n redelike deel van die aandag oorheers.
In teenstelling met verhoudingsdatabasisse, is MongoDB 'n "databasis vir dokumente", wat beteken dat dit data in stukke stoor, met verwante data in dieselfde stuk saamgeklem. Dit word die beste verstaan ​​deur 'n versameling van JSON-strukture soos hierdie voor te stel:
In teenstelling met 'n tabelgebaseerde struktuur, lê die kontakbesonderhede en toegangsvlakke van 'n gebruiker hier binne dieselfde voorwerp. As u die gebruikerobjek haal, word die gepaardgaande data outomaties gehaal, en daar is geen konsep van 'n aansluiting nie. Hier is 'n meer gedetailleerde inleiding tot MongoDB.
MongoDB het 'n paar ernstige (ek wil amper 'kick-ass' skryf om die impak oor te dra, maar dit sal miskien nie op 'n openbare webwerf geskik wees nie) funksies wat meegebring het dat verskeie gesoute argitekte die verhoudingsland vir altyd laat vaar het:
'N Buigsame skema vir gespesialiseerde / onvoorspelbare gebruiksgevalle.
Belaglik eenvoudige afskil en kluster. U hoef net die konfigurasie vir 'n groep op te stel en daarvan te vergeet.
Dit is eenvoudig om 'n knoop by 'n groep te voeg of te verwyder.
Transaksionele slotte versprei. Hierdie funksie het in die vorige weergawes ontbreek, maar is uiteindelik bekendgestel.
Dit is geoptimaliseer vir baie vinnige skryfwerk, wat dit uiters geskik maak vir analitiese data as 'n kasstelsel.
As ek soos 'n woordvoerder van MongoDB klink, vra ek om verskoning, maar dit is moeilik om die voordele van MongoDB te oorverkoop. Natuurlik, NoSQL-datamodellering is aanvanklik vreemd, en sommige kry nooit die kans nie, maar vir baie argitekte wen dit byna altyd oor 'n tabelgebaseerde skema.
Wanneer om MongoDB te gebruik
MongoDB is 'n wonderlike kruisbrug van die gestruktureerde, streng wêreld van SQL na die amorfe, amper verwarrende een van NoSQL. Dit presteer met die ontwikkeling van prototipes, want daar is eenvoudig geen skema om oor te bekommer nie, en wanneer jy regtig moet skaal. Ja, u kan 'n wolk-SQL-diens gebruik om probleme met DB-skaal ontslae te raak, maar seun is dit duur!
Laastens is daar gevalle waar SQL-gebaseerde oplossings dit nie doen nie. As u byvoorbeeld 'n produk soos Canva skep, waar die gebruiker willekeurig ingewikkelde ontwerpe kan skep en dit later kan redigeer, moet u geluk hê met 'n verhoudingsdatabasis!
Wanneer nie MongoDB gebruik word nie
Die totale gebrek aan skema wat MongoDB bied, kan dien as 'n teerput vir diegene wat nie weet wat hulle doen nie. Dataversoening, dooie data, leë velde wat nie leeg moet wees nie – dit alles en nog baie meer is moontlik. MongoDB is in wese 'n "stomme" datavoorraad, en as u dit kies, moet die toepassingscode baie verantwoordelikheid neem om die data-integriteit te handhaaf.
As u 'n ontwikkelaar is, sal u dit vind dit nuttig.
Soos die naam ook gaan, RethinkDB 'Herdenk' die idee en vermoëns van 'n databasis in real-time-programme.
As 'n databasis opgedateer word, is daar geen manier om die aansoek te weet nie. Die aanvaarde benadering is dat die app 'n kennisgewing afskiet sodra daar 'n opdatering is, wat deur 'n komplekse brug (PHP) na die voorkant gedruk word. -> Redis -> knoop -> Socket.io is een voorbeeld).
Maar wat as die opdaterings direk vanaf die databasis na die front-end gestoot kan word??!
Ja, dit is die belofte van RethinkDB. Dus as u op die regte tyd 'n toepassingsprogram (speletjie, markplek, analise, ens.) Wil maak, is Rethink DB die moeite werd om te kyk.
As dit kom by databasisse, is dit amper te maklik om die bestaan ​​van te versien Redis. Dit is omdat Redis 'n databasis in die geheue is en meestal gebruik word in ondersteuningsfunksies soos caching.
Leer hierdie databasis is 'n werk van tien minute (letterlik!), en dit is 'n eenvoudige sleutelwaarde-winkel wat snare ophou met 'n verstrykingstyd (wat natuurlik op oneindig gestel kan word). Wat Redis verloor in funksies wat dit uitmaak in nut en uitvoering. Aangesien dit geheel en al in RAM woon, is lees en skryf baie vinnig ('n paar honderd duisend bewerkings per sekonde is ongehoord).
Redis het ook 'n gesofistikeerde pub-sub-stelsel, wat hierdie "databasis" twee keer so aantreklik maak.
Met ander woorde, as u 'n projek het wat voordeel kan trek uit cache of wat verspreide komponente het, is Redis die eerste keuse.
Ja, ek het belowe dat ons klaar is met verhoudingsdatabasisse, maar SQLite is te oulik om te ignoreer.
SQLite is 'n liggewig C-biblioteek wat 'n relasionele databasisbergingsmotor verskaf het. Alles in hierdie databasis leef in 'n enkele lêer (met 'n .sqlite-uitbreiding) wat u enige plek in u lêersisteem kan plaas. En dit is al wat jy nodig het om dit te gebruik! Ja, geen "bediener" -sagteware om te installeer nie, en geen diens om aan te sluit nie.
Al is SQLite 'n liggewig alternatief vir 'n databasis soos MySQL, pak dit nogal 'n pons. Van die skokkende kenmerke daarvan is:
Volle ondersteuning vir transaksies met COMMIT, ROLLBACK en BEGIN.
Ondersteuning vir 32.000 kolomme per tafel
Navrae, volteksoektog, ens.
Maksimum databasisgrootte van 140 terabyte!
Maksimum ry grootte van 1 gigabyte!
35% vinniger as lêer I / O
Wanneer om SQLite te gebruik
SQLite is 'n buitengewoon gespesialiseerde databasis wat fokus op 'n no-nonsense, get-shit-done benadering. As u app relatief eenvoudig is en u nie die probleem met 'n volledige databasis wil hê nie, is SQLite 'n ernstige kandidaat. Dit maak veral sin vir klein tot middelgrootte CMS's en demo-toepassings.
Wanneer nie SQLite gebruik nie
Hoewel dit indrukwekkend is, dek SQLite nie al die funksies van standaard SQL of u gunsteling databasis-enjin nie. Clustering, gebergde prosedures en script-uitbreidings ontbreek. Daar is ook geen kliënt om die databasis te verbind, navraag te doen en te verken nie. Uiteindelik, namate die toedieningsgrootte toeneem, sal die prestasie afneem.
Terwyl baie mense verklaar dat die einde vir Java naby is, gooi die gemeenskap elke nou en dan 'n bomskoot en maak die kritici stil.. Cassandra is so 'n voorbeeld.
Cassandra behoort aan die sogenaamde 'kolom' databasisfamilie. Die bergingsabstraksie in Cassandra is 'n kolom eerder as 'n ry. Die idee hier is om al die gegewens in 'n kolom fisies saam op die skyf te stoor, om soektyd te verminder.
Cassandra is ontwerp met 'n spesifieke gebruikskas in gedagte – handel oor swaar vragte en geen verdraagsaamheid vir stilstand nie. Dit word die unieke verkoopspunte.
Baie vinnige skryfprestasie. Cassandra is waarskynlik die vinnigste databasis wat daar is by die hantering van swaar skryfvragte.
Lineêre skaalbaarheid. Dit wil sê, u kan aanhou om soveel nodusse by te voeg tot 'n groep as wat u wil, en daar sal 'n nul toename in die kompleksiteit of brosheid van die groep wees.
Ongeëwenaarde verdelingstoestand. Dit wil sê, selfs al val verskeie knope in 'n Cassandra-groep saam, is die databasis ontwerp om aan te hou presteer sonder verlies aan integriteit.
Wanneer moet u Cassandra gebruik?
Log en analise is twee van die beste gevalle vir Cassandra. Maar dit is nie al nie – die lieflike plek is wanneer u regtig groot groottes data moet hanteer (Apple het 'n Cassandra-ontplooiing wat 400+ petagrepe data hanteer, terwyl dit op Netflix 1 biljoen versoeke per dag hanteer) met letterlik nul stilstand. Hoog beskikbaarheid is een van die kenmerke van Cassandra.
Wanneer nie Cassandra gebruik word nie
Die kolomopbergingskema van Cassandra het ook sy nadele. Die datamodel is taamlik plat, en as u samevoegings benodig, is Cassandra kort. Boonop verkry dit hoë beskikbaarheid deur konsekwentheid op te offer (onthou die CAP-stelling vir verspreide stelsels), wat dit minder geskik maak vir stelsels waar 'n hoë lees akkuraatheid nodig is.
Nuwe ontwikkelings vereis nuwe soorte databasisse, en die Internet of Things (IoT) is een van hierdie verskynsels. Een van die beste open source databasisse daarvoor tydskaal.
Die tydskaal is 'n tipe wat 'n 'tydreeks'-databasis genoem word. Dit is anders as 'n tradisionele databasis, want die tyd is die belangrikste punt van kommer, en die ontleding en visualisering van massiewe datastelle is 'n topprioriteit. Tydreeksdatabasisse sien selde 'n verandering in bestaande data; 'n voorbeeld is temperatuurlesings wat deur 'n sensor in 'n kweekhuis gestuur word – nuwe data word elke sekonde opgehoop, wat vir analise en verslaggewing van belang is.
Waarom dan nie net 'n tradisionele databasis met 'n tydstempelveld gebruik nie? Daar is twee hoofredes daarvoor:
Algemene databasisse is nie geoptimaliseer om met tydgebaseerde data te werk nie. Vir dieselfde hoeveelhede data sal 'n databasis vir algemene doeleindes baie stadiger wees.
Die databasis moet enorme hoeveelhede data hanteer, aangesien nuwe data steeds invloei en data verwyder of skema verander; later is dit nie 'n opsie nie.
Timescale DB het 'n paar opwindende funksies wat dit onderskei van ander databasisse in dieselfde kategorie:
Dit is gebou op PostgreSQL, waarskynlik die beste open source relasionele databasis daar buite. As u projek alreeds met PostgreSQL loop, sal Timescale regs in gly.
Navrae word gedoen via die bekende SQL-sintaksis, wat die leerkurwe verminder.
Belaglik vinnige skryfsnelheid – miljoene insetsels per sekonde is ongehoord.
Miljarde rye of petabytes data – dit is nie 'n groot saak vir Timescale nie.
Ware buigsaamheid met skema – kies uit relasionele of skeefheid volgens u behoeftes.
Dit maak nie veel sin om te praat oor wanneer u Timescale DB moet gebruik of nie. As IoT u domein is, of dat u soortgelyke databasiskenmerke het, is dit die moeite werd om te kyk na Timescale.
CouchDB is 'n netjiese klein databasisoplossing wat stil in 'n hoek sit en 'n klein, maar toegewyde volgende bevat. Dit is geskep om die probleme van 'n netwerkverlies en die uiteindelike oplossing van data te hanteer, wat toevallig 'n probleem is dat die ontwikkelaars eerder van werk sou verander as om dit te hanteer..
In wese kan u aan 'n CouchDB-groep beskou as 'n verspreide versameling groot en klein nodusse, waarvan sommige na verwagting vanlyn sal wees. Sodra 'n knoop aanlyn kom, stuur dit data terug na die groep, wat stadig en noukeurig verteer word en uiteindelik beskikbaar word vir die hele groep.
CouchDB is iets van 'n unieke ras as dit kom by databasisse.
Gespesialiseerde weergawes vir mobiele en webblaaiers (PouchDB, CouchDB Lite, ens.)
Botsingsbestande, betroubare betroubaarheid
Maklike groepering met oortollige datastoor
Wanneer om CouchDB te gebruik
CouchDB is gebou vir aflyn verdraagsaamheid en is steeds ongeëwenaard in hierdie verband. 'N Tipiese gebruiksgeval is mobiele programme waar 'n deel van u data op 'n CouchDB-voorkoms op die gebruiker se telefoon geleë is (want dit is waar dit gegenereer is). Die opwindende ding is dat u nie kan vertrou dat die gebruiker se toestel heeltyds gekoppel is nie, wat beteken dat die databasis opportunisties moet wees en later gereed moet wees om teenstrydige opdaterings op te los. Dit word bereik deur gebruik te maak van die indrukwekkende Bank-replikasieprotokol.
Wanneer nie CouchDB gebruik nie
As u CouchDB buite die voorgenome gebruiksgeval gebruik, sal dit tot 'n ramp lei. Dit gebruik veel meer stoorplek as enigiets anders daar, bloot omdat dit onnodige kopieë van data en resultate van konflikoplossing moet behou. Gevolglik is die skryfsnelheid ook pynlik stadig. Laastens is CouchDB nie geskik as 'n skema-enjin vir algemene doeleindes nie, aangesien dit nie goed speel met skemaveranderings nie.
Ek moes baie interessante kandidate soos Riak uitlaat, so hierdie lys moet eerder as 'n gids as 'n gebod geneem word. Ek hoop dat ek met hierdie artikel my doel kon bereik – nie net 'n versameling databasisaanbevelings aanbied nie, maar ook kortliks bespreek waar en hoe dit gebruik moet word (en vermy moet word!).
As u nuuskierig is om databasis te leer, gaan kyk gerus Udemy vir sommige van die briljante aanlynkursusse.
Een van die vrae wat die meeste gevra word – watter databasis moet ek
Om die regte kleurskemas te hê, kan wonders vir u handelsmerk doen. En ek
Uptyd van toepassing is van uiterste belang vir bedryfsaktiwiteite en as infrastruktuurondersteuning moet u
11 Open Source en kommersiële wagwoordbestuurder vir spanne
'N Beter manier om u spanwagwoord te bestuur! Hoe kan u u wagwoord bestuur?
Monitering is noodsaaklik vir ondernemings om te verseker dat 'n nodige stelsel in werking
8 Populêre open source-intelligensiemiddele vir penetrasietoetsing
Die opvallende siening van verskillende Open Source Intelligensie (OSINT) gereedskap wat in die mark