GenieDB

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 19:43, 17 января 2019.
GenieDB
300px
Разработчики: GenieDB
Выпущена: 1 January 2008 (2008-01-01)
Постоянный выпуск: 1.3 / 28 July 2014 (2014-07-28)
Состояние разработки: Закрыт
Написана на: Java, Python
Операционная система: Linux/UNIX, CentOS 6.3
Локализация: Английский
Тип ПО: DBaaS
Лицензия: Коммерческая
Веб-сайт GenieDB

GenieDB - это облачная база данных MySQL как услугу (DBaaS), которая помогает быстро, безопасно и с минимальными затратами развернуть базу данных MySQL. DBaaS GenieDB использует репликацию с несколькими хозяевами и распределение по регионам в нескольких облачных инфраструктурах (Amazon AWS, HP Cloud, Rackspace Cloud и Google Cloud), чтобы сократить время ожидания, сократить время простоя и легко масштабировать базу данных. [Источник 1].

О компании

GenieDB основана в 2011 году. Компания стремится обеспечить надежный, простой в использовании и развертывании сервис базы данных для поддержки проектов облачных вычислений организаций. GenieDB создана с целью решить проблему «как легко распределить стандартное приложение SQL на большие географические расстояния, достичь более высоких уровней устойчивости и производительности приложений, чем это было возможно ранее, и сделать это таким образом, чтобы чрезвычайно прост в реализации и управлении ". [Источник 2].

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

Значительно упрощая миграцию SMB в географически распределенные облачные инфраструктуры, GenieDB обеспечивает глобальную масштабируемость для основного потока. Инновационный и запатентованный подход GenieDB автоматизирует и оптимизирует управление согласованностью, репликацией и синхронизацией данных в глобальных сетях и облаках, обеспечивая непрерывную доступность и производительность локальной базы данных в глобальном масштабе.

GenieDB- самая ранняя сценическая компания, представленная на Under The Radar и Oracle Open World 2010, и была номинирована и признана «Стартапом для наблюдения» на Structure 2011. Головной офис GenieDB находится в Сан-Хуан-Капистрано, Калифорния.

Основные особенности GenieDB

Основное нововведение GenieDB - это инженерное решение одной из самых давних проблем в области компьютерных наук. Проблема для любой распределенной системы, например, для реплицированной базы данных, была объяснена профессором Эриком Брюером в его CAP Теорема: ни одна база данных не может одновременно пользоваться допуском согласованности, доступности и разделения. Но действительно ли это имеет значение?

Конечный результат вызывает большие и дорогостоящие проблемы для разработчиков и предприятий соответственно:

  • Стоимость и компромисс при масштабировании или репликации для устойчивости
  • Время и непредсказуемость исправления реплицированных баз данных при их поломке
  • Нагрузка на разработчиков, чтобы справиться с зародышевыми альтернативами NoSQL

GenieDB - это «технология многоуровневой базы данных», которая обеспечивает немедленную согласованность с полной репликацией нескольких мастеров, не нарушая законов физики. Наша технология может быть применена к любой базе данных. Он продвигает современное состояние как полностью реплицированное хранилище данных NoSQL, но на этом не заканчивается. Как это поможет?

  • Почти линейный масштаб, невидимый для приложения или пользователя
  • Немедленная согласованность и минимальное влияние задержки во время разделения
  • Самовосстановление ... так что вы можете спать по ночам[Источник 3].

Основная особенность GenieDB - это, вероятно, глобальная репликация. Специфика там включает в себя: Технология самовосстановления, позволяющая обнаруживать ошибки и несинхронизированные условия и соответственно запрашивать повторную передачу данных. VPN, чтобы связать все вместе.

Очевидно, что репликация всей базы данных на каждый узел накладывает некоторые ограничения, в частности: Размеры базы данных GenieDB ограничены тем, что хорошо вписывается в узел - если, например, не добавлена ​​какая-либо технология прозрачного разделения. GenieDB не предлагает преимущества соответствия нормативным требованиям разделения данных в соответствии с их географическим происхождением.

