A következő projekt első 11 nyílt forráskódú adatbázisa

Az adatok minden. És kiterjesztésképpen, az adatbázisok is. Íme néhány fantasztikus nyílt forráskódú lehetőség a következő kick-ass projekthez.


Egy olyan világban, amelyet olyan sokáig uralnak az adatbázis-alkalmazások, mint például az Oracle és az SQL Server, most úgy tűnik, hogy a megoldások végtelenségének szélsősége van. Ennek egyik oka az innováció, amelyet a nyílt forráskód táplál – valóban tehetséges fejlesztők, akik meg akarják húzni egy viszketést, és olyan valamit készítenek, amelyben remekül tudnak élni.

A másik rész az új üzleti modellek megjelenése, amelyek során a vállalkozások termékük közösségi változatát karbantartják, hogy megtapasztalják és vonzzák a képességeket, ugyanakkor kereskedelmi, kiegészítő ajánlatot is nyújtanak..

Az eredmény?

Több adatbázis található, mint amennyivel képes lépést tartani. Erről még nincs hivatalos stat, de biztos vagyok benne, hogy ma több mint száz lehetőség áll rendelkezésre, ha mindent összekapcsolunk a verem-specifikus objektum-adatbázisoktól az egyetemek nem olyan népszerű projektéig..

Tudom, ez is rémít. Túl sok lehetőség – túl sok dokumentáció az áthaladáshoz – és egy ilyen rövid élet. ��

Ezért döntöttem úgy, hogy megírom ezt a cikket, bemutatva a tíz legjobb adatbázist, amelyek segítségével javíthatja megoldásait, akár magának, akár másoknak épít.

Nincs MySQL

Felhívjuk figyelmét: ez a lista nem fogja tartalmazni a MySQL-t, annak ellenére, hogy vitathatatlanul a legnépszerűbb nyílt forráskódú adatbázis-megoldás odakint.

Miért? Egyszerűen azért, mert a MySQL mindenhol megtalálható – ez az, amit mindenki megtanul, szinte minden CMS vagy a keretrendszer támogatja, és nagyon-nagyon jó a legtöbb felhasználási esetben. Más szavakkal, a MySQL-t nem kell „felfedezni”. ��

Ennek ellenére, kérjük, vegye figyelembe, hogy az alábbiak nem feltétlenül jelentik a MySQL alternatíváját. Bizonyos esetekben ezek lehetnek, míg másokban teljesen más megoldás egy teljesen más igény kielégítésére. Ne aggódjon, mivel megvitatom a felhasználásukat is.

Különleges megjegyzés: kompatibilitás

Mielőtt elkezdenénk, azt is megemlítenem kell, hogy a kompatibilitást figyelembe kell venni. Ha van egy olyan projektje, amely bármilyen okból csak egy adott adatbázis-motort támogat, akkor a választások nagyjából át vannak vetve.

Például, ha a WordPress-t futtatja, ez a cikk nem hasznos neked. �� Hasonlóképpen azok, akik statikus webhelyeket futtatnak a JAMStack-en, semmit nem fognak nyerni, ha túl komolyan keresnek alternatívákat.

Ez rajtad múlik, hogy kitalálja a kompatibilitási egyenletet. Ha azonban van üres pala, és az építészet rajtad múlik, íme néhány jó javaslat.

PostgreSQL

Ha a PHP területéről származik (WordPress, Magento, Drupal stb.), Akkor PostgreSQL idegennek tűnik számodra. Ez a relációs adatbázis-megoldás 1997 óta működik, és ez a legmegfelelőbb választás olyan közösségekben, mint a Ruby, Python, Go, stb..

Valójában sok fejlesztő végül „átvált” a PostgreSQL-re az általa kínált szolgáltatások vagy egyszerűen a stabilitás érdekében. Nehéz meggyőzni valakit egy ilyen rövid írásban, de gondolj a PostgreSQL-re, mint egy átgondoltan megtervezett termékre, amely soha nem enged le.

Számos jó SQL-ügyfél elérhető a PostgreSQL adatbázishoz való kapcsolódáshoz adminisztráció és fejlesztés céljából.

Egyedi tulajdonságok

