Данните са всичко. И като разширение, така са и базите данни. Ето няколко фантастични варианта с отворен код за следващия ви проект за ритъм.

За свят, доминиран толкова дълго от костюми на бази данни като Oracle и SQL Server, изглежда, че има безкраен шум от решения сега. Една от причините е иновациите, подхранвани от Open Source – наистина талантливи разработчици, които искат да надраскат сърбежа и да създадат нещо, от което могат да се насладят.

Другата част е появата на нови бизнес модели, при които предприятията поддържат общностна версия на своя продукт, за да спечелят ум и дял и сцепление, като същевременно осигуряват и комерсиално предложение за добавки.

Резултатът?

Повече бази данни, отколкото една може да бъде в крак. Няма официална статистика по този въпрос, но почти съм сигурен, че днес имаме на разположение над сто опции, ако комбинирате всичко – от специфични за стека бази данни до не толкова популярни проекти от университети.

Знам, че и мен ме плаши. Твърде много опции – твърде много документация, за да преминете – и живот, който е толкова кратък. ��

Ето защо реших да напиша тази статия, представяйки десет от най-добрите бази данни, които можете да използвате за подобряване на вашите решения, независимо дали изграждате за себе си или за другите.

Няма MySQL

Моля, обърнете внимание: този списък няма да съдържа MySQL, въпреки че е вероятно най-популярното решение за база данни с отворен код.

Защо? Просто защото MySQL е навсякъде – това е, което всички учат първо, той се поддържа от почти всеки CMS или рамка там и е много, много добър за повечето случаи на използване. С други думи, MySQL не е необходимо да бъде „открит“. ��

Имайки предвид това, моля, имайте предвид, че следните не са непременно алтернативи на MySQL. В някои случаи те могат да бъдат, докато в други те са съвсем различно решение за съвсем различна нужда. Не се притеснявайте, тъй като и аз ще обсъждам техните приложения.

Специална забележка: съвместимост

Преди да започнем, трябва също да спомена, че съвместимостта е нещо, което трябва да имате предвид. Ако имате проект, който по някаква причина поддържа само определен двигател на базата данни, вашите избори са доста успешни.

Например, ако използвате WordPress, тази статия не ви е от полза. �� По подобен начин онези, които изпълняват статични сайтове в JAMStack, няма да спечелят нищо, като търсят алтернативи твърде сериозно.

От вас зависи да разберете уравнението за съвместимост. Ако обаче имате празен лист и архитектурата зависи от вас, ето няколко спретнати препоръки.

PostgreSQL

Ако сте от земята на PHP (WordPress, Magento, Drupal и т.н.), тогава PostgreSQL ще ви звучи чуждо. Това релационно решение за база данни обаче съществува от 1997 г. и е най-добрият избор в общности като Ruby, Python, Go и т.н..

Всъщност много разработчици в крайна сметка „завършват“ към PostgreSQL за функциите, които предлага, или просто за стабилността. Трудно е да убедите някого в кратко писане като това, но помислете за PostgreSQL като замислен продукт, който никога не ви изпуска.

Има много добри SQL клиенти на разположение за свързване към PostgreSQL база данни за администриране и развитие.

Уникални черти

PostgreSQL има няколко завладяващи функции в сравнение с други релационни бази данни (по-специално MySQL), като например:

  • Вградени типове данни за масив, обхват, UUID, геолокация и т.н..
  • Поддържана поддръжка за съхранение на документи (стил JSON), XML и съхранение на ключови стойности (Hstore)
  • Синхронна и асинхронна репликация
  • Писане на сценарии в PL, Perl, Python и др
  • Цялостно търсене

Моите лични фаворити са двигателят за геолокация (който отнема болката при работа с приложения, базирани на местоположението – опитайте се да намерите всички точки наблизо ръчно и ще разберете какво имам предвид) и поддръжка за масиви (много MySQL проекти са отменени поради желание от масиви, избирайки вместо скандалните низове, разделени със запетая).

Кога да използвате PostgreSQL

