Базы данных для линукса

Лучшие базы данных для Linux

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

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

1. MySQL

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

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

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

2. PostgreSQL

Postgresql появился приблизительно в то же время, что и MySQL. Это объектно-реляционная база данных с открытым исходным кодом, все данные представлены в виде объектов. В отличие от MySQL, эта база данных неукоснительно следует всем стандартам SQL из-за чего она может показаться более сложной. Она разрабатывается программистами со всего мира, а направление развития контролируется советом.

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

3. SQLite

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

Благодаря компактности SQLite накладные расходы минимальны, а установка и использование очень просты. В то же время база данных соответствует большинству требований стандарта SQL. Поэтому SQLite используется по умолчанию во многих веб-фреймворках, и программах для рабочего стола, например: Mozilla Firefox, Skype, Thunderbird и многих других.

4. MariaDB

Эта база данных основана на исходном коде MySQL и ее разработка началась после перехода оригинала в собственность Oracle. За работу взялись первоначальные разработчики MySQL. MariaDB сохраняет тесную совместимость с MySQL, поддерживаются все ее команды и синтаксис запросов. Кроме того, из дополнительных возможностей можно отметить поддержку таблиц: XtraDB, Aria, PBXT, FederateX, OQGRAPH, SphinxSE и другие.

Кроме таблиц была очень сильно улучшена производительность и добавлены новые возможности. Разработка ведется компанией MariaDB Foundation и разработчиками по всему миру, но в развитие проекта инвестируют деньги множество компаний, среди которых Google и Intel. Это лучшая и самая популярная база данных Linux.

5. Percona

Percona DB — это сборка базы данных MySQL со включенным по умолчанию движком таблиц XtraDB. Этот движок основан на InnoDB но дает более высокую производительность и больше статистики.

Движок таблиц XtraDB основан на InnoDB, но включает патчи исправлений от компаний Google и Percona, поэтому дает большую производительность. Здесь улучшен механизм работы с памятью, скорость ввода/вывода, добавлена поддержка работы нескольких потоков и управление пропускной способностью. Вы можете не использовать отдельный сервер баз данных, а включить XtraDB в MariaDB или MySQL.

6. MongoDB

MongoDB — это не реляционная, документарная база данных, которая была выпущена в 2007 году. Основная ее особенность в том, что данные хранятся не в виде строк в таблицах, а в документах, в формате JSON. Запросы на получение и изменение данных тоже оформляются через jаvascript подобный язык.

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

7. Firebird

Firebird — это реляционная система управления базами данных, основанная на исходном коде базы данных Interbase, которая была выпущена компанией Borland в 2000 году. Поддерживаются все инструкции стандарта SQL 92 и почти все из SQL 99. Поддержка ACID реализована с помощью версий записи, каждый запрос работает со своей версией, а это значит, что ничего не блокируется и не мешает друг-другу. Из дополнительных возможностей поддерживаются тиггеры и процедуры хранения.

8. CUBRID

Это объектно-реляционная система управления базами данных, которая появилась в 2008 году. Она имеет особую архитектуру, специально оптимизированную для быстрой работы веб-приложений. За каждую задачу отвечает отдельный процесс, что дает преимущество в скорости. На данный момент поддерживается стандарт SQL 92.

База данных может интегрироваться со множеством языков программирования, среди которых PHP, Perl, Python и Ruby.

Выводы

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

На завершение вы можете посмотреть видео, о том, что такое базы данных:

Источник

Базы данных для линукса

Данный обзор — субъективные впечатления автора и не претендует на полную объективность. Наверняка, в обзоре много неточностей и ошибок. Сообщите мне о них. Возможно, кто-то продвинулся дальше и сможет рассказать многое в свою очередь. Многие СУБД рассматривались поверхностно и не испытывались вообще. Велись поиски под конкретный проект и некоторые варианты отбрасывались на этапе изучения документации.

Предисловие

Итак, не было специальной цели написания данного обзора. Цель была другая. Требовалось найти СУБД для системы, которая должна решать одну из основных задач автоматизации Сбербанка — лицевые счета клиентов. Поиски привели к тому, что пришлось пересмотреть несколько доступных на сегодня свободных СУБД. В результате сложилось определенное впечатление, которое и приведено ниже.