A PostgreSQL számos lenyűgöző funkcióval rendelkezik a többi relációs adatbázishoz (különösen a MySQL-hez képest), mint például:

  • Beépített adattípusok tömb, tartomány, UUID, földrajzi helyzet stb.
  • Natív támogatás a dokumentumtároláshoz (JSON stílus), XML és kulcsértékű tároláshoz (Hstore)
  • Szinkron és aszinkron replikáció
  • Szkriptelhető PL-ben, Perl-ben, Python-ban és így tovább
  • Teljes szövegű keresés

Személyes kedvenceim a földrajzi helymeghatározó motor (amely elveszíti a fájdalmat a helyalapú alkalmazásokkal való munka során – próbálja meg manuálisan megtalálni az összes közeli pontot, és tudni fogja, hogy mire gondolok), valamint a tömbök támogatása (sok MySQL projektet visszavontak tömbök, inkább a hírhedt vesszővel elválasztott karakterláncokat választva).

Mikor kell használni a PostgreSQL-t

A PostgreSQL mindig jobb választás, mint bármely más relációs adatbázis-motor. Vagyis ha új projektet indít, és a MySQL már megharapta, akkor ideje megfontolni a PostgreSQL-t. Van olyan barátaim, akik feladták a MySQL titokzatos tranzakciózár kudarcát, és véglegesen továbbmentek. Ha ugyanezt dönt, akkor nem fog túlzottan reagálni.

A PostgreSQL egyértelmű előnye is, ha részleges NoSQL lehetőségekre van szükség egy hibrid adatmodellhez. Mivel a dokumentumok és a kulcsértékek tárolása natív módon támogatott, nem kell vadásznia, telepítenie, tanulnia és karbantartania egy másik adatbázis-megoldást.

Mikor nem használja a PostgreSQL-t

A PostgreSQL-nek nincs értelme, ha az adatmodell nem relációs, és / vagy ha nagyon specifikus építészeti követelményei vannak. Vegyük figyelembe például az Analytics szolgáltatást, ahol a meglévő adatokból folyamatosan készülnek új jelentések. Az ilyen rendszerek nagyon nehézek és szenvednek, ha szigorú sémát vetnek rájuk. Persze, a PostgreSQL rendelkezik dokumentumtároló motorral, de a dolgok szétesnek, amikor nagy adatkészletekkel foglalkozik.

Más szavakkal, mindig használd a PostgreSQL-t, kivéve, ha 100% -ban tudod, mit csinálsz! ��

Nézd meg ezt SQL & PostgreSQL kezdőknek tanfolyam ha érdekel többet megtudni.

MariaDB

MariaDB a MySQL helyettesítésére hozta létre ugyanaz a személy, aki kifejlesztette a MySQL-t.

Zavaros?

Nos, miután a MySQL-t az Oracle vette át 2010-ben (a Sun Microsystems megvásárlásával, amely egyébként az is, hogy az Oracle a Java irányítására jött létre), a MySQL alkotója új nyílt forrású projektet indított a MariaDB néven..

Miért számít mindez az unalmas részlet? Ennek oka az, hogy a MariaDB-t ugyanabból a kódbázisból hozták létre, mint a MySQL (a nyílt forráskódú világban ez egy meglévő projekt „forking” -ja). Ennek eredményeként a MariaDB a MySQL „drop-in” helyettesítőjeként kerül bemutatásra.

Vagyis, ha MySQL-t használ, és át akar venni a MariaDB-re, akkor a folyamat olyan egyszerű, hogy nem fogja elhinni.

Sajnos az ilyen migráció egyirányú utca. A MariaDB-től a MySQL-hez való visszatérés nem lehetséges, és ha erőt próbál meg használni, akkor az állandó adatbázis-sérülést biztosít!

Egyedi tulajdonságok

Noha a MariaDB alapvetően a MySQL klónja, nem szigorúan igaz. Az adatbázis bevezetése óta a különbségek egyre növekednek. Az írás megírásától kezdve a MariaDB elfogadását az ön részéről átgondolt döntésnek kell hoznia. Ennek ellenére rengeteg új dolog folyik a MariaDB-ben, amelyek segíthetnek az átmenet végrehajtásában:

  • Valóban szabad és nyitott: Mivel egyetlen vállalati egység sem irányítja a MariaDB-t, mentes lehet hirtelen ragadozó engedélyezésektől és más gondoktól.
  • Számos további lehetőség tárolómotorok számára speciális igények kielégítésére: például a Spider motor elosztott tranzakciókhoz; ColumnStore tömeges adattároláshoz; a ColumnStore motor a párhuzamos, elosztott tároláshoz; és még sok más.
  • Sebességjavítások a MySQL-hez képest, különösen az Aria tároló motorjának köszönhetően a komplex lekérdezésekhez.
  • Dinamikus oszlopok a táblázat különféle soraihoz.
  • Jobb replikációs képességek (például több forrású replikáció)
  • Több JSON funkció
  • Virtuális oszlopok