Тем не менее, GenieDB предлагает:

Резервирование среди облачных дата-центров. Преимущества времени отклика, заключающиеся в том, что данные находятся рядом с пользователем. Поддержка иногда связанных топологий. (Пример GenieDB приводит нефтяные вышки.) [Источник 4].

Архитектура

Масштабируемость

Существует множество структур, шаблонов и технологий, которые помогают масштабировать приложение в одном месте. Фермы веб-приложений и серверов приложений, разработка приложений без сохранения состояния (Restful), memcached, сегментированные базы данных и т.д. Как насчет масштабирования в несколько географически распределенных местоположений? Хорошо написанный стек приложений, вероятно, будет работать «из коробки» или с небольшими изменениями, но есть над чем подумать. Во-первых, база данных на внутреннем сервере должна быть реплицирована и синхронизирована. Стандартные стратегии репликации, основанные на конфигурации доставки журналов и главного-подчиненного, могут быть проблематичными. GenieDB решает проблемы, связанные с распределением базы данных по географически распределенным местоположениям, позволяя вносить изменения в реплики базы данных в любом месте и обеспечивая синхронизацию этих обновлений по всем сайтам, а все конфликты разрешаются автоматически, поэтому база данных всегда остается в состоянии согласованности. Это решает проблемы с базой данных на бэкэнде, но есть и другие проблемы, связанные с тем, как оптимизировать время отклика, перенаправляя пользователей в самый отзывчивый/ближайший из множества сконфигурированных центров обработки данных. Потому что, если они не доберутся до самого отзывчивого стека приложений, они будут без необходимости видеть задержки приложений. Проблема масштабируемости: Если предположить, что уровень базы данных реплицируется, синхронизирован и надежен, какую инфраструктуру вы используете для обеспечения того, чтобы пользователи видели минимальное время простоя приложения, если оно есть.

Geo-DNS с Активным мониторингом

Это лучшая альтернатива, когда вам абсолютно необходимо меньше всего сбоев приложений во всем мире. Такие провайдеры, как Dyn.com, предлагают такую ​​услугу. Он позволяет вам настроить TTL для DNS-запроса и связать его с подпрограммой мониторинга, по сути, сердцебиением, ища известный, хороший ответ от вашего приложения, показывая, что все хорошо. Dyn.com позволяет устанавливать TTL на 30 секунд, а частоту мониторинга - каждую минуту. Более низкое значение TTL нереально, так как обычно что-то ниже, и многие кэширующие DNS-серверы переопределяют его с высоким значением, которое находится вне нашего контроля. Вы не можете сделать это слишком агрессивным, и есть также стоимость. Поставщики услуг DNS взимают плату в зависимости от количества запросов, которые должны решить их серверы. Чем ниже TTL, тем выше количество запросов, на которые необходимо ответить, и тем дороже. Гораздо более частый мониторинг также будет загружать ваши серверы, и, следовательно, это хорошие, разумные значения. С этими двумя настройками ваши пользователи увидят не более 1 минуты 30 секунд (в среднем 45 секунд) перерыва в обслуживании из-за любого крупного сбоя, который уносит весь центр обработки данных.

Репликация

Следующие шаги показывают, как технология GenieDB предоставляет вам полностью реплицированную систему с несколькими мастерами. Эти шаги представляют собой типичный запрос к базе данных из приложения, которое будет редактировать запись базы данных, например, «ВСТАВИТЬ» или «ОБНОВИТЬ»

  • Шаг первый - приложение делает запрос к базе данных. Запрос к базе данных вместо того, чтобы отправляться непосредственно в базу данных, отправляется в API GenieDB.
  • Шаг второй - «Немедленная согласованность». Затем этот запрос передается конкретному фрагменту, ответственному за соответствующую запись, на уровне «согласованности». Это известно как «немедленная последовательность». Поскольку уровень согласованности обновляется первым, любые последующие «чтения» в этой записи будут использовать информацию, хранящуюся в слое согласованности
  • Шаг третий - Репликация. В то же время запрос к базе данных отправляется на надежный уровень «обмена сообщениями». Это позволяет отправлять запрос к базе данных на все постоянные базы данных в вашем кластере.
  • Шаг четвертый - постоянство. Запрос к базе данных теперь передается на уровень «постоянство». Все базы данных в кластере теперь обновляются с новой записью.

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

