пт, 2 сентября 2016 г.
Переосмысление базы данных
Когда большинство людей говорят о базе данных, они имеют в виду реляционную базу данных. Реляционные базы данных были основой корпоративных приложений в течение последних 30 лет. Реляционные базы данных, впервые определенные в июне 1970 года Эдгаром Коддом из исследовательской лаборатории IBM в Сан-Хосе, хранят данные в уже знакомых таблицах, состоящих из строк и столбцов.
Реляционные базы данных хорошо работали, когда системы обслуживали сотни или даже тысячи пользователей, но Интернет все изменил. Количество пользователей и объем данных растут в геометрической прогрессии. Разнообразные социальные приложения доказали, что приложения могут быстро привлечь миллионы пользователей. Реляционные базы данных никогда не были созданы для обработки такого уровня одновременного доступа.
Меняется архитектура. Хотя данные по-прежнему играют ведущую роль, то, как мы проектируем наши системы, зависящие от данных, за последние несколько десятилетий значительно изменились. Во многих системах база данных выступала в качестве точки интеграции для различных частей приложения. Это требовало унифицированного хранения данных, поскольку база данных действовала как форма API. На следующей диаграмме показаны архитектурные переходы:
С переходом на сервис-ориентированные архитектуры (SOA) стало менее важным то, как хранятся данные для данного компонента. Приложение взаимодействует со службой, а не с базой данных. Приложение зависит от контракта службы, а не от схемы базы данных. Этот сдвиг открыл возможности для хранения данных в зависимости от потребностей службы.
RavenDB как база данных типа документа для .NET Базы данных документов состоят из полуструктурированных и свободных от схемы структур данных, известных как документы. В этом случае термин «документ» не относится к документу PDF или Word. Скорее, это относится к богатой структуре данных, которая может представлять связанные данные от простых до сложных. В базах данных документов документы обычно представлены в нотации объектов JavaScript (JSON). Документ может содержать любое количество полей любой длины. Поля также могут содержать несколько фрагментов данных. Каждый документ независим и содержит все элементы данных, необходимые организации. Ниже приведен пример простого документа:
{ Name: "Joko Widodo", BornIn: "Surakarta, Indonesia", Spouse: "Iriana" }А вот пример более сложного документа:
{ Name: "Joko Widodo", BornIn: "Surakarta, Indonesia", YearBorn: "1961", Children: [ { Name: "Gibran Rakabuming", YearBorn: "1988" }, { Name: "Kahiyang Ayu", YearBorn: "1991" }, { Name: "Kaesang Pangarep", YearBorn: "1994" } ] }Поскольку документы основаны на JSON, несоответствие импеданса, существующее между мирами объектно-ориентированных и реляционных баз данных, исчезло. Граф объектов просто сериализуется в JSON для хранения. Теперь сложность сущности оказывает небольшое влияние на производительность. Целые графы объектов могут быть прочитаны и записаны за одну операцию с базой данных. Нет необходимости выполнять ряд операторов select или создавать сложные хранимые процедуры для чтения связанных объектов.
Документы JSON также добавляют гибкости благодаря дизайну без схемы. Это позволяет развивать системы без принудительной реструктуризации существующих данных. Отсутствие схемы упрощает эволюцию и настройку структуры данных. Однако необходимо уделять внимание изменяющейся структуре данных. Если эволюция является критическим изменением, документы должны быть перенесены или в приложение должны быть встроены дополнительные интеллектуальные функции.
"Продолжение следует.."
Первоначально опубликовано на muhammad.fahrizalrahman.web.id.