. . . És még sok-sok más. Fárasztó az, hogy lépést tartson a MariaDB összes szolgáltatásával. ��

Mikor kell használni a MariaDB-t

Ha a MySQL valódi cseréjét akarja, továbbra is az innovációs görbén szeretne maradni, és nem tervezi, hogy visszatér a MySQL-hez, akkor a MariaDB-vel kell. Egy kiváló felhasználási eset az új tárolómotorok használata a MariaDB-ben a projekt meglévő relációs adatmodelljének kiegészítéseként.

Mikor nem használja a MariaDB-t

A MySQL-vel való kompatibilitás az egyetlen gond. Ennek ellenére ez egyre kevésbé jelent problémát, mivel a WordPress, Joomla, Magento stb. Projektek már megkezdték a MariaDB támogatását. Azt tanácsolnám, hogy ne használja a MariaDB-t olyan CMS becsapására, amely nem támogatja, mivel sok adatbázis-specifikus trükk létezik, amelyek könnyen összeomlik a rendszerrel.

CockroachDB

A CockroachDB mögött álló csapat látszólag mazochistákból áll. Ilyen terméknévvel minden bizonnyal meg akarják fordítani minden esélyüket és még mindig nyernek?

Nos, nem egészen.

A „csótány” gondolata az, hogy egy rovar a túlélésre épült. Nem számít, mi történik – ragadozók, árvizek, örök sötétség, rothadó ételek, bombázások, a csótány megtalálja a módját a túlélésre és a szaporodásra.

Az ötlet az, hogy a CockroachDB mögött álló csapat (a korábbi Google mérnökökből állt) csalódott volt a hagyományos SQL megoldások korlátozásaival szemben, amikor a nagy léptékű. Ennek oka az, hogy a történelmileg az SQL megoldásokat állítólag egyetlen gépen kellett tárolni (az adatok nem voltak olyan nagyok). Régóta nem volt mód az SQL-t futtató adatbázis-fürt felépítésére, ezért a MongoDB ilyen nagy figyelmet szentelt.

Még akkor is, ha a MySQL, a PostgreSQL és a MariaDB replikációja és csoportosulása jelent meg, a legjobban fájdalmas volt. A CoackroachDB ezt meg akarja változtatni, könnyű szilánkot, fürtözést és magas rendelkezésre állást hozva az SQL világába..

Mikor kell használni a CockroachDB-t?

CockroachDB a rendszerépítész álma valóra vált. Ha esküszik az SQL-től, és belemerül a MongoDB méretezési képességeibe, akkor imádni fogja a CockroachDB-t. Most gyorsan beállíthat egy fürtöt, kérdéseket tehet fel rá, és éjszaka békésen aludhat. ��

Mikor nem használja a CockroachDB-t

Jobban az ördögöt ismered, mint amit nem tudsz. Erre gondolok, ha a meglévő RDBMS jól működik az Ön számára, és úgy gondolja, hogy képes kezelni az általa okozott méretezési fájdalmakat, maradjon vele. Az összes érintett zseni számára a CockroachDB egy új termék, és nem akarja, hogy később küzdjön vele. Egy másik fő ok az SQL kompatibilitása – ha egzotikus SQL dolgokat csinálsz, és kritikus dolgokra támaszkodsz, a CockroachDB túl sok szélsőséges esetet mutat be az Ön kedveled szerint.

Mostantól a nem SQL (vagy NoSQL néven hívják) adatbázis-megoldásokat fogjuk fontolóra venni a magasan specializált igények kielégítésére..

Neo4j

Az elmúlt évtized egyik legjelentősebb fejleménye a kapcsolódó adatok. A körülöttünk lévő világ nem oszlik táblázatokba, sorokba és dobozokba – ez egy óriási rendetlenség mindennel, ami szinte minden máshoz kapcsolódik.

