Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1246 сообщений
Cообщения с меткой

базы данных - Самое интересное в блогах

Следующие 30  »
Максимыч-

Сервис поиска людей.

Четверг, 23 Июня 2016 г. 10:54 (ссылка)




Сервис поиска людей.


Makсимыч


Метки:   Комментарии (2)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Работа с MySQL: как масштабировать хранилище данных в 20 раз за три недели

Суббота, 30 Апреля 2016 г. 12:25 (ссылка)





Ранее в блоге на Хабре мы рассказывали о развитии нашего продукта — биллинга для операторов связи «Гидра», а также рассматривали вопросы работы с инфраструктурой и использования новых технологий. К примеру, мы рассмотрели плюсы Clojure, ситуации, когда стоит и не стоит использовать MongoDB и ограничения в PostgreSQL.



Сегодня речь пойдет о масштабировании. Разработчики open-source почтового приложения Nylas опубликовали в своем блоге материал о том, как им удалось масштабировать систему в 20 раз за три недели с помощью инструмента ProxySQL. Для этого им пришлось переехать с Amazon RDS на MySQL на EC2. Мы представляем вашему вниманию основные моменты этой интересной заметки.



Одним прекрасным днем…



История началась летом 2015. Солнце пробивалось сквозь туман, зависший над Сан-Франциско, по радио играл хит Bad Blood Тейлор Свифт и Кендрика Ламара. В распоряжении Nylas были лишь две машины синхронизации и одна база MySQL, управляемая через Amazon RDS. Это было самое простое решение, которое компании удалось на тот момент найти.



Инженерам компании удалось добиться хорошей производительности этой конфигурации так что они неспешно работали над улучшением логики синхронизации и телеметрии. Команда понимала все опасности преждевременной оптимизации продукта. Все считали, что лучший способ преуспеть в горизонтальном масштабировании системы (шардинге) – это откладывать его, насколько возможно. Поэтому, чтобы выиграть время, инженеры занимались оптимизацией работы с дисками, апгрейдом инстансов и сжатием данных



А затем появились пользователи



Все изменилось 5 октября 2015. В этот день вышел Nylas N1 – открытое email-приложение с красивым пользовательским интерфейсом и современной архитектурой с использованием плагинов. Ссылка на продукт была опубликована в Hacker News. По заверениям команды Nylas, это привело к появлению десятков тысяч новых пользователей за считанные минуты. А вместе с пользователями пришли большие объемы новой информации.



За час база на MySQL перестала справляться с такими объемами, а задержка работы API побила все рекорды. Пришлось временно отключить возможность регистрации. В компании еще не осознали всю глубину проблм, но одна вещь была очевидна всем: нужно масштабироваться как можно скорее.



На баррикады



В течение нескольких дней после запуска Nylas N1 удалось обнаружить сразу несколько узких мест в коде. Пришлось столкнуться с ограничениями Redis и MySQL на объемы вкладок. Инженеры узнали много нового и о работе с AWS.



Но самой серьезной проблемой была база данных. День и ночь команда Nylas пыталась исправить ошибки вроде утечки MySQL-соединений, а также плохо оптимизированные запросы, негативно влиявшие на производительность. Помимо того, чтобы залатать дыры, нужно было подумать о перспективе. Единственный вариант – применить горизонтальное масштабирование данных, чтобы обеспечить качественную поддержку новых пользователей. То есть все-таки пришло время шардинга системы.



Почему MySQL



В 2013, когда компания Nylas была основана, ее инженеры выбрали MySQL, не только исходя из специфических характеристик, но и потому что этот инструмент зарекомендовал себя в работе высоконагруженных проектов. Технологии Cassandra, MongoDB, и Postgres выглядели впечатляющими и быстро прогрессировали, но инженеры были уверены, что с помощью MySQL смогут создать систему обрабатывающую петабайты данных. Об этом говорил и опыт таких компаний как Facebook, Dropbox, Pinterest, и Uber. Использование MySQL позволяло опираться на опыт этих технологических гигантов.



Эта база проста в работе, а требования Nylas изначально были не особенно масштабными. Исходя из этого, было решено использовать хостинг Amazon RDS. RDS не дает root-доступа к хосту MySQL, зато многие процессы автоматизированы. Например, бэкапы и точечные обновления.



Время масштабировать



К моменту возникновения сложностей с производительностью инженеры уже сжали длинные текстовые колонки в базе, что помогло сэкономить 40% места на диске, а также перешли на использование 6-терабайтных дисков. Но InnoDB в СУБД MySQL имеет ограничение 2 ТБ на таблицу, что представляло собой проблему.



Инженеры рассматривали вариант с использованием Amazon Aurora — MySQL-совместимого хранилища с автомасштабированием до 64 Тб. Однако даже в этом случае, при превышении заданного лимита в 64 терабайта, чтобы уместиться в ограничения InnoDB, пришлось бы разбивать данные по различным таблицам. К тому же команде не хотелось настолько сильно зависеть от технологий Amazon в долгосрочной перспективе.



Вместо этого инженеры Nylas осуществили горизонтальное масштабирование с помощью разбиения данных по простой схеме, а также с помощью создания дополнительных MySQL-кластеров, работающих на версиях базы от Oracle на обычных инстансах EC2. Главной целью была простота конфигурации, что позволило завершить оптимизацию за три недели.



Прощай, RDS



В процессе масштабирования было решено отказаться от RDS. Причина в недостатке возможностей по контролю, а также неудачный опыт реализации решений для оптимизации. Казалось, что RDS — просто не решение для создания надежных систем с нулевым временем простоя.



Кроме того, в RDS крайне ограничены возможности настройки репликации. Да, в ней есть опция multi-AZ для синхронного копирования данных, но производительность таких операций оставляла желать лучшего. Однажды ее использование привело к 3-часовому простою в работе приложения Nylas. Пришлось связаться с инженерами Amazon и ждать, пока они исследуют проблему.



Также в Nylas пробовали создавать асинхронные копии для заданной мастер-базы, но оказалось, что активируется такая копия с задержкой в несколько минут. RDS не поддерживает последовательное копирование, которое планировалось использовать для разнесения шардов по инстансам базы.



Вместо этого выяснилось, что многие задачи можно успешно решать с помощью EC2. Да, с отдельными инстансами могут возникать проблемы, но можно было, по крайней мере, создать архитектуру базы, устойчивую к влиянию описанных выше проблем. В компании решили отказаться от RDS и управлять базой самостоятельно.



Запуск MySQL на EC2



Перевод MySQL на EC2 – не совсем простой процесс. Нужно было написать собственные скрипты для управления задачами, которые в RDS были автоматизированы — например провижининг новых серверов, создание и распределение slave-инстансов в случае сбоя master-базы и создание и восстановление резервных копий. В Nylas написали такие скрипты с нуля, но существует и ряд открытых инструментов, решающих те же задачи.



