NoSQL, NewSQL, эволюция баз данных
Основные веб-сайты используют базу данных NoSQL. Началось это с Google и Facebook.
Требуемая расширяемость и большое количество данных и обновлений делают реляционную модель неэффективной, что вынудило найти новую модель.
Слово NoSQL появилось в 2009 году для обозначения увеличивающегося числа программ, не использующих классическую реляционную модель. Название является ярлыком для «Not Only SQL», по-французски «Не только SQL», чтобы выразить тот факт, что ты хочешь выйти за рамки классической модели доступа к данным, как это объясняется ниже.
Можно считать, что BigTable, созданный Google для своего индекса, является движущей силой движения NoSQL, поскольку модель подхватили основные сайты Сети.
Почему NoSQL
?Классическая модель не работает перед лицом некоторых видов лечения:
- Индексация количества документов.
- Участки с высокой посещаемостью.
- Данные с переменным размером в зависимости от записей.
- Частые переписывания (классическая модель предусматривает больше чтения, чем записи).
- Расширяемость основания.
- Когда важна скорость.
- Повышение производительности - проще.
Некоторые компании не довольны своим опытом NoSQL и возвращаются в MySQL или MariaDB. Это дело «Арстечницы», Google с проектом «Спэннер». Это связано с прогрессом, достигнутым при работе этих комиксов. Но другие предпочитают NoSQL.
SQL против NoSQL
NoSQL ориентирован на столбцы: будем понимать, что можно добавлять столбцы к каждой записи так же легко, как добавлять строки (с помощью INSERT/UPDATE) в реляционной модели.
NoSQL не имеет концептуальной схемы и со временем может меняться в количестве как столбцов, так и строк.
Но что делает NoSQL намного быстрее? Это связано прежде всего с тем, как мы относимся к переменным столбцам.
Возьмем пример. Предположим, мы управляем движением аэропорта со списком всех рейсов.
Классическая таблица будет иметь следующую форму:
Номер рейса | Самолет | Пилот | Путь |
---|---|---|---|
001 | Аэробус | Джо | Нью-Дели |
Но нельзя иметь колонку с именем каждого пассажира. А у самолетов и рейсов очень разное количество пассажиров, таблица бы содержала какое-то количество дыр и поиск данных был бы тем более замедлен.
Вот как классическая реляционная модель решает проблему. Создаётся стол «Пассажиры» следующей формы.
Номер рейса | Имя пассажира |
---|---|
001 | x |
001 | там |
001 | z |
В одном и том же столе будут все рейсы и имена пассажиров. Само собой разумеется, что доступ к данным предполагает обработку большого объема информации до получения искомой информации.
Строка таблицы NoSQL, когда она имеет следующую форму:
Номер рейса | Самолет | Пилот | Путь | |||
---|---|---|---|---|---|---|
001 | Аэробус | Джо | Нью-Дели | x | там | z |
Количество колонок на каждый рейс зависит от количества пассажиров.
Найти пассажира на рейсе, очевидно, будет намного быстрее в такой модели, но, главное, изменить данные будет бесконечно проще.
NewSQL, другой подход
Это не формат, а новый подход в реализации. Первоначальное название было «ScalableSQL» и его цель - управление высокопроизводительными данными.
NoSQL упрекают в том, что он жертвует принципом ACID (Atomicity, Convistency, Isolation, Durability), атомностью, консистенцией, изоляцией, устойчивостью, поэтому обеспечивает меньшую надежность доступа к данным.
База данных NewSQL сохраняет классическую структуру в столбцах, но использует различные процессы, чтобы поддерживать скорость даже на больших томах.
VoltDB - новый менеджер комиксов на базе NewSQL: Он предназначен для полноценной работы в памяти, что обеспечивает ему непревзойденную скорость и делает Oracle устаревшим .
Ориентированная база данных графика
Разработанная специально для хранения и поиска отношений между объектами или людьми, она более эффективна, чем реляционная база данных (несмотря на название), для выполнения запросов по этим ссылкам. У нее нет стола.
Структура базы состоит из узлов и свойств, схожих с объектами LOO, и кромок, данных, представляющих связь между двумя объектами, со значением, представляющим вес связи. Количество связей является переменным, и база меняется на два уровня: Добавленные или удаленные объекты и ссылки.
Neo4J, пожалуй, лучший инструмент, доступный для такой базы данных, даже если там или там есть и другие проприетарные программы, такие как Pregel от Google.
См. также...
АрангоДБ, для неопределившихся.
Идеальный образец инструмента NoSQL, он сочетает в себе шаблон Document, Graphs и Key/Value. В статье описаны различные модели, а также настольная модель и классическая реляционная модель для сравнения.
Кассандра из Facebook. Производное от BigTable .
Программное обеспечение NoSQL
- Перколатор от Google. Преемник BigTable для индекса двигателя.
- MongoDB. Документально-ориентированная база данных. Используется, например, Sourceforge.
- ElasticSearch. Даже если он представляет себя как система хранения документов и поиска в этих документах, ES фактически является СУБД и достаточно похож на MongoDB. Его легко развертывать, использовать и применять на крупных сайтах, включая eCommerce.
- Хэдуп. Платформа MapReduce от Google, программное обеспечение для распределенной обработки больших объемов данных. Проект включает HBase, который является менеджером базы данных, использующим фреймворк и разработанный на основе BigTable.
- Аэроспайк. Основываясь на модели ключ-значение, как и Redis, утверждает, что в сто раз быстрее, чем любой другой комикс, такой как MySQL. Использует язык Aerospike Query Language. (Лицензия Apache ).