В обзоре отсутствуют объяснения, почему в качестве платформы автоматизации была выбрана ОС Linux. Это тема другой статьи. Если коротко, то Linux это Unix-like операционная система с сетевой оконной графической системой X Window. Все компоненты системы, включая исходные тексты, распространяются свободно. Здесь же перечислю те требования, которые я предъявлял к СУБД, с позиций ее применения в упомянутой системе:

• реальный многопользовательский режим;
• транзакционная защита от сбоев;
• возможность «плотного» хранения данных. (Имеется в виду возможность хранения множества типов, например языка С, и возможность их обработки. Требование связано с объемом и составом данных. Примерный объем 50000-100000 записей лицевых счетов и 300000-500000 записей о движении денег.);
• желательно, чтобы СУБД работала в режиме клиент-сервер через TCP/IP;
• возможность работать с базой из процедурного языка, лучше из С или С++. Желательно иметь доступ типа SQL;
• и, наконец, СУБД должна обладать достаточной «скорострельностью» (Например, задача получения баланса, т.е. сложение массива чисел (см. объем базы) на процессоре 486DX при 8 Мб и средних по скорости IDE дисках не должна занимать более 5 мин.)

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

Замечу, что предыдущий вариант системы был сделан в SCO UNIX с использованием коммерческой СУБД Raima Data Manager (RDM), известной больше под названием dbVista 3.21. И, надо сказать, RDM показала себя с лучшей стороны. Она удовлетворяла практически всем перечисленным требованиям, если не считать отсутствия режима клиент-сервер.

Кстати, загрузочная прикладная программа, собранная под управлением SCO Unix с библиотекой RDM, с успехом работала в Linux (через систему совместимости iBCS) и гораздо быстрее, чем в родном ей SCO UNIX. По некоторым данным, в Linux можно изготовить объектный модуль (в формате COFF), который линкуется с библиотекой из SCO Unix. Я не проверял, если кто знаком с этой технологией, пусть поделится. Если это так, то получается, что Linux позволяет работать с SCO-версией RDM, и при этом SCO Unix не нужен вообще.

Тому, кто знаком с RDM, должны быть понятны мои пристрастия. Среди требований ничего не сказано об интерфейсе с пользователем. Этот интерфейс логичнее, проще и стандартнее сделать другими средствами, например, на Tcl/Tk для X Window. Поэтому не обсуждаем эти вопросы.

Рассмотренные СУБД, пункты обзора и условности.

В следующем разделе приведена информация по СУБД:

Postgres
• Ingres
• Mbase
• ONYX
• mSQL
• Typhoon
• LINCKS
• Exodus

Источник

Кунг-фу стиля Linux: базы данных — это файловые системы нового уровня

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

Меня, если говорить о накопителях данных, удивляет то, что понятие «файловая система», в том виде, в котором мы его знаем, за годы его существования изменилось не слишком сильно. Конечно, если сравнить то, что есть сейчас, с тем, что было, скажем, в 1960-е годы, то можно сказать, что в наши дни файловые системы дают нам гораздо более широкий функционал, чем прежде. В наши дни всё гораздо лучше в плане скорости, способов кодирования, шифрования, сжатия данных и так далее. Однако фундаментальная природа того, как мы храним файлы, и того, как с ними работаем в компьютерных программах, практически не изменилась. А всё должно быть не так. Нам известны более эффективные способы организации данных, но по каким-то причинам большинство из нас не пользуется этими возможностями в своих программах. Оказывается, правда, что пользоваться ими достаточно просто, и я собираюсь это продемонстрировать на экспериментальном приложении, которое вполне может стать отправной точкой разработки базы данных электронных компонентов для моей лаборатории.

Основой для базы данных, подобной той, о которой я хочу рассказать, может быть файл, где в роли разделителя данных применяются запятые (CSV-файл). Тут можно воспользоваться и чем-то вроде формата JSON. Но я собираюсь задействовать полномасштабную базу данных SQLite для того чтобы избежать необходимости в «тяжёлом» сервере баз данных и сложностей, сопряжённых с его поддержкой. Можно ли, используя мой подход, сделать что-то, что способно заменить базу данных, на которой основана какая-нибудь система резервирования авиабилетов? Нет. А подойдёт ли он для решения большинства задач, которые всем нам так или иначе приходится решать? Готов поспорить, что подойдёт.