Один из шард-кластеров в MySQL состоит из управляющего узла и подчиненного узла. Второй поддерживает обновления через лог копирования MySQL, и обычно используется для бэкапов. В процессе перенастройки системы, перевода узлов на разные типы инстансов, кластер должен иметь более одного slave-инстанса. Если дополнительные слейвы не активны, они помечены тегом «debug» EC2, что исключает их из мониторинга, бэкапов и других процессов для активных узлов.



Аварийное переключение



Для каждого кластера базы нужно было предусмотреть ситуацию, когда узел мастера отказывается правильно функционировать. Это может произойти, когда процессы в базе сбиваются или виснут, хост становится недоступен, или происходит что-то еще в таком духе. На этот случай нужно иметь в запасе возможность восстановления, вручную или автоматически, когда slave-узел заменяет на время master-узел и получает одновременно запросы чтения и записи.



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



Восстановление работает автоматически, но инженеры получают оповещения. После чего, один из них может вручную выявлять узел, на котором произошел сбой, и преобразовывать его в новый слейв для кластера. Если такой возможности нет — например, в случае повреждения данных, предыдущий мастер выводится из эксплуатации, а новый слейв создается из самого последнего бэкапа. Система стала устойчивой к сбоям, и ей стало легче управлять.



Шардинг приложения



При переходе с одной базы данных к нескольким базам данных на разных машинах необходимо разработать новый механим маппинга ID объектов на конкретные серверы. Это особенно актуально, если приложение ссылается на базу по первичному ключу во вторичном хранилище, как это происходит у Redis.



Инженеры Nylas подобрали простое решение этой задачи: значение первичного ключа таблицы — это 64-битное целое число, верхние же биты содержат ID шарда, нижние биты являются локальным счетчиком автоматических числовых ключей.



|<--16bits-->|<--------48bits------->|
+------------+-----------------------+
| shard id | autoincrement |
+------------+-----------------------+


Это позволяет легко рассчитывать шард-ID по первичному ключу. Запрос на любой объект может быть направлен в правильный шард просто через первичный ключ. Чем проще система – тем надежнее работа с ней в перспективе.



Например, уровень аутентификации приложения способен конвертировать хэшированные токены доступа в ID аккаунта для доступа к API. Команде проекта удалось провести шардинг сервиса без изменения ключевых его компонентов. Поскольку движок Nylas так же как и приложение — открытый продукт, любой желающий может изучить особенности реализации такой системы на GitHub.



Создание новых шардов



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



При создании нового шарда рассчитать биты высокого порядка просто через:



N = (shard_id<<48) + 1



Значение автоматических чистовых ключей рассчитывается так:



ALTER TABLE mailsync_. AUTO_INCREMENT=N


Новые ряды в таблице, соответственно, будут иметь первичные ключи N, N+1 и так далее. В данном случае таблицы базы имеют автоматические ключ, начинающиеся со значения 1. Инженеры Nylas советуют при использовании этого метода обращать внимание на ошибку MySQL под номером #199. Этому багу уже 13 лет, но он до сих пор не исправлен. Чтобы избежать проблем с ним, код приложения должен быть защищен от некорректных значений автоматических ключей — вот здесь представлено описание решения этой задачи (на английском).



Минимизация времени ожидания при отказе



После проведения шардинга, была обнаружена еще одна проблема. Конфигурация mysqlfailover использовала вторичный IP-адрес Amazon VPC в качестве виртуального IP, чтобы отправлять трафик приложения к узлу мастера. Но обнаружение сбоя в узле и переключение трафика через этот виртуальный айпи занимало порядка 10 минут. Все запросы в течение этого промежутка, разумеется, отклонялись.



Следовательно, нужно было реализовать гладкое аварийное переключение. Что-то наподобие того, как HAProxy может удерживать запросы при перезапуске сервиса приложения, только в приложении к MySQL.



Здесь можно использовать HAProxy в сочетании с хранилищем значений ключей, а можно использовать кластерные инструменты MySQL: Orchestrator или Galera. В данном случае компания выбирала самое простое решение из доступных. В идеале – чтобы не было дополнительных сервисов, которые надо обслуживать.



ProxySQL



Такое решение было найдено в ProxySQL – новом инструменте с открытой лицензией. Если не вдаваться в подробности, его можно рассматривать как HAProxy, только заточенный под запросы SQL. После того, как Nylas перешла на работу с ProxySQL, время ожидания при переключении узлов снизилось с 10 минут до 10 секунд.



image



Переключение без ProxySQL (простой 10 минут)



image



Переключение с ProxySQL (простой 10 секунд)



В процессе обнаружились другие преимущества работы с ProxySQL:




  • динамическая маршрутизация;

  • автоматические ограничения для запросов или транзакций, предотвращающие случайные спады производительности;

  • статистика запросов: позволяет сравнивать запросы по узлам приложения, то есть понять, как загрузка распределена по шардам;

  • возможность резко снижать количество экспортных соединений к актуальной базе данных машины.



Инженеры Nylas используют ProxySQL локально для каждого сервиса, подключающегося к базе, включая внутренние инструменты управления и скрипты. Использование прокси в локальном режиме вместо централизованного позволяет добиться встроенной избыточности, а также сводит к минимуму вероятность возникновения задережек трафика на прокси. В итоге шарды в системе могут динамически меремещаться между экземплярами базы данных — время простоя кластера при этом не превышает 12 секунд.



Перевод данных на другую платформу



В марте 2016 года компания осуществила миграцию шард 0 (RDS) на “in-house” MySQL на EC2 посредством функции репликации. Это позволило обновить первичные ключи для самой крупной таблицы с 32 до 64 бит, чего нельзя было представить с RDS. Первичное пространство ключей (4 млрд рядов) было выбрано полностью за пару месяцев.



Планы



Облачная инфраструктура Nylas продолжает динамично развиваться. После обновления уровня базы данных пришло время обновления уровня самого приложения. Текущий проект включает разделение логики синхронизации по нескольким микросервисам и обновление топологии процессов с магистральным источником данных, типа Kafka. Есть также вариант реализовать денормализацию схем для уровня хранилища API, чтобы сделать дальнейшую работу с приложением более гибкой.



Другие технические статьи от «Латеры»:





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282798/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
itast

Базы данных

Воскресенье, 24 Апреля 2016 г. 18:34 (ссылка)

Любой бизнес основан на покупателях. Если вы хотите расширить базу своих покупателей и привлечь новых клиентов, тем самым увеличить число продаж - вам поможет компания http://baserus.ru/. Здесь вы сможете приобрести базы данных целевой аудитории или найти новых потребителей своих услуг. Отправьте коммерческое предложение своим потенциальным клиентам. С помощью новых баз данных вы сможете провести маркетинговое исследование и найти своих покупателей.

Метки:   Комментарии (1)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Масштабируя до 100 миллионов: архитектура, определяемая уровнем сервиса

Среда, 20 Апреля 2016 г. 15:44 (ссылка)

Это третья часть цикла «Масштабирование Wix до 100 миллионов пользователей». Вступление и второй пост.



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