Особенности и ограничения многоадресной репликации мастер-мастер

Синхронная репликация master-master дает строгую гарантию того, что репликация будет происходить согласованно на всех узлах (т.е. Без задержки репликации). Исходя из того, что MySQL полагается на доставку журналов, стандартный MySQL не поддерживает синхронную репликацию любого рода, но в последнее время стали доступны сторонние решения с различными наборами функций. В этой реализации любое изменение на конкретном сервере «сертифицируется» для всех (или большинства) других серверов в кластере. Только когда эта сертификация была успешно возвращена со всех узлов, клиент достигает успешной транзакции. Одной из проблем синхронной репликации является сопутствующий штраф за задержку, препятствующий общей пропускной способности системы, особенно в зоне с множественной доступностью или при развертывании в нескольких регионах. Кроме того, сбои любого узла могут вызвать сбои сертификации, существенный откат транзакций или, что еще хуже, deadlock. GenieDB написал технический документ, специально посвященный многорегиональному геораспределению MySQL в целях высокой доступности, так что отключение в одной географической области (сбой AWS, ураган и т. д.) Не влияет на доступность приложений. GenieDB решает проблему разрешения конфликтов, используя модифицированный подход с метками времени Лампорта, который также позволяет автоматически восстанавливать систему после сбоя или после периода работы, когда узлы отключены, разрешено получать обновления, а затем повторно подключаться.

Самовосстановление

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

  • Шаг первый - Обзор. В качестве примера, рассмотрим систему с тремя узлами, в которой «зеленые» записи хранятся в сегменте согласованности узла «A», «желтые» в узле «B» и «красные» записи в узле «C».
  • Шаг второй - Отключение сети. Внезапно сетевой соединительный узел «А» с остальной частью системы выходит из строя. Это означает, что любые новые «зеленые» записи не могут быть реплицированы в другие узлы. В то же время любые «красные» или «желтые» записи не могут быть реплицированы в узле «A» из-за сбоя в сети.
  • Шаг третий - Самовосстановление. Когда сеть восстановлена ​​и работает, любые новые записи, хранящиеся в постоянных базах данных, затем отправляются на все узлы. Они реплицируются по всей системе, так что все узлы снова становятся согласованными. Кроме того, любые новые полученные записи копируются в соответствии с нормой.

Консоль GeineDB

В GeineDB доступна простая и удобная консоль управления для автоматического администрирования базы данных. Она включает в себя процессы резервного копирования, настройки и обновления. С глобально распределенным MySQL-как-сервисом клиенты могут запускать базу данных MySQL, которая остается доступной, и обеспечивать быстрое время отклика приложений из любой точки мира.[Источник 5].

Быстрая настройка GeineDB

Многие сайты, поддерживаемые CMS, создаются с использованием MySQL и запускаются в облачной инфраструктуре. Чтобы уменьшить время простоя из-за региональных отключений, рекомендуется создать топологию с геораспределением избыточности как на уровне приложения, так и в базе данных. GenieDB позволяет очень легко настроить несколько серверов баз данных MySQL по всему миру, которые автоматически синхронизируются при изменении данных на любом из узлов. Узлы базы данных обычно сопряжены 1-на-1 с приложением или веб-сервером. Некоторые клиенты могут используют серверы приложений для рассылки своих сайтов, поддерживаемых CMS. База данных синхронизируется, но клиентам по-прежнему необходимо найти способ, чтобы используемый ими медиаконтент был доступен для всех этих приложений/веб-серверов. Ниже приведена простая настройка, которая может быть легко настроена при очень небольшом бюджете и обеспечивает высокую доступность как данных, так и статического содержимого во время простоя. В то время как некоторые из наших клиентов используют традиционные решения CDN, такие как CloudFront, у нас есть другие, которые хотели создать собственное решение. Именно для этой последней группы мы разработали «бюджетный CDN». Ключом к этому подходу является создание возможности поддерживать конкретный каталог, содержащий важные активы цифрового контента, синхронизированные на нескольких машинах в разных регионах. Для этого мы использовали Linux inotify и rsync по SSH. Это обеспечивает довольно простой и безопасный механизм, если один и тот же файл не изменяется одновременно на нескольких узлах. Поскольку статический контент обычно обновляется не так часто, как база данных, это обычно не является проблемой для большинства приложений. (Обратите внимание, что для базы данных GenieDB обеспечивает автоматический процесс разрешения конфликтов, но поскольку статический контент находится за пределами базы данных, эти незначительные меры предосторожности необходимо принимать на уровне приложений.) inotify предоставляет механизм для мониторинга файловой системы на наличие событий. Мы используем библиотеку Python, Watcher, которая предоставляет несколько хороших процедур управления поверх pyinotify, оболочки для вызовов inotify Linux.

Установка проста. Укажите каталог для просмотра в watcher.ini

watch=/var/www/uploads
events=create,delete,modify,move_from,move_to
recursive=true
#shell script to execute when changes are detected.
command=sync_www_directories.sh

Измените разрешения на watcher.py, чтобы разрешить выполнение, и мы на полпути. Оставшаяся часть - это скрипт, сконфигурированный в «command» для выполнения при необходимости. Сценарий довольно прост.

#!/bin/bash
#script to sync /var/www/uploads directories
#check if rsync is running and quit script if it still is

RUNNING=$(ps --no-headers -Crsync | wc -l)
if [ $RUNNING -ge 1 ]
then
  exit 1
fi

#Using root to simplify. You should create a specific user for this purpose.
/usr/bin/rsync --exclude '*.tmp' --delete --quiet -a /var/www/uploads root@123.123.123.123:/var/www/uploads &
/usr/bin/rsync --exclude '*.tmp' --delete --quiet -a /var/www/uploads root@231.231.231.231:/var/www/uploads

exit

Этот скрипт синхронизирует указанный каталог с помощью rsync. Просто замените приведенные выше примеры IP-адресов фактическими значениями. Сценарий наблюдателя может быть запущен с помощью:

./watcher.py -c watcher.ini start

Чтобы автоматически запустить этот скрипт при запуске компьютера, чтобы он выдержал перезагрузку, измените /etc/rc.local на указанную выше команду для запуска watcher.

Также необходимо настроить SSH-ключи, чтобы rsync мог войти на другие машины. Это можно сделать с помощью стандартных механизмов создания ключей и добавления их в файлы author_keys на разных серверах. Эти шаги необходимо повторить на всех серверах, входящих в « CDN». В сочетании с автоматическим управлением базой данных GenieDB в нескольких регионах вышеописанная процедура создает очень экономичное решение для обеспечения высокой доступности во время региональных отключений, а также лучшего времени отклика приложений для распределенных пользователей.

Источники

  1. Общая информация // Crunchbase GenieDB [2014-2014]. Дата обновления: 05.05.2014. URL: Crunchbase GenieDB (дата обращения: 05.01.2019)
  2. Информация о компании // Zdnet GenieDB [2014-2014]. Дата обновления: 05.05.2014. URL: zdnet (дата обращения: 05.01.2019)
  3. Особенности GenieDB // GenieDB [2012-2012] - Дата обновления: 27.10.2012. URL: Geniedb (дата обращения: 06.01.2019)
  4. Особенности GenieDB // Dbms2 GenieDB [2012-2012]. Дата обновления: 27.10.2012. URL: dbms2 (дата обращения: 05.01.2019)
  5. Архитектура GenieDB // Blog GenieDB [2012-2012]. Дата обновления: 27.10.2012. URL: GenieDB2 (дата обращения: 05.01.2019)