Абстракция

Если подумать о файловых системах, то окажется, что это — не более чем абстракция над физическим устройством для хранения данных. Обычно мы не знаем или попросту не беспокоимся о том, где именно хранится нечто вроде файла hello.c . Нас даже не интересует то, сжат ли этот файл, то, зашифрован ли он. Он, возможно, был загружен по сети, а, может, его части хаотично разбросаны по всему жёсткому диску. Обычно нас это не волнует. А что если абстрагировать саму файловую систему?

Это, в общем-то, идея, лежащая в основе баз данных. Если имеется, например, список электронных компонентов, я могу сохранить его в CSV-файле и прочитать этот файл с помощью программы для работы с электронными таблицами. Или могу использовать полноценную базу данных. Проблема баз данных заключается в том, что для работы с ними обычно требуется некое серверное ПО, вроде MySQL, SQL Server или Oracle. Можно абстрагировать интерфейс базы данных, но это — весьма тяжеловесное решение, если сравнить его с простой операцией открытия файла и с обычной работой с этим файлом.

Правда, существует, например, популярная библиотека, называемая SQLite, которая даёт весьма надёжный механизм работы с базой данных, размещённой в единственном файле. При этом для работы с такой базой данных не нужен специальный сервер, её не нужно как-то по-особенному поддерживать. В работе с подобной БД, конечно, есть и ограничения. Правда, при её применении во многих простых программах можно пользоваться полезными возможностями баз данных, но при этом не тратить системные и финансовые ресурсы на поддержку инфраструктуры, обеспечивающей работу обычной СУБД.

Правильный инструмент для правильной работы

У SQLite, конечно, есть ограничения. Но если, например, некто занимается созданием собственного файлового формата для хранения неких данных, ему, возможно, стоит рассмотреть возможность перехода на SQLite и обработки этих данных средствами СУБД. В соответствии с данными, приведёнными на сайте SQLite, такой ход вполне может привести к экономии дискового пространства и к увеличению скорости доступа к данным. И ещё — после того, как программист освоится с этой технологией, окажется, что она упрощает работу с данными. И небольшое приложение, основанное на SQLite, если решено будет перевести его на что-то более серьёзное, лучше поддастся такому переходу.

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

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

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

О моей задаче

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

Основы работы с базами данных

В современных реляционных базах данных обычно имеется как минимум одна таблица. Их может быть и несколько. В каждой таблице имеются строки, в которых хранятся данные. Строки состоят из столбцов, которым назначены типы данных. Например, в таблице может присутствовать текстовый столбец, предназначенный для серийного номера электронного компонента. Ещё один столбец, предназначенный для хранения вещественных чисел, содержит сведения о напряжении в испытательной точке. А ещё один, хранящий данные логического типа, содержит значение, указывающее на то, пройдено испытание или нет.

Строки каждой таблицы имеют уникальные идентификаторы (ID). Если программист не предусмотрел механизм формирования этого ID, СУБД обычно может сама его сформировать. В частности, речь идёт об автоматическом инкрементировании подобных идентификаторов и об обеспечении того, что каждой строке таблицы будет назначен уникальный идентификатор.

Если бы возможности СУБД ограничивались тем, о чём я только что рассказал, то у них не было бы особых преимуществ перед обычными CSV-файлами. Но после того, как данные организованы вышеописанным образом, многие задачи можно решать лучше, чем при отсутствии такой структуры. Например, легко попросить систему выполнить сортировку элементов, или, например, выбрать из таблицы строки, содержащие три самых больших значения напряжения.

Надо отметить, что одной из главных сильных сторон баз данных является возможность создавать соединения данных. Предположим, у меня есть список компонентов ( Components ): печатная плата ( PCB ), резистор ( Resistor ), держатель аккумуляторной батареи ( Battery Holder ) и светодиод ( LED ). Имеется таблица, в которой для каждого из этих компонентов предусмотрена отдельная строка. Теперь представим, что у меня есть таблица с описанием сборных изделий ( Assembly ), сделанных из этих компонентов. Тут можно применить простой подход:

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

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

