Топ-5 встроенных баз данных для приложений JavaScript

Что происходит, когда RedShift, BigQuery и даже MySQL слишком велики для решения наших крошечных требований к данным? Что ж, как оказалось, для этого есть необходимые приложения. На самом деле существует множество вариантов, но здесь я собираюсь рассмотреть 5 лучших встроенных баз данных для ваших крошечных потребностей в данных.

Но что такое встроенная база данных?

Когда мы читаем слово «встроенный», 90% из нас приходят к выводу, что я говорю об IoT или мобильных устройствах. Но это не так.

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

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

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

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

LowDB

Начнем с простого, LowDB — это крошечная база данных в памяти. Это базовое решение, но оно предоставляет очень простой вариант использования: необходимость хранить и получать доступ к JSON-подобным структурам (т. е. документам) из проектов на основе JavaScript.

Одним из основных преимуществ LowDB является то, что она предназначена для использования из JavaScript, что означает: ее можно использовать как для серверной части, так и для рабочей станции и кода браузера.
На стороне бэкенда вы можете использовать его с Node.js, для настольных компьютеров он может быть интегрирован в проект Electron и, наконец, его также можно запускать непосредственно в браузере через интегрированную среду выполнения JS.

API, предоставляемый этой базой данных, также довольно упрощен и минимален, он не предоставляет никаких встроенных функций поиска. Он ограничивается загрузкой данных файла JSON в переменную массива и позволяет вам (пользователю) найти то, что вы ищете, так, как вы считаете нужным. Например, взгляните на следующий код:

JavaScript import { LowSync, JSONFileSync } from ‘lowdb’ const title = “This is a test” const adapter = new JSONFileSync(‘file.json’) const db = new LowSync(adapter) db.read() //Load the content of the file into memory db.data ||= { posts: [] } //default value db.data.posts.push({ title }) //add data into the “collection” db.write() //persist the data by saving it to the JSON file //any Find-like operation is left to the skill of the user let record = db.data.posts.find( p => p.title == “Hello world”) if(!record) { console.log(“No data found!”) } else { console.log(“== Record found ==”) console.log(record) }

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

Он обладает высокой расширяемостью и совместим с TypeScript, который обеспечивает схематическое поведение, для хранилища данных (т. е. Вам не разрешается добавлять данные, которые не соответствуют заранее установленной схеме).

LevelDB

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

У нее всего три основных операции: Put, Get и Delete, ничего больше, если задуматься — подобно LowDB.
И, как и LowDB, у этой базы данных нет клиент-серверной оболочки, что означает, что нет возможности общаться с ней с помощью любого языка. Вам придется использовать библиотеки C / C ++, и если вы хотите получить поведение, подобное серверу, вам придется обернуть его самостоятельно.

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

Архитектура хранилища базы данных основана на лог-структурированном дереве слияния (LSM), что означает, что она оптимизирована для больших операций последовательной записи вместо небольших случайных.

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

Интересно, что эта база данных используется в качестве серверной БД для IndexedDB Chrome, и, по-видимому, версия Minecraft Bedrock использует ее для хранения некоторых фрагментов и сущностей (хотя, судя по всему, они используют слегка измененную версию реализации Google).

Raima Database Manager

Я уже упоминал об IoT, не так ли? Что ж, Raima — один из самых быстрых менеджеров баз данных, специально оптимизированный для работы на устройствах с ограниченными ресурсами.

Что я имею в виду под средой с ограниченными ресурсами? Для работы Raima требуется всего 350 КБ ОЗУ. Вот что значит — минималистичное использование ресурсов.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

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

Кроме того, в отличие от LevelDB, Raima позволяет осуществлять многопроцессорный доступ к базе данных через архитектуру клиент-сервер (т. е. она позволяет отойти от исходного кода немного дальше, чем другие). А если вы решите использовать встроенное приложение, близкое к исходному, вы также можете использовать многопоточность для поддержки одновременного доступа к нескольким базам данных.

Гибкость Raima позволяет перейти от традиционного клиент-серверного подхода к наиболее эффективному (и, конечно, ограниченному) варианту использования одной базы данных в памяти, потребляемой одним клиентом. Это подходящий вариант использования для встроенных баз данных.

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

Apache Derby

Если вы ищете еще одну очень маленькую SQL-подобную базу данных, Apache Derby вполне может быть тем, что вы искали.

Derby полностью написан на JAVA, и утверждает, что занимает всего 3,5 Мбайт. Но, в конце концов, вы не можете запустить ее или использовать каким-либо образом, не установив JVM в хост-системе.

При этом, если ваш вариант использования допускает JVM, то замечательно, вы можете продолжать рассматривать Derby, в противном случае вы можете выбрать другие решения, такое как LevelDb или Raima.

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

Она поставляется со встроенным драйвером JDBC, поэтому нет необходимости в дополнительных зависимостях. Она может работать как во встроенном режиме внутри вашего JAVA-приложения, так и как автономный сервер, позволяя нескольким приложениям взаимодействовать с ним одновременно (аналогично тому, как это делает Raima, но без множества вариантов).

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

solidDB

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

По сути, как и другие решения, перечисленные здесь, к solidDB можно получить доступ через ODBC или JDBC, что позволяет приложениям JAVA и C взаимодействовать с ним через SQL. Также, как и некоторые из перечисленных здесь решений, solidDB можно развернуть в нескольких режимах:

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

Доступ к общей памяти. Очень интересный режим, потому что solidDB не только хранит данные в памяти (как и другие уже перечисленные решения), но также позволяет нескольким приложениям получать доступ к памяти (следовательно, к разделяемой части памяти ). Конечно, прямой доступ к этой разделяемой памяти должен осуществляться приложениями в одном узле, однако он также обеспечивает доступ на основе JDBC/ODBC к одним и тем же данным с внешних узлов. Превращает общую память в базу данных в памяти, имеющую внешний доступ.

Многие известные компании, такие как Cisco, Alcatel, Nokia и Siemens, утверждают, что используют эту базу данных для своих критически важных операций из-за молниеносной скорости доступа к данным.

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

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

Вы пробовали какое-либо из этих решений в прошлом? Была ли у вас потребность во встроенной базе данных для одного из ваших проектов? На чем вы остановили свой выбор?

Автор: Fernando Doglio

Источник: webformyself.com