пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В первой части статей о протоколе Border Gateway Protocol (BGP) мы узнали и разобрали протокол BGP, а затем изучили типы сообщений BGP и состояния соседства. Сегодня, в этой статье, вы узнаете об одном из самых сложных аспектов BGP: как он принимает решение о выборе маршрута.
В то время как протоколы маршрутизации, такие как RIP, OSPF и EIGRP, имеют свои собственные метрики, используемые для выбора «лучшего» пути к целевой сети, BGP использует коллекцию атрибутов пути (PAs).
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Видео: Основы BGP за 7 минут
BGP- атрибуты пути (Path Attributes)
Когда ваш спикер BGP получает BGP префикс, к нему будет прикреплено множество атрибутов пути, и мы знаем, что они будут иметь решающее значение, когда речь заходит о том, чтобы BGP выбрал самый лучший путь к месту назначения.
Все атрибуты BGP- маршрута, делятся на четыре основные категории.
Well-Known Mandatory
Well-Known Discretionary
Optional Transitive
Optional Non-Transitive
Обратите внимание, что две категории начинаются с термина Well-Known. Well-Known означает, что все маршрутизаторы должны распознавать этот атрибут пути. Две другие категории начинаются с термина Optional. Optional означает, что реализация BGP на устройстве вообще не должна распознавать этот атрибут.
Тогда у нас есть термины mandatory и discretionary, связанные с термином Well-Known. Mandatory означает, что обновление должно содержать этот атрибут. Если атрибута нет, тогда появится сообщение об ошибке уведомления, и пиринг будет удален. Discretionary, конечно, будет означать, что атрибута не должно быть в обновлении.
У необязательных категорий атрибутов есть- транзитивные и нетранзитивные. Если он транзитивен, то устройство должно передать этот атрибут пути своему следующему соседу. Если он не является транзитивным, то может просто игнорировать это значение атрибута.
Пример 1 показывает проверку нескольких атрибутов пути для префикса, который был получен маршрутизатором TPA1 от маршрутизатора ATL. Обратите внимание, что мы используем команду show ip bgp для просмотра этой информации, которая хранится в базе данных маршрутизации BGP. В частности, этот вывод показывает атрибуты Next Hop, Metric (MED), LocPrf (Local Preference), Weight, и Path (AS Path).
TPA1#show ip bgp
BGP table version is 4, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale
Origin codes^ I – IGP, e – EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 100.100.100.0/24 10.10.10.2 0 200 i
Атрибут Origin
Атрибут ORIGIN в BGP-это попытка записать, откуда пришел префикс. Существует три возможности, когда речь заходит о происхождении этого атрибута: IGP, EGP и Incomplete. Как видно из легенды примера 1, коды, используемые Cisco для этих источников, являются i, e, и ?. Для префикса, показанного в примере 1, можно увидеть, что источником является IGP. Это указывает на то, что префикс вошел в эту топологию благодаря сетевой команде внутри конфигурации этого исходного устройства. Далее в этой статье мы рассмотрим сетевую команду во всей ее красе. Термин IGP здесь предполагает, что префикс произошел от записи протокола внутреннего шлюза (Gateway Protocol). Допустим, у нас есть префикс в нашей таблице маршрутизации OSPF, а затем мы используем сетевую команду внутри BGP, чтобы поместить его в экосистему BGP. Конечно, IGP - не единственный источник префиксов, которые могут нести этот атрибут. Например, вы можете создать локальный интерфейс обратной связи на устройстве, а затем использовать сетевую команду для объявления этого локального префикса в BGP.
EGP ссылается на ныне устаревший протокол внешнего шлюза (Exterior Gateway Protocol), предшественник BGP. В результате вы не увидите этот исходный код.
Incomplete означает, что BGP не уверен в том, как именно префикс был введен в топологию. Наиболее распространенным сценарием здесь является то, что префикс был перераспределен в Border Gateway Protocol из какого-то другого протокола, обычно IGP.
Возникает вопрос, почему исходный код имеет такое значение. Ответ заключается в том, что это ключевой фактор, когда BGP использует свой алгоритм для выбора наилучшего пути к месту назначения в сети. Он может разорвать «связи» между несколькими альтернативными путями в сети. Мы также уделяем этому атрибуту большое внимание, потому что это действительно один из хорошо известных, обязательных атрибутов, которые должны существовать в наших обновлениях.
Атрибут AS Path
AS Path - это well-known mandatory атрибут. Он очень важен для наилучшего поиска пути, а также для предотвращения петель внутри Border Gateway Protocol.
Рассматривая нашу топологию, показанную на рисунке 1, рассмотрим префикс, возникший в TPA. Обновление отправляется в TPA1, и TPA не добавляет свой собственный AS 100 в AS Path, так как сосед, которому он отправляет обновление, находится в своем собственном AS в соответствии с пирингом iBGP.
Когда TPA1 отправляет обновления на ATL, он добавляет номер 100 в обновления. Следуя этой логике, ATL отправит обновления на ATL2 и не будет добавлять свой собственный номер в качестве AS. Это будет работать до тех пор, пока ATL2 не отправит обновления на какой-то другой AS, предшествующий AS 200. Это означает, что, когда мы рассматриваем образец AS path, как показано в примере 2, крайним правым в пути является AS, который первым создал префикс (100), а крайним левым- AS, который доставил префикс на локальное устройство (342).
Пример 2: Пример BGP AS Path
Атрибут Next Hop
На самом деле нет ничего удивительного в том, что префикс BGP имеет атрибут под названием Next Hop. В конце концов, маршрутизатор должен знать, куда отправлять трафик для этого префикса. Next Hop атрибут удовлетворяет эту потребность. Интересным моментом здесь, однако, является тот факт, что Next Hop в BGP работает не так же, как это происходит в большинстве IGP. Также следует отметить, что правила меняются, когда вы рассматриваете iBGP в сравнении с eBGP.
При рассмотрении протокола внутреннего шлюза, когда устройство отправляет обновление своему соседу, значением Next Hop по умолчанию является IP-адрес интерфейса, с которого отправляется обновление. Этот параметр продолжает сбрасываться каждым маршрутизатором по мере прохождения обновления через топологию. Next Hop принимает простую парадигму «hop-by-hop».
С помощью BGP, когда у нас есть пиринг eBGP и отправляется префикс, Next Hop действительно будет (по умолчанию) IP-адресом спикера eBGP, отправляющего обновление. Однако IP-адрес этого спикера eBGP будет сохранен в качестве Next Hop, поскольку префикс передается от спикера iBGP к спикеру iBGP. Очень часто мы видим атрибут Next Hop, являющийся IP-адресом, который не является устройством, передавшим нам обновление. Это действительно адрес, который представляет собой соседний AS, который предоставил нам префикс. Таким образом, правильно думать о BGP как о протоколе «AS-to-AS» вместо протокола «hop-to-hop».
Это может вызвать определенные проблемы. Основной вывод состоит в том, что вы должны гарантировать, что все ваши спикеры BGP могут достичь значения Next Hop указанного в атрибуте, чтобы путь считался допустимым. Иначе говоря, спикеры BGP будут считать префикс недопустимым, если они не смогут достичь значения Next Hop.
К счастью, эту проблему можно обойти. Вы можете взять устройство iBGP и проинструктировать его, установив себя в качестве значения Next Hop всякий раз, когда вам это нужно. Это делается с помощью манипуляции пирингом командой neighbor, как показано в примере 3.
ATL (config)# router bgp 200
ATL (config-router)# neighbor 10.10.10.1 next-hop-self
Атрибут BGP Weight (веса)
Weight (вес) - это очень интересный атрибут BGP, так как он специфичен для Cisco. Хорошая новость заключается в том, что, поскольку Cisco является гигантом в отрасли сетей, то многие другие производители будут поддерживать использование Weight в качестве атрибута.
Weight также является одним из самых уникальных атрибутов, поскольку это значение не передается другим маршрутизаторам. Weight - это значение, которое присваивается нашим префиксам как локально значимое значение. Weight - это простое число в диапазоне от 0 до 65535, и чем выше значение веса, тем выше предпочтение этого пути. Когда префикс генерируется локально, он будет иметь вес 32768. В противном случае вес префикса по умолчанию равен 0.
Как можно использовать вес? Поначалу это покажется странным, так как он не передается другим спикерам BGP. Однако все просто. Допустим, ваш маршрутизатор получает один и тот же префикс от двух разных автономных систем, с которыми он работает. Если администратор хочет предпочесть один из путей по какой-либо причине, он может манипулировать локальным значением веса на предпочтительном пути и мгновенно влиять на процесс принятия решения о наилучшем пути BGP.
BGP Best Path (выбор лучшего пути)
Как было сказано ранее, мы знаем, что у IGP есть метрическое значение, которое является ключевым для определения наилучшего пути к месту назначения. В случае с OSPF эта метрика основана на стоимости, которая основана на пропускной способности. У BGP существует множество атрибутов пути, которые может иметь префикс. Все они поддаются алгоритму выбора наилучшего пути BGP. На рисунке 2 показаны шаги (начиная сверху), которые используются в выборе наилучших путей Cisco BGP.
Изучая эти критерии выбора пути, вы можете сразу же задаться вопросом, почему он должен быть таким сложным. Помните, когда мы имеем дело с чем-то вроде интернета, мы хотим, чтобы было как можно больше регулировок для политики BGP. Мы хотим иметь возможность контролировать, насколько это возможно, как префиксы используются совместно и предпочтительно в такой большой и сложной сети.
В эпоху, когда многие процессы автоматизированы, люди постоянно ищут способы, как эффективно выполнять задачи. А почему бы и нет? Дорога каждая секунда!
Совершенно аналогично, если вы используете Unix-подобную операционную систему, вы можете сэкономить свое время, прибегнув к автоматизации задач посредством заданий Cron. Давайте быстро разберемся, как это работает, и рассмотрим несколько облачных решений, предназначенных для мониторинга заданий Cron.
Итак, что же такое задание Cron на самом деле?
Задание Cron – это программа-утилита, которая планирует сценарии и команды на сервере. У этой встроенной команды есть запланированное время и дата для того, чтобы она могла запуститься автоматически без ручной реализации.
Более того, задания Cron созданы именно для того, чтобы автоматизировать повторяющиеся задачи, например, удаление файлов в недельный срок, перезагрузка сервера или выполнение ряда других функций.
Основные элементы задания Cron
Задание Cron работает с тремя важными компонентами:
Сценарий. Сценарий – это первое, что внедряется в задание Cron и вызывается для исполнения.
Расписание. Расписание определяет, когда необходимо запускать указанные сценарии.
Действие. Действие – это порядок, в котором должен появляться результат после того, как сценарий будет полностью выполнен.
Типы заданий Cron, которые нужно контролировать
Конечно, если вы пропустили какое-то уведомление о заданиях Cron, это не будет иметь никаких моментальных негативных последствий, но, если говорить о долгосрочной перспективе, то это может препятствовать работе системы. Вот список некоторых заданий Cron, которые зачастую остаются незамеченными, если люди не используете хорошую службу мониторинга:
Резервное копирование
Обновление SSL-сертификата
Антивирусное сканирование
Динамическое обновление DNS
Перезагрузка сервера
и многие другие.
Приятные бонусы мониторинга заданий Cron
Если не принимать во внимание истинную эффективность заданий Cron, которые предлагают пошаговое управление текущим выполнением по мере того, как идет время, службы мониторинга обладают следующими «плюшками»:
Планирование заданий. С помощью любых выражений Cron и временных интервалов можно легко планировать задачи.
Мгновенные оповещения. Если какой-то прикладной процесс или задание занимает больше времени, чем было рассчитано, эти службы отправляют мгновенные оповещения.
Анализ метрик. Вы можете отслеживать все метрики заданий, и, кроме того, контролировать их для того, чтобы выполнить наиболее эффективные действия.
А теперь давайте рассмотрим несколько облачных решений для контроля за заданиями Cron.
1. Better Uptime
Better Upime – это современная служба мониторинга, которая объединяет мониторинг cron-заданий и периода работоспособности, управление инцидентами и страницы состояний в один прекрасно устроенный продукт.
Настройка занимает всего 3 минуты. После того, как вы настроите Better Uptime, каждый раз, когда ваше Cron-задание будет выполняться с ошибками, вы получите звонок, письмо на электронную почту или уведомление в Slack. Вот его основные особенности:
Проверки Cron-заданий, API, Ping, HTTP(s) соединений, срока действия SSL и TLD
Неограниченное количество уведомлений посредством телефонных звонков
Простое планирование по требованию
Скриншоты и журналы регистрации ошибок и инцидентов
Slack, Teams, Heroku, AWS и еще более 100 прочих интеграций
2. HealthChecks
HealthChecks считается одной из самых лучших систем мониторинга Cron-заданий за счет своей простоты и эффективности. Она будет оповещать вас о происшествиях из еженедельных отчетов, некорректном выполнении запланированных задач, сбоях резервного копирования и т.д.
У HealthChecks есть еще одна немаловажная особенность. Эта система предоставляет уникальный URL-адрес для каждого периодического задания, для которого выполняется мониторинг. Вы можете с легкостью проверять запросы HTTP-службы или отправлять электронные письма.
Если вы будете использовать HealthChecks, в конечном итоге, число скрытых сбоев уменьшится. У нее есть информационная панель, которая обновляется в режиме реального времени и предоставляет подробную информацию обо всех уведомлениях и проверках. Кроме того, вы можете присвоить имена или теги проверкам, чтобы в последствие вам было проще их различать.
Она имеет простую конфигурацию с параметрами «Grace Time» и «Period», с помощью которых вы можете указать различные подходы и статусы мониторинга. Таким образом вы можете добавить подробное описание для каждой проверки или Cron-задания.
Вы можете добавить указатели или заметки для вашей команды, чтобы она могла работать с ними дальше. Кроме того, вы можете просмотреть отправленную или полученную историю Ping. Есть и другие функции: индикаторы общедоступного статуса, поддержка Cron-выражений и интеграция со Slack, электронной почтой, Webhook, Microsoft Teams и т.д.
3. Cronitor
Cronitor может посодействовать вам в планировании заданий и сделать его более удобным с помощью быстрых уведомлений. Он может работать с несколькими типами Cron-заданий: запланированные события AWS, планировщик задач Microsoft, задание Jenkins, Cron-задание в Kubernetes, Cron-задание в Java и т.д.
Мониторинг контрольного сигнала позволяет получить понимание того, как работают конвейеры данных, фоновые задания, демон-процессы, сценарии, ETL-задания и т.д. Его можно без проблем использовать на любом языке или платформе, у него гибкие политики уведомлений и правила.
Кроме того, Cronitor предлагает мониторинг периода работоспособности веб-сайта, API, хранилища S3 и т.д.
4. Cronhub
Cronhub избавит вас от необходимости писать код для того, чтобы планировать и контролировать фоновые задания. Все, что вам нужно сделать, это сфокусировать свое внимание на своих приложениях и позволить им планировать ваши задачи. Как только в запланированных задачах появятся какие-либо отклонения, вы получите мгновенное уведомление о результатах мониторинга.
Вы можете планировать свои задания с помощью Cron-выражений и временных интервалов. Для этого вам нужно определить API или целевой URL-адрес, который будет выполняться в вашем задании. После чего Cronhub отправит HTTP-запрос к этому API или URL.
Если по какой-либо причине расписание заданий меняется, Сronhub сразу же оповестит вас через встроенные каналы, например, SMS-сообщения, Slack, электронную почту и т.д.
Кроме того, с помощью Cronhub вы можете отслеживать аналитическую информацию для ваших заданий, обеспечивать поддержку работы команды и доступ к журналам. В итоге это поможет вам найти бреши в вашем приложении, а также отследить фоновые задания.
5. Dead Man’s Snitch
Dead Man’s Snitch разогнался только тогда, когда службы мониторинга Cron-заданий уже успели наделать шуму. Его целью стала точка, в которой задания выставления счетов и резервного копирования работали не в соответствии со своими расписаниями.
Dead Man’s Snitch заботиться о том, чтобы задания Cron отслеживались так, как хотят того разработчики и пользователи. С его помощью вы можете контролировать Cron, планировщик Heroku и т.д. Для того, чтобы он имел возможность информировать пользователей о неисправностях любого рода, ему нужно уведомление от HTTP-клиента, например, cURL.
Curl – это фрагмент кода, который добавляется к концу строки Crontab в качестве расширения. Он выполняет запрос к Dead Man's Snitch для того, чтобы проверить, работает ли задание и работает ли оно корректно. Вы можете изменить URL-адреса snitch’а для разных заданий, чтобы получить результаты мониторинга для каждого из них.
Есть еще одна довольно интересная функция. Вы можете добавить к заданию функцию «Field Agent». Вы можете скачать и установить ее для того, чтобы получить более качественные результаты мониторинга, а также метрики и записи данных. С ее помощью вы можете проверять журналы регистрации ошибок Cron-заданий для того, чтобы разрешить их наилучшим образом.
Все эти функции – это идеальный комплекс, с помощью которого вы можете отслеживать фоновые задания более эффективно. Его цена начинается с 5 долларов в месяц за три snitch’а и неограниченное количество членов команды.
6. Web Gazer
Wen Gazer поможет вам планировать задания и запускать мониторинг выбранных Cron-заданий для того, чтобы вы могли отслеживать производительность.
В Web Gazer не бывает ложных оповещений, так как, прежде чем оповещения об инцидентах будут отправлены пользователю, все инциденты проверяются в течение буквально доли секунды. Кроме того, Web Gazer предоставляет функцию мониторинга контрольного сигнала и мониторинга SSL.
Его ценник начинается с 19 долларов в месяц, или же вы можете воспользоваться его бесплатной версией, в которой есть все основные функции.
Заключение
Будущее за автоматизацией.
С помощью планирования и мониторинга Cron-заданий вы сможете эффективно выполнять свою работу. А как иначе вы бы смогли узнать, что что-то идет не по плану? Но вам не о чем беспокоиться, потому что решения, которые мы привели выше, в итоге помогут вам оптимизировать ваши задания и устранить бреши, которые затрудняют работу пользователя.
Многомерные системы управления данными (МСУБД) объединяют несколько систем баз данных в одну. Вместо работы с несколькими моделями и поиска возможностей для их объединения, МСУБД предлагает общий механизм для различных типов данных.
В данной статье приводится подробный обзор многомерных баз данных.
Что такое многомерные базы данных?
Многомерная база данных (Multi-Model Database) – это система управления, которая сочетает несколько типов БД в одну серверную систему. Большинство СУБД поддерживает одну модель БД, а в МСУБД можно хранить, запрашивать и индексировать данные из нескольких моделей.
Важное преимущество многомерных БД заключается в многоязычной сохранности, когда не нужно искать способы для объединения различных моделей. Гибкий подход позволяет хранить данные разными способами. В результате вы получаете:
Гибкое и динамичное программирование
Снижение избыточности данных
Например, изучать взаимосвязи между точками данных или создавать систему рекомендаций гораздо проще с помощью графовых БД, а реляционные БД лучше подходят для определения связи между столбцами данных.
Ключевая функция МСУБД заключается в ее способности преобразовывать данные из одного формата в другой. К примеру, данные в формате JSON быстро преобразуются в XML. Преобразование форматов данных обеспечивает дополнительную гибкость и упрощает соответствие определенным требованиям проекта.
Примеры использования МСУБД
Варианты использования СУБД позволяют лучше понять принципы работы данной модели. Анализируя практические примеры, вам становится ясно, как несколько моделей работают в единой системе.
Хранение и управление несколькими источниками данных
Классическая IT-система использует различные источники данных. Информация не всегда хранится в том же формате или в той же базе данных. Несколько форматов складываются в сложную систему – трудную для поддержания и поиска данных.
Хранение данных в МСУБД облегчает администрирование систем. Все находится в одной базе, поэтому на хранение и управление данными из разных источников тратится меньше времени.
Расширение возможностей модели
Многомерные базы данных предлагают расширения для моделей. Особенности одних моделей перекрывают недочеты других.
Например, очень просто запрашивать данные в JSON-формате через SQL-запросы. Нет необходимости корректировать исходный источник данных. Расширяемость сокращает время обработки данных и устраняет необходимость в ETL-системах (извлечение, преобразование, загрузка).
Гибридные среды данных
Классическая среда данных разграничивает операционные данные от аналитических. Данные для анализа необходимо преобразовать и хранить отдельно от операционных.
Происходит задвоение, и качество данных снижается. Разделенное пространство повышает затраты на техническое обслуживание. Всем базам данных необходимо администрирование и управление резервным копированием.
Многомерная БД использует гибридный подход к хранению данных. Унифицированные узлы, в которых хранятся транзакционные данные и из которых извлекаются аналитические, намного проще поддерживать.
Централизация данных
У данных в организации есть определенные ограничения. Такие ограничения нужны, но они усложняют работу с информацией внутри компании.
Многомерные БД хранят данные в формате as-is («как есть»), поэтому никакие преобразования не нужны. Централизация данных дает ценную информацию о существующих данных и предлагает возможности для создания новых вариантов использования.
Поиск больших данных
Hadoop отлично справляется с обработкой больших объемов данных в разных моделях. Основная причина – скорость получения, обработки и хранения данных. Единственное, чего не хватает Hadoop, – это эффективного механизма поиска.
Если взять вычислительные мощности Hadoop и объединить их с возможностями поиска по многомерной БД, то получится функциональная система. Процесс работы становится масштабируемым и удобным для выполнения задач над большими данными.
Плюсы и минусы многомерной базы данных
В многомерных базах данных есть свои плюсы и минусы. В таблице ниже перечислены ключевые пункты:
Плюсы
Минусы
Постоянство данных
Сложность
Динамичность
Все еще в стадии разработки
ACID-совместимость
Не хватает методов моделирования
Подходят для сложных проектов
Не подходят для простых проектов
Такая модель подходит для корпоративных настроек с множеством данных. Разные секторы пользуются данными для разных задач. Но детализированной и уже настроенной структуре многоязычной сохранности может не хватать возможностей многомерной системы.
Плюсы
Преимущества многомерных баз данных:
согласованность данных между моделями за счет единой серверной системы
динамичная среда с использованием различных типов данных на одной платформе
отказоустойчивость, из-за ACID-совместимости
подходят для сложных проектов с множественным представлением данных
Минусы
Недочеты многомерных баз данных:
сложность МСУБД, из-за чего с ними трудно работать
модель БД все еще развивается и не имеет окончательной формы
ограниченная доступность различных методов моделирования
не подходит для более простых проектов или систем
Какие многомерные базы данных считаются самыми лучшими?
На рынке представлено огромное множество многомерных типов БД. Их самой примечательной особенностью является поддержка нескольких моделей на одном сервере.
Некоторые БД накладывают несколько моделей на сервер через компоненты. Но такие типы БД не считаются подлинными многомерными базами.
Еще одно важное отличие – доступные методы моделирования. Этот аспект крайне важен для того, чтобы получать максимальную пользу от доступных данных.
MarkLogic Server
MarkLogic Server – это многомерная нереляционная база данных. Она появилась как хранилище XLM, а затем была доработана для хранения различных моделей:
документной
графовой
текстовой
пространственной
типа «ключ – значение»
реляционной
Это универсальная, эффективная и безопасная база данных. Возможности сервера MarkLogic:
Безопасность и управление. Интегрированное управление безопасностью данных и пользователей.
ACID-совместимость. Обеспечивает строгую согласованность данных.
Расширенный поиск. Доступ к данным обеспечивает встроенная поисковая система с семантическим поиском.
Разноплановая аналитика. Вам доступны настраиваемые инструменты для аналитики и бизнес-аналитики.
Встроенное машинное обучение. Интеллектуальное автоматизированное курирование данных с помощью встроенных алгоритмов машинного обучения обеспечивает более быстрый доступ к данным.
Отказоустойчивость. Mark Logic предлагает высокую доступность и систему аварийного восстановления, помогающую избегать любого рода сбоев.
Поддержка гибридного облака. База данных позволяет самостоятельно управлять развертыванием с помощью гибридных облачных решений.
ArangoDB
ArangoDB – это нативная многомерная система управления базами данных. Она поддерживает следующие форматы данных:
документные
графовые
«ключ-значение»
База данных извлекает и изменяет данные с помощью унифицированного языка запросов AQL. К другим важным особенностям относятся:
Расширенные соединения. Позволяет соединять данные с помощью гибких запросов, что снижает их избыточность.
Транзакции. Выполнение запросов к нескольким документам с доступной изоляцией и согласованностью транзакций.
Сегментирование. Синхронная репликация путем сегментирования позволяет снижать внутреннюю кластерную связь, повышая при этом производительность и скорость соединения.
Репликация. Репликация обеспечивает распределенную БД в пределах одного центра обработки данных.
Многопоточность. Благодаря многопоточности, БД может использовать несколько ядер.
OrientDB
OrientDB – это многомерная нереляционная база данных с открытым кодом, написанная на Java. Эта БД поддерживает следующие модели:
документную
графовую
тип «ключ-значение»
объектную
пространственную
OrientDB первая ввела несколько моделей на уровне ядра. Эта база данных поставляется с рядом уникальных функций, к которым относятся:
Поддержка SQL. БД поддерживает SQL-запросы, благодаря чему программистам легче переключиться с реляционных моделей на OrientDB.
ACID-совместимость. База данных полностью транзакционна; таким способом достигается ее надежность.
Распределенная. Полная поддержка репликации с множеством master на разных выделенных серверах.
Портативная. Позволяет быстро импортировать реляционные базы данных.
Заключение
Существует великое множество методов моделирования баз данных, и в каждом решении можно найти свои плюсы и минусы. Многомерные БД стремятся объединить различные базы данных в единую серверную систему, благодаря чему при разрастании системы ее сложность и потребление ресурсов не увеличиваются.