Да можно раскрыть объекты на любую глубину, но это:
1) Иногда увеличивает объем данных — например, каждая книга одного и того же автора в json будет содержать дублирующуюся информацию об авторе. Мы в одном из постов расскажем как избегать такого дублирования данных.
2) Иногда информация про промежуточные объекты бывает не нужна — например мы просто хотим получить список любимых издательств.
Еще пример, я хочу найти друзей друзей, которые учились со мной в одном институте — зачем мне тысячи человек? мне нужно только несколько.
1) А как получить все необходимые мне данные (понравившиеся книги, их издательства, кому они ещё понравились и тд) одним запросом, а не десятком последовательных запросов?
для этого существует опция $expand
например получить понравившиеся книги с издательствами и авторами
.../person(person1)/likes?$expand=publisher,author
мы про $expand расскажем подробнее в следующих постах
2. Прямые ссылки нормальные, а обратные через какие-то костыли. Почему бы не сделать модель с нормальными двусторонними ссылками (likedBook — likesPerson или in_likes — out_likes)?
можно даже не предусматривать двусторонние ссылки а просто указать что обратная ссылка с именем likesPerson или out_likes является обратной от likes (или наоборот) — провайдер просто должен иметь информацию как генерить join запрос
вопрос был а если разработчики сервера не описали модель и не написали никаких кодов для обработки таких обратных ссылок — можно ли как то получить данные?
например если провайдер использует schemaless модель — типа сохраняем данные как они есть без описания модели (например, сохраняет данные в mongodb)
идентифицировать — имеется в виду выставить ключевое поле — в разных реализациях OData это может быть поле id, _id и т.д. или же тот же набор полей, что в базе названы ключом
могут лишь ограничить доступ к таким длинным ссылкам — но не поменять семантику — если мы по ссылке
/persons(person1)/likes/publisher/president — получим не президентов компаний издавших книги, которые нравятся person1 — то это уже самодельный REST API а не OData
можно прямо так сохранять — но нужно однозначно идентифицировать каждый job — если хочется его проапдейтить
мы обязательно расскажем подробнее про добавление вложенных объектов в следующих постах
1) Довольно многие люди не знают что OData позволяет переходить по ссылкам как угодно далеко
/persons(person1)/likes/publisher/president
обычно рассматривают лишь получение объектов по прямой ссылке — /persons(person1)/likes
причем для обработки таких длинных ссылок вовсе не требуется что то писать на сервере — обычно OData провайдеры превращают такую ссылку в запрос автоматически
2) Также возникает проблема построить url — когда нет прямой ссылки на объект и разработчик сервера не позаботился об этом — OData провайдеры такую ссылку тоже превращают в запрос к базе данных автоматически создавая правильный SQL join запрос или аналогичный запрос для NoSQL баз данных
В худшем случае (когда мало запросов) то да — каждую запись нужно прочитать с диска. Но при большом количестве запросов существуют методы оптимизации
1) если есть множество запросов к разным страницам можно читать сначала ту к которой максимальное количество обращений (например 10) — тогда мы обеспечим одно обращение к диску вместо 10
2) пока читали некоторую страницу — возможно уже появились запросы на слудующую — тогда можно обеспечить последовательное чтение — что намного быстрее (особенно в с учетом того что к следующей странице к этому моменту уже может оказаться много запросов)
В эти структуры уже заложена версионность во время реализации. Узлы графа существуют в нескольких версиях, есть сборка мусора с учетом устаревших версий. Хэш таблица также поддерживает версионность. С разреженными матрицами мы пока проверяем три различных варианта реализации версионности.
В реализации версионности есть разные подходы в зависимости от сценариев использования базы. Допускается ли всего несколько параллельных версий или же допускается неограниченное количество версий. Неограниченное количество версий заманчиво но менее эффективно в большинстве реальных сценариев.
Но независимо от выбора сами механизмы версионности уже заложены.
Есть два разных варианта доступа к узлу
1) поиск по id — для этого используется специализированная хэш таблица — скорость доступа практически константа
2) доступ по ссылкам (связям между узлами) — для организации ссылок используется специализированная структура типа разреженной матрицы — ссылки представляются неким числом — скорость доступа по ссылке практически константа и равна 2-3 обращениям к памяти
1й вариант — это лишь для обработки простейшего запроса когда id объекта задается в запросе
2й вариант — это все запросы требующие навигации по графу
индексы также ссылаются на узлы не через их id а используют ссылку на запись
Скорость доступа к узлам графа при обработке запросов на графе требуется минимум раз в 100 больше чем предоставляет LevelDB и многие другие key-value структуры.
Да — этот уровень занял много человеко месяцев. Но в общих трудозатратах при создании графовой базы это менее 5%
Планировщик подбирает индексы в зависимости от типа запроса, типа условий, наличия логических операций, объемов данных и многих других условий. В одной из следующих статей мы подробнее расскажем как это работает.
В данный момент индексы создаются автоматически для удобства разработки и прототипирования приложений. В этом случае вообще не требуется никакого администрирования базы данных. Это конечно же оверхед — но не существенный.
«LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.»
Она не выполняет весь необходимый набор запросов на графах.
В качестве индексов применяются несколько вариантов B-tree, битовые индексы, хэш индексы, несколько специализированных вариантов разреженных матриц. Индексы создаются автоматически.
Например, запрос: получить человека с id=117 со всеми его друзьями и друзьями друзей (в виде дерева)
host/service/yourdb/person(117)?$expand=friends($levels=2)
OData предполагает выдачу в виде дерева в случае $expand — это оговорено в стандарте
1) Иногда увеличивает объем данных — например, каждая книга одного и того же автора в json будет содержать дублирующуюся информацию об авторе. Мы в одном из постов расскажем как избегать такого дублирования данных.
2) Иногда информация про промежуточные объекты бывает не нужна — например мы просто хотим получить список любимых издательств.
Еще пример, я хочу найти друзей друзей, которые учились со мной в одном институте — зачем мне тысячи человек? мне нужно только несколько.
для этого существует опция $expand
например получить понравившиеся книги с издательствами и авторами
.../person(person1)/likes?$expand=publisher,author
мы про $expand расскажем подробнее в следующих постах
2. Прямые ссылки нормальные, а обратные через какие-то костыли. Почему бы не сделать модель с нормальными двусторонними ссылками (likedBook — likesPerson или in_likes — out_likes)?
можно даже не предусматривать двусторонние ссылки а просто указать что обратная ссылка с именем likesPerson или out_likes является обратной от likes (или наоборот) — провайдер просто должен иметь информацию как генерить join запрос
вопрос был а если разработчики сервера не описали модель и не написали никаких кодов для обработки таких обратных ссылок — можно ли как то получить данные?
например если провайдер использует schemaless модель — типа сохраняем данные как они есть без описания модели (например, сохраняет данные в mongodb)
/persons(person1)/likes/publisher/president — получим не президентов компаний издавших книги, которые нравятся person1 — то это уже самодельный REST API а не OData
мы обязательно расскажем подробнее про добавление вложенных объектов в следующих постах
1) Довольно многие люди не знают что OData позволяет переходить по ссылкам как угодно далеко
/persons(person1)/likes/publisher/president
обычно рассматривают лишь получение объектов по прямой ссылке — /persons(person1)/likes
причем для обработки таких длинных ссылок вовсе не требуется что то писать на сервере — обычно OData провайдеры превращают такую ссылку в запрос автоматически
2) Также возникает проблема построить url — когда нет прямой ссылки на объект и разработчик сервера не позаботился об этом — OData провайдеры такую ссылку тоже превращают в запрос к базе данных автоматически создавая правильный SQL join запрос или аналогичный запрос для NoSQL баз данных
Кнопку Download заменим, спасибо за замечание
1) если есть множество запросов к разным страницам можно читать сначала ту к которой максимальное количество обращений (например 10) — тогда мы обеспечим одно обращение к диску вместо 10
2) пока читали некоторую страницу — возможно уже появились запросы на слудующую — тогда можно обеспечить последовательное чтение — что намного быстрее (особенно в с учетом того что к следующей странице к этому моменту уже может оказаться много запросов)
http://nitrosdata.com/formtest.html
http://nitrosdata.com/editgrid.html
Первая форма — Angular.js
В реализации версионности есть разные подходы в зависимости от сценариев использования базы. Допускается ли всего несколько параллельных версий или же допускается неограниченное количество версий. Неограниченное количество версий заманчиво но менее эффективно в большинстве реальных сценариев.
Но независимо от выбора сами механизмы версионности уже заложены.
1) поиск по id — для этого используется специализированная хэш таблица — скорость доступа практически константа
2) доступ по ссылкам (связям между узлами) — для организации ссылок используется специализированная структура типа разреженной матрицы — ссылки представляются неким числом — скорость доступа по ссылке практически константа и равна 2-3 обращениям к памяти
1й вариант — это лишь для обработки простейшего запроса когда id объекта задается в запросе
2й вариант — это все запросы требующие навигации по графу
индексы также ссылаются на узлы не через их id а используют ссылку на запись
Да — этот уровень занял много человеко месяцев. Но в общих трудозатратах при создании графовой базы это менее 5%
В данный момент индексы создаются автоматически для удобства разработки и прототипирования приложений. В этом случае вообще не требуется никакого администрирования базы данных. Это конечно же оверхед — но не существенный.
Она не выполняет весь необходимый набор запросов на графах.
Например, запрос: получить человека с id=117 со всеми его друзьями и друзьями друзей (в виде дерева)
host/service/yourdb/person(117)?$expand=friends($levels=2)
Спасибо за Вашу заявку, Мы пришлем Вам уведомление и ссылку как только продукт будет готов для скачивания.