1 Империя реляционных баз данных
На дворе 2009 год нашей эры, и Империя отношений правит нами уже более 30 лет, что слишком долго.
В 1970 году Кодд предложил реляционную модель, в 1974 году Чемберлен и Бойс создали SQL, и империя быстро установила свое господство.
От Северной Америки до Европы, от Европы до Азии бесчисленное количество программистов сдались у его ног.
Империя дает нам хорошие льготы:
Простая, но мощная реляционная модель
гибкий SQL
Есть также транзакции и ACID, которые мы так любим, освобождая нас от деталей низкоуровневого параллелизма.
Используя эти преимущества, программисты разработали бесчисленное множество систем, в основе каждой из которых лежит реляционная база данных.
Времена постоянно меняются, и город языков программирования постоянно меняет королевский флаг, но данные, хранящиеся в таблице, остались неизменными.
Данные всегда являются самым ценным активом компании.
Но империи также накладывают на нас тяжелые оковы: шаблоны и нормализация.
Правила Empire: Схема (структура таблицы) должна быть определена заранее для сохранения данных!
Все данные должны по крайней мере удовлетворять первой нормальной форме, даже второй нормальной форме, третьей нормальной форме и нормальной форме BCNF!
Если этого не удастся достичь, его бросят в тюрьму.Для одних племен даже простое лишнее поле будет осмеяно другими.
Заявленная империей переносимость SQL также обманула нас.Хотя SQL стандартизирован, у каждого производителя DB2, Oracle и SQL Server есть свой диалект!
Особенно при вычислении дат и манипуляциях со строками. Есть и хранимые процедуры, почти каждый производитель создаст свой набор, который вообще нельзя пересаживать!
2 Кризис
В 1990-х популярность объектно-ориентированных технологий привела к серьезному кризису в империи:
Несоответствие импеданса объектных отношений.
«Объект» имеет наследование, подкласс, родительский класс, ассоциацию, агрегацию, полиморфизм;
А реляционные базы данных — это просто таблицы!
Они настолько разные, что несовместимы друг с другом, а их противоречия непримиримы.
В то время на востоке империи появилось племя, называемое объектно-ориентированной базой данных OODB, утверждавшее, что оно может хранить объекты Java, объекты C#, объекты Ruby и т. д. непосредственно в OODB.
Сохранить объект напрямую в базу данных? Это действительно замечательная функция.
Но ООБД действительно неудовлетворительна и вскоре угасла, задержавшись на нескольких небольших территориях.
В 2001 году 27-летний парень по имени Гэвин Кинг разработал нечто под названием Hibernate, которое строило мост между объектами и отношениями, называемое O/R Mapping.
Это неожиданно завоевало сердца и умы Java-программистов.
Hibernate продолжал упорно работать и запустил NHibernate, прорвавшись на территорию .NET.
С появлением большего количества инструментов и интерфейсов O/R Mapping, таких как iBatis, JPA, империя реляционных баз данных успешно пережила этот кризис.
Позже хороший человек, Мартин Фаулер, даже написал книгу "Шаблоны архитектуры корпоративных приложений", в которой обобщил все виды паттернов O/R Mapping: "Наследование одной таблицы", "Наследование таблицы классов", "Запись активности" . . . . . .
Эта бурная операция продлила жизнь империи реляционных баз данных более чем на 20 лет.
3 новая надежда
Прилив Интернета не заставил себя долго ждать, и история дала нам еще один шанс.
Количество пользователей Интернета настолько велико, а количество параллелизма настолько велико, что мы этого не ожидали.
Объем данных настолько огромен, а разнообразие данных настолько велико, что мы ошеломлены.
Текст, изображения, ссылки, журналы, социальные связи, огромное количество данных, база данных на одной машине скоро станет неустойчивой.
Сначала империя отчаянно пыталась расширить свои возможности, надеясь превратить машину в память 1024 Гбайт, жесткий диск 1024 Тбайт и репутацию вертикального расширения.
Но чем мощнее будет машина, тем дороже будет цена, а налоговое бремя подданных будет все тяжелее и тяжелее, и скоро станет невыносимым.
Ни в коем случае империя должна была масштабироваться по горизонтали и распределять данные по нескольким машинам, что требовало тщательного планирования и необходимости, чтобы программисты и приложения точно помнили, где размещалась каждая часть данных.
Что еще хуже, такой подход отбрасывал преимущества, которыми гордилась империя: отношения и постоянство.
4 сопротивляться
Я решил восстать против этой огромной империи, я тайно повел группу братьев-единомышленников уйти, мы хотим построить новую и свободную территорию.
Мы внимательно изучили недостатки империи отношений и отправили в атаку несколько небольших команд по отдельности.
Когда мы давали присягу, мы выдвинули одинаковые требования к этим четырем командам: поддержка распределенных и кластерных!!!
Первая команда состояла из redis в качестве капитана и memcached в качестве заместителя Они быстро добились успеха, потому что столкнулись с самым большим недостатком реляционной империи: при высокой степени параллелизма операции ввода-вывода в базе данных выполняются очень медленно.
Redis и memcached приняли смелое решение, отказались от жесткого диска, выбрали память в десятки тысяч раз быстрее жесткого диска и поместили в нее данные в виде ключ-значение.
Сверхбыстрая скорость очень нравится программистам, которые не только помещают в него информацию о сеансе, конфигурации и данные корзины покупок.
Позже их просто использовали как тайник.
Вторая группа, возглавляемая Mongodb и которой помогал CouchDB, активно занималась данными, которые было неудобно хранить в реляционных таблицах.
Заказ на товарную позицию и платеж, заказ на товар — это типичная связь «один ко многим», что означает, что данные представляют собой древовидную структуру, так почему бы не представить их напрямую с помощью документа JSON?
{
"orderId":"1",
"userId":"123",
"lineItems":[
{
"productId":"1356",
"qty":"1"
},
{
"productId":"2375",
"qty":"2"
}
],
"shippingAddress":{
"type":"xxx",
"address":"xxx"
},
"payment":{
"type":"alipay",
"time":"xxxx"
}
}
MongoDB также подключается к JavaScript и Node.js для хранения данных JSON, отправленных браузерами, непосредственно в MongoDB, что просто и удобно.
Лидером третьей команды является Neo4j, этот парень очень хорошо разбирается в графической структуре, он очень подходит для представления данных социальных сетей и рекомендательных систем.
Четвертую команду возглавляет HBase, за ней следует Cassandra, все они столбчатые базы данных, и общими для них являются данные десятков миллиардов строк * один миллион столбцов.
Эта команда также добилась больших успехов.Огромные данные, генерируемые мобильным Интернетом, такие как журналы, записи чатов, данные мониторинга и данные из Интернета вещей,Структура не прочная, что очень удобно для хранения в столбчатой базе данных, такой как HBase.
5 новых империй
Через несколько лет четыре команды были успешно обучены, и все они вернули большое количество поклонников программистов, потому что самые подходящие — самые лучшие.
Потихоньку формируется новая империя, способная конкурировать с реляционными базами данных.
После бурного обсуждения мы придумали громкое название для империи:NoSQL.
Это означает, что нет SQL!
Однако программисты, присоединившиеся к империи NoSQL, обнаружили, что у нас есть и весьма очевидные слабости:
Отсутствие схем (таких как структуры таблиц), слабые ограничения целостности данных, слабая поддержка транзакций или их отсутствие, что вызвало сильное недовольство и протест со стороны программистов.
После непродолжительного периода первых последователей NoSQL многие люди отказались от нас и вернулись к SQL.
Мы решили вести переговоры с империей реляционных баз данных, сказав им, что NoSQL означает не только SQL, и что наши две империи должны учиться друг у друга и мирно сосуществовать.
Империя реляционных данных, которая пережила несколько лет войны, также заметила тенденции в области ИТ и приняла их.
С тех пор база данных вступила в эпоху гибридного хранения!
(Заканчивать)
Больше интересных статей, все в коде фермера переворачиваются
Code Farmer перевернул 3 года основных статей
Комикс: Семь негласных правил, которых программисты должны придерживаться
Комикс: Брат, сегодня мне снова придется не спать всю ночь!
Руководство по разубеждению архитектора
HTTP-сервер: плохая контратака
Как уменьшить зарплату программистам?
Программист, вы должны выбрать правильное время для запуска!