PostgreSQL винаги е по-добър избор спрямо всеки друг двигател на релационни бази данни. Тоест, ако стартирате нов проект и сте били ухапан от MySQL преди, е подходящ момент да помислите за PostgreSQL. Имам приятели, които се отказаха от борбата със загадъчните грешки на заключването на MySQL и продължиха постоянно. Ако решите същото, няма да прекалявате.

PostgreSQL също има явно предимство, ако се нуждаете от частични съоръжения NoSQL за хибриден модел на данни. Тъй като съхраняването на документи и ключ-стойност се поддържа от самото начало, не е нужно да ходят на лов, инсталиране, обучение и поддържане на друго решение за база данни.

Кога да не използвате PostgreSQL

PostgreSQL няма смисъл, когато моделът на данните ви не е релационен и / или когато имате много специфични архитектурни изисквания. Например, помислете за Анализ, където постоянно се създават нови отчети от съществуващи данни. Такива системи са тежки за четене и страдат, когато им се наложи строга схема. Разбира се, PostgreSQL има механизъм за съхранение на документи, но нещата започват да се разпадат, когато имате работа с големи набори от данни.

С други думи, винаги използвайте PostgreSQL, освен ако не знаете на 100% какво правите! ��

Вижте това SQL & Курс PostgreSQL за начинаещи ако се интересувате да научите повече.

MariaDB

MariaDB е създаден като заместител на MySQL от същия човек, който е разработил MySQL.

Объркани?

Е, всъщност, след като MySQL беше поет от Oracle през 2010 г. (чрез придобиване на Sun Microsystems, което между другото също е начинът, по който Oracle дойде да контролира Java), създателят на MySQL започна нов проект с отворен код, наречен MariaDB.

Защо питате цялата тази скучна подробност? Това е така, защото MariaDB е създаден от същата кодова база като тази на MySQL (в света с отворен код това е известно като „разклоняване“ на съществуващ проект). В резултат MariaDB се представя като „заместващ“ заместител на MySQL.

Тоест, ако използвате MySQL и искате да преминете към MariaDB, процесът е толкова лесен, че просто няма да повярвате.

За съжаление подобна миграция е еднопосочна улица. Връщане от MariaDB към MySQL не е възможно и ако се опитате да използвате сила, се гарантира постоянна повреда в базата данни!

Уникални черти

Въпреки че MariaDB по същество е клон на MySQL, това не е абсолютно вярно. От въвеждането на базата данни разликите между тях нарастват. Докато пишете, приемането на MariaDB трябва да бъде добре обмислено решение от ваша страна. Въпреки това в MariaDB се случват много нови неща, които може да ви помогнат да направите този преход:

  • Наистина свободен и отворен: Тъй като няма нито едно юридическо лице, което да контролира MariaDB, можете да бъдете свободни от внезапно хищническо лицензиране и други притеснения.
  • Още няколко варианта на двигатели за съхранение за специализирани нужди: например двигателят Spider за разпределени транзакции; ColumnStore за масивно съхранение на данни; двигателят ColumnStore за успоредно разпределено съхранение; и много, много други.
  • Подобрения на скоростта над MySQL, особено благодарение на механизма за съхранение на Aria за сложни заявки.
  • Динамични колони за различни редове в таблица.
  • По-добри възможности за репликация (например мулти-източник на репликация)
  • Няколко функции JSON
  • Виртуални колони

. . . И много, много повече. Изчерпателно е да сте в крак с всички функции на MariaDB. ��

Кога да използвате MariaDB

Трябва да MariaDB, ако искате истинска подмяна на MySQL, искате да останете на кривата на иновациите и да не планирате да се връщате отново към MySQL. Един отличен случай на използване е използването на нови двигатели за съхранение в MariaDB за допълване на съществуващия модел на релационни данни на вашия проект.

Кога да не използвате MariaDB

Съвместимостта с MySQL е единствената грижа тук. Това каза, че става все по-малък проблем, тъй като проекти като WordPress, Joomla, Magento и др. Започнаха да подкрепят MariaDB. Моят съвет би бил да не използвате MariaDB, за да измамите CMS, който не го поддържа, тъй като има много специфични трикове за базата данни, които лесно ще сринат системата.