A közösségi hálózatok kiváló példa, és egy hasonló adatmodell felépítése SQL vagy akár dokumentum-alapú adatbázisok felhasználásával rémálom.

Ennek oka az, hogy ezeknek a megoldásoknak az ideális adatstruktúrája a grafikon, amely egy teljesen más állat. Ehhez grafikus adatbázisra van szüksége, mint például Neo4j.

A fenti példa közvetlenül a Neo4j weboldalról származik, és azt mutatja, hogy az egyetemi hallgatók hogyan kapcsolódnak tanszékeikhez és tanfolyamukhoz. Egy ilyen adatmodell egyszerűen lehetetlen az SQL-nél, mivel nehéz lesz elkerülni a végtelen hurkokat és a memória túllépését.

Egyedi tulajdonságok

A gráf-adatbázisok önmagukban egyediek, és a Neo4j nagyjából az egyetlen lehetőség a grafikonok kezelésére. Ennek eredményeként bármely tulajdonsága egyedi. ��

  • Tranzakciós alkalmazások és grafikus elemzések támogatása.
  • Adat-transzformációs képesség nagy méretű táblázatos adatok grafikonokba történő emésztésére.
  • Specializált lekérdezési nyelv (Cypher) a gráf-adatbázis lekérdezésére
  • Megjelenítés és felfedezés funkciói

Nagyon fontos kérdés, hogy megvitassuk, mikor kell használni a Neo4j-t, mikor nem. Ha grafikon-alapú kapcsolatokra van szüksége az adatok között, akkor szüksége van a Neo4j-re. ��

MongoDB

MongoDB volt az első nem relációs adatbázis, amely nagy hullámokat hajtott végre a technológiai iparban, és továbbra is uralja a figyelem tisztességes részét.

A relációs adatbázisokkal ellentétben a MongoDB egy „dokumentum adatbázis”, azaz azt jelenti, hogy az adatokat darabonként tárolja, és a kapcsolódó adatok ugyanabba a darabba vannak csoportosítva. Ezt legjobban úgy lehet megérteni, ha elképzeljük a JSON-struktúrák ilyen aggregációját:

A táblázat alapú szerkezettel ellentétben itt a felhasználó elérhetőségei és hozzáférési szintjei ugyanazon az objektumon találhatók. A felhasználói objektum beolvasása automatikusan lekéri a társított adatokat, és nincs fogalom a csatlakozásról. Itt található egy részletesebb bevezetés a MongoDB-hez.

Egyedi tulajdonságok

A MongoDB-nek van néhány komoly dolga (szinte azt akarom, hogy „kick-ass” -ot írjak a hatás közvetítésére, de ez talán nem lenne megfelelő a nyilvános weboldalon) olyan funkciókkal, amelyek miatt több tapasztalt építész elhagyta a kapcsolatok földjét örökre:

  • Rugalmas séma a speciális / kiszámíthatatlan felhasználási esetekhez.
  • Nevetségesen egyszerű szilánkok és csoportosulások. Be kell állítania a fürt konfigurációját, és el kell felejtenie.
  • Csomópont hozzáadása vagy eltávolítása a fürtből egyszerűen elvégezhető.
  • Elosztott tranzakciós zárak. Ez a szolgáltatás hiányzott a korábbi verziókban, de végül bevezették.
  • Nagyon gyors írásokra van optimalizálva, így kiválóan alkalmas az analitikai adatok tárolására.

Ha úgy gondolom, hogy a MongoDB szóvivője, elnézést kérek, de nehéz elárulni a MongoDB előnyeit. Persze, a NoSQL adatmodellezése eleinte furcsa, és néhányan soha nem kapja meg ezt, de sok építész számára szinte mindig nyer egy asztal alapú séma miatt.

Mikor kell használni a MongoDB-t?

A MongoDB nagyszerű kereszteződéses híd az SQL strukturált, szigorú világából az amorf, szinte zavaró NoSQL egyikéhez. Kiválóan fejleszti a prototípusokat, mivel egyszerűen nincs séma, amely miatt aggódni kell, és amikor valóban méreteznie kell. Igen, felhő SQL szolgáltatással is megszabadulhat a DB méretarányos problémáitól, de fiú, drága!

