Интересуюсь в целях расширения кругозора альтернативными языками запросов и моделями данных для БД. А то кругом один SQL, да реляционная модель. Есть ли что-нибудь альтернативное, но сопоставимое по функциональным возможностям? Ну или просто интересное. В гугле пока не забанили, но хочется послушать разбирающихся людей.
Смотрел документо-ориентированные NoSQL СУБД. Как-то не впечатлили. Все таки реляционная модель достаточно универсальная штука. В ней можно представлять различные структуры данных и выполнять сложные запросы. А в документно-ориентированных, получается, древовидные данные и простейшие операции поиска по ним. Шаг в сторону от такой формы представления информации -- получается жутко неудобно и неэффективно.
Смотрел OQL. Тоже не впечатлил. Показалось, что это тот же SQL, разбавленный небольшой дозой синтаксического сахара для поддержки работы с объектно-ориентированной моделью данных.
Еще обратил внимание на prolog и его реляционный аналог datalog. Это уже интереснее. Пролог -- тот же язык запросов. Функционально даже более полный чем SQL. Таки тьюринг-полный. Модель данных в прологе по сравнению с реляционной более универсальна, внутри фактов могут использоваться сложные списковые структуры и т.п. Развитые средства обработки списков. Нет жесткой типизации.
Re: Экзотические модели и языки запросов к базам данных
Здравствуйте, chukichuki, Вы писали:
C>Интересуюсь в целях расширения кругозора альтернативными языками запросов и моделями данных для БД. А то кругом один SQL, да реляционная модель. Есть ли что-нибудь альтернативное, но сопоставимое по функциональным возможностям? Ну или просто интересное. В гугле пока не забанили, но хочется послушать разбирающихся людей.
Посмотри на связку RDF/SPARQL. Возможно покажется что это "тот же SQL, разбавленный небольшой дозой синтаксического сахара для поддержки работы с графовой моделью данных" (с). Тогда попробуй, например, разобраться что такое SPARQL entailment regimes.
no fate but what we make
Re[2]: Экзотические модели и языки запросов к базам данных
Здравствуйте, kl, Вы писали:
kl>Посмотри на связку RDF/SPARQL. Возможно покажется что это "тот же SQL, разбавленный небольшой дозой синтаксического сахара для поддержки работы с графовой моделью данных" (с). Тогда попробуй, например, разобраться что такое SPARQL entailment regimes.
Кстати, смотрел. Поверхностно правда. Насколько понял, модель данных RDF -- это множество троек вида "значение — связь — значение". Можно рассматривать как очень обрезанный вариант прологовской модели данных. Да и SPARQL напоминает очень обрезанные прологовские предикаты с прилепленным сбоку SQL-подобным синтаксисом. Когда смотрел, меня куда больше заинтересовал OWL и SWRL. Правда, как показалось, все эти онтологии -- это уже за границами обыкновенных баз данных.
Re[3]: Экзотические модели и языки запросов к базам данных
Здравствуйте, chukichuki, Вы писали:
C>Кстати, смотрел. Поверхностно правда. Насколько понял, модель данных RDF -- это множество троек вида "значение — связь — значение". Можно рассматривать как очень обрезанный вариант прологовской модели данных. Да и SPARQL напоминает очень обрезанные прологовские предикаты с прилепленным сбоку SQL-подобным синтаксисом. Когда смотрел, меня куда больше заинтересовал OWL и SWRL. Правда, как показалось, все эти онтологии -- это уже за границами обыкновенных баз данных.
Ну да, все примерно правильно понял (так же их можно рассматривать как графовую модель/язык запросов). Разумеется OWL и SWRL интереснее, только вот OWL очень вычислительно сложен (в своих интересных фрагментах), а SWRL и вовсе неразрешим (в необрезанной семантике). И да, это за границами обыкновенных баз данных и используется значительно реже (в то время как RDF/SPARQL — это уже не экзотика, куча компаний на Западе занимаются Linked Data в той или иной степени при поддержке всяких Oracle и DB2).
no fate but what we make
Re[4]: Экзотические модели и языки запросов к базам данных
Здравствуйте, kl, Вы писали:
kl>Ну да, все примерно правильно понял (так же их можно рассматривать как графовую модель/язык запросов). Разумеется OWL и SWRL интереснее, только вот OWL очень вычислительно сложен (в своих интересных фрагментах), а SWRL и вовсе неразрешим (в необрезанной семантике). И да, это за границами обыкновенных баз данных и используется значительно реже (в то время как RDF/SPARQL — это уже не экзотика, куча компаний на Западе занимаются Linked Data в той или иной степени при поддержке всяких Oracle и DB2).
Последнее очень любопытно. Что-нибудь посоветуете почитать насчет применения RDF/SPARQL на практике: для каких задач используется, какие инструменты существуют и т.д. и т.п. ? По началу мне эта связка показалась скорее такой "игрушкой" нежели серьезным инструментом для хранения и обработки данных. Сейчас посмотрел, действительно в том же оракле есть даже какой-то движок для RDF.
Re[5]: Экзотические модели и языки запросов к базам данных
Здравствуйте, chukichuki, Вы писали:
kl>>Ну да, все примерно правильно понял (так же их можно рассматривать как графовую модель/язык запросов). Разумеется OWL и SWRL интереснее, только вот OWL очень вычислительно сложен (в своих интересных фрагментах), а SWRL и вовсе неразрешим (в необрезанной семантике). И да, это за границами обыкновенных баз данных и используется значительно реже (в то время как RDF/SPARQL — это уже не экзотика, куча компаний на Западе занимаются Linked Data в той или иной степени при поддержке всяких Oracle и DB2).
C>Последнее очень любопытно. Что-нибудь посоветуете почитать насчет применения RDF/SPARQL на практике: для каких задач используется, какие инструменты существуют и т.д. и т.п. ? По началу мне эта связка показалась скорее такой "игрушкой" нежели серьезным инструментом для хранения и обработки данных. Сейчас посмотрел, действительно в том же оракле есть даже какой-то движок для RDF.
Ну, Linked Data — это сейчас такой модный hype, наподобие Big Data. Используется, как правило, в задачах так или иначе связанных с интеграцией большого количества разнородных данных из разных источников (с разными схемами, способами физического хранения и т.д.). Стало очень модно предоставлять к ним доступ без физического объединения, т.е. представляя в виде эдакого виртуального RDF-графа с точкой доступа через SPARQL. Из научпопа о LD можно почитать статью Тома Хита, он в курсе ситуации. Насчет "почитать о RDF/SPARQL", есть всяческие primers, после которых должна стать понятна спецификация. RDF вообще очень прост, как модель данных, если не влезать в его формальную семантику, которую, как показыает практика, все равно 99% использующих RDF не понимают. Насчет инструментов — гугли по "RDF triplestore", это и есть движки хранения RDF и запросов SPARQL. Если что-то непонятно, я попробую ответить, я как раз занимаюсь оптимизатором запросов для одного из таких коммерческих продуктов. У Oracle и IBM такие движки реализованы поверх их реляционных платформ, у других вендоров — нативно.
no fate but what we make
Re: Экзотические модели и языки запросов к базам данных
Здравствуйте, chukichuki, Вы писали:
C>Все таки реляционная модель достаточно универсальная штука. В ней можно представлять различные структуры данных и выполнять сложные запросы.
Графы практически полностью лежат вне покрытия реляционными БД. Т. е. оно то, конечно, возможно... Но простой запрос типа: вывести все вершины на расстоянии на более заданного. И как быть? Так что для полноты надо смотреть еще в сторону graph database.
Re: Экзотические модели и языки запросов к базам данных
Здравствуйте, chukichuki, Вы писали:
C>Интересуюсь в целях расширения кругозора альтернативными языками запросов и моделями данных для БД.
Есть широко известная книга "Введение в системы баз данных", Дейт, 8-е издание.
Так-то в ней рассказывается именно о реляционных СУБД, но подробно рассматриваются реляционное исчисление и реляционная алгебра, и приведены примеры, как могут выглядеть запросы с их использованием.
В книге широко используется язык Tutorial D, в который запросы встроены.
Также вкратце рассказывается о языках запросов QBE (Query By Example), QUEL (основан на реляционном исчислении), ConQuer, Datalog.
В приложении подробно описана модель TransRelational. Суть этой модели в том, что данные хранятся в очень компактном сжатом виде, и к тому же уже объединённые (join) хитрым способом. В итоге запросы выполняются намного быстрее, чем в традиционных РСУБД. Однако вставка и обновление, вероятно, могут быть медленнее.
Ещё в этой книге мне было интересно почитать про хронологические БД.
А вот мысли автора об ООП вызывали неудержимый смех своей категоричностью.
C> А в документно-ориентированных, получается, древовидные данные и простейшие операции поиска по ним.
Операции поиска в таких БД не обязательно будут простейшими. Взять те же XPath/XQuery для XML — они весьма мощны (как мне кажется).
Re[6]: Экзотические модели и языки запросов к базам данных
Здравствуйте, kl, Вы писали:
kl>Ну, Linked Data — это сейчас такой модный hype, наподобие Big Data. Используется, как правило, в задачах так или иначе связанных с интеграцией большого количества разнородных данных из разных источников (с разными схемами, способами физического хранения и т.д.). Стало очень модно предоставлять к ним доступ без физического объединения, т.е. представляя в виде эдакого виртуального RDF-графа с точкой доступа через SPARQL. Из научпопа о LD можно почитать статью Тома Хита, он в курсе ситуации. Насчет "почитать о RDF/SPARQL", есть всяческие primers, после которых должна стать понятна спецификация. RDF вообще очень прост, как модель данных, если не влезать в его формальную семантику, которую, как показыает практика, все равно 99% использующих RDF не понимают. Насчет инструментов — гугли по "RDF triplestore", это и есть движки хранения RDF и запросов SPARQL. Если что-то непонятно, я попробую ответить, я как раз занимаюсь оптимизатором запросов для одного из таких коммерческих продуктов. У Oracle и IBM такие движки реализованы поверх их реляционных платформ, у других вендоров — нативно.
Спасибо, буду смотреть.
Re[2]: Экзотические модели и языки запросов к базам данных
Здравствуйте, Mystic, Вы писали:
M>Графы практически полностью лежат вне покрытия реляционными БД. Т. е. оно то, конечно, возможно... Но простой запрос типа: вывести все вершины на расстоянии на более заданного. И как быть? Так что для полноты надо смотреть еще в сторону graph database.
Да, тут согласен. Графовые СУБД -- отдельный вопрос. Я их рассматривал, но опять-таки очень поверхностно. На уровне беглого просмотра википедии и всяких разных helloworld-ов и howto. Как я понял, основная их особенность -- это именно разного рода операции поиска по графу в глубину, в ширину, поиск путей из одного узла в другой и т.п. На мой взгляд весьма специфические операции. Может порекомендуете с чего можно начать, чтобы разобраться с этими СУБД поподробнее: cтатьи, книги, сайты, может какие-нибудь "правильные" реализации графовых СУБД ?
Re[2]: Экзотические модели и языки запросов к базам данных
Здравствуйте, koodeer, Вы писали:
K>Есть широко известная книга "Введение в системы баз данных", Дейт, 8-е издание. K>Так-то в ней рассказывается именно о реляционных СУБД, но подробно рассматриваются реляционное исчисление и реляционная алгебра, и приведены примеры, как могут выглядеть запросы с их использованием. K>В книге широко используется язык Tutorial D, в который запросы встроены. K>Также вкратце рассказывается о языках запросов QBE (Query By Example), QUEL (основан на реляционном исчислении), ConQuer, Datalog.
K>В приложении подробно описана модель TransRelational. Суть этой модели в том, что данные хранятся в очень компактном сжатом виде, и к тому же уже объединённые (join) хитрым способом. В итоге запросы выполняются намного быстрее, чем в традиционных РСУБД. Однако вставка и обновление, вероятно, могут быть медленнее.
K>Ещё в этой книге мне было интересно почитать про хронологические БД. K>А вот мысли автора об ООП вызывали неудержимый смех своей категоричностью.
Спасибо за ссылочку. Буду смотреть.
C>> А в документно-ориентированных, получается, древовидные данные и простейшие операции поиска по ним.
K>Операции поиска в таких БД не обязательно будут простейшими. Взять те же XPath/XQuery для XML — они весьма мощны (как мне кажется).
Как я понял, основная цель языков запросов в документо-ориентированных СУБД это поиск именно в пределах одного документа. Поиск между документами -- этого они не очень любят. И СУБД от этого "кривит", и языки запросов поддерживают такие операции плохо. Впрочем, могу ошибаться.
Re[3]: Экзотические модели и языки запросов к базам данных
On 17.03.2014 14:28, chukichuki wrote:
> Кстати, смотрел. Поверхностно правда. Насколько понял, модель данных RDF > -- это множество троек вида "значение — связь — значение". Можно
Точнее --
subject -- verb -- object.
> рассматривать как очень обрезанный вариант прологовской модели данных.
Да, именно так.
Posted via RSDN NNTP Server 2.1 beta
Re[5]: Экзотические модели и языки запросов к базам данных
Здравствуйте, MasterZiv, Вы писали:
MZ>Сейчас посмотрел, действительно в том же >> оракле есть даже какой-то движок для RDF.
MZ>Дай ссылку пожалуйста, если не сложно.
Спасибо.
А может быть -- если ты уже прочитал -- расскажешь, как это лицензионно
выглядит ? Т.е. я понимаю, что это только в 12, что уже весело, но как
это в виде лицензии выглядит ? Бесплатная добавка, либо входит в одну из
эдиций, либо опция к одной из эдиций ?
Просто для создания OLAP-хранилищь RDF уж больно хорош, думаю вот,
попробовать...
Posted via RSDN NNTP Server 2.1 beta
Re[3]: Экзотические модели и языки запросов к базам данных
Здравствуйте, chukichuki, Вы писали:
C>Да, тут согласен. Графовые СУБД -- отдельный вопрос. Я их рассматривал, но опять-таки очень поверхностно. На уровне беглого просмотра википедии и всяких разных helloworld-ов и howto. Как я понял, основная их особенность -- это именно разного рода операции поиска по графу в глубину, в ширину, поиск путей из одного узла в другой и т.п. На мой взгляд весьма специфические операции. Может порекомендуете с чего можно начать, чтобы разобраться с этими СУБД поподробнее: cтатьи, книги, сайты, может какие-нибудь "правильные" реализации графовых СУБД ?
Аналогично. Просто знаю, что они есть, и в общих чертах куда надо копать, если вдруг надо будет. А собственно копать не было времени.
Еще я сталкивался с шахматными базами данных, но там большей частью свои велосипеды. SQL теоретически наверное возможен, но все равно специфика перевешивает.
Re[8]: Экзотические модели и языки запросов к базам данных
Здравствуйте, MasterZiv, Вы писали:
MZ>Спасибо. MZ>А может быть -- если ты уже прочитал -- расскажешь, как это лицензионно MZ>выглядит ? Т.е. я понимаю, что это только в 12, что уже весело, но как MZ>это в виде лицензии выглядит ? Бесплатная добавка, либо входит в одну из MZ>эдиций, либо опция к одной из эдиций ?
Не, к сожалению не подскажу, не в курсе. Я не занимаюсь выбором продукта, я работаю над конкретным продуктом...
MZ>Просто для создания OLAP-хранилищь RDF уж больно хорош, думаю вот, MZ>попробовать...
Хм, я не уверен что это хорошая идея, но я очень плохо знаком с OLAP. Все-таки масштабируемость RDF пока не дотягивает до реляционных хранилищ, плюс там где можно за счет денормализации read-only хранилища добиться быстрых аналитических SQL запросов, обычный SPARQL-сервер (если он как-то хитро не заточен под данный вид запросов) будет делать множество джойнов. Впрочем, может есть и доводы "за", вот, например, известные люди опубликовали схему RDF Data Cube.
Короче говоря, я бы посоветовал сначала получше понять преимущества и недостатки RDF как модели данных для твоего случая, а потом уже подбирать продукт, для которого смотреть лицензии и т.д.
no fate but what we make
Re[9]: Экзотические модели и языки запросов к базам данных
Здравствуйте, kl, Вы писали:
kl>Хм, я не уверен что это хорошая идея, но я очень плохо знаком с OLAP. Все-таки масштабируемость RDF пока не дотягивает до реляционных хранилищ, плюс там где можно за счет денормализации read-only хранилища добиться быстрых аналитических SQL запросов, обычный SPARQL-сервер (если он как-то хитро не заточен под данный вид запросов) будет делать множество джойнов. Впрочем, может есть и доводы "за", вот, например, известные люди опубликовали схему RDF Data Cube. kl>Короче говоря, я бы посоветовал сначала получше понять преимущества и недостатки RDF как модели данных для твоего случая, а потом уже подбирать продукт, для которого смотреть лицензии и т.д.
Кстати, может подскажите что-нибудь почитать по внутренней организации распределенных RDF хранилищ? Возник вопрос относительно этой самой масштабируемости. Кругом пишут про RDF и всякие облачные технологии. Не могу себе представить как правильно RDF данные разложить на вычислительном кластере, чтобы обеспечить эту самую масштабируемость.
Получается, что типовой SPARQL-запрос -- это по сути куча "перевязок" между тройками. Если тройки как-то произвольно-равномерно распределять между узлами кластера, то интуитивно кажется, что при выполнении запроса сильно потеряем на пересылки промежуточных результатов этих "перевязок". Если тройки как-то объединять в связанные подграфы, а подграфы разместить каждый на отдельном узле, то рискуем не получить равномерного распределения данных между узлами кластера. Любопытная задача. Как-то было дело, столкнулся с проблемой обработки больших графов. Была идея использовать кластер. До практики дело, правда, не дошло. Хочется посмотреть как данную задачу решают в RDF-хранилищах.
Re[10]: Экзотические модели и языки запросов к базам данных
Здравствуйте, chukichuki, Вы писали:
C>Кстати, может подскажите что-нибудь почитать по внутренней организации распределенных RDF хранилищ? Возник вопрос относительно этой самой масштабируемости. Кругом пишут про RDF и всякие облачные технологии. Не могу себе представить как правильно RDF данные разложить на вычислительном кластере, чтобы обеспечить эту самую масштабируемость. C>Получается, что типовой SPARQL-запрос -- это по сути куча "перевязок" между тройками. Если тройки как-то произвольно-равномерно распределять между узлами кластера, то интуитивно кажется, что при выполнении запроса сильно потеряем на пересылки промежуточных результатов этих "перевязок". Если тройки как-то объединять в связанные подграфы, а подграфы разместить каждый на отдельном узле, то рискуем не получить равномерного распределения данных между узлами кластера. Любопытная задача. Как-то было дело, столкнулся с проблемой обработки больших графов. Была идея использовать кластер. До практики дело, правда, не дошло. Хочется посмотреть как данную задачу решают в RDF-хранилищах.
Есть разные подходы, но пока развитие находится на этапе исследовательских статей и прототипов. Но есть и продукты, например, Virtuoso cluster или 4store. Я бы посоветовал сначала ознакомиться с базовыми способами хранения RDF и индексирования для быстрого выполнения запросов, тогда будут лучше понятны проблемы в распределенном случае. Есть вот уже ставший классикой open-source продукт — RDF-3X, предложенные там решения позже использовались в ряде коммерческих продуктов. Можно начать с их статьи на VLDB.
Что касается распределенности, то самых крупных проблемы две: 1) распределенное кодирование ресурсов (т.е. как эффективно распределить то, что в RDF-3X называется the Dictionary) и 2) распределение самих индексов (в отличие от реляционных БД, в большинстве нативных RDF СУБД индексы — это и есть данные, опять-таки смотри на RDF-3X). Естественно возникают сложности равномерности, нелокальности и т.д. Исследовательских статей много, из прикладных лучшее наверное 4store: The Design and Implementation of a Clustered RDF Store.
no fate but what we make
Re[9]: Экзотические модели и языки запросов к базам данных
On 18.03.2014 01:02, kl wrote:
> Хм, я не уверен что это хорошая идея, но я очень плохо знаком с OLAP. > Все-таки масштабируемость RDF пока не дотягивает до реляционных > хранилищ, плюс там где можно за счет денормализации read-only хранилища > добиться быстрых аналитических SQL запросов, обычный SPARQL-сервер (если > он как-то хитро не заточен под данный вид запросов) будет делать > множество джойнов.
У меня есть опыт работы с хранилищем на 55 миллиардов триплов.
Положительный. Я бы сказал, очень положительный. Если ещё учесть, что
триплов у меня предвидится гораздо меньше ( как минимум на 3 порядка ),
то всё это очень привлекательно выглядит.
> Короче говоря, я бы посоветовал сначала получше понять преимущества и > недостатки RDF как модели данных для твоего случая, а потом уже
Тут как раз всё очень просто. Преимущество -- scheme less,
недостаток -- только идеологическая сложность технологии.