Развертывание новой версии нашей системы в некоторых случаях требовало изменения схемы MySQL. Поскольку Hibernate не прощает несовпадений между ожидаемой им схемой и реальной схемой базы данных (БД), мы использовали общую практику развертывания программного обеспечения: плановая двухчасовая остановка в период наименьшего трафика (полночь в США на выходных). За время этой плановой остановки мы должны были остановить сервис, выключить сервер, внести изменения в схему MySQL, развернуть новую версию и перезапустить сервер.



Эта плановая двухчасовая остановка часто превращалась в нечто более сложное из-за проблем, которые могли случаться при развертывании. В некоторых случаях внесение изменений в схему MySQL занимало заметно больше времени, чем планировалось (изменение больших таблиц, перестройка индексов, отмена ограничений на миграцию данных и т.д.). Иногда после изменения схемы и попытки перезапустить сервер он не запускался из-за каких-то непредусмотренных проблем с развертыванием, конфигурацией или схемой, которые не давали ему работать. А в некоторых случаях новая версия нашего программного обеспечения оказывалась неработоспособной, поэтому для восстановления сервиса нам приходилось снова менять схему MySQL (чтобы привести ее в соответствие с предыдущей версией) и вновь разворачивать предыдущую версию системы.



Но самое худшее случалось, если через несколько дней после «успешного» развертывания мы обнаруживали в новой версии критический, хоть и редкий, баг, приводивший к повреждению пользовательских сайтов. В этом случае самым лучшим было откатиться к предыдущей версии (по крайней мере до момента исправления бага), а для этого требовалось снова менять схему, что означало внеплановую остановку сервиса.

Важно отметить, что, поскольку мы использовали одно серверное приложение для обслуживания всех систем Wix, остановка затрагивала весь сервис, включая опубликованные сайты. Поскольку наша пользовательская база росла, все больше и больше сайтов оказывались затронутыми нашими плановыми и внеплановыми остановками.



А потом нас осенило



Wix выполняет две разные функции: обслуживание действующих сайтов и создание новых сайтов. Остановка создания сайтов оказывает прямое воздействие на наши ежедневные продажи, но остановка действующих сайтов оказывает прямое воздействие на наших существующих и платящих пользователей. Нам нужно было определить и создать разные уровни сервиса для каждой из функций.

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



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



Технологический стек, выбранный для выстраивания публичного сегмента, был намеренно простым. Мы больше не использовали Hibernate, мы отказались от любых форм кэша, и мы начали использовать Spring MVC 3.0. Важным принципом проектирования было сделать сегменты не связанными друг с другом в терминах программного обеспечения, цикла релизов и хранения данных, а также сделать программный стек простым для понимания и оптимизированным для обслуживания сайтов.



Явным признаком такой несвязанности был процесс публикации (потомки которого по-прежнему присутствуют в ядре Wix), который копировал данные из БД редакторского сегмента в БД публичного сегмента. В ходе этого процесса структуры данных трансформировались от представления, эффективного для редактирования, в представление, которое наилучшим образом подходит для опубликованного сайта.







В результате развертывания публичного сегмента стали редкими и низкорискованными. Он по-прежнему функционирует в системе Wix, спустя шесть лет после первого развертывания (хотя кое-что изменилось с тех пор).



Чему мы научились



Мы уже понимали, что цикл релиза связан с риском, но теперь осознали, что две наши ключевые бизнес-функции – строительство и обслуживание сайтов – по-разному подвержены риску. Мы поняли, что нам нужно обеспечить разные уровни сервиса для этих функций и что именно вокруг них мы должны выстраивать нашу систему. Что это за разные уровни сервиса? Мы рассматривали следующие аспекты: доступность, производительность, рискованность изменений и время восстановления после сбоя. Публичный сегмент, который затрагивает всех пользователей и все сайты Wix, должен иметь наивысший уровень сервиса по этим аспектам. Но в редакторском сегменте сбой затрагивает только пользователей, непосредственно занятых созданием сайта, поэтому последствия для бизнеса менее значительные. Поэтому мы несколько поступились высоким уровнем сервиса ради большей гибкости, что позволило снизить усилия, необходимые для разработки.



Главный архитектор программного обеспечения конструктора сайтов Wix,

Йоав Абрахами

Оригинал статьи: блог инженеров компании Wix



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282045/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Зачем нужна денормализация баз данных, и когда ее использовать

Суббота, 09 Апреля 2016 г. 10:22 (ссылка)





В нашем блоге на Хабре мы не только рассказываем о развитии своего продукта — биллинга для операторов связи «Гидра», но и публикуем материалы о работе с инфраструктурой и использовании технологий.



