Топ 11 открытых источников данных для вашего следующего проекта

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


В мире, в котором так долго доминировали базы данных, как 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 не имеет смысла, когда ваша модель данных не реляционная и / или когда у вас очень специфические архитектурные требования. Например, рассмотрим Analytics, где новые отчеты постоянно создаются на основе существующих данных. Такие системы тяжелы для чтения и страдают, когда на них накладывается строгая схема. Конечно, 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

Лучше дьявола, которого ты знаешь, чем того, кого ты не знаешь. Под этим я подразумеваю, что если ваша существующая СУБД работает хорошо для вас, и вы думаете, что справитесь с масштабирующими болями, которые она приносит, продолжайте. Несмотря на всю гениальность, 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-сервис, чтобы избавиться от проблем с масштабированием БД, но это дорого!

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

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

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

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

RethinkDB

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

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

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

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

Redis

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

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

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

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

SQLite

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

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

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

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

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

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

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

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

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

Cassandra

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

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

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

Cassandra была разработана с особым вниманием к конкретному случаю использования – для работы с большими нагрузками при записи и нулевым допуском для простоя. Они становятся его уникальными точками продаж.

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

Когда использовать Кассандру

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

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

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

Временные рамки

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

Временная шкала – это тип базы данных «временных рядов». Он отличается от традиционной базы данных тем, что является основной проблемой, а аналитика и визуализация массивных наборов данных является главным приоритетом. Базы данных временных рядов редко видят изменения в существующих данных; Например, показания температуры, посылаемые датчиком в теплице – новые данные накапливаются каждую секунду, что представляет интерес для аналитики и отчетности..

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

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

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

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

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

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

CouchDB

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

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

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

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

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

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

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

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

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

Вывод

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

Если вам интересно изучать базу данных, проверьте Udemy для некоторых из блестящих онлайн-курсов.

TAGS:

  • База данных

  • Открытый исходный код

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