Топ 13: Базы Данных с Открытым Исходным Кодом. Open Source DB 2024

Данные — это все. А значит, и базы данных. Вот несколько фантастических вариантов с открытым исходным кодом для вашего следующего крутого проекта.

В мире, где долгое время доминировали базы данных Oracle и SQL Server, сейчас, кажется, существует бесконечный шквал решений. Одной из причин этого являются инновации, подпитываемые Open Source — действительно талантливые разработчики, желающие почесать зуд и создать что-то, чем они могут наслаждаться.

Другая часть — появление новых бизнес-моделей, в рамках которых компании поддерживают версию своего продукта для сообщества, чтобы завоевать популярность, а также предоставляют коммерческое дополнительное предложение.

Результат?

Больше баз данных, чем можно успеть. Официальной статистики по этому поводу нет, но я уверен — пишет Ankush Thakur¹, что сегодня у нас есть более сотни вариантов, если объединить все, начиная от объектных баз данных, специфичных для стека, и заканчивая не слишком популярными проектами университетов.

Я знаю; меня это тоже пугает. Слишком много вариантов — слишком много документации, которую нужно изучить — и такая короткая жизнь 🙂

Именно поэтому я решил написать эту статью, в которой представил десять лучших баз данных, которые вы можете использовать для улучшения своих решений, будь то разработка для себя или для других.

Без MySQL

Обратите внимание: в этом списке не будет MySQL, несмотря на то, что это, пожалуй, самая популярная база данных с открытым исходным кодом.

Почему?

Просто потому, что MySQL есть везде — это то, что все изучают в первую очередь, его поддерживают практически все CMS и фреймворки, и он очень, очень хорош для большинства случаев использования. Другими словами, MySQL не нужно «открывать» 🙂

Учитывая это, обратите внимание, что нижеприведенные варианты не обязательно являются альтернативой MySQL. В некоторых случаях они могут быть таковыми, а в других — это совершенно другое решение для совершенно других нужд. Не волнуйтесь, поскольку я буду обсуждать и их применение.

Особое замечание: совместимость

Прежде чем мы начнем, я также должен упомянуть, что совместимость — это то, о чем вы должны помнить. Если ваш проект по каким-то причинам поддерживает только определенный движок базы данных, то ваш выбор практически исчерпан.

Например, если вы используете WordPress, эта статья вам не пригодится 🙂 Аналогично, те, кто работает со статическими сайтами на JAMStack, ничего не выиграют, если будут слишком серьезно искать альтернативы.

Уравнение совместимости зависит только от вас. Однако если у вас чистый лист и архитектура зависит от вас, вот несколько хороших рекомендаций.

PostgreSQL

CREATE TABLE users (id SERIAL PRIMARY KEY, name VARCHAR(255));
INSERT INTO users (name) VALUES ('John Rush');
SELECT * FROM users;

Если вы родом из страны 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. Если вы решите сделать то же самое, вы не прогадаете.

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

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

PostgreSQL не имеет смысла использовать, если ваша модель данных не является реляционной и/или если у вас очень специфические архитектурные требования. Например, возьмем аналитику, где постоянно создаются новые отчеты на основе существующих данных. Такие системы требовательны к чтению и страдают, когда им навязывают строгую схему. Конечно, в PostgreSQL есть механизм хранения документов, но все начинает рушиться, когда вы имеете дело с большими массивами данных.

Другими словами, всегда используйте PostgreSQL, если вы не знаете на 100%, что делаете! 🙂

Ознакомьтесь с курсом «SQL и PostgreSQL для начинающих «, если хотите узнать больше.

MariaDB

CREATE TABLE users (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(255));
INSERT INTO users (name) VALUES ('John Rush');
SELECT * FROM users;

MariaDB была создана как замена MySQL тем же человеком, который разработал MySQL.

Сбиты с толку?