Недавно мы писали об использовании Clojure и MongoDB, а сегодня речь пойдет о плюсах и минусах денормализации баз данных. Разработчик баз данных и финансовый аналитик Эмил Дркушич (Emil Drkusi'c) написал в блоге компании Vertabelo материал о том, зачем, как и когда использовать этот подход. Мы представляем вашему вниманию главные тезисы этой заметки.



Что такое денормализация?



Обычно под этим термином понимают стратегию, применимую к уже нормализованной базе данных с целью повышения ее производительности. Смысл этого действия — поместить избыточные данные туда, где они смогут принести максимальную пользу. Для этого можно использовать дополнительные поля в уже существующих таблицах, добавлять новые таблицы или даже создавать новые экземпляры существующих таблиц. Логика в том, чтобы снизить время исполнения определенных запросов через упрощение доступа к данным или через создание таблиц с результатами отчетов, построенных на основании исходных данных.



Непременное условие процесса денормализации — наличие нормализованной базы. Важно понимать различие между ситуацией, когда база данных вообще не была нормализована, и нормализованной базой, прошедшей затем денормализацию. Во втором случае — все хорошо, а вот первый говорит об ошибках в проектировании или недостатке знаний у специалистов, которые этим занимались.



Рассмотрим нормализованную модель для простейшей CRM-системы:







Пробежимся по имеющимся здесь таблицам:




  • Таблица user_account хранит данные о пользователях, зарегистрированных в приложении (для упрощения модели роли и права пользователей из нее исключены).

  • Таблица client содержит некие базовые сведения о клиентах.

  • Таблица product — это список предлагаемых товаров.

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

  • Таблицы call и meeting хранят данные о заказах и встречах с клиентами и связывают их с текущими задачами.

  • Словари task_outcome, meeting_outcome и call_outcome содержат все возможные варианты результата звонков, встреч и задания.

  • product_offered хранит список продуктов, которые были предложены клиентам;

  • product_sold — продукты, которые удалось продать.

  • Таблица supply_order хранит информацию обо всех размещенных заказах.

  • Таблица writeoff содержит перечень списанных по каким-либо причинам товаров.



В этом примере база данных сильно упрощена для наглядности. Но нетрудно увидеть, что она отлично нормализована — в ней нет никакой избыточности, и все должно работать, как часы. Никаких проблем с производительностью не возникает до того момента, пока база не столкнется с большим объёмом данных.



Когда полезно использовать денормализацию



Прежде чем браться разнормализовывать то, что уже однажды было нормализовано, естественно, нужно четко понимать, зачем это нужно? Следует убедиться, что выгода от применения метода перевешивает возможные негативные последствия. Вот несколько ситуаций, в которых определенно стоит задуматься о денормализации.




  1. Сохранение исторических данных. Данные меняются с течением времени, но может быть нужно сохранять значения, которые были введены в момент создания записи. Например, могут измениться имя и фамилия клиента или другие данные о его месте жительства и роде занятий. Задача должна содержать значения полей, которые были актуальны на момент создания задачи. Если этого не обеспечить, то восстановить прошлые данные корректно не удастся. Решить проблему можно, добавив таблицу с историей изменений. В таком случае SELECT-запрос, который будет возвращать задачу и актуальное имя клиента будет более сложным. Возможно, дополнительная таблица — не лучший выход из положения.

  2. Повышение производительности запросов. Некоторые запросы могут использовать множество таблиц для доступа к часто запрашиваемым данным. Пример — ситуация, когда необходимо объединить до 10 таблиц для получения имени клиента и наименования товаров, которые были ему проданы. Некоторые из них, в свою очередь, могут содержать большие объемы данных. При таком раскладе разумным будет добавить напрямую поле client_id в таблицу products_sold.

  3. Ускорение создания отчетов. Бизнесу часто требуется выгружать определенную статистику. Создание отчетов по «живым» данным может требовать большого количества времени, да и производительность всей системы может в таком случае упасть. Например, требуется отслеживать клиентские продажи за определенный промежуток по заданной группе или по всем пользователям разом. Решающий эту задачу запрос в «боевой» базе перелопатит ее полностью, прежде чем подобный отчет будет сформирован. Нетрудно представить, насколько медленнее все будет работать, если такие отчеты будут нужны ежедневно.

  4. Предварительные вычисления часто запрашиваемых значений. Всегда есть потребность держать наиболее часто запрашиваемые значения наготове для регулярных расчетов, а не создавать их заново, генерируя их каждый раз в реальном времени.



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



Не все так гладко



Очевидная цель денормализации — повышение производительности. Но всему есть своя цена. В данном случае она складывается из следующих пунктов:




  • Место на диске. Ожидаемо, поскольку данные дублируются.

  • Аномалии данных. Необходимо понимать, что с определенного момента данные могут быть изменены в нескольких местах одновременно. Соответственно, нужно корректно менять и их копии. Это же относится к отчетам и предварительно вычисляемым значениям. Решить проблему можно с помощью триггеров, транзакций и хранимых процедур для совмещения операций.

  • Документация. Каждое применение денормализации следует подробно документировать. Если в будущем структура базы поменяется, то в ходе этого процесса нужно будет учесть все прошлые изменения — возможно, от них вообще можно будет к тому моменту отказаться за ненадобностью. (Пример: в клиентскую таблицу добавлен новый атрибут, что приводит к необходимости сохранения прошлых значений. Чтобы решить эту задачу, придется поменять настройки денормализации).

  • Замедление других операций. Вполне возможно, что применение денормализации замедлит процессы вставки, модификации и удаления данных. Если подобные действия проводятся относительно редко, то это может быть оправдано. В этом случае мы разбиваем один медленный SELECT-запрос на серию более мелких запросов по вводу, обновлению и удалению данных. Если сложный запрос может серьезно замедлить всю систему, то замедление множества небольших операций не отразится на качестве работы приложения столь драматических образом.

  • Больше кода. Пункты 2 и 3 потребуют добавления кода. В то же время они могут существенно упростить некоторые запросы. Если денормализации подвергается существующая база данных, то потребуется модифицировать эти запросы, чтобы оптимизировать работу всей системы. Также понадобится обновить существующие записи, заполнив значения добавленных атрибутов — это тоже потребует написания некоторого количества кода.



Денормализация на примере



В представленной модели были применены некоторые из вышеупомянутых правил денормализации. Синим отмечены новые блоки, розовым — те, что были изменены.







Что изменилось и почему?







Единственное нововведение в таблице product — строка units_in_stock. В нормализованной модели мы можем вычислить это значение следующим образом: заказанное наименование — проданное — (предложенное) — списанное (units ordered — units sold — (units offered) — units written off). Вычисление повторяется каждый раз, когда клиент запрашивает товар. Это довольно затратный по времени процесс. Вместо этого можно вычислять значение заранее так, чтобы к моменту поступления запроса от покупателя, все уже было наготове. С другой стороны, атрибут units_in_stock должен оновляться после каждой операции ввода, обновления или удаления в таблицах products_on_order, writeoff, product_offered и product_sold.







В таблицу task добавлено два новых атрибута: client_name и user_first_last_name. Оба они хранят значения на момент создания задачи — это нужно, потому что каждое из них может поменяться с течением времени. Также нужно сохранить внешний ключ, который связывает их с исходным пользовательским и клиентским ID. Есть и другие значения, которые нужно хранить — например, адрес клиента или информация о включенных в стоимость налогах вроде НДС.







Денормализованная таблица product_offered получила два новых атрибута: price_per_unit и price. Первый из них необходим для хранения актуальной цены на момент предложения товара. Нормализованная модель будет показывать лишь ее текущее состояние. Поэтому, как только цена изменится, изменится и «ценовая история». Нововведение не просто ускорит работу базы, оно улучшает функциональность. Строка price вычисляет значение units_sold * price_per_unit. Таким образом, не нужно делать расчет каждый раз, как понадобится взглянуть на список предложенных товаров. Это небольшая цена за увеличение производительности.



Изменения в таблице product_sold сделаны по тем же соображениям. С той лишь разницей, что в данном случае речь идет о проданных наименованиях товара.







Таблица statistics_per_year (статистика за год) в тестовой модели — абсолютно новый элемент. По сути, это денормализованная таблица, поскольку все ее данные могут быть рассчитаны из других таблиц. Здесь хранится информация о текущих задачах, успешно выполненных задачах, встречах, звонках по каждому заданному клиенту. В данном месте также хранится общая сумма проведенных начислений за каждый год. После ввода, обновления или удаления любых данных в таблицах task, meeting, call и product_sold приходится пересчитывать эти данные для каждого клиента и соответствующего года. Так как изменения, скорее всего, касаются лишь текущего года, отчеты за предыдущие годы теперь могут оставаться без изменений. Значения в этой таблице вычисляются заранее, поэтому мы сэкономим время и ресурсы, когда нам понадобятся результаты расчетов.



Денормализация — мощный подход. Не то чтобы к ней следует прибегать каждый раз, когда стоит задача увеличения производительности. Но в отдельных случаях это может быть лучшим или даже единственным решением.



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



Наш опыт



Мы в Латере много занимаемся оптимизацией производительности нашей биллинговой системы «Гидра», что неудивительно, учитывая объемы наших клиентов и специфику телеком-отрасли.



Один из примеров в статье предполагает создание таблицы с промежуточными итогами для ускорения отчетов. Конечно, самое сложное в этом подходе — поддерживать актуальное состояние такой таблицы. Иногда можно переложить эту задачу на СУБД — например, использовать материализованные представления. Но, когда бизнес-логика для получения промежуточных результатов оказывается чуть более сложной, актуальность денормализованных данных приходится обеспечивать вручную.



«Гидра» имеет глубоко проработанную систему привилегий для пользователей, операторов биллинга. Права выдаются несколькими способами — можно разрешить определенные действия конкретному пользователю, можно заранее подготовить роли и выдать им разные наборы прав, можно наделить определенный отдел специальными привилегиями. Только представьте, насколько медленными стали бы обращения к любым сущностям системы, если бы каждый раз нужно было пройти всю эту цепочку, чтобы убедиться: «да, этому сотруднику разрешено заключать договоры с юридическими лицами» или «нет, у этого оператора недостаточно привилегий для работы с абонентами соседнего филиала». Вместо этого мы отдельно храним готовый агрегированный список действующих прав для пользователей и обновляем его, когда в систему вносятся изменения, способные на этот список повлиять. Сотрудники переходят из одного отдела в другой намного реже, чем открывают очередного абонента в интерфейсе биллинга, а значит вычислять полный набор их прав нам приходится настолько же реже.



Конечно, денормализация хранилища — это только одна из принимаемых мер. Часть данных стоит кэшировать и непосредственно в приложении, но если промежуточные результаты в среднем живут намного дольше, чем пользовательские сессии, есть смысл всерьез задуматься о денормализации для ускорения чтения.



Другие технические статьи в нашем блоге:







Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/281262/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Облачный мир Oracle Database 12c

Четверг, 07 Апреля 2016 г. 19:17 (ссылка)

Целью технологического форума Oracle Database 12c, который прошел в Москве 22 марта 2016 г., было освещение главных новинок в области хранения корпоративных данных и управления ими. Нас особенно заинтересовала первая секция форума, посвященная облачным вычислениям.









Гибридное облако уже здесь



Доклад, посвященный лучшим практикам управления гибридным облаком, Прабакер Гонглур, старший директор по развитию направления Oracle Database 12c в корпорации Oracle, начал с важной мысли: гибридное облако — уже реальность. Что это такое? Это объединение частного и публичного облаков, в котором реализовано перекрестное контролируемое использование данных и приложений между ними. Гибридное облако очень удобно для разработки и тестирования, интеграции B2B-решений, внедрения требовательных к ИТ-ресурсам продуктов, пробной эксплуатации новых сервисов.



Единого для всех сценария перехода в гибридное облако, разумеется, не существует. Одни компании ищут возможности оптимизировать расходы на физическую ИТ-инфраструктуру и виртуализуют локальные ресурсы, переводя их в частное облако. Другие планомерно переводят ресурсы в частное облако для того, чтобы постепенно, отрабатывая рабочие процессы на уровне виртуализации, переводить их в публичное облако. Некоторые компании просто переводят в публичное облако отдельные проекты. Для всех подобных случаев характерен также переход от капиталовложений к операционным затратам, который в силу экономических причин сейчас во многом является требованием времени.



Легко выделить типичные примеры использования гибридного облака на предприятиях. Организации, которые занимаются разработкой и тестированием приложений в промышленных масштабах — неважно, для собственных потребностей или в качестве основной деятельности — переводят инфраструктуру разработки и тестирования в публичное облако, чем добиваются существенного ускорения развертывания этих систем и оптимизации управления ими, при этом бизнес-критичные приложения они продолжают использовать локально. Для ряда организаций — например, зависимых от сезонных колебаний на рынке — периодический перенос нагрузки в публичное облако является условием существования бизнеса, поэтому им важно обеспечивать динамическое распределение нагрузки на ИТ-ресурсы и быстрый переход в публичное облако по требованию. Еще одним популярным паттерном является, например, выполнение резервного копирования и бизнес-аналитических приложений в публичном облаке, в то время как транзакционная обработка выполняется локально.



Разумеется, размещение ИТ-ресурсов в гибридном облаке имеет смысл только в том случае, если компания может полноценно владеть этими ресурсами и управлять ими. Облако является облаком, когда автоматизированы предоставление услуг, их администрирование и оплата. Компании с большой, сложной ИТ-инфраструктурой это понимают особенно хорошо, потому что управлять такими инфраструктурами без автоматизации невозможно. Поставщик соответствующих платформ и технологий обязан обеспечить унификацию процедур управления частным и публичным облаком; стабильное качество сервиса в частном и публичном облаке, а также его соответствие регламентам; прозрачность управления публичным и частным облаком и потоков действий (user flows) между ними.



Но и в этом случае использование гибридного облака не самоцель. Для того чтобы эта технология привлекала предприятия, она должна обеспечивать оптимизацию ресурсов — т. е. использование ресурсов в частном и публичном облаке должно быть самым экономным способом их размещения, при этом обязательны механизмы точного расчета требований для инфраструктуры частного облака и платформенных сервисов публичного облака. Отдельным вызовом становится возможность динамического распределения нагрузки между частным и публичным облаком.







Компания Oracle реализует и предоставляет на выбор своим клиентам все облачные модели. И именно Enterprise Manager, начиная с версии 12cR5, является единым инструментом управления для локальных и облачных ресурсов, он обеспечивает предприятиям не только единый взгляд на локальные и облачные ресурсы, но и возможность переноса нагрузки в облако Oracle Cloud и обратно (Рис. 1).



Особенно впечатляет то, что для обеспечения качества сервиса и для частных, и для публичных облаков Oracle использует одну и ту же методологию «Find–Fix–Validate», т. е. «найти–исправить–проверить», точную и автоматическую (Рис. 2).







На каждом из трех шагов методологии в обоих случаях используется одно и то же базовое ПО:


  1. Find («найти»): встроенный модуль самодиагностики — Automatic Database Diagnostics Monitor (ADDM): Oracle Diagnostics Pack;

  2. Fix («исправить»): автоматическая настройка приложения — Oracle Tuning Pack;

  3. Validate («проверить»): плановая настройка приложения — Oracle Real Application Testing SPA.



Новый тип отчета, который называется Performance Hub, графически отображает отчет о производительности базы данных, формируемый на основе данных диагностического репозитория Automatic Workload Repository (AWR-отчет) в удобном и наглядном графическом виде (Рис. 3).







Новая возможность SQL Performance Analyzer, которая называется SPA Quick Check, позволяет быстро оценить влияние плановых системных изменений на SQL-нагрузку на рабочей системе. Она разработана для использования на рабочих системах, не оказывает влияния на работу конечных пользователей и создает минимальную дополнительную нагрузку.



Обеспечение качества сервиса для частных и публичных облаков достигается новыми возможностями Oracle Enterprise Manager 13c. Отдельно упомянем инструментарий Oracle Real Application Testing, который кроме тестирования инфраструктурных изменения базы данных теперь ещё предлагает интегрированный набор средств для комплексного сквозного управления консолидацией баз данных Database Consolidation Workbench.



Перевод нагрузки из частного облака в публичное должен выполняться без потери качества сервиса, а инструментарий управления, предоставляемый поставщиком, должен гарантировать точное планирование мощностей и возможность внесения изменений при переходе в облако. Oracle Enterprise Manager автоматизирует перемещение баз данных в облака следующими способами:


  • клонирование подключаемых баз данных в Oracle Cloud для Oracle Database 12c;

  • клонирование или миграция подключаемых баз данных из Oracle Cloud в локальные контейнерные базы данных;

  • клонирование для сценариев разработки и тестирования — с использованием маскирования данных.



Миграция базы данных в частное и публичное облака обычно включает в себя существенные инфраструктурные изменения — аппаратной части, системы хранения, сети, версии базы данных и т. д. Средство Oracle Real Application Testing помогает проверить изменения, используя реальную нагрузку, и спланировать ресурсы, чтобы уменьшить SLA-риски и не допустить снижения качества сервиса.



Новые возможности Oracle Enterprise Manager 13c



Более подробно представляя Oracle Enterprise Manager 13c, Сергей Томин, ведущий консультант департамента технологического консалтинга Oracle СНГ, рассказал о том, что изначально тремя основными целями при разработке предыдущей версии Enterprise Manager 12c были: во-первых, дать заказчикам полноценное решение для управления и мониторинга корпоративного уровня (т. е. решение, которое позволяет управлять сотнями и тысячами объектов), во-вторых, сделать возможным интегрированное управление всем стеком приложений и глубокую диагностику от уровня приложения до уровня базы данных и дисков с прозрачным переходом между уровнями, в-третьих, самое главное, создать коммерческое решение для управления частными облаками, всем жизненным циклом облака — планированием, развертыванием, тестированием, учетом потребления ресурсов и биллингом.



Благодаря успешной реализации этих функций Oracle Enterprise Manager 12c получил заслуженное признание пользователей. Крупнейшая сеть розничных магазинов шаговой доступности 7-Eleven использует Enterprise Manager для быстрого развертывания инфраструктуры своих мобильных приложений. Крупнейшая сеть аптек Walgreens использует Enterprise Manager для контроля конфигураций, для контроля соблюдения регламентных требований и автоматизации применения патчей — теперь они тратят на эти операции вдвое меньше усилий. Банк Societe General использует новую возможность Enterprise Manager, тонкое клонирование, для создания тонких клонов тестовых баз данных и экономит при этом 90 % времени и дискового пространства. В Allied Irish Banks используется Replication Application Testing для тестирования инфраструктурных изменений базы данных, благодаря чему на 25 % сократились затраты усилий на тестирование.



Oracle Enterprise Manager используется и для управления самим публичным облаком Oracle. Например, на самом крупном сайте Cloud Public Oracle он управляет 2,5 млн единиц мониторинга, контролируя более 25 тыс. экземпляров сервисов, и каждый день обрабатывает 3,4 млн событий, выполняет 2 млн заданий, 11 млн тестовых транзакций.



Enterprise Manager 13c предоставляет единый интерфейс для управления как публичным, так и частным облаком. Enterprise Manager позволяет легко переносить нагрузки баз данных из ЦОДа в публичное облако Oracle и обратно.



Предоставляя доступ к ПО и инфраструктуре по требованию в режиме самообслуживания с возможностью масштабирования и учёта потребления ресурсов, Enterprise Manager обеспечивает следующие преимущества.




  • Повышение качества обслуживания. ИТ-организации стремятся не только сократить затраты, но и найти решения, позволяющие повысить производительность, доступность и безопасность. Облачные клиенты получают естественные преимущества от средств высокой доступности, встроенных в облако.

  • Гибкость использования ресурсов. Возможность увеличивать и уменьшать вычислительную мощность базы данных делает приложения гибкими и легко адаптируемыми к меняющимся рабочим нагрузкам.

  • Ускоренное предоставление баз данных. Базы данных в облаке могут предоставляться очень быстро. Это сокращает общее время развертывания производственных приложений и платформ для разработки и ускоряет создание тестовых конфигураций.

  • Возможность количественно измерять использование ресурсов базы данных в облаке для составления бюджета, планирования и распределения административных ресурсов в зависимости от использования ресурсов.



Oracle Enterprise Manager 13c предлагает единое окно управления аппаратным и программным обеспечением (впервые в индустрии), единое представление для частных и публичных облаков и простую диагностику с возможностью перехода на разные уровни стека приложения.



Кроме того, решение автоматизирует патчирование всех компонентов программно-аппаратного комплексов Oracle Engineered Systems, а инструментарий управления комплаенсом поддерживает STIG стандарт и предлагает единое окно управления комплаенсом для локальных и облачных компонентов, которое позволяет настраивать и проверять правила комплаенса в режиме реального времени.



В числе новых возможностей Oracle Enterprise Manager 13c управление дрейфом конфигураций, т. е. отслеживание изменения динамичных конфигураций любого масштаба — при этом источник для сравнения может быть как «живым» объектом, так и сохраненной базисной конфигурацией.



Непрерывный (“always on”) мониторинг позволяет получать по e-mail уведомления о критически важных событиях даже во время плановых простоях управляющего сервера Enterprise Manager.



Большое количество агентов Enterprise Manager стало проще разворачивать и обновлять с помощью “золотых образов”.



Крайне важна для корпоративных заказчиков возможность управления промежуточным программным обеспечением. Oracle Enterprise Manager поддерживает мультиарендность WebLogic 12.2, имеет встроенные возможности WebLogic Admin Console (Change Center, запись WLST скриптов, управление JDBC Data Source, конфигурирование домена, кластера, сервера, возможности аудита) и улучшенную функциональность диагностики — Java Workload Explorer для глубокой диагностики JVM и Middleware Diagnostics Advisor для обнаружения известных проблем, включая утечки памяти, зависшие потоки, JDBC/JMS проблемы и т. д.



Заказчики Oracle высоко оценивают возможности нового решения. Так, Наото Касиваги (Naoto Kashiwagi), руководитель команды промежуточного ПО и облачных технологий NEC Japan, и Йоки Морияма (Yoki Moriyama), заместитель генерального директора компании, говорят: «Enterprise Manager является мощным средством для управления нашими большими системами, которые обслуживают большие сделки. Мы используем Enterprise Manager для управления сотнями объектов настолько важных, что мы не можем позволить себе пропустить ни одного предупреждения, и мы должны эффективно обслуживать эти системы без ошибок».



Новые облачные сервисы Oracle для управления ИТ





Борис Пищик, ведущий консультант департамента технологического консалтинга Oracle СНГ, рассказал об облачной платформе Oracle для ИТ-мониторинга — Oracle Management Cloud.



Решение Oracle Management Cloud предназначено для служб эксплуатации ИТ и разработки, оно основано на идее периодического, в реальном масштабе времени, сбора различной диагностической информации в реальном масштабе времени, передачи ее в публичное облако Oracle, консолидации, хранения и предоставления к ней удобного пользовательского веб-интерфейса. Ключевые возможности решения:


  • Мониторинг на уровне конечных пользователей веб-приложений и компонентов инфраструктуры как локальных так облачных.

  • Поддержка планирования мощностей и ресурсов.

  • Широкий охват для анализа метрик и событий.

  • Сбор журналов, поиск, агрегирование, понимание топологии.

  • Автоматизированное выявление аномалий.

  • Удобный пользовательский интерфейс, панели управления.



Три главных сервиса Oracle Management Cloud — Application Performance Monitoring, Logs Analytics и IT Analytics — уже сейчас доступны в публичном облаке Oracle.



Application Performance Monitoring обеспечивает диагностику на различных уровнях: от уровня конечного пользователя до журналов инфраструктуры. Сервис ведет постоянный мониторинг приложений для выявления проблем, своевременно предупреждает о проблемах, которые могут повлиять на работу пользователей, и предлагает удобные средства поиска первопричин возникновения проблем. Функциональность предлагает единый интерфейс для эксплуатации ИТ и разработчиков и обеспечивает проактивный мониторинг опыта конечных пользователей, который достигается постоянным контролем производительности веб-страниц и AJAX, регулярными замерами производительности запросов и возможностью сопоставления проблем пользователей с «узкими местами» в производительности инфраструктуры.



Log Analytics — это новый облачный сервис, предназначенный для консолидации журнальных файлов из разных источников. Log Analytics обеспечивает мониторинг, агрегирование, индексирование, анализ, поиск и корреляцию всех журнальных данных от приложений и компонентов инфраструктуры (локальной и облачной) в реальном масштабе времени. Для анализа журналов применяются машинные алгоритмы, позволяющие распознавать и группировать записи, основанные на общих шаблонах, и быстро находить первопричины проблем.

Инструментарий IT Analytics позволяет определять закономерности функционирования текущего ИТ-ландшафта, выявлять проблемные участки и эффективно планировать мощности. Его главные задачи: анализ ресурсов (выявление неравномерной нагрузки, анализ потребления ресурсов в разных разрезах и по различным периодам) и планирование их роста, анализ производительности с использованием встроенных средств аналитики для выявления «узких мест», ресурсоемких SQL-запросов и т. п., визуализация картины производительности по типам ресурсов и по ключевым индикаторам.



Результатом внедрения Oracle Management Cloud становится повышение качества сопровождения и эксплуатации. Также, заказчик не должен делать капиталовложения в поддержку и администрирование данных сервисов, с появлением Oracle Management Cloud это больше не его ответственность.



Гибридное облако Oracle в деталях





Доклад Дмитрия Ермошина, ведущего консультанта департамента технологического консалтинга Oracle СНГ, был посвящен тому, как применение частных и гибридных облаков Oracle позволяет решать такие важные задачи ИТ-служб, как:


  1. Быстрое развертывание новых баз данных.

  2. Клонирование больших баз данных.

  3. Снижение рутинной нагрузки, автоматизация и ускорение работы облачных баз данных.

  4. Стандартизация.

  5. Консолидация.

  6. Детальный учет использования вычислительных ресурсов.

  7. Более эффективное использование вычислительных ресурсов (включая диски).

  8. Повышение надежности работы существующих баз данных.

  9. Построение гибкой, легко наращиваемой ИТ-инфраструктуры.



Компания Oracle вкладывает большие ресурсы в развитие облачной автоматизации. Если мы посмотрим на диаграмму облачных решений, предлагаемых главными мировыми поставщиками (Рис. 4), окажется, что только Oracle предоставляет полный стек облачных решений, включая HWaaS — оборудование как сервис.







Подход Oracle основан на понятии гибридного облака — объединении частного и публичного облаков, в котором реализовано перекрестное контролируемое использование данных и приложений между ними. Гибридное облако очень удобно для разработки и тестирования, интеграции B2B-решений, внедрения требовательных к ИТ-ресурсам продуктов, пробной эксплуатации новых продуктов.







Компания Oracle реализует и предоставляет на выбор своим клиентам все облачные модели — публичное, частное и гибридное облако (Рис. 5). С одной стороны, предлагаются продукты, на базе которых можно развернуть Oracle-системы в ЦОДе, превратив их в частное облако. С другой стороны, во всем мире есть центры обработки данных Oracle, которые предоставляют услуги публичного облака. Продукт Oracle Enterprise Manager позволяет связать оба подхода, связать одно облако с другим и управлять ими при помощи единого интерфейса.



Наиболее популярными сейчас и в мире, и в России облачными сервисами Oracle являются платформенные сервисы — база данных как сервис и сервер приложений как сервис.



Два главных способа предоставления услуги «база данных как сервис», т. е. Oracle PaaS (DBaaS), таковы: клиенты работают либо с виртуальными машинами Oracle VM, либо с серверами Exadata. Если клиенты работают традиционными виртуальными машинами, для них существует несколько преднастроенных размеров виртуальных машин, которые характеризуются определенным количеством процессоров и объемом памяти. Решение на основе серверов Exadata предназначено для клиентов с очень большими требованиями к объему и производительности баз данных. Кроме того, оно дает возможность использования ячеек Exadata для высоких нагрузок.



База данных по требованию заказывается с портала самообслуживания в необходимой версии, конфигурации и с требуемой степенью консолидации (Рис. 6). Для создания облака Oracle требуется только Enterprise Manager. Нового оборудования, новых настроек, нового подхода к системе управления доступом или к рабочим станциям не требуется. Enterprise Manager настраивается на пулы баз данных DBaaS, пулы WebLogic или пулы виртуализации. Затем частное облако Oracle можно использовать для подключения к внешним системам.







Быстрое развертывание новых баз данных возможно благодаря удобному порталу самообслуживания и каталогу шаблонов, который хранит набор процедур развертывания в виде шаблонов сервисов и предлагает разные варианты шаблонов, для разных версий СУБД, конфигураций и т. д. Процедура Database Provisioning позволяет захватывать конфигурации баз данных и сохранять процедуры развертывания для последующего использования.



Новая процедура клонирования баз данных Snap Clone использует передовые возможности систем хранения и может быть реализована как аппаратными, так и програмными средствами. И если на традиционное клонирование базы данных уходит в среднем полторы недели, то решение, выполняющее автоматизированное клонирование, позволяет получать базы данных объемом в несколько терабайт в течение часа.



Для управления гибридным облаком Enterprise Manager версий 12c R5 и 13c содержит Hybrid Agent, который нужно установить в облачный сервис. После установки Hybrid Agent начнет взаимодействовать с Enterprise Manager, передавая информацию об облачной системе.



Процитированные доклады далеко не исчерпывают всю тематику очередного технологического форума Oracle Database 12c. Мы хотим закончить этот обзор напоминанием, которое сделал в своем докладе Прабакер Гонглур — о том, что многие ИТ-департаменты уже сейчас строят комбинированную инфраструктуру, используя как частные, так и публичные облака, и уже сейчас понимают, что они обязаны управлять ресурсами — где бы те ни находились. Поэтому они пытаются строить собственные частные облака в соответствии с аналогичными архитектурными и эксплуатационными требованиями — или доверяют тем поставщикам облачных ресурсов, которые соответствуют требованиям масштабируемости, производительности, мониторинга, безопасности и регламентов. Положительный опыт компаний, ставших клиентами Oracle Cloud, говорит о том, что они правильно выбрали поставщика.





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/281198/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

За и против: Когда стоит и не стоит использовать MongoDB

Суббота, 26 Марта 2016 г. 10:37 (ссылка)





Разработчик и сотрудник проекта CouldBoost.io Наваз Дандала (Nawaz Dhandala) написал материал о том, почему в некоторых случаях не стоит использовать MongoDB. Мы в «Латере» развиваем биллинг для операторов связи «Гидра» и уже много лет работаем с этой СУБД, поэтому решили представить и свое мнение по данному вопросу.



Дандала сразу оговаривается, что работал со многими СУБД (как SQL, так и NoSQL) и считает MongoDB отличным инструментом, однако существуют сценарии, в которых его применение нецелесообразно.



Документоориентированные СУБД такие, как MongoDB, прекрасно справляются с хранением JSON-данных, сгруппированных в «коллекции». В таком формате можно хранить любые JSON-документы и удобно категоризировать и по коллекциям. Содержащийся в MongoDB JSON-документ называется двоичным JSON или BSON и, как любой другой документ этого формата, является неструктурированным. Поэтому, в отличии от традиционных СУБД, в коллекциях можно сохранять любые виды данных, и эта гибкость сочетается с горизонтальной масштабируемостью базы данных. Эта возможность нравится многим разработчикам, однако «не все так однозначно».



Если MongoDB такая классная, почему ее не используют все и всегда?



Выбор СУБД зависит в том числе и от того, что за приложение планируется создать. То есть базу данных выбирают не разработчики, а сам продукт, убежден Дандала. Он приводит пример, подтверждающий этот тезис.



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



Однако, необходимо отметить, что у MongoDB нет связей между документами и “коллекциями” (частично это компенсируется Database Reference — ссылками в СУБД, но это не полностью решает проблему). В итоге, возникает ситуация, при которой имеется некий набор данных, который никак не связан с другой информацией в базе, и не существует никакого способа объединить данные из различных документов. В SQL-системах это было бы элементарной задачей.



Здесь возникает другой вопрос — если в MongoDB нет связей и возможностей по объединению двух таблиц, то зачем ее тогда вообще использовать? Ответ — потому что эта СУБД отлично масштабируется, и по сравнению с традиционными SQL-системами, гораздо быстрее осуществляет чтение и запись.MongoDB прекрасно подходит для приложений, в которых практически не используются данные с зависимостями и необходима масштабируемость базы данных.



Многие разработчики применяют MongoDB и для хранения связанных данных, реализуя объединения вручную в коде — этого достаточно в сценариях «одноуровневого» объединения или малого количества связей. То есть данный метод далеко не универсален.



Так какую СУБД выбрать?



Существует огромное количество различных СУБД, и каждая из них соответствует определённому набору требований, которые разработчики предъявляют к своему приложению:




  • Документоориентированные СУБД (к примеру, MongoDB): Как уже сказано выше, документоориентированные СУБД используются для хранения JSON-документов в “коллекциях” и осуществления запросов по нужным полям. Можно использовать эту базу данных для создания приложений, в которых не будет содержаться слишком большого количества связей. Хорошим примером такого приложения является движок для блог-платформы или хранения каталога продуктов.

  • Графовые СУБД (например Neo4j): Графовая СУБД используется для хранения между субъектами, где узлы являются субъектами, а грани — связями. Например, если разработчики создают социальную сеть, и один пользователь подписывается на другого, то пользователи являются узлами, а их “подписка” — связью. Такие СУБД прекрасно справляются с образованием связей, даже если глубина таких связей более ста уровней. Этот инструмент столь эффективен, что может даже позволяет выявлять мошенничество в сфере электронной коммерции.

  • Кэш (например Redis): Такие СУБД используются, когда требуется крайне быстрый доступ к данным. Если создается приложение для интернет-торговли, в котором есть подгружаемые на каждой страницы категории, то вместо обращения к базе данных при каждом чтении, что крайне затратно, можно хранить данные в кэше. Он позволяет быстро осуществлять операции чтения/записи. Дандала советует применять СУБД, использующие кэш, в качестве оболочки для обработки часто запрашиваемых данных, избавляющей от необходимости совершения частых запросов к самой базе.

  • Поисковые СУБД (например ElasticSearch): В случае необходимости осуществления полнотекстового поиска по базе данных (например поиск продукции в ecommerce-приложении), то хорошей идее будет использование поисковой СУБД вроде ElasticSearch. Эта система способна искать по огромному массиву данных и обладает обширной функциональностью — например, СУБД умеет осуществлять поиск по именованным категориям.

  • Строковые СУБД (например Cassandra): СУБД Cassandra используется для хранения последовательных данных, логов, или огромного объема информации, который может генерироваться автоматически — к примеру, каким-нибудь датчиками. Если разработчики собираются использовать СУБД для записи больших массивов данных и при этом планируется, что будет намного меньше обращений для чтения и данные не будут иметь связи и объединения, тогда Cassandra будет хорошим выбором, уверен Дандала.



Использование комбинации баз данных







Существуют и ситуации, в которых может понадобиться использование сразу нескольких различных СУБД.



Например, если в приложении есть функция поиска, то его можно реализовать с помощью ElasticSearch, а уже для хранения данных без связей лучше подойдет MongoDB. Если речь иет о проекте в сфере «интернета вещей», где огромное количество всевозможных устройств и датчиков генерируют гигантские объёмы данных, вполне разумно будет использовать Cassandra.



Принцип, при котором используются несколько СУБД для работы в одном приложении, называется “Polyglot Persistence”. В этой статье можно почитать о плюсах и минусах такого подхода.



Наш опыт



Наша биллинговая система «Гидра» использует для учета первичных данных и хранения финансовой информации реляционную СУБД. Она идеально подходит для этих целей. Но некоторые модули Гидры, например, RADIUS-сервер, работают под высокой нагрузкой и могут получать тысячи запросов в секунду с жесткими ограничениями на время обработки запроса. Кроме того, в БД нашего автономного RADIUS-сервера данные хранятся в виде набора AVP (attribute/value pair). В таком сценарии реляционная СУБД уже не выглядит лучшим решением, и тут на помощь приходит MongoDB с ее хранилищем документов произвольной структуры, быстрой выдачей ответа и горизонтальной масштабируемостью.



При эксплуатации более чем на 100 инсталляциях Гидры на протяжении последних 5 лет серьезных проблем с Mongo мы не обнаружили. Но пара нюансов все же есть. Во-первых, после внезапного отключения сервера БД хоть и восстанавливается благодаря журналу, но происходит это медленно. К счастью, необходимость в этом возникает нечасто. Во-вторых, даже при небольшом размере БД редко используемые данные сбрасываются на диск и когда запрос к ним все же приходит, их извлечение занимает много времени. В результате нарушаются ограничения на время выполнения запроса.



Все это относится к движку MMAPv1, который применяется в Mongo по умолчанию. С другими (WiredTiger и InMemory) мы пока не экспериментировали — проблемы не настолько серьезны.



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/280196/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<базы данных - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda