Кстати, в общем виде такое утверждение всё-таки не совсем верно. Оно верно при чисто навигационном стиле запросов, который не всегда возможен и не всегда оптимален.
И «аналитическая записка» убрали бы из названия, а то аналитики тоже особо не видно. Прочитали-поняли-пересказали, насколько могу судить. И то, и другое, и третье может быть объективно трудно, но аналитикой от этого автоматически не становится...
Используя все известные человечеству штампы и клише, они рассказывают, как же нам здорово будет на их конференции, затем пишут, как же всё было здорово, в надежде сделать завидно непришедшим.
Вот я бы тоже просил авторов разного рода анонсов в корпоративных блогах постить их и прочие сontent-free материалы (в частности, лишенные текстовой версии видеоотчеты с этих мероприятий) в разделе «Новости», например. Или брать пример с автора этого поста.
Шикарная статья, спасибо! Но я бы всё-таки различал три вещи: абстрактная реляционная модель, язык запросов к ней, реализация всего этого в современных СУБД. Из названия статьи хочется заподозрить, что речь пойдет о втором пункте, но на самом деле речь идёт о всех трёх. Как-то бы переименовать статью, быть может (но не знаю как).
Как по-вашему, что из дидактики иностранных языков применимо при освоении нового языка программирования, а что наоборот? Допустим, не получается освоить Rust. Какие советы дадите?
Мне не хотелось бы сваливаться в комментариях в дискуссии на тему «SQL vs. NoSQL». Сойдемся на том, что люди используют (не обязательно по соображениям производительности) и то, и другое, причем порой одновременно. Тогда возникают две основных проблемы: сложность управления всем этим хозяйством и невозможность транзакций в такой гетерогенной среде. СУБД, называющие себя мультимодельными, пытаются их как-то решить. Некоторые — ценой ухудшения производительности по сравнению со специализированными «одномодельными». А по отношению к сторонам спора «SQL vs. NoSQL» я стараюсь выдерживать нейтральное отношение.
С этим отлично справляются РСУБД
Отказ от джойнов «вообще» — движение в каменный век.
Проблема джойнов в РСУБД в том, что подлежащие соединению кортежи, так сказать, вычисляются. Конечно, не выборкой из декартова произведения, но все же. Несколько штук джойнов могут сильно замедлить выполнение запроса. Поэтому даже в РСУБД практикуют денормализацию.
Для сравнения, в графовых СУБД сведения о «соединенных» вершинах являются непосредственно хранимыми, поэтому запросы графового характера могут в них выполняться быстрее. В конце концов, не нужно пытаться быть большим католиком, чем сам папа. А папа говорил:
It may be argued that in some applications the problems have an immediate natural formulation in terms of networks. This is true of some applications, such as studies of transportation networks, power-line networks, computer design, and the like. We shall call these network applications and consider their special needs later.
Ну а документные СУБД решают проблему джойнов денормализацией и дублированием, да.
Это вы заявляете на основе просто наличия самой возможности что-то поправить, но какова скорость правки? Для неё нужно распарсить документ, изменить нужное значение, снова сериализовать, ну а потом, понятно, сохранить.
Это в SQL Server так, причем, хочется надеяться, временно. В документной СУБД документ уложен в какую-то структуру данных, хранится не как текст. Есть индексы по полям, работой с ними по сути можно и ограничиться, если пользователь просто хочет поменять себе год рождения :).
Например, так обстоят дела в MongoDB: https://docs.mongodb.com/manual/core/write-performance/. И в статьях с жалобами на документные СУБД жалобы на производительность модификации записей занимают не первое место. Первое место занимают джойны, ну а чего хотели-то?
mad_nazgul, я бы за любую РСУБД так не сказал, может, где и можно побороться.
С XML и JSON тоже дела могут обстоять не одинаково. Например, в SQL Server для XML есть индексы, а для JSON нет.
Какие-то рекомендации по увеличению производительности при работе с c JSON в SQL Server 2017 были по второй ссылке в том разделе статьи (извиняюсь, она сначала дублировала первую, исправил это).
… пришлось перелопатить достаточно большое количество партий, где встретилось это окончание.
А как и где их искали? А не подскажете случайно, как выглядел бы запрос на поиск партии с таким окончанием на CQL? А на использование конкретного метода матования?
Термин «агрегаты» взят из второй главы NoSQL Distilled Садаладжа и Фаулера, там много об этом. Сам термин мне не нравится, больше нравятся «композиты», в том числе с точки зрения значений слов в UML.
По сути, речь идет о денормализации. Поскольку производительность операций соединения в РСУБД не очень высока, давайте не будем их выполнять при каждом запросе. Будем хранить пакеты данных с предвыполненными такими операциями в готовом к отправке формате. Если что, клиент доразберет.
Поскольку все нужные соединения как бы уже выполнены, давайте разучимся их хоть как-то выполнять. Тогда и масштабироваться будет легко, а то межшардовые джойны — ужас-ужас.
Однако аналоги других реляционных операций, например, выборки по значениям полей, делать будем уметь, а то нас назовут хранилищем «key-value». Особых же проблем с тем, чтобы изменять документы, удовлетворяющие условию выборки, в документных СУБД нет, см. следующий комментарий.
Примерно такова идеология документных СУБД в утрированном виде. Т. е. «строить» в цитированной вами фразе означало что-то типа «собирать», а не «отбирать» или «изменять».
Ну, это немного другая разновидность того, что в совокупности можно назвать конвергентными платформами хранения или как-то так. Наверное, стоило бы в статье указать на отличия этих разновидностей. Про нестуктурированные данные вы сами говорите, про преимущественно не-OLTP характер задач тоже :-).
Да, там перед таблицей я говорю «наиболее важными будем считать реляционную, документную и графовую модели» ввиду невозможности объять необъятное.
Что до объектной модели… Тот же Gartner в «IT Market Clock for DBMSs 2019»» предсказывает ей скорую кончину (а мультимодельным СУБД, наоборот, расцвет).
Картинка с циферблатом
Как человеку, занимавшемуся информатизацией здравоохранения, мне будет Caché немного жаль :-). Однако вот OrientDB тоже заявляет о поддержке объектной модели.
Ну а что… Есть, например, одноименная отечественная компания: datafabric.cc. Существует с 2015 года, по-моему.
Просто есть много концепций, о которых в родных пенатах слыхом не слыхивали (или переизобретают под другими названиями), а переводчик не слышал тем более. «Графические СУБД» — это апофеоз, конечно…
Кстати, в одном довольно профильном сообществе я предлагал переводить «data fabric» как «кружево данных» или как «информационная ткань». Второй вариант вроде бы даже понравился участникам.
Кстати, в общем виде такое утверждение всё-таки не совсем верно. Оно верно при чисто навигационном стиле запросов, который не всегда возможен и не всегда оптимален.
См., например, статью «How to avoid costly traversals with join hints» в базе знаний Neo4j. Пример запроса оттуда:
И «аналитическая записка» убрали бы из названия, а то аналитики тоже особо не видно. Прочитали-поняли-пересказали, насколько могу судить. И то, и другое, и третье может быть объективно трудно, но аналитикой от этого автоматически не становится...
Вот я бы тоже просил авторов разного рода анонсов в корпоративных блогах постить их и прочие сontent-free материалы (в частности, лишенные текстовой версии видеоотчеты с этих мероприятий) в разделе «Новости», например. Или брать пример с автора этого поста.
Николай, а в чем отличия того, что вы называете Persistent Fabric, от того, что Gartner называет Data Fabric? Как бы вы размежевались?
P.S. «Но это все маркетинговый bullshit, а мы будем строить digital twin» — звучит забавно, конечно.
Шикарная статья, спасибо! Но я бы всё-таки различал три вещи: абстрактная реляционная модель, язык запросов к ней, реализация всего этого в современных СУБД. Из названия статьи хочется заподозрить, что речь пойдет о втором пункте, но на самом деле речь идёт о всех трёх. Как-то бы переименовать статью, быть может (но не знаю как).
42 V’s.
Выписал отсюда сокращения, известные мне, но в ваш список не попавшие: A.M., P.M., RIP, AD, C.V., M.A., M.D., Ph.D.
Многие из них были впоследствии переосмыслены как имеющие происхождение в английском, поэтому, наверное, в ваш список и не попали.
Да, спасибо, закомментировал.
Написал кусочек про сравнительно новые возможности MarkLogic в статье о мультимодельных СУБД, интересно ваше мнение.
Как по-вашему, что из дидактики иностранных языков применимо при освоении нового языка программирования, а что наоборот? Допустим, не получается освоить Rust. Какие советы дадите?
Мне не хотелось бы сваливаться в комментариях в дискуссии на тему «SQL vs. NoSQL». Сойдемся на том, что люди используют (не обязательно по соображениям производительности) и то, и другое, причем порой одновременно. Тогда возникают две основных проблемы: сложность управления всем этим хозяйством и невозможность транзакций в такой гетерогенной среде. СУБД, называющие себя мультимодельными, пытаются их как-то решить. Некоторые — ценой ухудшения производительности по сравнению со специализированными «одномодельными». А по отношению к сторонам спора «SQL vs. NoSQL» я стараюсь выдерживать нейтральное отношение.
Проблема джойнов в РСУБД в том, что подлежащие соединению кортежи, так сказать, вычисляются. Конечно, не выборкой из декартова произведения, но все же. Несколько штук джойнов могут сильно замедлить выполнение запроса. Поэтому даже в РСУБД практикуют денормализацию.
Для сравнения, в графовых СУБД сведения о «соединенных» вершинах являются непосредственно хранимыми, поэтому запросы графового характера могут в них выполняться быстрее. В конце концов, не нужно пытаться быть большим католиком, чем сам папа. А папа говорил:
Ну а документные СУБД решают проблему джойнов денормализацией и дублированием, да.
Это в SQL Server так, причем, хочется надеяться, временно. В документной СУБД документ уложен в какую-то структуру данных, хранится не как текст. Есть индексы по полям, работой с ними по сути можно и ограничиться, если пользователь просто хочет поменять себе год рождения :).
Например, так обстоят дела в MongoDB: https://docs.mongodb.com/manual/core/write-performance/. И в статьях с жалобами на документные СУБД жалобы на производительность модификации записей занимают не первое место. Первое место занимают джойны, ну а чего хотели-то?
Я бы спросил у автора, почему аффинные типы так называются.
mad_nazgul, я бы за любую РСУБД так не сказал, может, где и можно побороться.
С XML и JSON тоже дела могут обстоять не одинаково. Например, в SQL Server для XML есть индексы, а для JSON нет.
Какие-то рекомендации по увеличению производительности при работе с c JSON в SQL Server 2017 были по второй ссылке в том разделе статьи (извиняюсь, она сначала дублировала первую, исправил это).
Спасибо за статьи!
А как и где их искали? А не подскажете случайно, как выглядел бы запрос на поиск партии с таким окончанием на CQL? А на использование конкретного метода матования?
CQL-то сейчас скорее мертв, чем жив, не знаете?
Термин «агрегаты» взят из второй главы NoSQL Distilled Садаладжа и Фаулера, там много об этом. Сам термин мне не нравится, больше нравятся «композиты», в том числе с точки зрения значений слов в UML.
По сути, речь идет о денормализации. Поскольку производительность операций соединения в РСУБД не очень высока, давайте не будем их выполнять при каждом запросе. Будем хранить пакеты данных с предвыполненными такими операциями в готовом к отправке формате. Если что, клиент доразберет.
Поскольку все нужные соединения как бы уже выполнены, давайте разучимся их хоть как-то выполнять. Тогда и масштабироваться будет легко, а то межшардовые джойны — ужас-ужас.
Однако аналоги других реляционных операций, например, выборки по значениям полей, делать будем уметь, а то нас назовут хранилищем «key-value». Особых же проблем с тем, чтобы изменять документы, удовлетворяющие условию выборки, в документных СУБД нет, см. следующий комментарий.
Примерно такова идеология документных СУБД в утрированном виде. Т. е. «строить» в цитированной вами фразе означало что-то типа «собирать», а не «отбирать» или «изменять».
Сильных жалоб на трудности с тем, чтобы изменять документы в документных СУБД, вроде бы нет, см., например,
db.collection.update()в MongoDB.P.S. Понял, это был сарказм.
Ну, это немного другая разновидность того, что в совокупности можно назвать конвергентными платформами хранения или как-то так. Наверное, стоило бы в статье указать на отличия этих разновидностей. Про нестуктурированные данные вы сами говорите, про преимущественно не-OLTP характер задач тоже :-).
Да, там перед таблицей я говорю «наиболее важными будем считать реляционную, документную и графовую модели» ввиду невозможности объять необъятное.
Что до объектной модели… Тот же Gartner в «IT Market Clock for DBMSs 2019»» предсказывает ей скорую кончину (а мультимодельным СУБД, наоборот, расцвет).
Как человеку, занимавшемуся информатизацией здравоохранения, мне будет Caché немного жаль :-). Однако вот OrientDB тоже заявляет о поддержке объектной модели.
Поддержку «key-value» почти для всех СУБД обошел вниманием, упоминаю ее только если совсем нечего сказать.
Просто есть много концепций, о которых в родных пенатах слыхом не слыхивали (или переизобретают под другими названиями), а переводчик не слышал тем более. «Графические СУБД» — это апофеоз, конечно…
Кстати, в одном довольно профильном сообществе я предлагал переводить «data fabric» как «кружево данных» или как «информационная ткань». Второй вариант вроде бы даже понравился участникам.