Végül vannak olyan esetek, amikor az SQL-alapú megoldások csak nem sikerülnek. Például, ha olyan terméket készít, mint a Canva, ahol a felhasználó tetszőlegesen összetett mintákat hozhat létre, és később szerkesztheti őket, sok szerencsét kapsz egy relációs adatbázismal!

Mikor nem használja a MongoDB-t

A séma teljes hiánya, amelyet a MongoDB nyújt, kátrányozóként szolgálhat azok számára, akik nem tudják, mit csinálnak. Adatok eltérése, halott adatok, üres mezők, amelyeknek nem szabad üresnek lenniük – mindez és még sok más lehetséges. A MongoDB lényegében „hülye” adattároló, és ha ezt választja, akkor az alkalmazáskódnak nagy felelősséget kell vállalnia az adatok integritásának fenntartása érdekében..

Ha Ön fejlesztő, akkor megtalálja ez hasznos.

RethinkDB

Ahogy a neve megy, RethinkDB „Átgondolja” egy adatbázis ötletét és képességeit, amikor a valós idejű alkalmazásokról van szó.

Amikor egy adatbázis frissítésre kerül, az alkalmazásnak nem szabad megismernie azt. Az elfogadott megközelítés az, hogy az alkalmazás értesítést indítson, amint megjelenik egy frissítés, amelyet egy összetett hídon keresztül (PHP) kell kezelni a felhasználói felület felé. -> Redis -> Csomópont -> A Socket.io egy példa).

De mi lenne, ha a frissítéseket közvetlenül az adatbázisból a felhasználói felületre lehetne tolni?!

Igen, ez a RethinkDB ígéretét. Tehát ha valódi valós idejű alkalmazásokat készít (játék, piac, elemzés stb.), Akkor a Rethink DB érdemes megnézni.

Redis

Az adatbázisokról szinte túl könnyű figyelmen kívül hagyni az adatbázis létezését Redis. Ennek oka az, hogy a Redis egy memóriában lévő adatbázis, és főként olyan támogatási funkciókban használják, mint például a gyorsítótárazás.

Az adatbázis megtanulása egy tíz perces munka (szó szerint!), és ez egy egyszerű kulcsérték-tároló, amely tárolja a karakterláncokat lejárati idővel (amelyet természetesen a végtelenségre lehet beállítani). Amit Redis veszít olyan funkciókból, amelyeket felszámol a hasznosság és a teljesítmény szempontjából. Mivel teljes mértékben RAM-ban él, az olvasás és az írás óriási gyors (másodpercenként néhányszázezer művelet nem ismeretlen).

Redisnek is kifinomult pub-sub rendszer, ami ezt az „adatbázist” kétszer vonzóvá teszi.

Más szavakkal, ha van olyan projekted, amely hasznos lehet a gyorsítótárazásból, vagy van néhány elosztott összetevője, akkor a Redis az első választás.

SQLite

Igen, megígértem, hogy relációs adatbázisokkal dolgozunk, de SQLite túl aranyos ahhoz, hogy figyelmen kívül hagyja.

Az SQLite egy könnyű C könyvtár, amely relációs adatbázis-tároló motort biztosított. Az adatbázisban minden található egyetlen fájlban (.sqlite kiterjesztéssel), amelyet bárhol elhelyezhet a fájlrendszerben. És ehhez csak szükséged van! Igen, nincs telepítendő „szerver” szoftver, és nincs szolgáltatás, amelyhez csatlakozni lehet.

Hasznos szolgáltatások

Annak ellenére, hogy az SQLite egy könnyű alternatíva egy olyan adatbázishoz, mint a MySQL, nagyon lyukasztó. Néhány megdöbbentő tulajdonsága a következő:

  • Teljes tranzakciók támogatása a COMMIT, ROLLBACK és BEGIN rendszerekkel.
  • Támogatás táblánként 32 000 oszlophoz
  • JSON támogatás
  • 64-utas JOIN támogatás
  • Alkeresések, teljes szöveges keresés stb.
  • A maximális adatbázisméret 140 terabyte!
  • A sor maximális mérete 1 gigabájt!
  • 35% -kal gyorsabb, mint a fájl I / O

Mikor kell használni az SQLite-t