На самом деле, после того как в 2010 году MySQL была поглощена компанией Oracle (путем приобретения 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

Если вам нужна настоящая замена MySQL, вам следует использовать MariaDB, так как они хотят оставаться на кривой инноваций и не планируют возвращаться к MySQL снова. Одним из отличных вариантов использования является применение новых движков хранения данных в MariaDB для дополнения существующей реляционной модели данных вашего проекта.

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

Совместимость с MySQL — единственная причина для беспокойства. Тем не менее, это становится все меньшей проблемой, поскольку такие проекты, как WordPress, Joomla, Magento и т. д., начали поддерживать MariaDB. Я бы посоветовал не использовать MariaDB для CMS, которая ее не поддерживает, так как многие трюки, связанные с базой данных, легко приведут к краху системы.

Ознакомьтесь с разницей между MariaDB и MySQL и руководством по установке MariaDB.

CockroachDB

CREATE TABLE users (id UUID DEFAULT gen_random_uuid() PRIMARY KEY, name STRING);
INSERT INTO users (name) VALUES ('John Rush');
SELECT * FROM users;

Команда, создавшая CockroachDB, похоже, состоит из мазохистов. С таким названием продукта они, конечно, хотят обратить все шансы против себя и все равно победить?

Ну, не совсем так.

Идея «таракана» заключается в том, что это насекомое, созданное для выживания. Что бы ни случилось — хищники, наводнения, вечная темнота, гниющая пища, бомбардировки, — таракан находит способ выжить и размножиться.

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

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

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

CockroachDB — это воплощение мечты системного архитектора. Если вы клянетесь SQL и с замиранием сердца следите за возможностями масштабирования MongoDB, вам понравится CockroachDB. Теперь вы можете быстро создать кластер, закидать его запросами и спокойно спать по ночам 🙂

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

Лучше дьявол, которого ты знаешь, чем тот, которого ты не знаешь. Под этим я подразумеваю, что если ваша существующая СУБД работает хорошо и вы думаете, что сможете справиться с проблемами масштабирования, которые она принесет, оставайтесь с ней. CockroachDB — это новый продукт для всех гениев, и вы не захотите потом бороться с ним. Другой важной причиной является совместимость с SQL — если вы занимаетесь экзотическим SQL и полагаетесь на него в критически важных вещах, CockroachDB будет представлять слишком много крайних случаев, чтобы вам понравиться.

Впредь мы будем рассматривать не-SQL (или NoSQL, как его еще называют) базы данных для узкоспециализированных нужд.

ClickHouse

CREATE TABLE columns_transformers (i Int64, j Int16, k Int64) ENGINE = MergeTree ORDER by (i);
INSERT INTO columns_transformers VALUES (100, 10, 324), (120, 8, 23);
SELECT * APPLY(sum) FROM columns_transformers;

Ищете быструю OLAP-систему баз данных с открытым исходным кодом?

Выбирайте ClickHouse.

Она использует все аппаратные средства по максимуму, чтобы быстрее выполнять каждый запрос. Пиковая производительность обработки запроса обычно составляет более двух терабайт в секунду. Чтобы избежать увеличения задержек, чтение автоматически балансируется между здоровыми репликами.

Поддерживается многомастерная асинхронная репликация, и ее можно развернуть в разных центрах обработки данных. Поскольку узлы поддерживаются одинаковыми, вы можете избежать даже единичных точек отказа. Простои как одного узла, так и всего центра обработки данных никогда не повлияют на доступность системы в плане записи и чтения.

ClickHouse очень прост и удобен в использовании. Она упрощает обработку данных, упорядочивает все данные в системе и мгновенно предоставляет их для создания отчетов. Более того, диалект SQL помогает выразить результат без использования нестандартных API, которые вы можете получить в альтернативных системах.

Вы можете положиться на эту систему управления базами данных и настроить ее как распределенную систему, расположенную на отдельных узлах без точек отказа. Кроме того, в ней реализованы надежные функции безопасности, включая защиту корпоративного уровня и механизмы отказоустойчивости на случай человеческих ошибок.

ClickHouse может обрабатывать запросы быстрее по сравнению с системами, ориентированными на работу со строками, при одинаковой мощности процессора и пропускной способности ввода-вывода. Столбцовый формат хранения данных позволяет хранить больше данных в оперативной памяти, что приводит к сокращению времени отклика.

Совокупная стоимость владения может быть снижена за счет того, что в товарном оборудовании используются вращающиеся дисковые накопители, а не NVMe/SSD без ущерба для латентности запросов. Она стремится к эффективности процессора, оптимизирует доступ к дисковому накопителю и минимизирует передачу данных.

Кроме того, благодаря многофункциональной базе данных SQL вы можете эффективно обрабатывать запросы в кратчайшие сроки, объединять расположенные и распределенные данные, эффективно управлять денормализованной информацией и многое другое. ClickHouse масштабируется по горизонтали и вертикали и легко адаптируется для работы как на одном сервере, так и в кластерах с тысячами узлов.

Используйте ClickHouse для аналитики веб-сайтов и приложений, телекоммуникаций, рекламных сетей, онлайн-игр, IoT, бизнес-аналитики, финансов, электронной коммерции, мониторинга и многого другого.

Он интегрируется с Hadoop, Postgres и MySQL.

Если вы не готовы устанавливать и настраивать сервер, можете попробовать Kamatera, которая предлагает ClickHouse одним кликом.

Neo4j

CREATE (john:User {name: "John Rush"});
MATCH (user:User) RETURN user;

Одним из самых значительных событий последнего десятилетия стали связанные данные. Мир вокруг нас не разделен на таблицы, строки и ячейки — это один гигантский беспорядок, в котором все связано почти со всем остальным.

Социальные сети — яркий тому пример, и построение подобной модели данных с помощью SQL или даже баз данных на основе документов — сущий кошмар.

Все потому, что идеальная структура данных для таких решений — это граф, который представляет собой совершенно другого зверя. И для этого вам нужна база данных графов, такая как Neo4j.

Пример выше взят непосредственно с сайта Neo4j и показывает, как студенты университета связаны со своими факультетами и курсами. Такая модель данных просто невозможна на SQL, так как будет сложно избежать бесконечных циклов и перерасхода памяти.

Уникальные возможности

Графовые базы данных уникальны сами по себе, а Neo4j — практически единственный вариант для работы с графами. Поэтому все ее возможности уникальны 🙂

• Поддержка транзакционных приложений и графовой аналитики.
• Возможность трансформации данных для преобразования больших табличных данных в графы.
• Специализированный язык запросов (Cypher) для работы с базой данных графов
• Функции визуализации и обнаружения

Обсуждать, когда стоит использовать Neo4j, а когда нет, не имеет смысла. Если вам нужны отношения между данными, основанные на графах, вам нужен Neo4j. 🙂

MongoDB

// Connect to MongoDB and insert a document
const { MongoClient } = require("mongodb");
const uri = "mongodb://localhost:27017";
const client = new MongoClient(uri);
await client.connect();
const db = client.db("mydb");
await db.collection("users").insertOne({ name: "John Rush" });

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

В отличие от реляционных баз данных, MongoDB — это «база данных документов», которая хранит данные в виде фрагментов, причем связанные данные объединяются в один фрагмент. Лучше всего это можно понять, представив себе совокупность структур JSON, как здесь:

Здесь, в отличие от структуры на основе таблиц, контактные данные пользователя и уровни доступа находятся в одном объекте. Получение объекта пользователя автоматически извлекает связанные с ним данные, и здесь нет концепции объединения. Вот более подробное введение в MongoDB.

Уникальные возможности

У MongoDB есть несколько серьезных (хочется написать «офигенных», чтобы передать эффект, но на публичном сайте это было бы неуместно) особенностей, которые заставили нескольких опытных архитекторов навсегда отказаться от реляционной земли:

• Гибкая схема для специализированных/непредсказуемых случаев использования.
• Невероятно простые шардинг и кластеризация. Вам нужно только задать конфигурацию кластера и забыть о нем.
• Добавить или удалить узел из кластера очень просто.
• Распределенные транзакционные блокировки. Эта функция отсутствовала в ранних версиях, но со временем была добавлена.
• Она оптимизирована для очень быстрой записи, что делает ее очень подходящей для аналитических данных в качестве системы кэширования.

Если я выгляжу как представитель MongoDB, прошу прощения, но преимущества MongoDB трудно переоценить. Конечно, поначалу NoSQL-моделирование данных выглядит странно, и некоторые так и не могут освоить его, но для многих архитекторов оно почти всегда выигрывает по сравнению со схемой на основе таблиц.

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

MongoDB — это отличный переходный мостик от структурированного, строгого мира SQL к аморфному, почти непонятному миру NoSQL. Она отлично подходит для разработки прототипов, поскольку здесь просто нет схемы, о которой нужно беспокоиться, и когда вам действительно нужно масштабирование. Да, вы можете использовать облачный SQL-сервис, чтобы избавиться от проблем с масштабированием БД, но это очень дорого!

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

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

Полное отсутствие схемы, которую предоставляет MongoDB, может стать ямой с дегтем для тех, кто не знает, что делает. Несоответствие данных, мертвые данные, пустые поля, которые не должны быть пустыми — все это и многое другое возможно. MongoDB — это, по сути, «тупое» хранилище данных, и если вы выберете его, то код приложения должен будет взять на себя большую ответственность за поддержание целостности данных.

Если вы разработчик, то вам это будет полезно.

RethinkDB

r.table('games').changes().run(conn, function(err, cursor) {
  cursor.each(console.log);
});

Как следует из названия, RethinkDB «переосмысливает» идею и возможности базы данных, когда речь идет о приложениях реального времени.

Когда база данных обновляется, приложение никак не может об этом узнать. Принятый подход заключается в том, что приложение отправляет уведомление, как только происходит обновление, которое передается на фронтенд через сложный мост (PHP -> Redis -> Node -> Socket.io — один из примеров).

Но что, если бы обновления можно было передавать непосредственно из базы данных во фронтенд?!

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

Redis

import redis
r = redis.Redis(host="localhost", port=6379)
r.set("name", "John Rush")
print(r.get("name"))

Когда речь заходит о базах данных, слишком легко упустить из виду существование Redis. Это потому, что Redis — база данных in-memory и используется в основном для поддержки функций, таких как кэширование.

Изучение этой базы данных — дело десяти минут (буквально!), и это простое хранилище ключевых значений, в котором хранятся строки со временем истечения (которое, конечно же, можно установить на бесконечность). То, что Redis теряет в возможностях, он компенсирует в удобстве и производительности. Поскольку он полностью живет в оперативной памяти, чтение и запись выполняются безумно быстро (несколько сотен тысяч операций в секунду — не редкость).

Redis также имеет развитую систему pub-sub, что делает эту «базу данных» вдвойне привлекательной.

Другими словами, если у вас есть проект, который может выиграть от кэширования или имеет некоторые распределенные компоненты, Redis — это первый выбор.

SQLite

CREATE INDEX index_name
ON table_name ( column_name COLLATE NOCASE );

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

SQLite — это легковесная библиотека на языке C, предоставляющая механизм хранения реляционных баз данных. Все данные в этой базе хранятся в одном файле (с расширением .sqlite), который вы можете поместить в любое место в вашей файловой системе. И это все, что вам нужно для ее использования! Да, не нужно устанавливать «серверное» программное обеспечение и подключаться к сервисам.

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

Несмотря на то, что SQLite — это легкая альтернатива базам данных типа MySQL, он обладает достаточно мощным потенциалом. Вот некоторые из его потрясающих возможностей:

• Полная поддержка транзакций, с COMMIT, ROLLBACK и BEGIN.
• Поддержка 32 000 столбцов в одной таблице
• Поддержка JSON
• поддержка 64-сторонних JOIN
• Подзапросы, полнотекстовый поиск и т. д.
• Максимальный размер базы данных — 140 терабайт!
• Максимальный размер строки — 1 гигабайт!
• на 35 % быстрее файлового ввода-вывода

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

SQLite — это чрезвычайно специализированная база данных, которая ориентирована на несерьезный подход к работе. Если ваше приложение относительно простое и вам не нужны хлопоты, связанные с полноценной базой данных, SQLite — серьезный кандидат. Это особенно важно для небольших и средних CMS и демонстрационных приложений.

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

Хотя SQLite и впечатляет, он не охватывает всех возможностей стандартного SQL или вашего любимого движка баз данных. Кластеризация, хранимые процедуры и скриптовые расширения отсутствуют. Кроме того, нет клиента для подключения, запроса и изучения базы данных. Наконец, с ростом размера приложения производительность будет падать.

Cassandra

CREATE TYPE student.basic_info (
  birthday timestamp,
  race text,
  weight text,
  height text
);

Хотя многие заявляют, что конец Java близок, время от времени сообщество бросает бомбу и заставляет критиков замолчать. Одним из таких примеров является Cassandra.

Cassandra принадлежит к так называемому «столбцовому» семейству баз данных. Абстракция хранения данных в Cassandra — это столбец, а не строка. Идея заключается в том, чтобы хранить все данные в столбце физически вместе на диске, минимизируя время поиска.

Уникальные возможности

Cassandra была разработана с учетом специфики использования — работа с большими нагрузками на запись и нетерпимость к простоям. Это стало ее уникальными преимуществами.

• Чрезвычайно высокая производительность записи. Cassandra является, пожалуй, самой быстрой базой данных, когда речь идет о работе с большими нагрузками на запись.
• Линейная масштабируемость. То есть вы можете добавлять в кластер столько узлов, сколько захотите, и при этом сложность или хрупкость кластера не увеличится.
• Непревзойденная устойчивость к разделениям. То есть даже если несколько узлов в кластере Cassandra выйдут из строя, база данных будет работать без потери целостности.
• Статическая типизация

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

Логирование и аналитика — два лучших варианта использования Cassandra. Но это еще не все — «сладкая точка» — это когда вам нужно обрабатывать действительно большие объемы данных (в Apple развернута Cassandra, обрабатывающая 400 петабайт данных, а в Netflix — 1 триллион запросов в день) буквально без простоев. Высокая доступность — одна из отличительных черт Cassandra.

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

Колоночная схема хранения данных в Cassandra также имеет свои недостатки. Модель данных довольно плоская, и если вам нужны агрегаты, то Cassandra не подходит. Кроме того, она достигает высокой доступности, жертвуя согласованностью (вспомните теорему CAP для распределенных систем), что делает ее менее подходящей для систем, где требуется высокая точность чтения.

Timescale

SELECT * FROM stocks_real_time srt
WHERE symbol='TSLA' and day_volume is not null

Новые разработки требуют новых типов баз данных, и Интернет вещей (IoT) — одно из таких явлений. Одной из лучших баз данных с открытым исходным кодом для этого является Timescale.

Timescale — это так называемая база данных временных рядов. Она отличается от традиционных баз данных тем, что время является основной осью, а аналитика и визуализация огромных массивов данных — главным приоритетом. Базы данных временных рядов редко видят изменения в существующих данных; примером могут служить показания температуры, передаваемые датчиком в теплице — каждую секунду накапливаются новые данные, которые представляют интерес для аналитики и отчетности.

Почему же тогда не использовать только традиционную базу данных с полем временной метки? На это есть две основные причины:

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

Уникальные возможности

У Timescale DB есть несколько интересных особенностей, которые отличают ее от других баз данных в той же категории:

• Она построена на PostgreSQL, пожалуй, лучшей реляционной базе данных с открытым исходным кодом. Если в вашем проекте уже используется PostgreSQL, то Timescale сразу же впишется в него.
• Запросы выполняются с помощью знакомого синтаксиса SQL, что сокращает время обучения.
• Невероятно высокая скорость записи — миллионы вставок в секунду не являются чем-то неслыханным.
• Миллиарды строк или петабайты данных — для Timescale это не проблема.
• Настоящая гибкость схемы — выбирайте реляционную или бессхемную в зависимости от ваших потребностей.

Нет особого смысла говорить о том, когда стоит или не стоит использовать Timescale DB. Если ваша сфера деятельности — IoT, или вам нужны похожие характеристики баз данных, Timescale стоит посмотреть.

CouchDB

export CHANNEL_NAME=mychannel
peer chaincode query -C $CHANNEL_NAME -n marbles -c '{"Args":["queryMarbles", "{\"selector\":{\"docType\":\"marble\",\"owner\":\"tom\"}, \"use_index\":[\"indexOwnerDoc\", \"indexOwner\"]}"]}'

CouchDB — это маленькая аккуратная база данных, которая тихо сидит в углу и имеет небольшую, но преданную аудиторию. Оно было создано для решения проблем, связанных с потерей сети и последующим восстановлением данных, причем эта проблема настолько запутанная, что разработчики скорее сменят работу, чем займутся ее решением.

По сути, кластер CouchDB можно представить как распределенную коллекцию больших и малых узлов, некоторые из которых, как ожидается, будут находиться в автономном режиме. Как только узел подключается к сети, он отправляет данные обратно в кластер, которые медленно и тщательно перевариваются и в итоге становятся доступны всему кластеру.

Уникальные возможности

CouchDB — это нечто уникальное, когда речь идет о базах данных.

• Возможность синхронизации данных в автономном режиме
• Специализированные версии для мобильных устройств и веб-браузеров (PouchDB, CouchDB Lite и т. д.)
• Устойчивость к сбоям, надежность, проверенная в боях
• Простая кластеризация с резервным хранением данных

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

CouchDB был создан для автономной работы и остается непревзойденным в этом отношении. Типичный пример использования — мобильные приложения, где часть данных хранится в экземпляре CouchDB на телефоне пользователя (потому что именно там они и были сгенерированы). Самое интересное, что вы не можете полагаться на то, что устройство пользователя будет постоянно подключено, а значит, база данных должна быть оппортунистической и готовой разрешить конфликтующие обновления позже. Это достигается с помощью впечатляющего протокола Couch Replication Protocol.

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

Попытка использовать CouchDB не по назначению приведет к катастрофе. Она использует гораздо больше памяти, чем все остальные, просто потому, что ей необходимо поддерживать избыточные копии данных и результатов разрешения конфликтов. В результате скорость записи также оказывается мучительно низкой. Наконец, CouchDB не подходит для использования в качестве универсального движка схем, поскольку плохо справляется с изменением схем.

FerretDB

db.league.insertOne({
  club: 'PSG',
  points: 30,
  average_age: 30,
  discipline: { red: 5, yellow: 30 },
  qualified: false
})

FerretDB — это инновационная платформа с открытым исходным кодом, построенная на Postgres в качестве альтернативы MongoDB. MongoDB — самая простая в использовании и хорошо поддерживаемая база данных, позволяющая разработчикам создавать приложения быстрее, чем реляционные базы данных.

Однако MongoDB отказалась от своих корней Open-Source, изменив лицензию Server-Side Public License и сделав ее непригодной для многих Open Source и коммерческих проектов; именно здесь на помощь приходит FerretDB. С помощью FerretDB пользователи могут выполнять те же запросы по протоколу MongoDB, не изучая новый язык или команды.

FerretDB — это база данных документов с открытым исходным кодом, в которую встроена совместимость с MongoDB и которая позволяет PostgreSQL и другим бэкэндам баз данных выполнять рабочие нагрузки MongoDB; это позволяет вам использовать существующий синтаксис и команды MongoDB с вашей базой данных, хранящейся в PostgreSQL.

PostgreSQL, на которой построена FerretDB, — это надежная система управления реляционными базами данных (RDMS) с открытым исходным кодом. Это недорогой вариант для создания масштабируемых баз данных корпоративного уровня. PostgreSQL обладает всеми возможностями и функциями, которые необходимы реляционной базе данных. Она хранит данные в виде структурированных объектов со строками и столбцами, что идеально подходит для массивных сложных поисков и транзакций.

FerretDB — это база данных документов, которая использует для хранения данных команды, драйверы и инструменты, аналогичные MongoDB.

В отличие от реляционных баз данных, которые определяют структуру базы данных с помощью таблиц, строк и столбцов, FerretDB сохраняет информацию в виде JSON-документов, что позволяет легко интегрировать ее в современные онлайн и мобильные приложения.

Способность FerretDB быстро и эффективно искать информацию в огромных базах данных — одна из ее самых выдающихся характеристик. Кроме того, платформа отличается высокой адаптивностью, что позволяет подстраивать ее под нужды вашей организации.

Это потрясающее решение для работы с базами данных как для профессионалов, так и для новичков. Это полностью децентрализованная система поиска приложений на основе блокчейна.

Ferretdb — это надежный инструмент администрирования баз данных, который позволяет разработчикам и администраторам баз данных искать, тестировать и развертывать код.

Заключение

Мне пришлось опустить много интересных кандидатов, таких как Riak, поэтому этот список следует воспринимать как руководство, а не как заповедь. Надеюсь, мне удалось достичь своей цели в этой статье — представить не просто подборку рекомендаций по программному обеспечению для баз данных, но и кратко обсудить, где и как их нужно использовать (и избегать!).

1. Переведено по материалам Ankush Thakur ↩︎