Comments 21
Какими из свойств ACID обладает эта база данных? Какова вероятность потери данных при, например, отключении питания?
Обработка транзакций удовлетворяет всем требованиям ACID, включая восстановление данных после сбоя. В данный момент реализация недостаточно эффективна. Например, требования изолированности транзакций реализовано на уровне блокировки всей базы данных, хотя модификация данных происходит очень быстро.
В настоящий момент подготовлены все необходимые алгоритмы и структуры для реализации механизма MVCC, но мы пока не определились с приоритетами и, соответственно, со сроками реализации. Если продукт будет использоваться в основном для прототипирования — то это не является существенным.
Нам интересно Ваше мнение насколько критичен MVCC механизм для Ваших приложений.
В настоящий момент подготовлены все необходимые алгоритмы и структуры для реализации механизма MVCC, но мы пока не определились с приоритетами и, соответственно, со сроками реализации. Если продукт будет использоваться в основном для прототипирования — то это не является существенным.
Нам интересно Ваше мнение насколько критичен MVCC механизм для Ваших приложений.
Нам интересна Ваша реализации MVCC на JavaScript и собственно как реализовано к примеру журналирование (оно же у вас наверное есть ?), какие типы индексов присутсвуют.
И да, почему то невозможно скачать вашу субд.
И да, почему то невозможно скачать вашу субд.
Ядро базы реализовано на C++ (под Linux и Windows 64бит), соответсвенно и журналирование и механизм MVCC тоже реализованы на C++.
Спасибо за Вашу заявку, Мы пришлем Вам уведомление и ссылку как только продукт будет готов для скачивания.
Спасибо за Вашу заявку, Мы пришлем Вам уведомление и ссылку как только продукт будет готов для скачивания.
А как там с индексами всё же?
В качестве индексов применяются несколько вариантов B-tree, битовые индексы, хэш индексы, несколько специализированных вариантов разреженных матриц. Индексы создаются автоматически.
Понятно, как планировщик выбирает тот или иной индекс? Автоматически создается какой индекс или создаются все? не является ли это оверхедом?
Какой индекс применяется при большом наборе данных, с большим количеством дубликатов?
Какой индекс применяется при большом наборе данных, с большим количеством дубликатов?
Планировщик подбирает индексы в зависимости от типа запроса, типа условий, наличия логических операций, объемов данных и многих других условий. В одной из следующих статей мы подробнее расскажем как это работает.
В данный момент индексы создаются автоматически для удобства разработки и прототипирования приложений. В этом случае вообще не требуется никакого администрирования базы данных. Это конечно же оверхед — но не существенный.
В данный момент индексы создаются автоматически для удобства разработки и прототипирования приложений. В этом случае вообще не требуется никакого администрирования базы данных. Это конечно же оверхед — но не существенный.
Почему понадобилось делать свою реализацию вместо того, чтобы, скажем, взять leveldb?
«LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.»
Она не выполняет весь необходимый набор запросов на графах.
Она не выполняет весь необходимый набор запросов на графах.
Ну вы же сами пишете про MVCC. Persistent (функциональные) структуры деревянные, значит вы могли бы использовать готовые хранимые деревья, а на них уже писать графы. А не делать уровень храенения с нуля. Это не так просто, как кажется. Может отнять у вас пару-тройку человеко-лет.
Скорость доступа к узлам графа при обработке запросов на графе требуется минимум раз в 100 больше чем предоставляет LevelDB и многие другие key-value структуры.
Да — этот уровень занял много человеко месяцев. Но в общих трудозатратах при создании графовой базы это менее 5%
Да — этот уровень занял много человеко месяцев. Но в общих трудозатратах при создании графовой базы это менее 5%
Так а какая асимптотика доступа к узлу? Лучше логарифма? Какая структура данных используется, если не секрет?
Есть два разных варианта доступа к узлу
1) поиск по id — для этого используется специализированная хэш таблица — скорость доступа практически константа
2) доступ по ссылкам (связям между узлами) — для организации ссылок используется специализированная структура типа разреженной матрицы — ссылки представляются неким числом — скорость доступа по ссылке практически константа и равна 2-3 обращениям к памяти
1й вариант — это лишь для обработки простейшего запроса когда id объекта задается в запросе
2й вариант — это все запросы требующие навигации по графу
индексы также ссылаются на узлы не через их id а используют ссылку на запись
1) поиск по id — для этого используется специализированная хэш таблица — скорость доступа практически константа
2) доступ по ссылкам (связям между узлами) — для организации ссылок используется специализированная структура типа разреженной матрицы — ссылки представляются неким числом — скорость доступа по ссылке практически константа и равна 2-3 обращениям к памяти
1й вариант — это лишь для обработки простейшего запроса когда id объекта задается в запросе
2й вариант — это все запросы требующие навигации по графу
индексы также ссылаются на узлы не через их id а используют ссылку на запись
Но ведь эти структуры сами по себе не могут быть multi-version. Как планируется переключиться на этот подход? Как делать консистентный update разреженной матрицы, хэш-таблицы, и т. п.?
В эти структуры уже заложена версионность во время реализации. Узлы графа существуют в нескольких версиях, есть сборка мусора с учетом устаревших версий. Хэш таблица также поддерживает версионность. С разреженными матрицами мы пока проверяем три различных варианта реализации версионности.
В реализации версионности есть разные подходы в зависимости от сценариев использования базы. Допускается ли всего несколько параллельных версий или же допускается неограниченное количество версий. Неограниченное количество версий заманчиво но менее эффективно в большинстве реальных сценариев.
Но независимо от выбора сами механизмы версионности уже заложены.
В реализации версионности есть разные подходы в зависимости от сценариев использования базы. Допускается ли всего несколько параллельных версий или же допускается неограниченное количество версий. Неограниченное количество версий заманчиво но менее эффективно в большинстве реальных сценариев.
Но независимо от выбора сами механизмы версионности уже заложены.
«и равна 2-3 обращениям к памяти» — а если перестаёт влезать в память, то производительность скатывается до количества IOPS диска?
В худшем случае (когда мало запросов) то да — каждую запись нужно прочитать с диска. Но при большом количестве запросов существуют методы оптимизации
1) если есть множество запросов к разным страницам можно читать сначала ту к которой максимальное количество обращений (например 10) — тогда мы обеспечим одно обращение к диску вместо 10
2) пока читали некоторую страницу — возможно уже появились запросы на слудующую — тогда можно обеспечить последовательное чтение — что намного быстрее (особенно в с учетом того что к следующей странице к этому моменту уже может оказаться много запросов)
1) если есть множество запросов к разным страницам можно читать сначала ту к которой максимальное количество обращений (например 10) — тогда мы обеспечим одно обращение к диску вместо 10
2) пока читали некоторую страницу — возможно уже появились запросы на слудующую — тогда можно обеспечить последовательное чтение — что намного быстрее (особенно в с учетом того что к следующей странице к этому моменту уже может оказаться много запросов)
Язык запросов OData сопоставим по мощности с SQL.
Можно пример аналога с использованием SQLных СТЕ?
OData поддерживает рекурсивные запросы (подробнее в документации http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part2-url-conventions.html)
Например, запрос: получить человека с id=117 со всеми его друзьями и друзьями друзей (в виде дерева)
host/service/yourdb/person(117)?$expand=friends($levels=2)
Например, запрос: получить человека с id=117 со всеми его друзьями и друзьями друзей (в виде дерева)
host/service/yourdb/person(117)?$expand=friends($levels=2)
Sign up to leave a comment.
Управление данными с помощью протокола OData