NoSQL — это актуальная тема, и почти у каждого, от Google до Facebook, есть какой-то вкус. В этом посте из двух частей мы попытаемся ответить на дилемму Sql или NoSQL. Первая часть объяснит преимущества и механику каждого простого старого Sql и нового блестящего NoSQL. Во второй части мы рассмотрим хранилище данных Google App Engine и постараемся ответить, является ли это лучшим выбором для конкретной бизнес-задачи.
Традиционная СУБД
Вероятно, можно с уверенностью сказать, что большинство реальных приложений полагаются на СУБД определенного типа для хранения и извлечения своих данных. У вашего приложения может быть множество причин не выбирать NoSQL и вместо этого придерживаться СУБД. Давайте посмотрим на ключевые моменты RDBMS Excel в:
- Гибкость запроса
- Поддержание согласованности по всему набору данных
- Управление транзакциями
- Разделение проблем / Работа с постоянно развивающимися приложениями под ним
Чтобы поддерживать согласованный набор данных, СУБД применяет ограничения целостности. Каждое действие с набором данных должно выполняться в транзакции со свойствами ACID . Это гарантирует, что все, что происходит внутри транзакции, никогда не нарушит целостность ваших данных.
С какими бы новыми задачами ни сталкивалось ваше приложение, пока ваша модель данных остается прежней, СУБД будет успешно обрабатывать ваши запросы. Такое разделение базы данных и приложения идеально подходит для нескольких приложений, обращающихся к одной и той же базе данных. Структура (отношения) в ваших данных обрабатывается СУБД . Это, конечно, требует полного знания о том, как ваши данные связаны (обеспечены отношениями, которые вы создаете), а также строгое соответствие 12 принципам реляционной модели . Эти принципы обеспечивают прочную теоретическую основу для простого и высоко структурированного хранения (в идеале) четко определенных данных.
Беспорядки в Силе
К сожалению, все эти замечательные функции имеют несколько недостатков, если упомянуть существенные:
- Объекты с переменными или сложными атрибутами не поддерживаются
- Слабая поддержка иерархических или графических данных
- Нет простого способа масштабирования
Первый и второй являются функциональными недостатками: СУБД нуждается в структуре, и она может структурировать только то, что логически вписывается в отношение. Например, вы можете хранить сложные атрибуты в виде двоичных строк, но СУБД не сможет эффективно с ними работать. Атрибуты переменных не подходят для статической схемы, и каждая строка должна содержать каждый атрибут. Обновления схемы происходят медленно и требуют запланированного простоя. С «реляционной точки зрения» это имеет абсолютный смысл. Помните, что СУБД выполняет задачи, требующие знаний о структуре ваших данных. Он должен быть «информирован» всякий раз, когда вы намереваетесь изменить эту структуру (например, путем добавления или удаления атрибутов).
Реляционные базы данных просто не подходят для иерархических или графических данных. Эти типы моделирования требуют множества отношений один-ко-многим и многие-ко-многим, которые не могут быть эффективно смоделированы в реляционной базе данных. Образно говоря, вы пытаетесь вписать дерево или сетку в то, что по сути является таблицей.
Третий недостаток связан с производительностью. СУБД не может легко масштабироваться по горизонтали, что является огромной (в буквальном смысле) проблемой для современных многомиллионных пользовательских «веб-масштабируемых» приложений.
На самом базовом уровне базы данных масштабируются с помощью шардинга. Если одна машина больше не может обрабатывать том, набор данных разделяется на подмножества, сегменты, которые затем могут храниться на нескольких машинах. Главный сервер управляет балансировкой нагрузки и направляет каждый запрос на соответствующий компьютер («ведомый»). Эта конфигурация ведущий-ведомый не единственно возможная, но ради краткости я не буду вдаваться в другие модели.
И в этом суть, СУБД не может автоматически разделять данные на подмножества, потому что информация для одного приложения-объекта (обычно) хранится в нескольких отношениях базы данных. Если вы не знакомы с моделированием реляционных данных, вам следует начать с нормализации . Да, некоторые гигантские веб-приложения, такие как Twitter, работают на RDBMS, но разработчики должны реализовать специальный слой шардинга, который не обрабатывается RDBMS автоматически.
Новая порода: NoSQL
NoSQL, «не только SQL» — это общий термин, используемый для описания множества баз данных, многие из которых ни в коем случае не являются новыми. Но в последнее время они переживают своего рода ренессанс. Базы данных NoSQL направлены на решение проблем с производительностью СУБД, передавая работу по структурированию в руки программиста приложения — Вас. К счастью, приложениям не всегда требуется агрегирование и структура на уровне базы данных, поэтому эти приложения могут безопасно извлечь выгоду из огромных улучшений производительности, которые могут обеспечить базы данных NoSQL. Нашей целью будет выяснить, является ли ваше приложение одним из них, но сначала позвольте мне представить несколько баз данных NoSQL (примерно в порядке сложности):
- (Заказано) Магазины Key-Value (Апач Кассандра, Динамо, Проект Волдеморт)
- Объектные магазины (AppEngine Datastore)
- Магазины документов (CouchDB)
- Древовидные и графические базы данных (Neo4J, Twitter’s FlockDB)
Все они решают некоторые проблемы и, конечно, приносят некоторые свои.
Теперь у нас достаточно четкое понимание механики и ограничений реляционной базы данных и базы данных NoSQL. В качестве контекста мы рассмотрим хранилище данных Google App Engine в следующей части этого поста. Продолжай смотреть.