Az SQLite egy rendkívül speciális adatbázis, amely egy non-nonsense, get-shit-done megközelítésre koncentrál. Ha alkalmazásod viszonylag egyszerű, és nem akarja a teljes adatbázis problémamentességét, az SQLite komoly jelölt. Különösen értelmes a kis és közepes méretű CMS-k és a demo alkalmazások számára.

Mikor nem használja az SQLite-t

Noha lenyűgöző, az SQLite nem fedi le a szokásos SQL vagy a kedvenc adatbázis-motor összes funkcióját. Hiányoznak a fürtözés, a tárolt eljárások és a parancsfájl-kiterjesztések. Ezenkívül nincs olyan ügyfél, aki csatlakozhat, lekérdezhet és felkutathat az adatbázist. Végül, az alkalmazás méretének növekedésével a teljesítmény romlik.

Cassandra

Bár sokan kijelentik, hogy a Java számára a vége közel van, a közösség csak időről időre bombázik és elhallgattatja a kritikusokat. Cassandra az egyik ilyen példa.

A Cassandra az úgynevezett adatbázisok „oszlopos” családjába tartozik. A Cassandra tároló absztrakciója oszlop, nem pedig sor. Az ötlet az, hogy az összes adatot egy oszlopban fizikailag együtt tárolja a lemezen, minimalizálva a keresési időt.

Egyedi tulajdonságok

A Cassandra-t egy speciális felhasználási esetre tervezték – foglalkozik az írási nehézségekkel és a leállás ideje nélküli zéró toleranciával. Ezek válnak az egyedi értékesítési pontokká.

  • Rendkívül gyors írási teljesítmény. A Cassandra vitathatatlanul a leggyorsabb adatbázis odakinn, amikor nehéz írási terhelésekkel foglalkozik.
  • Lineáris skálázhatóság. Vagyis folytathatja annyi csomópont hozzáadását a fürthez, amennyit csak akar, és a klaszter komplexitása vagy törékenysége nullán növekszik..
  • Páratlan partíciótűrés. Vagyis akkor is, ha egy Cassandra-fürt több csomópontja lecsökken, az adatbázist úgy tervezték, hogy a integritás elvesztése nélkül továbbra is teljesítsen.
  • Statikus gépelés

Mikor kell használni a Cassandra-t?

Az adatgyűjtés és az elemzés a Cassandra két legjobb felhasználási esete. De ez még nem minden – az a kedves hely, amikor igazán nagy méretű adatokat kell kezelnie (az Apple rendelkezik egy Cassandra telepítéssel, amely legalább 400 petayte adatot kezel, míg a Netflix napi 1 billió kérést kezeli), szó szerint nulla állásidővel. A magas rendelkezésre állás Cassandra egyik legfontosabb jellemzője.

Mikor nem használja a Cassandra-t

A Cassandra oszloptároló rendszerének vannak hátrányai is. Az adatmodell meglehetősen sima, és ha aggregációkra van szüksége, akkor a Cassandra hiányzik. Sőt, magas rendelkezésre állást ér el a konzisztencia feláldozása révén (emlékezzen az elosztott rendszerekre vonatkozó CAP-tételre), ami kevésbé alkalmassá teszi azokat a rendszereket, ahol nagy leolvasási pontosság szükséges.

Ütemterv

Az új fejlemények új típusú adatbázisokat igényelnek, és a tárgyak internete (IoT) az egyik ilyen jelenség. Erre az egyik legjobb nyílt forráskódú adatbázis Ütemterv.

Az időskála egyfajta úgynevezett „idősor” adatbázis. Ez eltér a hagyományos adatbázistól, abban az időben az elsődleges aggodalomra ad okot, és a hatalmas adatkészletek elemzése és megjelenítése kiemelt prioritás. Az idősor-adatbázisok ritkán látnak változást a meglévő adatokban; példa erre az üvegházban egy érzékelő által küldött hőmérséklet-leolvasások – az új adatok másodpercenként felhalmozódnak, ami az elemzés és a jelentések szempontjából érdekes.

Akkor miért nem csak egy tradicionális adatbázist használ egy időbélyegző mezővel? Nos, ennek két fő oka van:

  • Az általános célú adatbázisokat nem optimalizálják az időalapú adatokkal való együttműködésre. Ugyanazon adatmennyiség esetén az általános célú adatbázis sokkal lassabb lesz.
  • Az adatbázisnak hatalmas mennyiségű adatot kell kezelnie, mivel az új adatok folyamatosan beáramlanak és eltávolítják az adatokat, vagy megváltoznak a séma; később nem lehetséges.