CockroachDB

Екипът зад CockroachDB изглежда е съставен от мазохисти. С подобно име на продукт със сигурност искат да обърнат всички коефициенти срещу тях и все пак да спечелят?

Е, не съвсем.

Идеята зад „хлебарка“ е, че е насекомо, изградено за оцеляване. Без значение какво се случва – хищници, наводнения, вечен мрак, гниеща храна, бомбардировки, хлебарката намира начин да оцелее и да се размножи.

Идеята е, че екипът зад CockroachDB (съставен от бивши инженери на Google) беше разочарован от ограниченията на традиционните SQL решения, когато става дума за голям мащаб. Това е така, защото исторически SQL решенията трябваше да бъдат хоствани на една машина (данните не бяха толкова големи). Дълго време нямаше начин да се изгради клъстер от бази данни, работещ със SQL, поради което MongoDB привлече толкова много внимание.

Дори когато репликацията и клъстерирането излязоха в MySQL, PostgreSQL и MariaDB, в най-добрия случай беше болезнено. CoackroachDB иска да промени това, като внесе без усилие заточване, групиране и висока наличност в света на SQL.

Кога да използвате CockroachDB

CockroachDB е сбъдната мечта на системния архитект Ако се закълнете в SQL и сте ситуирали възможностите за мащабиране на MongoDB, ще харесате CockroachDB. Сега можете бързо да настроите клъстер, да хвърляте заявки към него и да спите спокойно през нощта. ��

Кога да не използвате CockroachDB

По-добре дявола, когото познаваш, отколкото този, който нямаш. Имам предвид, че ако съществуващите ви RDBMS работят добре за вас и смятате, че можете да управлявате мащабите, които носи, го придържайте. За всички участващи гении CockroachDB е нов продукт и не искате да се борите срещу него по-късно. Друга основна причина е съвместимостта с SQL – ако правите екзотични неща в SQL и разчитате на това за критични неща, CockroachDB ще представи твърде много крайни случаи за вашето харесване.

Отсега нататък ще разгледаме решения, които не са SQL (или NoSQL, както се нарича), бази данни за високоспециализирани нужди.

Neo4j

Едно от най-значимите развития през последното десетилетие е свързаните данни. Светът около нас не е разделен на таблици, редове и кутии – това е една гигантска бъркотия с всичко, свързано с почти всичко останало.

Социалните мрежи са отличен пример и изграждането на подобен модел на данни с помощта на SQL или дори базирани на документи бази данни е кошмар.

Това е така, защото идеалната структура на данни за тези решения е графиката, която е съвсем различен звяр. И за това се нуждаете от графична база данни като Neo4j.

Примерът по-горе е взет директно от уебсайта Neo4j и показва как студентите са свързани с техните катедри и курсове. Подобен модел на данни е невъзможен при SQL, тъй като ще бъде трудно да се избегнат безкрайни контури и превишаване на паметта.

Уникални черти

Графичните бази данни са уникални сами по себе си и Neo4j е почти единствената възможност за работа с графики. В резултат, каквито и функции да са уникални. ��

  • Поддръжка за транзакционни приложения и графична анализа.
  • Способности за преобразуване на данни за усвояване на мащабни таблични данни в графики.
  • Специализиран език за заявки (Cypher) за запитване към графичната база данни
  • Функции за визуализация и откриване

Спорно е да обсъждаме кога да използвате Neo4j, а кога не. Ако имате нужда от графично базирани взаимоотношения между вашите данни, имате нужда от Neo4j. ��

MongoDB

MongoDB беше първата нерелационна база данни, която направи големи вълни в технологичната индустрия и продължава да доминира справедлив дял от вниманието.

За разлика от релационните бази данни, MongoDB е „база данни с документи“, което означава, че съхранява данни на парчета, като свързаните данни се събират в един и същ парче. Това се разбира най-добре, като си представим съвкупност от JSON структури по този начин:

