Не пора ли реляционным базам данных на свалку истории?

    Здравствуйте, меня зовут Дмитрий Карловский и я… антиконформист, то есть человек, который не держится за свои привычки и всегда готов их поменять, если в том есть необходимость. Например, как и многие разработчики, я начинал изучение баз данных с реляционных. Хотя реляционная алгебра и довольно красива в своей простоте, я постоянно ловил себя на мысли, что пытаюсь впихнуть круглую фигуру в квадратное отверстие и получалось как-то не герметично.



    Нет, я не буду рассказывать вам про MongoDB или ещё какую неполноценную «убийцу SQL». Статей на тему «SQL vs NoSQL» сравнивающих на самом деле реляционные субд с документными и так полно:


    Но у большинства из них есть фатальный недостаток — авторы просто не в курсе, что моделей данных в СУБД есть куда больше, чем два упомянутых: от узкоспециализированных «словарей», то универсальных «графов». А популярные «реляционные» и «документные» находятся лишь где-то по середине между универсальностью и специализированностью.

    Давайте сравним типичных представителей упомянутых типов СУБД (от большего к меньшему).

    • Популярность: Oracle, MongoDB, Redis, HBase, OrientDB.
    • Функциональность: OrientDB, Oracle, MongoDB, HBase, Redis.
    • Скорость: очень сильно зависит от задачи, данных и реализации приложения. Я пересмотрел кучу бенчмарков, везде всё по разному.

    SQL


    Силы тысяч разработчиков направлены на то, чтобы довольно простые модели предметной области расположить в табличках так, чтобы это было быстро, гибко и не слишком сложно. Получается плохо. Пишутся огромные ORM фреймворки, зубодробительные SQL запросы, создаются огромные индексы, и дублируются данные.

    В качестве примера приведу одну из типичных задач — работа с деревьями. Это может быть дерево комментариев, дерево разделов сайта, дерево тэгов. Деревьев очень много в предметных областях, но работая с реляционными СУБД их стараются избегать, так как работа с ними вызывает много боли.

    Вот, сколько статей на одном только Хабре написано о проблеме, которая есть исключительно в РСУБД ввиду попытки упихнуть всё многообразие моделей предметной области в прямоугольные таблицы:


    Все решения сводятся к трём основным:

    Таблица смежности. Потомок хранит ссылку на родителя. Тут не сохраняется порядок потомков (чтобы его сохранять нужно вводить дополнительную нумерацию, по которой сортировать, что замедляет как вставки так и выборки). Требуются рекурсивные запросы или денормализация таблиц смежностей.

    Рекурсивный запрос поддерева:

    WITH RECURSIVE Rec(id, parent, name, ord)
    AS (
        SELECT id, parent, name, ord FROM tree
        UNION ALL
        SELECT Rec.id, Rec.parent, Rec.name, Rec.ord
        FROM Rec, tree
        WHERE Rec.id = tree.parent
    )
    SELECT * FROM Rec
    WHERE parent = 123
    ORDER BY ord
    

    Запрос поддерева по денормализованной таблице смежности:

    SELECT navi.id , navi.name , navi.parent
    FROM tree , navi
    WHERE tree.ancestor = 123 AND navi.id = tree.node
    ORDER BY ord
    

    Материализованный путь. Потомок хранит номера всех предков (с сохранением их порядка). В худшем случае изменение иерархии приводит к обновлению данных всех узлов. При отсутствии соответствующего АПИ со стороны СУБД, требует фигурной манипуляции над строками, что не во всех случаях приемлемо по скорости. Не допускает вхождение одного потомка в несколько предков.

    Запрос поддерева с использованием ordpath:

    SELECT RowId, name FROM dbo.Tree WHERE @ParentId.IsDescendant(RowId) = 123
    

    Вложенные интервалы. Каждый узел хранит два числа, которые определяют его точное положение в иерархии. В худшем случае изменение иерархии приводит к обновлению данных всех узлов. Не допускает вхождение одного потомка в несколько предков. Относительно сложные алгоритмы требуют повышенной аккуратности.

    Запрос поддерева:

    SELECT node.id, node.name
    FROM tree AS node, tree AS parent
    WHERE node.left BETWEEN parent.left AND parent.right
    AND parent.id = 123
    ORDER BY node.left;
    

    Изменение деревьев гораздо сложнее, примеры кода можно найти по ссылкам выше.

    Как видим, каждый тип решения имеет свои серьёзные ограничения на представимую им модель и эффективность разных типов запросов. А знаете почему нет такого большого числа обстоятельных статей про хранение деревьев, например, в графовых СУБД? Да потому, что там в принципе нет этих проблем, так как дерево — это частный случай графа. Так что вопрос «как же мне так исхитриться и сохранить в базу иерархию» в графовых базах вообще не стоит.

    Запрос поддерева в графе:

    SELECT name , parent FROM ( TRAVERSE child FROM #1:123 )
    

    Да, нереляционные СУБД, не смотря на общее название «NoSQL», тоже могут поддерживать Structured Query Language, расширяя его своими операторами :-)

    Многие SQL-профи тут обычно заявляют, мол деревья и тем более графы в предметных областях почти не встречаются. Но стоит немного выйти из зоны комфорта как тут же увидишь, что любая предметная область на самом деле представляет из себя граф — набор сущностей, между которыми есть разнообразные отношения. Если отношения эти 1-к-1 или хотя бы 1-ко-многим и при этом связывают лишь разнотипные сущности, то такие модели относительно легко ложатся на реляционную модель (если не учитывать разные виды джойнов с костылями в виде индексов). Но обычно всё не так. Во многих местах можно встретить отношения многие-ко-многим. В РСУБД для каждого такого отношения приходится заводить отдельную таблицу и несколько индексов к ней, а это усложнение архитектуры, раздувание данных и замедление работы с ними.

    Некоторые, особо «передовые» программисты, предлагают хранить каждый тип моделей в своей СУБД. «Важные данные» в реляционных, деревья в графовых, а примитивные вообще в словарях. Но подобные подходы вида «всякой задаче свой инструмент» лишь добавляют головной боли (и как следствие багов разной степени тяжести) на тему консистентности данных в разных частях приложения.

    Программная разработка — штука очень динамичная. Сегодня мастер у вас должен иметь одну профессию и вы просто даёте ему текстовое поле вписать её. Завтра потребуется, чтобы он мог указать профессию лишь из предложенных вами и вы даёте ему селект для выбора нужной, сохраняя id профессии в модель мастера (один-ко-многим). После завтра потребуется, чтобы он мог выбрать несколько профессий разом (многие-ко-многим). А через неделю вам срочно потребуется реализовать уже иерархический каталог профессий. В реляционной СУБД сложность каждого следующего перехода значительно превосходит предыдущий. С графовой — вы больше времени потратите на обсуждение, чем на реализацию. Так что при старте проекта имеет смысл брать наиболее гибкий инструмент, который позволит вам не терять темп разработки в процессе изменения бизнес требований (или лучшего понимания оных). Да, специализированные инструменты могут в некоторых случаях быть быстрее и именно в этих случаях, если в этом есть необходимость, стоит заниматься такого рода оптимизацией.

    NoSQL


    Часто толковые SQL-разработчики берут какую-нибудь MongoDB, о которой говорят на каждом углу, и пытаются примерить к своему проекту, но разобравшись с ней, недоумевающе крутят пальцем у виска. Бестолковые так и остаются на MongoDB, мирясь с отсутствием транзакций и отношений между документами, ради мифической скорости и возможности засунуть в документ любой json.

    Нет, MongoDB даже среди документных СУБД — так себе, а уж в качестве альтернативы полноценным реляционным её в принципе нельзя рассматривать. А вот другая документная СУБД — OrientDB, бьёт реляционные по всем фронтам. Да, OrientDB на самом деле документная СУБД, которая, благодаря прямым ссылкам между документами позволяет описывать произвольные графы.

    Давайте развеем несколько типичных мифов по поводу NoSQL, о котором судят по наиболее громким представителям — MongoDB и Redis:

    1. Они не контролируют структуру записываемых пользователем данных. У отсутствия схем есть и плюсы (можно делать миграции данных в фоне, можно хранить не только кортежи примитивов), но и минусы (нужно внимательно следить что записываешь в базу, не эффективно хранятся данные). В OrientDB нашли разумный компромисс: вы можете указать схему и указанные там поля будут валидироваться в соответствии с ней при записи и не будут тратить место на имена полей, а не указанные валидироваться не будут, но будут занимать чуть больше места. Тут важно отметить, что изменение схемы не приводит к изменению самих документов — просто вы не сможете изменить их пока не приведёте к новому формату.

    2. Они не удовлетворяют требованиям ACID (Атомарность, Согласованность, Изолированность, Надёжность). OrientDB этим требованиям удовлетворяет. Более того, она из коробки умеет партицирование и мастер-мастер репликацию, так что поддерживает в том числе и распределённые транзакции. При этом вы можете регулировать баланс между согласованностью и скоростью ответа:
    writeQuorum определяет число узлов, которые должны подтвердить запись, прежде чем СУБД вернёт ответ, об успешном завершении транзакции.
    readQuorum определяет число узлов, которые должны подтвердить актуальность данных, прежде чем данные вернутся в ответ на запрос.
    По умолчанию все транзакции синхронны (дожидаемся ответа всех реплик), а чтение соответственно происходит без подтверждения актуальности (за её не надобностью в этом случае).
    Примечательной особенностью является прозрачная поддержка map-reduce: если узел содержит не все данные, то он сам делает запрос к остальным узлам и сливает их ответы. Клиент может работать с партицированной базой данных как с цельной. Есть даже автобалансировщик, раскидывающий документы в кластеры по разным стратегиям.

    3. Они не поддерживают SQL и предоставляют лишь простой специализированный API. OrientDB написана на Java и может быть интегрирована в другое Java приложение в качестве библиотеки. При этом есть несколько уровней публичного API:
    Объектное. Низкоуровневый доступ к записям. Не рекомендуется к использованию, так как через него вы можете нарушить совместимость с двумя остальными API.
    Документное. Тут вы имеете весь основной функционал основанный на документах и перекрёстных ссылках.
    Графовое. Оно предоставляет дополнительные удобства для организации графов, но на практике всё же удобней оказалось использовать документное апи.
    В качестве фронтенда к этим Java-API есть несколько библиотек, позволяющих писать запросы на разных языках (SQL, Gremlin, SPARQL).
    Можно расширять функционал плагинами на Java. Собственно Lucene индекс и админка реализованы в качестве плагинов.

    Так что не все NoSQL одинаково бесполезны :-)

    NewSQL


    Для сравнения подходов работы с графовой и реляционной СУБД, давайте создадим простейшую бизнес сущность — персону:

    SQL
    create table Persons (
        name text,
        age smallint
    )
    

    OSQL
    create class Person
    create property Person.name string
    create property Person.age short
    

    Тут всё просто и почти одинаково. Теперь добавим отношение «друзья»:

    SQL
    create table Persons_friends (
        subject integer,
        object integer
    )
    create unique index Persons_friends on Persons_friends ( subject , object )
    

    OSQL
    create property Person.friend linkset Person
    

    Недостатки РСУБД уже начинают вылезать — нам потребовалась дополнительная таблица и уникальный индекс на ней. Индекс этот с одной стороны гарантирует, что у нас не будет дубликатов связей, а с другой позволяет быстро находить друзей по идентификатору пользователя.

    Выведем основные данные о друзьях одного из пользователей:

    SQL
    select
        Persons.rowid ,
        Persons.name ,
        Persons.age
    from
        Persons_friends as friends,
        Persons
    where
        friends.subject = 123 ,
        friends.object = Persons.rowid
    

    OSQL
    select expand( friend )
    from #19:0
    fetchplan *:-2 name:0 age:0
    

    В РСУБД мы не можем хранить ссылки между записями — только их идентификаторы. Поэтому появляется хитрая конструкция, объясняющая как данные из одной таблицы соотносятся с другой. В графовой же мы просто разворачиваем ссылки.

    А теперь найдём друзей его друзей:

    SQL
    select
        Persons_1.rowid ,
        Persons_1.name ,
        Persons_1.age ,
        Persons_2.rowid ,
        Persons_2.name ,
        Persons_2.age
    from
        Persons_friends as friends_1 ,
        Persons_friends as friends_2 ,
        Persons as Persons_1 ,
        Persons as Persons_2
    where
        friends_1.subject = 123 ,
        friends_1.object = Persons_1.rowid ,
        friends_1.object = friends_2.subject ,
        friends_2.object = Persons_2.rowid
    

    OSQL
    select expand( friend )
    from #19:0
    fetchplan *:-2
        name:0
        age:0
        friend.name:0
        friend.age:0
    

    В РСУБД запрос заметно усложнился. По хорошему его нужно усложнить ещё сильнее, чтобы данные друзей первого уровня не дублировались для каждого друга второго уровня.

    Продолжать можно долго, но суть, я думаю, уже ясна. Немного больше подробностей о различиях реляционного подхода и графового можно почерпнуть из презентации "How Graph Databases started the Multi Model revolution".

    На последок отмечу, что в реляционных базах данные хранятся таблицами, но они крайне не эффективны при запросах, поэтому к ним добавляют автогенерируемое дерево — индекс. Причём индексы стараются делать покрывающими, то есть не требующими обращения к собственно таблицам за данными. Так вот, если вырезать таблицы и позволить индексному дереву иметь циклы, то мы получим ни что иное как графовую СУБД, где вся база данных — это один большой максимально эффективный индекс.

    Хватит теории. Что на практике-то?


    Последний год я занимался разработкой бэкенда для проекта SKEDDY (Поиск мастеров и запись к ним на услуги). Звучит вроде бы не сложно, однако число бизнес сущностей сейчас уже равно 20 (20 таблиц сущностей, если бы я использовал РСУБД): person, mail, phone, social, token, application, profession, service, meeting, assessment, album, image, notification, place, track, payment, article, aspect, facet, salon.

    Между ними порядка 50 отношений, из них около 20 являются многими-ко-многим (ещё 20 таблиц смежностей и 20-40 индексов в РСУБД). В OrientDB же потребовался лишь один индекс для трансляции внешних айдишников во внутренние (внешние — человекопонятные и изменяемые, внутренние — персистентные и «странные»), один для фасетного поиска услуг плюс ещё пяток полнотекстовых и всё. Граф полностью нормализован, большинство запросов идут по прямым ссылкам между узлами, что позволяет делать глубокие выборки, не теряя в производительности и наглядности запросов.

    Благодаря графовой модели данных, отображение на неё бизнес модели происходит легко и просто — единожды написанный простой обобщённый код для синхронизации с базой данных, позволил программировать в терминах бизнес сущностей без лишних забот об оптимизации запросов к СУБД. Собственно борьба с AngularJS отняла куда больше времени, но это уже совсем другая история…

    Теперь о недостатках:

    Документация довольно не плоха для основного функционала, но некоторые аспекты в ней отражены крайне слабо. Например, информацию о хуках приходится собирать по крупицам.

    Больше что-то на ум ничего не приходит :-)

    На этом всё. Кто заинтересовался, но что-то недопонял — не стесняйтесь задавать вопросы в комментариях.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Какой тип СУБД вы предпочитаете?

    Поделиться публикацией

    Комментарии 329

      +18
      Наверное СУБД — это все же инструмент. И в зависимости от задачи мы берем тот или иной инструмент (это кстати и к голосованию относится). Универсальных СУБД не существует.
        –17
        Наверное СУБД — это все же инструмент. И в зависимости от задачи мы берем тот или иной инструмент (это кстати и к голосованию относится)
        Это сферическое «правильное» утверждение в вакууме. На практике один хороший шуруповёрт легко заменяет десяток инструментов для разных задач (от миксера до перфоратора).

        Универсальных СУБД не существует.
        Обоснуйте, пожалуйста :-)
          +8
          Возьмите шуруповёрт и попробуйте им проперфорировать бетонную стену. Тоже самое в случае с базами.
            –8
            Прогресс не стоит на месте :-)

              –7
              Или вот ещё один универсальный инструмент, который я недавно себе приобрёл:

                +6
                Угу, а у меня на кухне две разных ступки с пестиками, и сковороды из трех разных металлов. А вы обходитесь «универсальными инструментами».
                  –5
                  Никак не могу уловить какую мысль вы пытались этим донести :-)
                    +7
                    То, что для каждой задачи — свой инструмент. Чем универсальнее инструмент, тем, скорее всего, хуже он выполняет каждую отдельную задачу по сравнению со специализированным.
                      0
                      Тем больше вам нужно инструментов для выполнения разных задач. Тем больше вероятность получить несовместимость, несогласованность. Тем больше точек отказа. Вы только подумайте, что бы было, если бы для выполнения каждой задачи у нас с вами было по отдельной специализированной руке :-)
                        0
                        Тем больше вам нужно инструментов для выполнения разных задач.

                        У меня в каждый конкретный момент задачи ограничены.

                        Тем больше точек отказа.

                        … и тем меньше опасность отказа каждой точки.
                          –2
                          > У меня в каждый конкретный момент задачи ограничены.

                          Только ящик с инструментами бездонный :-)

                          > … и тем меньше опасность отказа каждой точки.

                          Тем больше вероятность отказа хотя бы одной точки. Так и будете спорить с тем, что простые решения надёжней? :-)
                            0
                            Только ящик с инструментами бездонный :-)

                            Не вижу в этом ничего плохого. Особенно в случае с ПО.

                            Так и будете спорить с тем, что простые решения надёжней?

                            Понятие «надежности» нынче не так однозначно, как вам кажется. Какая система «надежнее» — та, которая падает с вероятностью 25%, но вся, или та, в которой с вероятностью 50% происходит потеря части функциональности?
                              –3
                              Не вижу в этом ничего плохого. Особенно в случае с ПО.
                              В случае ПО вы тратите время на интеркоммуникацию и поддержку разных инструментов.

                              Понятие «надежности» нынче не так однозначно, как вам кажется.
                              Я понимаю, что попираю устои, но вы не могли бы вести себя менее спесиво? Спасибо.

                              Какая система «надежнее» — та, которая падает с вероятностью 25%, но вся, или та, в которой с вероятностью 50% происходит потеря части функциональности?
                              Та, в которой не происходит при этом потеря данных и их согласованности :-)
                                +2
                                В случае ПО вы тратите время на интеркоммуникацию и поддержку разных инструментов.

                                Вместо того, чтобы тратить его на попытки забить гвозди гантелей. Я считаю, это выигрыш.

                                Та, в которой не происходит при этом потеря данных и их согласованности

                                Для простоты — в обеих.
                                  –4
                                  Вместо того, чтобы тратить его на попытки забить гвозди гантелей. Я считаю, это выигрыш.
                                  Вы забиваете даже шурупы (деревья, графы) молотком (РСУБД), а я вам предлагаю шуроповёрт (мультимодельную СУБД) и не пользоваться одноразовыми гвоздями (таблицами).

                                  Для простоты — в обеих.
                                  В одной ACID СУБД потерь не будет. Но если вы будете использовать «на каждый чих свой инструмент», то без услуг СУБД без ACID явно не обойдётесь.
                                    0
                                    Вы забиваете даже шурупы (деревья, графы) молотком (РСУБД),

                                    Вы не знаете, что, где и как я делаю.

                                    а я вам предлагаю шуроповёрт (мультимодельную СУБД)

                                    А эта ваша мультимодельная СУБД умеет реляционную модель?

                                    Но если вы будете использовать «на каждый чих свой инструмент», то без услуг СУБД без ACID явно не обойдётесь.

                                    (А вы все еще держитесь за ACID?)

                                    Вопрос был не в этом, а в том, что есть две системы с разными вероятностями отказа (и последствиями этого отказа). Для простоты обсуждения ACID-гарантии у них одинаковые. Какая из них «надежнее»?
                                      –1
                                      А эта ваша мультимодельная СУБД умеет реляционную модель?
                                      Джойны не умеет за не надобностью. Эквивалент таблицы из SQL — класс. orientdb.com/docs/last/Tutorial-Document-and-graph-model.html

                                      А вы все еще держитесь за ACID?
                                      А чего б не держаться за хорошие вещи?

                                      Вопрос был не в этом, а в том, что есть две системы с разными вероятностями отказа (и последствиями этого отказа). Для простоты обсуждения ACID-гарантии у них одинаковые. Какая из них «надежнее»?
                                      При прочих равных комбинация двух технологий не может быть надёжней одной. OrientDB, например, образует аналог RAID но для баз данных, так что отказ одного узла не фатален.
                                        0
                                        Джойны не умеет за не надобностью. Эквивалент таблицы из SQL — класс.

                                        Она еще и индексные оптимизации не умеет (если я, конечно, ничего не путаю).

                                        Та самая ситуация, когда вы мне предлагаете шуруповерт вместо перфоратора… а у меня несущая бетонная стена.

                                        А чего б не держаться за хорошие вещи?

                                        Стоимость реализации?

                                        При прочих равных комбинация двух технологий не может быть надёжней одной.

                                        А откуда вы взяли «комбинацию двух технологий»? Я, вроде бы, говорил о системе в целом.
                                          0
                                          Индексные оптимизации — это вы о чём?

                                          Та самая ситуация, когда вы мне предлагаете шуруповерт вместо перфоратора… а у меня несущая бетонная стена.
                                          Нет нет, если у вас такая прочная стена, то вам стоит в дополнение к универсальному шуруповёрту приобрести перфоратор. А вот дрель можно и не покупать.

                                          Стоимость реализации?
                                          Если стоимость данных меньше стоимости ACID, то да, можно и поиграть с ненадёжными инструментами :-) Но по мне так чем меньше непредсказуемости тем лучше, так что без веских аргументов я бы не стал отказываться от ACID.

                                          А откуда вы взяли «комбинацию двух технологий»? Я, вроде бы, говорил о системе в целом.
                                          Система в целом состоит из разных задач. А к каждой вы предлагаете индивидуальный подход. Я же говорю, что есть инструменты, которые без лишнего оверхеда позволяют решать сразу несколько типов задач. Что в этом плохого — ума не приложу.
                                            0
                                            Индексные оптимизации — это вы о чём?

                                            Вот об этом:

                                            SELECT COUNT(*) FROM SomeData WHERE SomeField = 15
                                            


                                            Работает себе из коробочки полным перебором таблицы. Стало медленно — построили индекс, и внезапно — не трогая кода! — стало быстрее в разы.

                                            Если стоимость данных меньше стоимости ACID, то да, можно и поиграть с ненадёжными инструментами

                                            Вы так говорите, словно кроме ACID надежных инструментов не бывает.

                                            Я же говорю, что есть инструменты, которые без лишнего оверхеда позволяют решать сразу несколько типов задач.

                                            Вот «без лишнего оверхеда» — еще надо доказать.

                                            Но речь здесь шла не о том, а о простом вопросе «как меняется надежность системы с увеличением числа точек отказа». Я привел конкретный пример — вы до сих пор не можете ответить, что происходит с надежностью системы.
                                              0
                                              Работает себе из коробочки полным перебором таблицы. Стало медленно — построили индекс, и внезапно — не трогая кода! — стало быстрее в разы.

                                              Ориент тоже поддерживает индексы разных типов: orientdb.com/docs/last/Indexes.html

                                              Вы так говорите, словно кроме ACID надежных инструментов не бывает.
                                              ACID — это и есть различные аспекты надёжности, без которых данным полученным из БД нельзя доверять.

                                              Я привел конкретный пример — вы до сих пор не можете ответить, что происходит с надежностью системы.
                                              Мы ходим по кругу. Мне нечего добавить к тому, что я уже сказал.
                                                0
                                                Ориент тоже поддерживает индексы разных типов: orientdb.com/docs/last/Indexes.html

                                                Какой-то из них работает так, как описано в моем примере?

                                                ACID — это и есть различные аспекты надёжности, без которых данным полученным из БД нельзя доверять.

                                                Вот только ACID на распределенных системах на редкость дорог, и поэтому чаще не используется, чем используется. Но вы все равно пользуетесь этими системами (и доверяете им). И даже на не-распределенной БД можно жить без полноценного ACID. С ним, конечно, легче (пока вы не строите высоконагруженную систему), но и без него можно.
                                                  0
                                                  Разумеется.

                                                  Он дорог лишь при большом числе реплик, но не шардов. Ориент позволяет гибко настроить как кластеры (наборы однотипных узлов данных) раскидываются по узлам (инстансам субд).
                                                    0
                                                    Разумеется.

                                                    Я так понимаю, это про индексы… вы, конечно же, можете показать, где в документации написано, что с момента построения индекса по полям все запросы по этим полям автоматически попадают в индекс?

                                                    Он дорог лишь при большом числе реплик, но не шардов.

                                                    Ровно наоборот. Количество реплик не влияет на стоимость ACID (если вы, конечно, не включаете в ACID write-quorum, которого там не было изначально). А вот каждый шард — это, потенциально, новая нода в распределенной транзакции.

                                                    (да, а еще бывают распределенные транзакции между несколькими экземплярами/системами)
                                                      0
                                                      Я так понимаю, это про индексы… вы, конечно же, можете показать, где в документации написано, что с момента построения индекса по полям все запросы по этим полям автоматически попадают в индекс?
                                                      Интересно, почему вы сомневаетесь, что это так? :-) Индексы работают также как в любой РСУБД. Можете проверить это explain-ом.

                                                      Количество реплик не влияет на стоимость ACID (если вы, конечно, не включаете в ACID write-quorum, которого там не было изначально).
                                                      Куда ж без него? Если кворум не будет достигнут, то транзакция не пройдёт, а мы уже отчитались, что прошла.

                                                      А вот каждый шард — это, потенциально, новая нода в распределенной транзакции.
                                                      А реплика — гарантированная новая нода в распределённой транзакции.

                                                      (да, а еще бывают распределенные транзакции между несколькими экземплярами/системами)
                                                      А мы сейчас о чём говорили?
                                                        0
                                                        Интересно, почему вы сомневаетесь, что это так?

                                                        Потому в документации написано, что обращение к индексу делается через префикс, и нигде не написано иного. Если это не так — прекрасно.

                                                        Куда ж без него? Если кворум не будет достигнут, то транзакция не пройдёт, а мы уже отчитались, что прошла.

                                                        Это если кворум на запись больше единицы.

                                                        А реплика — гарантированная новая нода в распределённой транзакции.

                                                        Только если вы используете стопроцентный кворум на запись.

                                                        А мы сейчас о чём говорили?

                                                        Об операциях внутри одной системы (потому что и реплики, и шардинг — это одна система).
                                                          0
                                                          Потому в документации написано, что обращение к индексу делается через префикс, и нигде не написано иного. Если это не так — прекрасно.
                                                          Это просто дополнительный функционал. Узлы индексов — это те же узлы графа на низком уровне.

                                                          Это если кворум на запись больше единицы.
                                                          Если кворум меньше большинства.

                                                          Об операциях внутри одной системы (потому что и реплики, и шардинг — это одна система).
                                                          Имеются ввиду транзакции между разными СУБД? Ну, я про такие не слышал. Разве что через приложение.
                                                            0
                                                            Это просто дополнительный функционал. Узлы индексов — это те же узлы графа на низком уровне.

                                                            Это само по себе ни о чем не говорит и ничего не обещает.

                                                            Если кворум меньше большинства.

                                                            Эээ… вы как-то по-своему понимаете кворум. Write quorum — это число реплик, которые должны рапортовать, что запись прошла успешно, прежде чем она будет признаной успешной системой в целом. Большинство тут ни при чем. Соответственно, транзакция становится распределенной в тот момент, когда write quorum больше единицы.

                                                            Имеются ввиду транзакции между разными СУБД?

                                                            Между разными системами — СУБД не единственный транзакционный ресурс.

                                                            Ну, я про такие не слышал.

                                                            А зря. Они есть, и они составляют немалую головную боль.
                                                              0
                                                              Транзакция становится распределённой, когда затрагивает несколько узлов. Моё замечание про большинство касалось случая отката транзакции. Если вы не дожидаетесь завершения транзакции (writeQuorum < majority), то получаете нарушение Durability.

                                                              Не слышал — в смысле реализаций такого в СУБД, а не вообще.
                                                                0
                                                                Не слышал — в смысле реализаций такого в СУБД, а не вообще.

                                                                В MS SQL есть, например. Другое дело, что все равно эта реализация рано или поздно упирается в ограничения (или принципиальную невозможность), и вы вынуждены делать систему, не имеющую ACID в одной из точек. После этого, внезапно, становится понятно, как работать с системами, которые имеют очень ограниченные ACID-гарантии.
                                                                  0
                                                                  И как же, например?
                                                                    0
                                                                    Через компенсации и eventual consistency. Если грубо, то аналогично тому, как проходят списания по пластиковым картам.
                                                                      0
                                                                      Ну то есть путём усложнения процессов. В случае гетерогенных систем это необходимость. Но стоит ли самому себе вставлять палки в колёса?
                                                                        +1
                                                                        Во-первых, почти любая сложная система в бизнесе — гетерогенная (по крайней мере, в моем опыте всегда получалось так). Во-вторых, ей достаточно быть распределенной (две БД одного производителя, не состоящие в кластере), чтобы эти проблемы начали проявляться.

                                                                        В-третьих — CAP-«теорема».
                                                                          –1
                                                                          Поэтому давайте напихаем побольше разных no-acid систем, чтобы «всё как у взрослых»? :-)

                                                                          Вот именно, что «теорема» :-)
                                                                            0
                                                                            Поэтому давайте напихаем побольше разных no-acid систем, чтобы «всё как у взрослых»?

                                                                            Нет, поэтому давайте не будем ограничивать себя только теми архитектурами, которые дают ACID в границах системы.

                                                                            Вот именно, что «теорема»

                                                                            Опровергнуть ее тоже пока никому не удалось. Собственно, OrientDB ей удовлетворяет.
                                                                              0
                                                                              И всё же тем, что дают ACID стоит, отдать предпочтение.

                                                                              (http://habrahabr.ru/post/231703/)[Давайте не будем снова вспоминать эти глупости.] :-)
                                                                                0
                                                                                И всё же тем, что дают ACID стоит, отдать предпочтение.

                                                                                Ну да, нам всем хочется жить в идеальном мире.

                                                                                Давайте не будем снова вспоминать эти глупости

                                                                                Ничего глупого в CAP нет. Она просто помогает правильным образом понимать некоторые компромисы.
                                                                                  0
                                                                                  Скорее запутывает, внося неожиданные определения привычных терминов.
                                                                                    0
                                                                                    Множественное число лишнее — только consistency. Ну и да, ничего неожиданного в использованном там определении, если смотреть на распределенные системы, нет.

                                                                                    В частности, как уже говорилось, Orient не поддерживает consistency в понимании CAP-теоремы, и при этом еще и отказывается от availability при сетевом отказе… так себе компромис, будем честными.
                                                                                      0
                                                                                      В Ориенте это всё гибко настраивается: http://www.slideshare.net/lvca/orientdb-distributed-architecture-11
                                                                                        0
                                                                                        Его можно сделать полностью строго консистентным при распределенной архитектуре? А как тогда понимать следующую фразу из документации:

                                                                                        During the distributed transaction, in case of rollback, there could be an amount of time when the records appear changed before they are rollbacked.

                                                                                          0
                                                                                          «In case one or more nodes fail on commit, the quorum is checked. If the quorum has been respected, then the failing nodes are aligned to the winner nodes, otherwise all the nodes rollback the transaction.»
                                                                                          Ну то есть, если не используются локи и master-slave конфигурация, то такая ситуация вполне возможна из-за конкурирующей транзакции.
                                                                                            0
                                                                                            А если используется мастер-слейв, и связь между мастером и слейвом нарушена — что будет при записи?
                                                                                              0
                                                                                              На сколько я понимаю слейв будет выкинут из кластера и все клиенты переподключатся к мастеру.
                                                                                                0
                                                                                                … это если мастер доступен оттуда, откуда клиенты стучались к слейву.

                                                                                                Но, как видите, ориент прекрасно иллюстрирует треугольник CAP: при отсутствии сетевой связности вы можете иметь либо консистентную систему, пожертвовав доступностью и производительностью (пример с мастер-слейвом), либо HA/HL-систему, пожертвовав строгой консистентностью (пример с мульти-мастером и, желательно, кворумом меньше 100%)
                                                                                                  –1
                                                                                                  Не уверен можно ли в Ориенте сделать так, чтобы слейв давал отлуп при потере синхронизации.

                                                                                                  Как видите вы сами, гаворя о CAP, используете другие термины (консистентность, доступность, производительность). А то что мы не можем обеспечить синхронизацию, если между узлами нет связи, и как следствие вынуждены выбирать отказывать ли в обслуживании или выдавать устаревшие данные — это очевидно без всяких «теорем».
                                                                                                    +1
                                                                                                    Как видите вы сами, гаворя о CAP, используете другие термины (консистентность, доступность, производительность).

                                                                                                    Как же другие? Consistency, availability. Просто в CAP «производительность» заложена в «доступность», потому что доступность ограничена во времени.
                                                                                                      0
                                                                                                      Факт номер 2 в упомянутой мной выше статье как раз об этом :-)
                                                                                                        0
                                                                                                        Тогда в чем ваши претензии к CAP? Она есть, и orientdb ее очередной раз подтверждает.
                                                                                                          0
                                                                                                          http://habrahabr.ru/post/267079/#comment_8581265
                                                                                                            0
                                                                                                            Примеры в студию.
                          0
                          Да, кстати, по поводу «тем больше точек отказа».

                          Когда у меня отказывает «шуруповерт-дрель-перфоратор» — я не могу ни заворачивать шурупы, ни сверлить, ни долбить стены. Когда у меня отказывает шуруповерт — я могу взять отвертку, а дырки делать дрелью. Когда отказывает перфоратор — заворачивать шурупы в уже пробитые дырки.
                            0
                            Достаточно иметь запасной шуруповёрт и когда отказывает один — делать дырки, заворачивать шурупы и долбить стены другим, не теряя возможности делать что-то из этих действий. При этом иметь взаимозаменяемые между ними детали.
                              +1
                              Достаточно иметь запасной шуруповёрт и когда отказывает один — делать дырки, заворачивать шурупы и долбить стены другим, не теряя возможности делать что-то из этих действий.

                              И вы что-то говорите о бездонном ящике для инструментов? Иметь по две (как минимум) копии каждого инструмента?
                                0
                                Не каждого, а одного универсального. А вот вам для обеспечения того же уровня надёжности придётся дублировать уже каждый специализированный инструмент.
                                  0
                                  Не бывает совсем универсальных инструментов (вы не замените шуруповертом пилу).

                                  И да, мне не нужен тот же уровень надежности, мне достаточно ситуации, когда при отказе одного инструмента не останавливается весь рабочий процесс.
                                    –1
                                    Не бывает совсем универсальных инструментов (вы не замените шуруповертом пилу).
                                    Конечно, но и задачи-то в большинстве случаев типовые, а не «уникальные».

                                    И да, мне не нужен тот же уровень надежности, мне достаточно ситуации, когда при отказе одного инструмента не останавливается весь рабочий процесс.
                                    Если у вас отказал перфоратор, то вы не сможете пробурить отверстие, чтобы завинтить в него шуруп отвёрткой.
                                      0
                                      Если у вас отказал перфоратор, то вы не сможете пробурить отверстие, чтобы завинтить в него шуруп отвёрткой.

                                      Как уже говорилось выше, у меня есть другие набуренные отверстия. Если нет — ну что ж, горе мне, сегодня я отдыхаю.

                                      (ну или пойду полочки скручивать, для этого мне перфоратор не нужен)
                  0
                  Угу. Моя несущая бетонная стена передает этим «шуруповертам» пламенный привет.
                    –3
                    Вы пробовали или теоретизируете?
                      +2
                      Эти конкретные не пробовал (а что их пробовать, в них все равно бур на 25 не влезет), а вообще на моей стенке заткнулось три разных дрели (дрели! не шуруповерта).

                        0
                        Собственно, даже в видео видно, с каким мучением они сверлят какой-то непонятный камень.
                          –1
                          Бур на 25 и в перфоратор-то не в каждый влезет :-) Сочувствую вашему горю, ваши специфические условия требуют специфического инструмента. Именно поэтому я выделил жирным ремарку «когда в этом есть необходимость». Но если необходимость не продиктована особо прочными стенами, то не вижу смысла покупать кучу специализированных инструментов.

                          Да какие там мучения? Что лёгкий инструмент сильнее вибрирует? или что медленно сверлит? Не такая уж большая жертва за мобильность.
                            +2
                            Сочувствую вашему горю, ваши специфические условия требуют специфического инструмента.

                            Ура, вы наконец-то с этим согласились.

                            Да какие там мучения? [...] или что медленно сверлит?

                            Медленно сверлит — видно, что не хватает мощности — на более прочной стене заткнется — даже на этой стене будет садиться аккумулятор чаще, чем надо — чем дольше работаешь, тем больше устаешь.

                            Я, знаете ли, очень ценю, что почти любая дырка в моей стене делается моим перфоратором за секунды.
                              0
                              А я с этим и не спорил. Не всем же так повезло как вам :-)

                              Если бы я каждый день делал дырочки — я бы наверно тоже это ценил. А вот раз в месяц — ничего страшного, если потребуется чуть больше времени.
                                0
                                А мне и раз в месяц жалко свое время и силы.
                                  +4
                                  Ребята, вы, случайно, ремонтами не занимаетесь?
                                    0
                                    Я завязал…
                      0
                      Пора завязывать на сегодня: сперва прочитал Postgres не стоит на месте
                +9
                Невероятно кульно, а теперь сравним размеры индексов и бенчмарки с банальными «прямоугольными табличками».
                  –13
                  Вы думаете 40 частично денормализованных таблиц и 60 индексов на них будут весить меньше, чем один нормализованный граф с 20 классами узлов? :-)
                    –9
                    Другого ответа я и не ожидал на передовом IT-ресурсе :-)
                      0
                      То, что я думаю, часто не совпадает с тем, что есть на самом деле.
                      Приведите Ваши реальные сравнения, что сколько весит и каково время выполнения запросов в каждом случае, только после этого можно о чем-то говорить всерьез.
                        0
                        Я же писал, всё сильно зависит от задачи и того как её решают. Выбирайте задачу, на которой будем сравнивать :-)
                        +7
                        Мы не хотим думать, просто дайте нам конкретные бенчмарки — конфигурация, ресурсы, скорость.
                          0
                          Ну ок, вот замеры, которые я проводил год назад на реальной базе: docs.google.com/spreadsheets/d/1GHwY63pOMlipNJgbRKAzXtlfa64shWagpXgdWTHiWUo/edit
                          У меня не стояла задача всесторонне исследовать производительность — просто показать, что оно как минимум не хуже и имеет смысл присмотреться.
                            +2
                            Угу, вот прямо первая же метрика потрясает:

                            Размер на диске:
                            PostgreSQL: 600mb
                            OrientDB: 750mb
                            Вывод: объемы сопоставимы.

                            Разница в 25% — это для вас «сопоставимы».

                            Замеры скорости, сделанные разными инструментами — тоже доставляют.

                            Ну и, наконец, тестируете вы на конкретной задаче, которая для графов выгодна.
                              –2
                              Да, сопоставимы. 25% — это во первых не такая уж большая разница. А во вторых, там было много дубликатов связей из денормализованной SQL базы, которые графовую базу только раздували и замедляли.

                              Замеры скорости имеют фору у PostgreSQL ибо он напрямую общался с СУБД по бинарному протоколу, а не через JS прослойку в NodeJS.

                              Тестировал я на наиболее частом и сложном запросе. Вы бы не придирались :-) Если бы эти замеры доказывали неоспоримые преимущества OrientDB перед PostgreSQL по всем показателям на всех задачах, я бы пренепременно упомянул их в статье. Возьмите и проверьте на своих задачах и сделайте выводы. Сейчас же вы просто уверены, что «ничего не может быть быстрее моей любимой СУБД» и требуете от меня доказательств обратного.
                                +2
                                25% — это во первых не такая уж большая разница.

                                Когда у вас размеры БД измеряются терабайтами, вы будете иначе к этому относиться.

                                А во вторых, там было много дубликатов связей из денормализованной SQL базы, которые графовую базу только раздували и замедляли. [...] Замеры скорости имеют фору у PostgreSQL ибо он напрямую общался с СУБД по бинарному протоколу, а не через JS прослойку в NodeJS.

                                Это означает, что ваше тестирование некорректно.

                                Тестировал я на наиболее частом и сложном запросе.

                                Наиболее частом и сложном для вашей системы. А в «моей» системе таких запросов нет, зато дофига объемных выборок с отбором, группировкой и агрегатами.

                                Сейчас же вы просто уверены, что «ничего не может быть быстрее моей любимой СУБД» и требуете от меня доказательств обратного.

                                Вот еще. Я точно знаю, что есть СУБД, которые быстрее тех СУБД, которыми я пользуюсь. Заодно я знаю, благодаря чему это происходит, и что я теряю, чтобы приобрести эту скорость.
                                  0
                                  Когда у вас размеры БД измеряются терабайтами, вы будете иначе к этому относиться.
                                  С чего бы? Плюс-минус террабайт в таких масштабах погоды не делают. А погоду делают совсем другие метрики. Возможности масштабирования, например.

                                  Это означает, что ваше тестирование некорректно.
                                  Оно достаточно корректно для поставленной задачи.

                                  Наиболее частом и сложном для вашей системы. А в «моей» системе таких запросов нет, зато дофига объемных выборок с отбором, группировкой и агрегатами.
                                  Разумеется. Вы же хотели конкретный пример — вы его получили. А теперь жалуетесь, что он имеет мало чего общего с вашими задачами.

                                  Вот еще. Я точно знаю, что есть СУБД, которые быстрее тех СУБД, которыми я пользуюсь. Заодно я знаю, благодаря чему это происходит, и что я теряю, чтобы приобрести эту скорость.
                                  Ну раз вы всё знаете наперёд без тестирования, то мне нечего вам возразить :-)
                                    0
                                    Плюс-минус террабайт в таких масштабах погоды не делают.

                                    Вообще-то, они денег стоят. Денег и времени.

                                    Ну раз вы всё знаете наперёд без тестирования, то мне нечего вам возразить

                                    Я как раз знаю на основании тестирования, по большей части.
                                      –2
                                      А ещё можно зиповать данные в базе, если жёсткие диски такие дорогие :-)

                                      Вы тестировали OrientDB на своих задачах?
                                        0
                                        Нет, не тестировал. У меня (сейчас) нет задач, требующих документо-ориентированной или графо-ориентированной БД.
                                  0
                                  25% в кровавом энторпрайсе — это, порой десятки терабайт, а то и сотни. Это, во-первых, SAN. Это резервирование в территориально-распределенных ДЦ. Это бэкапы. Это, в конце-концов, новые стойки в ДЦ. Но самое главное, это всё надо согласовать. На согласование +25% SAN уйдет больше ресурсов организации, чем на преимущества от внедрения модной СУБД.
                                    –2
                                    Вы так говорите будто объёмы данных не растут просто по естественным причинам чуть ли не удваиваясь каждый год.
                                      +1
                                      Речь идет о сопоставимости, а не совпадении.
                                      25% это всегда 25%, независимо от того составляют они десятки терабайт или сотни петабайт.
                                    +1
                                    А что? Для вас 25% — это несопоставимы? Это же не в 3 раза, правда? Ведь самый ценный ресурс в Enterprise это время разработчиков и время простоя системы из-за багов, так? А купить лишних винчестеров они не пожалеют денег…

                                    тестируете вы на конкретной задаче, которая для графов выгодна

                                    Так автор, как мне показалось, как раз стремится доказать, что таких «выгодных» — большинство.
                                      0
                                      Для вас 25% — это несопоставимы?

                                      Для меня 25% могут иметь существенное значение при оценке.

                                      Так автор, как мне показалось, как раз стремится доказать, что таких «выгодных» — большинство.

                                      К сожалению, я не вижу даже попытки такого доказательства.
                            +11
                            Знатно вы набросали на… вентиль
                              +2
                              Для разных зада, свои БД :)
                                0
                                Да для них БД не нужны, мне кажется :)
                                  0
                                  Да я всё жду, когда же будет клавиатура, которая будет из мозга печатать, а то мои пальцы намного медленнее мыслей :(
                                +4
                                Ваш атниконформизм заключается в том, что вы назло всем неправильно пишете слово нонконформизм?
                                  0
                                  А вы сами-то читали статью, на которую ссылаетесь? :-)
                                  Нонконформи́зм — стремление индивида придерживаться и отстаивать установки, мнения, результаты восприятия, поведение и так далее, прямо противоречащие тем, которые господствуют в данном обществе или группе. Часто считается синонимом понятия «негативизм» и антонимом понятия «конформизм». В некоторых случаях нонконформизмом называют просто готовность индивида отстаивать свою личную позицию в тех случаях, когда она противоречит позиции большинства. В таких случаях описанное в данной статье явление выделяют под названием «антиконформи́зм»
                                    +2
                                    Вы сами-то читали, что запостили?
                                    готовность индивида отстаивать свою личную позицию в тех случаях, когда она противоречит позиции большинства
                                    и
                                    человек, который не держится за свои привычки и всегда готов их поменять, если в том есть необходимость
                                    совсем не одно и тоже. Ваше опредление больше похоже на лабильность
                                      +1
                                      В данном контексте это родственные понятия. Если вам так станет легче — можете считать, что уделали меня в этом терминологическом споре :-)

                                      На «лабильность психики» уж точно не похоже.
                                  +3
                                  http://orientdbleaks.blogspot.com/2015/06/the-orientdb-issues-that-made-us-give-up.html

                                  Хорошую базу вы для продакшена выбрали. Главное, что не пришлось над дизайном и запросами к РСУБД думать.
                                    –1
                                    Скандалы, интриги, расследования… как-то много уж в той статье притянутых за уши пунктов. То форкнули проект на ГитХабе, не спросив разрешения, то удалили тег «bug» с не актуальных репортов. На тему стабильности — сам я не сталкивался с такими проблемами за тот же год, но я и не обновлял СУБД каждый месяц на последнюю версию. Тем не менее те репорты, что я создавал — довольно быстро фиксились. Я бы тоже предпочёл, чтобы багов не было вообще и всё сразу было идеально :-)

                                    Но альтернатив у OrientDB я особо не вижу. Возвращаться на реляционные — боже упаси. И не потому, что я не люблю думать о дизайне и запросах, а именно потому, что я люблю думать о дизайне. А дизайн реляционной базы — это всегда костыль на костыле и приходится решать проблемы, которых вообще быть не должно при правильном дизайне.
                                      +1
                                      А дизайн реляционной базы — это всегда костыль на костыле

                                      Серьезно? Всегда?
                                        –1
                                        А разве есть контр-пример не уровня «привет мир»?
                                          +1
                                          Конечно. Многие классические учетные задачи.
                                            –1
                                            Приведите пример хотя бы одной, что ли.
                                              0
                                              Да легко.

                                              Вот организация учитывает находящиеся в ее собственности запасы нефти, газа и разных ценных металлов. Ее интересует — на каждый отчетный момент — общая стоимость запасов, а так же стоимость в разбивке по конкретному наименованию, виду, учетной категории и складу. И все то же самое — по объему и весу.

                                              Как мы понимаем, для РСУБД это очень простая по дизайну задача. И я что-то не вижу там ни одного, как вы выражаетесь, костыля.
                                                0
                                                Костыли начнутся, когда надо будет строить отчёты по параметрам, а параметры у всех типов ресурсов разные. Придётся либо каждый ресурс в отдельной таблице хранить, либо выносить параметры в отдельную таблицу и приджойнивать её. Это ещё одна фундаментальная проблема РСУБД, которую я забыл упомянуть.
                                                  0
                                                  Вот если такая ситуация случится, то можно будет смотреть, насколько костыльно такое решение. Я-то не вижу фундаментальной проблемы ни в одном, ни в другом, ни в третьем известном мне решении.
                                                    –4
                                                    Ну ок, вот мы и нашли область применения реляционный СУБД. Довольно узкая область, надо сказать :-)
                                                      0
                                                      Угу, очень узкая — львиная доля всех количественных отчетов, включая чуть менее, чем все финансы.
                                                        0
                                                        В довольно редком приложении есть только отчёты :-)
                                                          0
                                                          Но отчеты очень удобно строить по реляционной БД (или по OLAP, который тоже работает по реляционной БД). А дальше либо оказывается, что вносить в нее данные тоже удобно, либо, если неудобно, на внесение данных берется другое хранилище.
                                                            0
                                                            Да также как и по графовой, в принципе. Индексы — не прерогатива реляционных баз.
                                                              0
                                                              Напомню, что изначально вы утверждали, что дизайн реляционной БД — всегда костыль на костыле. А сейчас мы дошли до того, что «ну и на графовой так сделать можно».
                                                                –2
                                                                Кроме той маленькой области, да, костыль на костыле.
                                                                1. многие-ко-многим — костыли
                                                                2. деревья — костыли
                                                                3. большое разнообразие свойств — костыли
                                                                Без всего этого, ниша сужается до области OLAP, где опять же рулят не реляционные СУБД.
                                                                  0
                                                                  маленькой

                                                                  Маленькой, серьезно?

                                                                  многие-ко-многим — костыли

                                                                  А почему вы считаете промежуточную таблицу костылем, кстати? Это всего лишь стандартный шаблон, вполне логично описывающий происходящее.

                                                                  деревья — костыли

                                                                  «Костыли» нужны, когда вы хотите иметь эффективные выборки по определенными видам деревьев. Это нужно не всегда. И, в общем-то, некоторые СУБД уже включают встроенную поддержку деревьев, так что тут тоже костыли пропали.

                                                                  большое разнообразие свойств — костыли

                                                                  Нет там никаких костылей.

                                                                  ниша сужается до области OLAP, где опять же рулят не реляционные СУБД.

                                                                  … а какие?
                                                                    –1
                                                                    А почему вы считаете промежуточную таблицу костылем, кстати? Это всего лишь стандартный шаблон, вполне логично описывающий происходящее.
                                                                    Лишняя сущность, усложняющая работу, замедляющая выборки.

                                                                    «Костыли» нужны, когда вы хотите иметь эффективные выборки по определенными видам деревьев.
                                                                    Было бы странно хотеть неэффективные выборки)

                                                                    И, в общем-то, некоторые СУБД уже включают встроенную поддержку деревьев, так что тут тоже костыли пропали.
                                                                    Наличие встроенной поддержки костылей не делает их более эффективными. рекурсивные запросы не избавляют от сложности log(N) каждого хопа, где N — число записей в таблице. ordpath не избавляет от обновления кучи узлов при изменении дерева.

                                                                    Нет там никаких костылей.

                                                                    Да ну? И как же без костылей засунуть в РСУБД гетерогенные сущности?

                                                                    … а какие?
                                                                    Тут я не специалист, но говорят колоночные рулят в этой области.
                                                                      +1
                                                                      Лишняя сущность, усложняющая работу, замедляющая выборки.

                                                                      У вас есть реальные тесты, подтверждающие замедление?

                                                                      Было бы странно хотеть неэффективные выборки)

                                                                      Иногда конкретный вид выборок никого не волнует (его просто нет в бизнес-кейсе).

                                                                      Наличие встроенной поддержки костылей не делает их более эффективными. рекурсивные запросы не избавляют от сложности log(N) каждого хопа, где N — число записей в таблице. ordpath не избавляет от обновления кучи узлов при изменении дерева.

                                                                      Понимаете ли, если для меня работа с деревом прозрачна, и скорость меня устраивает — чего еще мне хотеть?

                                                                      Да ну? И как же без костылей засунуть в РСУБД гетерогенные сущности?

                                                                      А в чем проблема?
                                                                        –2
                                                                        У вас есть реальные тесты, подтверждающие замедление?
                                                                        Временная сложность алгоритмов для вас не достаточный аргумент? У каждого джойна она О(n*log(N)) при использовании индекса.

                                                                        Иногда конкретный вид выборок никого не волнует (его просто нет в бизнес-кейсе).
                                                                        Мы опять скатились к ограничению области применимости РСУБД: «когда плевать на эффективность выборки» или «только для небольших иерархий».

                                                                        А в чем проблема?
                                                                        В том, что в одной таблице могут быть лишь гомогенные сущности.
                                                                          0
                                                                          Временная сложность алгоритмов для вас не достаточный аргумент?

                                                                          Нет. Когда мы начинаем говорить о конечной производительности, константы тоже имеют значение.

                                                                          У каждого джойна она О(n*log(N)) при использовании индекса.

                                                                          Только если стоимость прохода по индексу — O(log(N))

                                                                          Мы опять скатились к ограничению области применимости РСУБД: «когда плевать на эффективность выборки»

                                                                          Извините, но… нет. Сами по себе РСУБД дают очень эффективный механизм выборок.

                                                                          В том, что в одной таблице могут быть лишь гомогенные сущности.

                                                                          А внутри одного класса в ООП могут быть только объекты этого класса. И что?
                                                                            0
                                                                            Нет. Когда мы начинаем говорить о конечной производительности, константы тоже имеют значение.
                                                                            Есть основания полагать, что константы при прямых ссылках больше?

                                                                            Только если стоимость прохода по индексу — O(log(N))
                                                                            А есть индексы с меньшей сложностью?

                                                                            Извините, но… нет. Сами по себе РСУБД дают очень эффективный механизм выборок.
                                                                            Не более эффективный, чем в любой другой СУБД с поддержкой индексов. Алгоритмы одни и те же.

                                                                            А внутри одного класса в ООП могут быть только объекты этого класса. И что?
                                                                            То, что в ООП есть полиморфизм. А в РСУБД всё гвоздями приколочено к таблицам. И один индекс на несколько таблиц не построить, и выборка из 100 таблиц требует полного перечисления их имён и связей между ними.
                                                                              0
                                                                              Есть основания полагать, что константы при прямых ссылках больше?

                                                                              Есть основания полагать, что мы ничего о них не знаем. Равно как и о цене поддержки.

                                                                              А есть индексы с меньшей сложностью?

                                                                              Orient же утверждает, что сделал доступ O(1) к произвольному элементу БД. Значит, ничего не мешает сделать так же организованный доступ и в РСУБД.

                                                                              Не более эффективный, чем в любой другой СУБД с поддержкой индексов. Алгоритмы одни и те же.

                                                                              Это утверждение работает в любую сторону.

                                                                              То, что в ООП есть полиморфизм.

                                                                              … создающий кучу реализационных проблем регулярно.

                                                                              И один индекс на несколько таблиц не построить

                                                                              Построить. Но зачем?

                                                                              и выборка из 100 таблиц требует полного перечисления их имён и связей между ними.

                                                                              Плата за структуру.
                                                                                –1
                                                                                Orient же утверждает, что сделал доступ O(1) к произвольному элементу БД. Значит, ничего не мешает сделать так же организованный доступ и в РСУБД.
                                                                                Архитектура мешает. Нужно не просто id в поле хранить, но и поддерживать такие значения как linkmap, linkset, linklist.

                                                                                … создающий кучу реализационных проблем регулярно.
                                                                                Каких же?

                                                                                Построить. Но зачем?
                                                                                Как? И что значит зачем? Чтобы делать выборку по одному индексу, а не по 100.

                                                                                Плата за структуру.
                                                                                Полиморфизм позволяет не платить за структуру.
                                                                                  +1
                                                                                  Нужно не просто id в поле хранить, но и поддерживать такие значения как linkmap, linkset, linklist.

                                                                                  Зачем? Если мы можем сделать O(1) доступ по ключу, то дальше стоимость выборки коллекции — O(n) даже в случае реализации с дополнительной таблицей.

                                                                                  Каких же?

                                                                                  Необходимость придерживаться LSP, например. Про проблему квадрата и прямоугольника слышали?

                                                                                  Полиморфизм позволяет не платить за структуру.

                                                                                  Спорный тезис. Насколько я помню, сама по себе поддержка наследования в языке приводит к (некоторым) потерям производительности.
                                                                                    –1
                                                                                    O(1) по ключу мы можем добиться лишь потратив O(N) памяти.

                                                                                    К полиморфизму проблемы наследования относятся очень опосредованно.

                                                                                    Во первых мы про СУБД, а не про ЯП говорим. А во вторых, не все языки одинаково бесполезны.
                                                                                      +1
                                                                                      O(1) по ключу мы можем добиться лишь потратив O(N) памяти.

                                                                                      Передайте это ориенту, ага?

                                                                                      Во первых мы про СУБД, а не про ЯП говорим. А во вторых, не все языки одинаково бесполезны.

                                                                                      Я, если честно, не знаю, что вы понимаете под полиморфизмом в СУБД.
                                                                                        0
                                                                                        Передал, говорит у него там O(n) по памяти, где n — число связей с заданным именем в заданном узле. И эта сложность не зависит от общего числа узлов в графе. В отличие от индексов.

                                                                                        Полиморфизм примерно в этом:

                                                                                        create class Cart
                                                                                        create class Product
                                                                                        create class Database extends Product
                                                                                        create class Framework extends Product
                                                                                        
                                                                                        create property Cart linklist Product
                                                                                        create property Product.name string
                                                                                        create property Product.price decimal
                                                                                        create property Database.acid boolean
                                                                                        create property Framework.language string
                                                                                        
                                                                                        create index Product.price notunique
                                                                                        
                                                                                        insert into Database content { "name" : "OrientDB" , "acid" : true , price : 0 }
                                                                                        insert into Framework content { "name" : "NodeJS" , "language" : "javascript" , price : 0 }
                                                                                        
                                                                                        select from Product where price < 1000
                                                                                        
                                                                                          0
                                                                                          Передал, говорит у него там O(n) по памяти, где n — число связей с заданным именем в заданном узле. И эта сложность не зависит от общего числа узлов в графе. В отличие от индексов.

                                                                                          Индексы здесь вообще ни при чем — они для данной задачи не нужны, весь доступ осуществляется по основному ключу (я под индексом понимаю вторичный индекс). Так что я не очень понимаю, почему, если считать, что O(1) по ключу — достижимы, то нельзя сделать выборку коллекции за O(n), не используя никаких дополнительных типов.

                                                                                          Полиморфизм примерно в этом:

                                                                                          Вы правда не знаете, как это реализуется в реляционных СУБД? Я знаю три традиционных способа, дающих разные преимущества (и больше одного ОРМ, который сделает это незаметно для меня).

                                                                                          Вообще, конечно, выглядит красиво, ничего не скажешь. Но вопрос производительности остается неочевидным.
                                                                                            –2
                                                                                            Первичный индекс ни чем не лучше вторичного, кроме того, что его не нужно явно объявлять.

                                                                                            Я даже 4 способа знаю разной степени костыльности :-)
                                                                                              0
                                                                                              Ну во-первых, первичный индекс лучше тем, что одна операция доступа вместо двух, а в случае ключа — еще и уникальность гарантирована.

                                                                                              А во-вторых, повторю вопрос: если предположить, что используется доступ по ключу с константной стоимостью (т.е. то, что утверждается в ориенте), что мешает организовать проход по коллекции за линейное время (от объема коллекции)?
                                                                                                0
                                                                                                В Ориенте доступ по ключу не за константное время, а за тот же логарифм. Другое дело, что ссылки — это не ключи, а физические координаты. РСУБД же нужно используя первичный индекс транслировать логический адрес (идентификатор) в физический (имя файла + смещение).
                                                                                                  0
                                                                                                  Фундаментальной разницы между ключом и физическими координатами — нет, можно использовать физические координаты в качестве ключа. Правда, тут РСУБД (если мы хотим сохранить семантику) все-таки понадобится индекс…

                                                                                                  И вот пока я думал эту мысль, до меня внезапно дошла простая вещь, которую я почему-то пропустил раньше. Помните вот этот диалог?

                                                                                                  Только если стоимость прохода по индексу — O(log(N))

                                                                                                  А есть индексы с меньшей сложностью?


                                                                                                  Так вот, индексы с меньшей сложностью есть. У хэш-таблицы амортизированная сложность доступа — O(1).
                                                                                                    0
                                                                                                    Чтобы хеш таблица работала за O(1) необходим непрерывный участок памяти объёмом O(N). И это без хеширования. С хешированием у нас появляется вероятность коллизии и тогда объём памяти нужно кратно увеличить, чтобы коллизии происходили не слишком часто. Кроме того, хеш таблицы очень дорого перестраивать для поддержки больших объёмов данных.
                                                                                                      0
                                                                                                      Чтобы хеш таблица работала за O(1) необходим непрерывный участок памяти объёмом O(N).

                                                                                                      Не обязательно памяти. Любого хранилища.

                                                                                                      Кроме того, хеш таблицы очень дорого перестраивать для поддержки больших объёмов данных.

                                                                                                      А вот это вопрос констант как раз, который вы раньше проигнорировали.
                                                                                                        0
                                                                                                        Я говорил не только про оперативную память.

                                                                                                        Не игнорировал. И тут дело не в константах, а именно в алгоритмической сложности ресайза. Бинарные деревья куда лучше приспособлены для больших объёмов.
                                                                                                          0
                                                                                                          Я говорил не только про оперативную память.

                                                                                                          Осталось выяснить, каким же же чудом Ориент обходит эти ограничения.

                                                                                                          И тут дело не в константах, а именно в алгоритмической сложности ресайза.

                                                                                                          Еще раз: амортизированная алгоритмическая сложность хэш-таблицы — O(1), как на чтение, так и на добавление. Ресайз сюда включен.
                                                                                                            0
                                                                                                            Никак не обходит.

                                                                                                            Ну да, обычно всё летает, а иногда встаёт колом на час.
                                                                                                              0
                                                                                                              Какая полезная возможность!
                                                                                                                0
                                                                                                                Еще раз: амортизированная алгоритмическая сложность хэш-таблицы — O(1), как на чтение, так и на добавление. Ресайз сюда включен.
                                                                                                                Ну да, обычно всё летает, а иногда встаёт колом на час.
                                                                                                                0
                                                                                                                Никак не обходит.

                                                                                                                Прекрасно, значит, и здесь у него (ориента) нет никаких концептуальных преимуществ.

                                                                                                                Ну да, обычно всё летает, а иногда встаёт колом на час.

                                                                                                                Scheduled maintenance рулит. Иначе вы на банальном приросте файла под БД можете очень больно лечь.
                                                                                                                  0
                                                                                                                  Прекрасно, значит, и здесь у него (ориента) нет никаких концептуальных преимуществ.
                                                                                                                  Есть. И я не буду больше повторять про ссылки.

                                                                                                                  Scheduled maintenance рулит. Иначе вы на банальном приросте файла под БД можете очень больно лечь.
                                                                                                                  По вашему увеличение файла происходит путём копирования содержимого из маленькой непрерывной области в большую? :-)
                                                                                                                    0
                                                                                                                    По вашему увеличение файла происходит путём копирования содержимого из маленькой непрерывной области в большую?

                                                                                                                    Нет, а с чего вы это взяли?
                                                                                                              +1
                                                                                                              Бинарные деревья куда лучше приспособлены для больших объёмов.

                                                                                                              B-tree != бинарные деревья
                                                                                                                0
                                                                                                                А Би-деревья ещё приспособленней :-)
                                                                  0
                                                                  Но отчеты очень удобно строить по реляционной БД

                                                                  Не очень удобно. Даже если забыть про избыточность собственно SQL-запроса (разработчик вынужден хранить в голове связи типа contract.id = contract_transaction.contract_id и указывать их в запросе явно, хотя до этого указывал СУБД, что contract_transaction.contract_id не может указывать может указывать только на contract.id, не забывать включать таблицу в FROM, если указал её в SELECT или WHERE), то многие часто встречающиеся для отчётов задачи решаются средствами SQL нетривиально. Например, отчёт по балансу какого-то числового агрегатного поля сущности по дням, где должен быть указан баланс на начало дня, начисления за день, списания за день, баланс на конец дня, причём баланс на начало дня должен быть ноль, даже если сущность ещё не существует, отчёт должен быть по каждой дате, даже если транзакций по сущности не было, а если транзакций не было, то начисления и списания тоже должны быть нулями. А в наличии у нас сущность и
                                                                  транзакции по ней. Как минимум, придётся извращаться с преобразованием NULL в 0 и установлением начального баланса в 0.
                                                                    0
                                                                    Как минимум, придётся извращаться с преобразованием NULL в 0

                                                                    Вот поэтому изначально в реляционной теории NULL и не было. Соответственно, как только вы решаете проблему с преобразованием «нет данных» в нули (а это чистое бизнес-требование), ваша задачка решается легко и просто.

                                                                    Впрочем, я с удовольствием послушаю про СУБД, в которой это строить проще.
                                                                      0
                                                                      Бог с ним с преобразованием реальных данных, в конце концов на уровне интерфейса можно указать, что NULL отображать как 0, '', 'нет данных' или ещё как (может даже удобнее для бизнеса чем 0). Но вот start_balance + SUM(tr.amount) (где tr.amount NULL как отсутствующая в результате LEFT JOIN) или любые подобные агрегатные данные вернут тоже NULL, который так просто на уровне интерфейса не разрешить.

                                                                      А я не говорил, что они есть я спорил с утверждением, что в SQL строить подобные отчёты, довольно обычные в практике, удобно. Имхо, реляционная модель вообще (а её реализация в SQL особенно) слабо приспособлена для реализации, с одной стороны, отношений типа «имеет», «содержит», «принадлежит» и т. п. между сущностями и, с другой, для агрегирующих выборок с известным начальным состоянием.

                                                                      Проще это делается в, например, документо-ориентированных СУБД, в которых в качестве языка запросов используется, например, javascript — обычный reduce на коллекцию с начальным состоянием. Другое дело, что цена этой простоты меня лично не устроила и мучаюсь с Postgre- и, пока, MySql. Ещё активно навязывают (поставщики внешних решений MS SQL через начальство), но пока сопротивляюсь.
                                                                        0
                                                                        Но вот start_balance + SUM(tr.amount) (где tr.amount NULL как отсутствующая в результате LEFT JOIN)

                                                                        Просто нужно вытаскивать все агрегаты отдельно, тогда можно будет разделять «транзакций за день не было» и «общий баланс транзакций за день — 0». И складывать на уровне интерфейса, благо, это просто.

                                                                        (на уровне SQL тоже не сложно, прямо скажем).

                                                                        Проще это делается в, например, документо-ориентированных СУБД, в которых в качестве языка запросов используется, например, javascript — обычный reduce на коллекцию с начальным состоянием.

                                                                        Описываемая вами простота приходит не от документо-ориентированности — а от использования JS. Сама модель никак на это не влияет.
                                                                          0
                                                                          В этой ветке я ничего не говорил про реляционную модель, а говорил про удобство самого языка запросов. Часть неудобств проистекает из недостатков реляционной модели (многие из них с той или иной мерой успешности решаются разными производителями, как правило, по разному), а часть самим языком запросов, который создавался чтобы «любая домохозяка могла сделать запрос по базе».
                                                                            0
                                                                            А я говорил именно о реляционной БД. SQL я стараюсь избегать.
                                          +5
                                          JSON убили, пора приниматься за РСУБД. Неизменно деструктивные настроения у автора =)
                                            +11
                                            Для быстрого и комфортного перемещения были созданы автомашины.
                                            Я люблю лес.
                                            По лесу машины передвигаются плохо, а велосипеды хорошо.
                                            Вывод: Считаю надо выкинуть все автомашины и всем пересесть на велосипеды.
                                              0
                                              погоди ховерборды
                                              выкидывать будешь и машины и ролики и велосипед
                                                0
                                                Для быстрого перемещения были созданы суперкары.
                                                Для комфортного — лимузины.
                                                Но для повседневной жизни обычно выбирают хетчбэк.
                                                +6
                                                Многие SQL-профи тут обычно заявляют, мол деревья и тем более графы в предметных областях почти не встречаются. Но стоит немного выйти из зоны комфорта как тут же увидишь, что любая предметная область на самом деле представляет из себя граф — набор сущностей, между которыми есть разнообразные отношения.

                                                Это утверждение неверно. Любую предметную область можно представить в виде графа, однако это не означает, что это представление для нее наиболее эффективно. И тем более не значит, что это представление нужно выбирать для реализации.

                                                Собственно, все же уже сказано в хорошей книжке.
                                                  –3
                                                  Но также любую предметную область можно представить в виде таблиц, однако это не означает, что это представление для нее наиболее эффективно. И тем более не значит, что это представление нужно выбирать для реализации. Однако большинство предметных областей на граф ложатся лучше, чем на таблицы.
                                                    +3
                                                    Однако большинство предметных областей на граф ложатся лучше, чем на таблицы.

                                                    Что вы понимаете под «лучше»? Ну и в любом случае мне, конечно, интересно увидеть статистику, на основании которой вы делаете это утверждение.

                                                    (отдельно, конечно, неплохо бы определиться, что же вы именно понимаете под графами...)
                                                      –3
                                                      В статье я и изложил свои мысли на этот счёт.
                                                        0
                                                        Никакой статистики — равно как и адекватного определения того, что такое «граф», на который предметные области ложатся лучше — в вашей статье нет.
                                                          –1
                                                          Вы не знаете, что такое граф?

                                                          Бизнес модель — коллекция сущностей с отношениями.
                                                          Графовая модель — коллекция узлов со связями.
                                                          Реляционная модель — таблицы с данными и всё.

                                                          Первая на вторую мапится 1-в-1. На третюю не памятся, ибо нет отношений (они указываются только потом, в запросе), да и сущности по сложнее кортежа примитивов.
                                                            +1
                                                            Я знаю, что такое граф. Вопрос в том, например, могут ли узлы графа иметь свои свойства? Типы? (я говорю именно о графе как концепции, а не реализации в ориенте)

                                                            Реляционная модель — таблицы с данными и всё.

                                                            На самом деле, нет. Реляционная модель — это таблицы с данными и их связи.

                                                            Первая на вторую мапится 1-в-1.

                                                            А еще бизнес-модель точно так же «точно» маппится на документо-ориентированную парадигму (потому что там тоже коллекция сущностей со связями) и на объектно-ориентированную парадигму.

                                                            Это все еще не значит, что любое из перечисленных представлений (включая реляционное) по каким-то причинам лучше подходит для реализации всех задач.
                                                              0
                                                              Вполне могут, почему нет?

                                                              В таблицах нету связей. Там есть одинаковые числа в разных колонках разных таблиц. Смысл связей они обретают лишь при запросе и соответствующие записи могут быть найдены лишь по индексам.

                                                              Документная модель со связями — это уже графовая модель. Типа той, что мы видим в Ориенте.

                                                                +1
                                                                В таблицах нету связей.

                                                                Это экзистенциальный вопрос. В таблице есть информация, позволяющая однозначно определить связанный объект. Этого достаточно.

                                                                Документная модель со связями — это уже графовая модель.

                                                                Тогда и табличная модель со связями — графовая модель, после чего вообще сравнивать нечего становится.
                                                                  0
                                                                  Разумеется логически связи есть (иначе приложение бы никакое было не построить), но физически нет ссылок на другие записи. Есть только числа по которым можно найти связанную запись только через поисковой индекс. В этом смысле числа ни чем не лучше любого другого типа данных. Вы можете к возрасту приджойнить айдишники и получить странный результат. А РСУБД ничего на это даже не возразит. Так что притянуть отношения к таблицам можно, но выражены они не явно и требуют специального шаманства.
                                                                    0
                                                                    но физически нет ссылок на другие записи. Есть только числа по которым можно найти связанную запись только через поисковой индекс.

                                                                    Вы так говорите, будто в других БД «физически» хранятся не «числа» (опустим для простоты тот факт, что идентификатором записи может быть что угодно). Те же самые числа, пусть даже в OrientDB они являются указателями на конкретное физическое место в БД.

                                                                    Семантику этих «чисел» обеспечивают метаданные, лежащие поверх, и ограничивающие операции. Сейчас, наверное, все РСУБД поддерживают внешние ключи, как для ограничения множества допустимых значений, так и для распространения изменений. Семантически это эквивалентно ссылкам на объекты.

                                                                    Вы можете к возрасту приджойнить айдишники и получить странный результат. А РСУБД ничего на это даже не возразит.

                                                                    Да, могу — ни одна известная мне РСУБД не имеет ограничений на объекты под джойнами. Но есть и оборотная сторона — я могу приджойнить возраст к возрасту, или имя к имени, или результат группировки к результату группировки. Можно ли так сделать в графовой БД?

                                                                      0
                                                                      Не совсем эквивалентны, но ладно. С той лишь оговоркой, что реализуются эти ссылки крайне не эффективно — через прослойку из индексов.

                                                                      Можно, через подзапросы.
                                                                        0
                                                                        Можно, через подзапросы.

                                                                        Во-первых, являются ли «подзапросы» свойством любой графовой БД?
                                                                        Во-вторых, какова их функциональность и эффективность по сравнению с РСУБД?
                                                                          0
                                                                          1. Я не говорю про любую ГСУБД. Но в любой толковой — можно. Из толковых я знаю только одну.

                                                                          2. Да такая же при наличии индексов. Разве что для full outer join нужно шаманить.
                                                                            +1
                                                                            Я не говорю про любую ГСУБД. Но в любой толковой — можно. Из толковых я знаю только одну.

                                                                            Значит, это не врожденное свойство графовых БД.

                                                                            Да такая же при наличии индексов. Разве что для full outer join нужно шаманить.

                                                                            Правда?

                                                                            У меня есть две таблицы (два класса в терминах ориента), «книги» и «фильмы». В каждой из них есть поле «год». Мне нужно получить таблицу вида «год выхода — число книг — число фильмов». Считаем, что с каждой стороны есть хотя бы по одной записи для каждого года, поэтому достаточно INNER JOIN.
                                                                              0
                                                                              Разумеется, не все ГСУБД одинаково полезны :-)

                                                                              Если честно, лень шаманить с селектами… в ГСУБД эта задача решается несколько иначе и более эффективно:

                                                                              select value , book.length() as booksCount , movies.lengh() as moviesCount from Year
                                                                              


                                                                              При этом это ограничение «с каждой стороны есть хотя бы по одной записи для каждого года» не требуется.

                                                                                +1
                                                                                Во-первых, это не «более эффективно» — теперь каждый раз, когда мне нужна информация о годе для книги или кино, я должен пройти по связи.
                                                                                Во-вторых, увеличивается стоимость поддержки — когда у меня появляется новая сущность (диск, например), в котором я сделаю связь с годом, ориент сам добавит «ответное» свойство со стороны года, или его будет нужно добавлять руками?
                                                                                В-третьих, это как раз типичный костыль: графовая модель не справляется с задачей, которая для реляционной модели проста, и вы вынуждены изменять семантику модели так, чтобы она влезла в граф.

                                                                                В конце концов это приведет к тому, что у вас все свойства будут ребрами (со всеми вытекающими отсюда проблемами), вы получите «чистый» граф и модель категорий по Партриджу (которую на хабре уже обсуждали).
                                                                                  0
                                                                                  1. Это в РСУБД переход по связи дорогой. Тут же это почти ничего не стоит (прочитать лишний блок памяти, который, к тому же, скорее всего возьмётся из кэша).

                                                                                  2. Если используется графовое апи, то обратные связи создаются автоматически. Если же документное (которое я нахожу более практичным), то ответное нужно создавать руками.

                                                                                  3. Я бы не назвал это таким уж прям костылём. Если у нас выводится аналитика по годам, то без сущности «год выпуска» так или иначе не обойтись. К ней надо будет привязывать не только вышедшие произведения, но и ежегодные премии, аналитические статьи и тп. А не вытягивать их по косвенным данным (датам во всех этих сущностях) при каждом запросе, внимательно следя, чтобы диапазоны не пересекались. Тем более что премия за текущий год может вручаться в следующем. А аналитическая статья за любой год может выйти хоть через десятилетие.

                                                                                  4. Можно ссылку, где обсуждали?
                                                                                    0
                                                                                    Это в РСУБД переход по связи дорогой. Тут же это почти ничего не стоит (прочитать лишний блок памяти, который, к тому же, скорее всего возьмётся из кэша).

                                                                                    Это все равно дополнительная операция. А кэши — они во всех СУБД есть.

                                                                                    Если же документное (которое я нахожу более практичным), то ответное нужно создавать руками.

                                                                                    Вот и увеличение стоимости поддержки.

                                                                                    Если у нас выводится аналитика по годам, то без сущности «год выпуска» так или иначе не обойтись.

                                                                                    Год выпуска — это не сущность, а атрибут.

                                                                                    К ней надо будет привязывать не только вышедшие произведения, но и ежегодные премии, аналитические статьи и тп. А не вытягивать их по косвенным данным (датам во всех этих сущностях) при каждом запросе, внимательно следя, чтобы диапазоны не пересекались. Тем более что премия за текущий год может вручаться в следующем. А аналитическая статья за любой год может выйти хоть через десятилетие.

                                                                                    Все эти проблемы решаются введением соответствующего атрибута, сущность все еще не нужна.

                                                                                    Можно ссылку, где обсуждали?

                                                                                    habrahabr.ru/post/246313
                                                                                    habrahabr.ru/post/245241

                                                                                    И вообще в комментариях почти к любому поcту maxstroy
                                                                                      0
                                                                                      Это все равно дополнительная операция.
                                                                                      Она как минимум лучше масштабируется, чем джойны таблиц.

                                                                                      Вот и увеличение стоимости поддержки.
                                                                                      Один раз пишется обобщённый код и всё. Ну то есть я реализовал своё графовое апи с поддержкой как двусторонних так и односторонних связей. То, что есть в Ориенте — всегда двустороннее и направленное

                                                                                      Год выпуска — это не сущность, а атрибут.
                                                                                      Ссылка на сущность хранится в атрибуте. Это философский спор :-) Я лично усматриваю в годе выпуска все признаки сущности. Сформулировать их пока не возьмусь, чисто интуитивно.

                                                                                      Все эти проблемы решаются введением соответствующего атрибута, сущность все еще не нужна.
                                                                                      Но с ней в целом удобней.

                                                                                      habrahabr.ru/post/246313
                                                                                      habrahabr.ru/post/245241
                                                                                      Спасибо, почитаю.
                                                                                        0
                                                                                        Она как минимум лучше масштабируется, чем джойны таблиц.

                                                                                        Почему?

                                                                                        Один раз пишется обобщённый код и всё.

                                                                                        А создает описание связей в БД тоже «обобщенный код»?

                                                                                        Я лично усматриваю в годе выпуска все признаки сущности.

                                                                                        Попробуйте сформулировать, и поймете, что по этим признакам всё — сущность. Это, конечно, нативный для графа подход (все есть вершина кроме того, что ребро), но вы уверены, что вам будет удобно так работать.

                                                                                        Но с ней в целом удобней.

                                                                                        Удобнее вам реализовывать на графовой БД. Но в бизнесе этого нет… и что вы там говорили про то, что предметная область лучше ложится на граф?
                                                                                          0
                                                                                          Почему?
                                                                                          Потому что скорость перехода по ссылке не зависит от числа записей в таблице…

                                                                                          А создает описание связей в БД тоже «обобщенный код»?
                                                                                          Вполне, почему бы и нет?

                                                                                          вы уверены, что вам будет удобно так работать.
                                                                                          Да, весьма.

                                                                                          Удобнее вам реализовывать на графовой БД. Но в бизнесе этого нет… и что вы там говорили про то, что предметная область лучше ложится на граф?
                                                                                          В бизнесе есть «отчётные периоды» и это вполне себе бизнес сущности. И с ней удобнее и быстрее работать как с отдельной сущностью, а не жонглировать временными метками.
                                                                                            0
                                                                                            Потому что скорость перехода по ссылке не зависит от числа записей в таблице…

                                                                                            Уже проходили: для реляционной БД это тоже возможно.

                                                                                            Вполне, почему бы и нет?

                                                                                            Ну так, представляю себе результаты его работы.

                                                                                            Да, весьма.

                                                                                            Пробовали? Пока все ваши примеры — они документо-ориентированы.

                                                                                            В бизнесе есть «отчётные периоды» и это вполне себе бизнес сущности.

                                                                                            Не надо путать отчетные периоды и год выхода. Это очень разные вещи. А временные метки вы себе вообще сам придумали, я про них не слова не сказал.
                                                                                              0
                                                                                              Уже проходили: для реляционной БД это тоже возможно.
                                                                                              Если б всё было так легко, никто бы не пилил NoSQL решения.

                                                                                              Ну так, представляю себе результаты его работы.
                                                                                              Озвучите?

                                                                                              Пробовали? Пока все ваши примеры — они документо-ориентированы.
                                                                                              Бизнес вообще документно ориентирован.

                                                                                              Не надо путать отчетные периоды и год выхода.
                                                                                              Вы строите отчёты по годам. Вполне себе отчётные периоды.
                                                                                                +1
                                                                                                Если б всё было так легко, никто бы не пилил NoSQL решения.

                                                                                                А вы думаете, NoSQL решения «пилят» из-за невозможности сделать константное время доступа по ключу?

                                                                                                Озвучите?

                                                                                                Если вкратце, то: book.Editor_Person.

                                                                                                Бизнес вообще документно ориентирован.

                                                                                                Ну и как же вы собираетесь его положить на чистый граф тогда?

                                                                                                Вы строите отчёты по годам. Вполне себе отчётные периоды.

                                                                                                Нет, я строю отчеты по атрибуту «год выхода». Это не то же самое, что «отчетный период — 2010 год» или «финансовый год 2010».
                                                                                                  –4
                                                                                                  А вы думаете, NoSQL решения «пилят» из-за невозможности сделать константное время доступа по ключу?
                                                                                                  Из-за фундаментальных проблем масштабирования РСУБД.

                                                                                                  Если вкратце, то: book.Editor_Person.
                                                                                                  Что это?

                                                                                                  Ну и как же вы собираетесь его положить на чистый граф тогда?
                                                                                                  Бизнес документы тоже имеют перекрёстные ссылки.

                                                                                                  Нет, я строю отчеты по атрибуту «год выхода». Это не то же самое, что «отчетный период — 2010 год» или «финансовый год 2010».
                                                                                                  Не вижу разницы.
                                                                                                    +1
                                                                                                    Из-за фундаментальных проблем масштабирования РСУБД.

                                                                                                    Как интересно! А расскажите какие там есть проблемы? И да кстати посмотрите про то как PostgreSQL ускоряют при помощи GPGPU.

                                                                                                      0
                                                                                                      Спасибо за ссылку. Но GPU ускорение работает только если все данные помещаются в память видеокарты и при наличии этой самой видеокарты. При этом алгоритмическая сложность никуда не девается, а просто уменьшается константа.
                                                                                                      0
                                                                                                      Что это?

                                                                                                      Это типичный пример именования, вышедшего из под обобщенного кода.

                                                                                                      Бизнес документы тоже имеют перекрёстные ссылки.

                                                                                                      Перекрестные ссылки — это, конечно, граф, но бизнес-документы — это не чистый граф, а речь выше шла именно об этом.

                                                                                                      Не вижу разницы.

                                                                                                      Я, в принципе, уже заметил.

                                                                                                      Окей, представьте, что у вас не год, а дата — и вам надо строить аналитику по датам (рождения, смерти, свадьбы и развода).
                                                                                                        –1
                                                                                                        Это типичный пример именования, вышедшего из под обобщенного кода.
                                                                                                        Зачем тип указывать в имени свойства?

                                                                                                        Перекрестные ссылки — это, конечно, граф, но бизнес-документы — это не чистый граф, а речь выше шла именно об этом.
                                                                                                        Что такое «грязный граф»?

                                                                                                        Окей, представьте, что у вас не год, а дата — и вам надо строить аналитику по датам (рождения, смерти, свадьбы и развода).
                                                                                                        Точно так же, создаём отдельные узлы для дат и имеем быструю аналитику по ним. Говорю же, принципы работы с графами несколько отличаются от подходов к которым вы привыкли при работе с таблицами.
                                                                                                          0
                                                                                                          Зачем тип указывать в имени свойства?

                                                                                                          Потому что обобщенный код так сгенерил.

                                                                                                          Что такое «грязный граф»?

                                                                                                          Граф, в котором у вершин есть свойства.

                                                                                                          Точно так же, создаём отдельные узлы для дат и имеем быструю аналитику по ним.

                                                                                                          Вы себе представляете количество таких вершин?

                                                                                                          Говорю же, принципы работы с графами несколько отличаются от подходов к которым вы привыкли при работе с таблицами.

                                                                                                          Спасибо, я в курсе. Только почему-то подходы, применяемые в реляционной модели, вы считаете костылями, а подходы, применяемые в графовой — нет.
                                                                                                            0
                                                                                                            Потому что обобщенный код так сгенерил.
                                                                                                            Напишите нормальный обобщённый код :-)

                                                                                                            Граф, в котором у вершин есть свойства.
                                                                                                            Теория графов не накладывает никаких ограничений на вершины.

                                                                                                            Вы себе представляете количество таких вершин?
                                                                                                            Не больше чем узлов в индексе.

                                                                                                            Спасибо, я в курсе. Только почему-то подходы, применяемые в реляционной модели, вы считаете костылями, а подходы, применяемые в графовой — нет.
                                                                                                            Потому что они имеют большую алгоритмическую сложность и меньшую наглядность.
                                                                                                              0
                                                                                                              Напишите нормальный обобщённый код

                                                                                                              Если бы можно было написать нормальный обобщенный код, порождающий модель, соответствующую домену, программистов можно было бы выкинуть на свалку.

                                                                                                              Теория графов не накладывает никаких ограничений на вершины.

                                                                                                              И как следствие никак не описывает алгоритмы для работы с «дополнительными» данными.

                                                                                                              Не больше чем узлов в индексе.

                                                                                                              Вот только узлы в индексе я — как разработчик — не вижу. А вершины в граф добавлять мне.

                                                                                                              Потому что они имеют большую алгоритмическую сложность

                                                                                                              Докажите.

                                                                                                              меньшую наглядность.

                                                                                                              А это субъективно.
                                                                                                                0
                                                                                                                Если бы можно было написать нормальный обобщенный код, порождающий модель, соответствующую домену, программистов можно было бы выкинуть на свалку.
                                                                                                                Вы улетели в стратосферу. Что мешает генерировать нормальные имена в духе «book.editor»?

                                                                                                                И как следствие никак не описывает алгоритмы для работы с «дополнительными» данными.
                                                                                                                А должна? К чему вы клоните?

                                                                                                                Вот только узлы в индексе я — как разработчик — не вижу. А вершины в граф добавлять мне.
                                                                                                                Вы их фактически создаёте налету в агрегирующем запросе. Из таблиц «инфа о книгах» и «инфа о фильмах» создаёте виртуальную таблицу «инфа о годе выпуска».
                                                                                                    +1
                                                                                                    Бизнес вообще документно ориентирован.

                                                                                                    Бизнес обычно не документно ориентирован, документы, как правило, лишь средства отражения (учёта) состояния бизнес-процессов, модель по сути, по которой кто-то может узнать состояние бизнес-процессов на определенный момент времени (при условии, что документы составлялись в нужном объёме и фиксировали объективные состояния процессов).
                                                                                                      0
                                                                                                      Бизнес — разный. Учетный бизнес вполне бывает документо-ориентирован.