Egyedi tulajdonságok

A Timescale DB néhány izgalmas funkcióval rendelkezik, amelyek különböznek az azonos kategóriába tartozó többi adatbázistól:

  • A PostgreSQL-re épül, amely vitathatatlanul a legjobb nyílt forráskódú relációs adatbázis létezik. Ha a projekt már fut PostgreSQL, akkor a Timescale jobbra becsúszik.
  • A lekérdezés az ismert SQL szintaxissal történik, csökkentve a tanulási görbét.
  • Nevetségesen gyors írási sebesség – másodpercenként több millió betét nem hallható.
  • Milliárd sor vagy petaitta adat – ez nem nagy ügy a Timescale számára.
  • Valódi rugalmasság a sémával – válasszon relációs vagy séma nélküli igényeinek megfelelően.

Nincs értelme beszélni arról, mikor kell használni vagy nem használni a Timescale DB-t. Ha az IoT az Ön domainje, vagy hasonló adatbázisjellemzőket követ, akkor érdemes megnézni a Timescale-t.

CouchDB

CouchDB egy ügyes kis adatbázis-megoldás, amely csendesen ül egy sarokban, és egy kicsi, de dedikált követéssel rendelkezik. Úgy hozták létre, hogy foglalkozzon a hálózati veszteségek és az adatok esetleges megoldása problémáival, ami oly rendetlen probléma, hogy a fejlesztők inkább a munkát váltják, mint kezelik.

Alapvetően egy CouchDB-fürtre gondolhat, mint a nagy és kicsi csomópontok elosztott gyűjteményére, amelyek közül néhány várhatóan offline is. Amint egy csomópont csatlakozik az internethez, visszajuttatja az adatokat a klaszterhez, amelyet lassan és óvatosan emészt fel, és végül az egész klaszter számára elérhetővé válik..

Egyedi tulajdonságok

A CouchDB az adatbázisok szempontjából egyedülálló fajta.

  • Offline-első adatszinkronizálási képességek
  • Specializált verziók mobil és böngészőkhöz (PouchDB, CouchDB Lite, stb.)
  • Ütésálló, csata-tesztelt megbízhatóság
  • Könnyű fürtözés redundáns adattárolással

Mikor kell használni a CouchDB-t

A CouchDB az offline tolerancia érdekében lett kifejlesztve, és ebben a tekintetben páratlan marad. Egy tipikus felhasználási eset a mobilalkalmazások, amelyekben az adatok egy része a felhasználó telefonján található CouchDB példányon található (mert ott jött létre). Izgalmas dolog az, hogy nem támaszkodhat a felhasználói eszköz állandó csatlakoztatására, ami azt jelenti, hogy az adatbázisnak opportunistanak kell lennie, és készen kell állnia arra, hogy később megoldja az ütköző frissítéseket. Ez a lenyűgöző használatával érhető el Kanapé replikációs protokoll.

Mikor nem használja a CouchDB-t

A CouchDB rendeltetésszerű használaton kívüli használatának megkísérlése katasztrófához vezet. Sokkal több tárolót használ, mint bármi más odakinn, egyszerűen azért, mert az adatok redundáns példányait és a konfliktuskezelési eredményeket meg kell őriznie. Ennek eredményeként az írási sebesség is fájdalmasan lassú. Végül, a CouchDB nem alkalmas általános célú sémamotorra, mivel nem játszik jól a sémaváltozásokkal.

Következtetés

Sok érdekes jelöltet el kellett hagynom, mint például Riak, tehát ezt a listát inkább útmutatónak, mint parancsolatnak kell tekinteni. Remélem, hogy sikerült elérni a célomat ezzel a cikkel – nemcsak az adatbázis-ajánlások gyűjteményét mutatom be, hanem röviden megvitatom, hogy hol és hogyan kell ezeket felhasználni (és elkerülni!).

Ha kíváncsi az adatbázis megismerésére, akkor nézd meg Udemy néhány ragyogó online tanfolyamhoz.

CÍMKÉK:

  • adatbázis

  • Nyílt forráskód

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map