Тук, за разлика от структура на базата на таблица, данните за контакт и нивата на достъп на потребителя пребивават в един и същ обект. Извличането на потребителския обект автоматично извлича асоциираните данни и няма концепция за присъединяване. Ето и по-подробно запознаване с MongoDB.

Уникални черти

MongoDB има някои сериозни (почти искам да напиша „ритник“, за да предам въздействието, но това не би било правилно в публичен уебсайт, може би) функции, които накараха няколко опитни архитекти да изоставят релационната земя завинаги:

  • Гъвкава схема за специализирани / непредвидими случаи на използване.
  • Смешно просто заточване и групиране. Просто трябва да настроите конфигурацията за клъстер и да забравите за него.
  • Добавянето или премахването на възел от клъстер е просто безпроблемно.
  • Разпределени транзакционни брави. Тази функция липсваше в по-ранните версии, но в крайна сметка бе въведена.
  • Той е оптимизиран за много бързи записи, което го прави изключително подходящ за анализиране на данни като кешираща система.

Ако звуча като говорител на MongoDB, се извинявам, но е трудно да се препродават предимствата на MongoDB. Разбира се, моделирането на данни от NoSQL в началото е странно и някои никога не го хващат, но за много архитекти той почти винаги печели над схема, базирана на таблица..

Кога да използвате MongoDB

MongoDB е чудесен кръстосан мост от структурирания, строг свят на SQL до аморфния, почти объркващ един от NoSQL. Той се отличава при разработването на прототипи, тъй като просто няма схема, за която да се притеснявате и когато наистина трябва да мащабите. Да, можете да използвате облачна SQL услуга, за да се отървете от проблеми с мащабирането на DB, но момчето е скъпо!

И накрая, има случаи на използване, при които решения, базирани на SQL, просто няма да направят. Например, ако създавате продукт като Canva, където потребителят може да създава произволно сложни дизайни и да може да ги редактира по-късно, късмет с релационна база данни!

Кога да не използвате MongoDB

Пълната липса на схема, която MongoDB предоставя, може да работи като катран за тези, които не знаят какво правят. Несъответствие на данни, мъртви данни, празни полета, които не трябва да бъдат празни – всичко това и много повече е възможно. MongoDB по същество е „тъпо“ хранилище на данни и ако го изберете, кодът на приложението трябва да поеме голяма отговорност за поддържането на целостта на данните.

Ако сте разработчик, тогава ще намерите това полезно.

RethinkDB

Както върви името му, RethinkDB „Преосмисля“ идеята и възможностите на база данни, когато става въпрос за приложения в реално време.

Когато базата данни се актуализира, няма начин приложението да знае. Приетият подход е приложението да задейства известие веднага след като има актуализация, която се изтласква към предния край през сложен мост (PHP -> Redis -> възел -> Socket.io е един пример).

Но какво ще стане, ако актуализациите могат да бъдат избутани директно от базата данни към предния край?!

Да, това е обещанието на RethinkDB. Така че, ако искате да направите истинско приложение в реално време (игра, пазар, анализи и т.н.), Rethink DB си заслужава да разгледате.

Redis

Що се отнася до базите данни, почти прекалено лесно е да се пренебрегне съществуването на Redis. Това е така, защото Redis е база данни в паметта и се използва най-вече в функции за поддръжка като кеширане.

Учене на тази база данни е десетминутна работа (буквално!) и е обикновен магазин с ключови стойности, който съхранява низове с изтичане на времето (което, разбира се, може да бъде зададено до безкрайност). Какво Redis губи в функции, които компенсира в полезността и производителността. Тъй като живее изцяло в RAM, четенето и записването е безумно бързо (няколкостотин хиляди операции в секунда не са нечувани).

Redis също има сложен pub-подсистема, което прави тази „база данни“ два пъти по-привлекателна.

С други думи, ако имате проект, който би могъл да се възползва от кеширане или има някои разпределени компоненти, Redis е първият избор.

SQLite

