Значение реляционных баз данных
Реляционные базы данных стали настолько привычной частью обработки данных, что их можно принять просто как неизбежную данность. Тем более полезно понять, какие преимущества они имеют.
Персистентные данные
Вероятно, самым главным преимуществом баз данных является возможность долговременного хранения больших объемов данных. Большинство компьютерных архитектур подразумевают два вида памяти, быструю и изменчивую основную память, и более крупное и медленное резервное хранилище.
Основная память ограничена по объему и может потерять все данные при отключении электропитания или сбое в работе операционной системы. Следовательно, чтобы сохранить данные надолго, необходимо записывать их в резервное хранилище, в роли которого обычно выступает жесткий диск.
Это обеспечивает более высокую гибкость при хранении крупных объемов данных по сравнению с файловой системой в том смысле, что база данных позволяет прикладным программам быстро и легко получать небольшие порции информации.
Параллельность
Промышленные приложения обычно позволяют многим клиентам одновременно просматривать и, возможно, модифицировать одни и те же данные. Большую часть времени пользователи работают с разными частями этих данных, но иногда они могут оперировать одними и теми же данными. В результате возникает необходимость координации этих взаимодействий, чтобы избежать ситуаций, подобных двум заказам на один и тот же гостиничный номер.
Как известно, параллельность трудно обеспечить в полной мере, предотвратив все возможные ошибки, которые встречаются даже у самых внимательных программистов.
Интеграция
Промышленные приложения функционируют в сложном окружении, где требуется обеспечить взаимодействие многих приложений, написанных разными коллективами.
Обеспечить такое взаимодействие приложений довольно сложно, потому что для этого необходимо раздвинуть организационные границы, установленные людьми. Разные приложения часто используют одни и те же данные, и изменения, внесенные одним приложением, должны быть известны другим.
(Почти) стандартная модель
Реляционные базы данных получили признание благодаря тому, что они предоставляют важные преимущества, указанные выше, (почти) стандартным способом. В результате разработчики баз данных могут изучить основную реляционную модель и применять ее во многих проектах. Несмотря на различия между разными реляционными базами данных, их основной механизм остается одним и тем же: разные диалекты языка SQL похожи друг на друга и транзакции обрабатываются практически одинаково.
Потеря соответствия
Реляционные базы данных имеют много преимуществ, но они не идеальны. Уже с первых лет они приносили много проблем.
Для разработчиков приложений основной проблемой была потеря соответствия (impedance mismatch): различие между реляционной моделью и структурами данных, находящимися в памяти. Реляционная модель данных представляет их в виде таблиц и строк, или точнее, отношений и кортежей. В реляционной модели кортежем называется множество пар имя-значение, а отношением - множество кортежей. (Реляционное определение кортежа немного отличается от их определения в математике и многих языках программирования, имеющих соответствующие типы данных, в которых кортежи представляют собой последовательности значений.) Все операции в языке SQL получают и возвращают отношения, что приводит к математически элегантной реляционной алгебре.
Использование отношений обеспечивает определенную элегантность и простоту, но одновременно накладывает некоторые ограничения. В частности, значения в реляционном кортеже должны быть простыми - они не должны содержать никаких структур, например, вложенных записей или списков. Это ограничение не относится к структурам данных, находящихся в памяти, которые могут быть намного сложнее отношений.
В результате, если вы захотите использовать сложную структуру данных, находящихся в памяти, то должны будете преобразовать реляционное представление для хранения на диске. В итоге возникает потеря соответствия - два разных представления, требующих трансляции.
Потеря соответствия - основной источник неприятностей для разработчиков приложений. В 1990-х годах многие считали, что это в конце концов приведет к замене реляционных баз данных базами, реплицирующими структуры данных, хранящихся в памяти, на диск. Это десятилетие было отмечено ростом объектно-ориентированных языков программирования, а за ними появились объектно-ориентированные базы данных. Ожидалось, что они будут доминировать в области разработки программного обеспечения в новом тысячелетии.
Интеграционные базы данных и базы данных приложения
Точные причины, по которым реляционные базы данных триумфально победили объектно-ориентированные базы данных, остаются предметом публичных споров между разработчиками определенного возраста. С нашей точки зрения, основным фактором была роль языка SQL в качестве интегрирующего механизма между приложениями.
В этом сценарии база данных действует как интеграционная 6аза Jанных (integration database) - с многочисленными приложениями, которые, как правило, разработаны разными коллективами и хранят свои данные в общей базе данных. Это улучшает взаимодействие, потому что все приложения оперируют согласованным множеством сохраняемых данных.
Интеграция общих баз данных имеет свои недостатки. Структура, разработанная для интеграции многих приложений, рано или поздно становится сложнее – на самом деле, часто она оказывается намного сложнее, - чем требуется для отдельного приложения.
Кластеры атакуют!
В начале нового тысячелетия в технологическом мире лопнул пузырь доткомов (dot-com bubble), надувавшийся в 1990-х годах. Это вызвало у многих людей вопросы об экономических перспективах Интернета, но в 2000-х годах некоторые из главных свойств сети веб приобрели очень большой масштаб.
Это увеличение масштаба происходило во многих направлениях. Веб-сайты стали внимательно следить за деятельностью клиентов и структурой. Появились крупные совокупности данных: связи, социальные сети, активность в блогах, картографические данные.
Рост объема данных сопровождался ростом количества пользователей – крупнейшие сайты достигли громадных размеров и обслуживали огромное количество клиентов.
Для того чтобы справиться с возрастающим объемом данных и трафика, потребовались более крупные вычислительные ресурсы. Существовали две возможности масштабирования: вертикальное и горизонтальное.
Появление баз данных NoSQL
Рождение термина "NoSQL" в современном смысле датируется 11 июня 2009 года. Он появился на конференции в Сан-Франциско, организованной Йоханом Оскарссоном Oohan Oskarsson), разработчиком программного обеспечения, живущим в Лондоне.
Термин "NoSQL" прижился, но никогда не имел строгого определения. Исходное название семинара относилось к "распределенным нереляционным базам данных с открытым исходным кодом" [NoSQL Meetup].
Для начала отметим очевидный факт: базы данных NoSQL не используют язык SQL. Некоторые из них имеют свой язык запросов, и их целесообразно было бы сделать похожим на SQL, чтобы их легче было изучить.