В результате я, в своей базе данных, планирую создать три таблицы. В таблице parts будет храниться список имеющихся у меня компонентов. В таблице partnums — сведения о типах компонентов (например — 7805, 2N2222 или CDP1802). И наконец — в таблице locations будут сведения о том, где именно хранится тот или иной компонент. Мои данные можно структурировать и по-другому. Скажем, может иметься таблица, в которой хранятся сведения о способах монтажа компонента. Например, компоненту 2N2222 может быть назначено значение TO92, или может быть указано, что он предназначен для поверхностного монтажа. Кроме того, я собираюсь создать механизм для просмотра данных, представление (view), в котором все данные будут показаны в развёрнутом виде — как в первом примере. Представление — это нечто такое, что в базе данных не хранится, но, для удобства, выглядит как таблица. А на самом деле это — всего лишь результат выполнения запроса к базе данных, с которым можно что-то делать.

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

Ровно столько SQL, сколько нужно для дела

Нам, для решения наших задач, понадобится сравнительно немного SQL-инструкций: create , insert и select . Имеется программа, sqlite3 , которая позволяет выполнять команды в применении к базе данных. Этой программе, средствами командной строки, можно передать имя базы данных, а потом можно работать с этой базой данных, что совсем несложно. Для выхода из программы используется команда .exit .

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

Я выполнил эти команды с помощью sqlite3 , в командной строке, но их можно было бы выполнить и из программы с графическим интерфейсом. А если бы мне это было нужно, я мог бы сделать так, чтобы они были бы выполнены из моей C-программы. Средства командной строки я использовал и для того, чтобы добавить в базу данных несколько тестовых записей. Например:

Для получения данных из базы используется команда select :

Если вы хотите глубже разобраться в этих и других командах — существует множество учебных руководств по SQL.

Программирование!

До сих пор мы, готовя основу программы, не нуждались, собственно, в программировании. При этом, исходя из предположения о том, что в нашем распоряжении имеется пакет наподобие libsqlite3-dev , для того чтобы оснастить C-программу функциями, направленными на работу с базой данных, нам не придётся прилагать особенно больших усилий. В частности, в коде нужно будет подключить sqlite3.h . Если такого заголовочного файла найти не удаётся — это может означать то, что в системе не установлено то, что нужно для SQLite-разработки. Ещё понадобится связь с libsqlite3 . Если говорить о простом однофайловом проекте, то, чтобы приступить к работе над ним, скорее всего, достаточно будет такого makefile :

Сам код очень прост. Сначала нужно открыть файл базы данных (с использованием функции sqlite3_open ). Вместо имени файла можно передать функции :memory . Тогда в нашем распоряжении окажется база данных, расположенная в памяти, которая будет существовать столько же времени, сколько будет работать программа. Этот вызов возвращает дескриптор базы данных. Далее — нужно подготовить SQL-запрос, который планируется выполнить. Это может быть запрос, подобный тем, которые мы уже выполняли, или — любой другой запрос. В моём случае мне нужно взять все данные из представления full и вывести их. Поэтому я собираюсь выполнить такой запрос:

И наконец — мы пользуемся функцией sqlite3_step . До тех пор, пока она возвращает SQLITE_ROW , мы можем обрабатывать строки, пользуясь функциями вроде sqlite3_column_text . В конце выполняется финализация и закрытие базы данных. Вот готовый код, из которого удалены механизмы обработки ошибок:

Если хотите — вот полный код. А в ситуации, когда перебор строк нас не интересует, можно воспользоваться функцией sqlite3_exec . Даже в документации говорится, что это — лишь обёртка вокруг функций prepare , step и finalize . Поэтому данной функции можно просто передать соответствующие входные данные и всё должно заработать.

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

Итоги

Когда вы в следующий раз поймёте, что занимаетесь выдумыванием нового файлового формата — поразмыслите о том, чтобы, вместо этого, воспользоваться SQLite. К вашим услугам будут свободные инструменты, а после того, как вы освоите SQL, вы поймёте, что можете сделать очень многое, не написав никакого программного кода, кроме, разве что, кода различных SQL-команд. Можно даже использовать систему для хранения разных версий базы данных, подобную той, что применяется в Git. И, кстати, некоторые используют в роли базы данных Git, но мы этого делать не рекомендуем.

Источник