Да, обещах, че приключихме с релационни бази данни, но SQLite е твърде сладък, за да игнорира.

SQLite е лека C библиотека, която предостави двигател за съхранение на релационни бази данни. Всичко в тази база данни живее в един файл (с разширение .sqlite), който можете да поставите навсякъде във вашата файлова система. И това е всичко, което трябва да го използвате! Да, няма „сървър“ софтуер за инсталиране и няма услуга, с която да се свържете.

Полезни функции

Въпреки, че SQLite е лека алтернатива на база данни като MySQL, той има доста голям удар. Някои от неговите шокиращи характеристики са:

  • Пълна поддръжка за транзакции с COMMIT, ROLLBACK и BEGIN.
  • Поддръжка за 32 000 колони на маса
  • Поддръжка на JSON
  • 64-посочна ПРИЛОЖЕНИЕ
  • Подзапроси, пълнотекстово търсене и т.н..
  • Максимален размер на базата данни от 140 терабайта!
  • Максимален размер на реда 1 гигабайт!
  • 35% по-бързо от входно-изходния файл

Кога да използвате SQLite

SQLite е изключително специализирана база данни, която се фокусира върху не-глупости, подхождайте към лайна. Ако приложението ви е сравнително просто и не искате да се притеснявате от пълноценна база данни, SQLite е сериозен кандидат. Това има особен смисъл за малки и средни CMS и демонстрационни приложения.

Кога да не използвате SQLite

Макар и впечатляващ, SQLite не покрива всички функции на стандартния SQL или любимия ви двигател на базата данни. Клъстериране, съхранени процедури и разширения за скриптове липсват. Освен това няма клиент, който да се свърже, да запитва и изследва базата данни. И накрая, с увеличаване на размера на приложението, производителността ще се влоши.

Касандра

Докато мнозина заявяват, че краят е близо до Java, всеки път от време на време общността пуска бомба и заглушава критиците. Касандра е един такъв пример.

Касандра принадлежи към това, което е известно като “колонна” фамилия от бази данни. Абстракцията за съхранение в Касандра е колона, а не ред. Идеята тук е да съхранявате всички данни в колона физически заедно на диска, като сведете до минимум търсенето на време.

Уникални черти

Касандра е проектиран с конкретен случай на употреба – имайки предвид натоварването с големи изпитвания и нулева толеранс за престой. Те се превръщат в неговите уникални търговски точки.

  • Изключително бързо изпълнение на запис. Касандра е може би най-бързата база данни там, когато става въпрос за обработка на големи натоварвания при запис.
  • Линейна мащабируемост. Тоест, можете да продължите да добавяте колкото се може повече възли към клъстер и ще има нулево увеличение на сложността или чупливостта на клъстера.
  • Несъвместим толеранс за разделяне. Тоест, дори ако множеството възли в клъстер Касандра намаляват, базата данни е проектирана така, че да продължава да работи без загуба на целостта.
  • Статично въвеждане

Кога да използвате Cassandra

Записването и анализа са два от най-добрите случаи за използване на Касандра. Но това не е всичко – сладкото място е, когато трябва да боравите с наистина големи размери на данни (Apple има разгръщане на Cassandra, обработващо 400+ петабайта данни, докато в Netflix обработва 1 трилион заявки на ден) с буквално нулев престой. Високата наличност е един от отличителните белези на Касандра.

Кога да не използвате Cassandra

Схемата за съхранение на колони на Касандра също има своите недостатъци. Моделът с данни е доста плосък и ако се нуждаете от обобщения, Касандра намалява. Нещо повече, той постига висока наличност чрез жертва на последователност (не забравяйте теоремата на ОСП за разпределените системи), което го прави по-малко подходящ за системи, където е необходима висока точност на четене.

времева

Новите разработки изискват нови видове бази данни, а Интернет на нещата (IoT) е едно такова явление. Една от най-добрите бази данни с отворен код за това е времева.

Времевата скала е вид база данни за „серия от време“. Тя е различна от традиционната база данни, тъй като това време е основната тема на загриженост, а анализирането и визуализирането на масивни масиви от данни е основен приоритет. Базите данни във времеви серии рядко виждат промяна в съществуващите данни; пример са показанията на температурата, изпращани от сензор в оранжерия – новите данни продължават да се натрупват всяка секунда, което представлява интерес за анализи и отчитане.

Защо тогава да не използвате само традиционна база данни с поле за отметка? Е, има две основни причини за това:

  • Базите данни с общо предназначение не са оптимизирани за работа с данни, базирани на времето. За същите количества данни базата данни с общо предназначение ще бъде много по-бавна.
  • Базата данни трябва да борави с големи количества данни, тъй като новите данни продължават да текат и премахват данни или променят схемата; по-късно, не е вариант.

Уникални черти

DB на Timescale има някои вълнуващи функции, които го отличават от други бази данни в същата категория:

  • Той е изграден на PostgreSQL, вероятно най-добрата релационна база данни с отворен код. Ако вашият проект вече работи с PostgreSQL, Времето ще се плъзне право.
  • Заявката се извършва чрез познатия SQL синтаксис, намалявайки кривата на обучение.
  • Смешно бързи скорости на запис – милиони вложки в секунда не се чуват.
  • Милиарди редове или петабайти данни – това не е голяма работа за Timescale.
  • Истинска гъвкавост при схема – изберете от релационни или без схеми според вашите нужди.

Няма смисъл да се говори за това кога да се използва или не се използва DB на Timescale. Ако IoT е вашият домейн или имате подобни характеристики на базата данни, Timescale си струва да разгледате.

CouchDB

CouchDB е спретнато малко решение за база данни, което седи тихо в ъгъла и има малко, но посветено следване. Той е създаден за справяне с проблемите на загубата на мрежа и евентуалното разрешаване на данни, което се оказва проблем, толкова разхвърлян, че разработчиците вместо това да превключват задачи, отколкото да се справят с него.

По същество можете да мислите за CouchDB клъстер като разпределена колекция от големи и малки възли, някои от които се очаква да са офлайн. Веднага след като възелът се появи онлайн, той изпраща данни обратно в клъстера, който бавно и внимателно се усвоява, в крайна сметка става достъпен за целия клъстер.

Уникални черти

CouchDB е нещо от уникалната порода, що се отнася до базите данни.

  • Офлайн възможности за синхронизиране на данни
  • Специализирани версии за мобилни и уеб браузъри (PouchDB, CouchDB Lite и др.)
  • Устойчивост на удар и надеждност, тествана в битки
  • Лесно групиране с излишно съхранение на данни

Кога да използвате CouchDB

CouchDB е създаден за офлайн толерантност и остава ненадминат в това отношение. Типичен случай на използване са мобилни приложения, при които част от вашите данни пребивава в CouchDB екземпляр на телефона на потребителя (защото там са генерирани). Вълнуващото е, че не можете да разчитате на устройството на потребителя да бъде свързано през цялото време, което означава, че базата данни трябва да е опортюнистична и да е готова да разрешава конфликтни актуализации по-късно. Това се постига с помощта на впечатляващото Протокол за репликация на дивана.

Кога да не използвате CouchDB

Опитът да се използва CouchDB извън предвидения случай, ще доведе до катастрофа. Той използва много повече място за съхранение от всичко друго, просто защото трябва да поддържа излишни копия на данни и резултати от разрешаване на конфликти. В резултат скоростите на запис също са болезнено бавни. И накрая, CouchDB не е подходящ като двигател с обща цел, тъй като не се справя добре с промените в схемата.

заключение

Трябваше да оставя много интересни кандидати като Риак, така че този списък трябва да се приема като ръководство, а не като заповед. Надявам се, че успях да постигна целта си с тази статия – да представя не само колекция от препоръки на базата данни, но и да обсъдим накратко къде и как те трябва да бъдат използвани (и избягвани!).

Ако сте любопитни да научите база данни, проверете Udemy за някои от брилянтните онлайн курсове.

ЕТИКЕТИ:

  • База данни

  • Отворен код

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me