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


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

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

Следующие 30  »
rss_rss_hh_new

Соревнование по программированию на открытых данных: Budget Sprint

Вторник, 09 Августа 2016 г. 19:40 (ссылка)





Команда «Инфокультуры» в эту субботу, 13 августа, тестирует новый формат хакатона — в стиле спортивного программирования. Ждём людей, которые уверенно программируют и ловят фан от решения задач на скорость. Если вы хорошо кодите на Phyton'e, давайте соревноваться.



У нас есть 20 задач, примеры которых можно посмотреть на GitHab'е, предлагаем их решить в течение дня (с 10.00 до 20.00), посмотрим, кто быстрее и лучше.



Возможно, кому-то будет лень идти по ссылке, поэтому часть задач выведем сюда:



1. Визуализация расходов на закрытие Олимпиады в Сочи с помощью движка TheOpenBudget (но не просто так, а за 1 час)

2. Дашборд о состоянии финансов России за 1,5 часа.

3. База данных налоговой муниципальной статистики (за 1,5 часа, а?)



У каждой команды (не более 3 человек) будет 10 часов времени и доступ к общему пулу задач. Каждая задача будет стоить N баллов. M баллов будет присуждаться за скорость.



— Сумма баллов поможет определить победителя, который унесёт с собой 30.000 рублей.

— Команда, занявшая второе место, получит 20.000 рублей.

— На третье место и призы по 10.000 рублей смогут претендовать две команды.



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



Количество мест ограничено. Соревнование будет в «Точке кипения» (АСИ), г. Москва, Малый Конюшковский переулок, 2.

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

https://habrahabr.ru/post/307466/

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

Как мы NoSQL в «реляционку» реплицировали

Среда, 03 Августа 2016 г. 09:20 (ссылка)

В наши дни NoSQL продолжает набирать популярность, но мало кто знает, что нереляционные СУБД появились гораздо раньше даже самой реляционной алгебры. 40 и даже 50 лет назад в первичном «бульоне» зарождающейся IT индустрии «варились» только NoSQL-продукты. И что самое интересное – продукты, рожденные в те сложные времена, живы до сих пор и прекрасно себя чувствуют.

Одним из таких продуктов стала СУБД GT.m, разработанная компанией Graystone Tehnologies в 70-80-х годах прошлого века. СУБД нашла широкое применение в медицине, страховании и банковской сфере.



В нашем банке мы тоже используем GT.m, и этот инструмент прекрасно справляется с обработкой большого количества транзакций. Но… Есть одна проблема: GT.m никакой для аналитики, в нем нет SQL, аналитических запросов и всего того, что делает финансового аналитика счастливым. Поэтому мы разработали собственный «велосипед» для репликации данных из GT.m в «реляционные» СУБД.





А вот здесь должна была быть картинка с летающим велосипедом



Всех заинтересованных приглашаем под кат.





Псс… Не хочешь еще немного GT.m? Уже в те доисторические времена GT.m имела (или имел) подержу ACID, сериализацию транзакций и наличие индексов и процедурного языка MUMPS. Кстати, MUMPS – это не просто язык, это целое направление, появившееся еще в 60-х годах 20 века!



Одной из самых успешных и популярных MUMPS-based СУБД стала Cach'e, и вы, скорее всего, слышали о ней.



Основой MUMPS СУБД являются иерархические структуры – глобалы. Представьте JSON, XML или структуру папок и файлов на вашем компьютере – примерно то же самое. И всем этим наши отцы и деды наслаждались до того, как это стало мейнстримом.

Один важный момент – в 2000 году СУБД стала Open Source.



Так вот, старушка GT.m надежна и, несмотря на свои преклонные года, обслуживает большое количество специфичных транзакций без каких-либо усилий в отличие, например, от своих SQL собратьев (фраза, конечно, холиварная, но для нас это факт: на определенной нагрузке NoSQL все же шустрее SQL). Однако все проблемы начинаются тогда, когда нам нужно сделать простейшую аналитику, передать данные в аналитические системы или, не дай бог, автоматизировать все это.



Долгое время решением данной проблемы были вездесущие «выгрузки». CSV файлы формировались процедурами, написанными на языке M (MUMPS), и каждая такая выгрузка разрабатывалась, тестировалась и внедрялась высококвалифицированными специалистами. Усилия, затрачиваемые на разработку каждой выгрузки, были огромными, а содержимое двух разных выгрузок могло существенно пересекаться между собой. Случалось такое, что заказчики требовали выгрузки, на несколько полей отличные от существующих, и приходилось делать все заново. При этом сам язык M код достаточно тяжелый для понимания и чтения, что влечет за собой дополнительные «расходы» как на разработку, так и на поддержку всего этого хардкода.







Решение с выгрузками



ODS (Operational Data Store)



У нас уже был реализованный архитектурный паттерн под названием ODS (Operational Data Store), в который мы реплицируем наши источники с минимальными отставаниями от 2 секунд до 15 минут.



Данные из ODS мы загружаем в хранилище данных (DWH) либо строим по ним оперативные отчеты. И с реляционными СУБД типа Oracle, MS SQL, Sybase и т.д. нет проблем – грузим таблицы источников в те же самые таблицы на ODS.







Мы очень хотели реализовать подобную репликацию GT.m в ODS.

Но как же грузить NoSQL структуры в простые таблицы? Как, например, загрузить клиента, у которого может быть 2 телефона, а может и 22?







Мы понимали, что правильнее будет организовать репликацию на основе бинарных логов СУБД (в других СУБД они называются WAL, Redo, transaction log и т.п.), благо, GT.m журналирует каждую транзакцию, изменяемую данные. При этом на рынке уже существовали готовые продукты, одним из которых является Evolve Replicator от компании CAV systems.



Evolve CAV systems



Evolve читает журналы транзакций, трансформирует их и записывает строки в таблицы уже на реляционном приемнике.



Но была одна совсем маленькая проблема – это решение нам не подходило… В наших структурах имелось большое количество вычисляемых значений (Computed Data Items или CDI).



Попробую объяснить на пальцах. Это чем-то напоминает «виртуальное поле» в таких СУБД, как Oracle, в которых значение не хранится, а вычисляется на момент обращения к этому полю. При этом CDI может иметь достаточно сложную логику и базироваться на данных из дочерних узлов и т.д. И, как вы наверно уже догадались, такие Computed Data Items невозможно реплицировать из журналов СУБД, так как информация по ним там не хранится, потому что в журналы записываются только изменения физических полей. Но такие поля-призраки нам очень нужны для аналитики, в них сложная логика, и иметь аналитическую реплику без этих полей было бы бессмысленно.



Реализовать подобную логику с вычисляемыми полями в реплике – нереально. Во-первых, по причине производительности, во-вторых – переписывать весь этот хардкод с языка М на SQL – дело неблагодарное.







FIS Profile



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



Таким приложением является FIS Profile (далее Profile) – это автоматизированная банковская система, полностью интегрированная с GT.m. Кроме функций автоматизации банковской деятельности, Profile обеспечивает следующий функционал:

1. Простейший SQL (select * from table where id=1)

2. Доступ к данным по JDBC

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

4. Триггеры

5. Секьюрность

По сути, мы имеем еще одну СУБД поверх другой СУБД. При этом одна из них будет реляционной, а другая – NoSQL.



Profile является полностью проприетарным ПО, но есть и Open Source аналоги, например, Vista Fileman.





Логические уровни нашей GT.m-системы.



Реализация концепции



Для репликации NoSQL-структур данных в SQL СУБД в первую очередь необходимо:



1. Представить глобалы в табличном виде.

При этом один узел «дерева» может быть представлен в виде нескольких, связанных между собой таблиц. Такую возможность уже предоставляет Profile, и все, что нам необходимо, – это правильно настроить такие табличные представления. Задача хоть и сложная, но вполне решаемая.



2. Захват изменений.

К сожалению, наличие CDI в нашей системе не позволяет сделать «правильную репликацию» из журналов СУБД. Единственный возможный вариант – логическая репликация триггерами. Изменилось значение в таблице – триггер это отловил и записал изменение в журнальную таблицу. Кстати, журнальная таблица – это тот же самый глобал. Сейчас все сами увидите!



Вот так выглядит типичный глобал:







Понимаем, выглядит как минимум… странно, но в те далекие годы понятия красоты были совершенно другими. Структура глобала также называется «многомерным разреженным массивом». И ключ – это как бы координата данных, которые в нем лежат.

Кстати, по «данным» можно также строить индексы, что бывает очень удобно для табличного представления.



Собственно, из такого глобала мы можем получить 2 таблицы:



TABLE_HEADER





TABLE_SHED — лог изменений





Кстати, числовые значения преобразовались в даты, например, для поля TJD.



По имеющимся таблицам выполняется запрос





где:

:STARTPOINT – дата последнего запуска;

'Т' – текущая дата (выглядит как минимум странно, но эта функция – аналог sysdate() или now() в нормальных других СУБД)



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



3. Выборка данных из журнальных таблиц и последующая их передача в ODS.

Существовавший на тот момент данных JDBC-драйвер прекрасно работал с атомарными запросами, но вызывал утечки памяти во время массированных операций Select. Имеющийся драйвер пришлось значительно переписать.



4. Доставка и применение изменений.

Очень важный аспект – быстрое применение данных на приемнике. Если GT.m успешно справляется с большим количеством атомарных транзакций, то для реляционных СУБД типа Oracle это несет большую нагрузку. При этом в наш ODS льются данные из большого количества других источников (всего около 15).

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





Текущая архитектура репликации



Наше приложение – кстати, мы его назвали Profile Loader – загружает в ODS два типа таблиц: журнальные и зеркальные. Мы постараемся рассказать про ODS в будущих статьях, но если кратко, то:

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

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



5. Пункт управления.

Для удобного администрирования мы сделали веб-мордочку для запуска и остановки потоков репликации. Да и вообще, вся основная логика была написала на Java, что позволило использовать уже готовые Open Source компоненты для решения каких-то специфичных кейсов.



Задачи, решаемые SQL репликой



1. Избавление от разрозненных выгрузок. Мы получили единое окно для всех потребителей данных.

2. Аудит. Упрощается процедура аудита за счет того, что данные лежат в удобном виде, а мощь SQL позволяет удобно и быстро этими данными оперировать.

3. Качество данных. Например, в GT.m всего 2 типа данных – числовой и строковый. Когда данные прилетают в ODS, они преобразуется в другие типы, в том числе и в даты. Если дата в неправильном формате, мы можем легко отлавливать такой инцидент и улучшать качество данных уже на источнике.

4. Вычисление инкремента для дальнейшей загрузки в DWH.



Дальнейшие пути развития



На будущее планируем реализовать следующее:

1. Полностью избавиться от существующих CSV-выгрузок. Сейчас они все еще живы, но мы их будем потихоньку «отстреливать».

2. Оптимизировать некоторые проблемы с производительностью.

3. Поделиться идеями с заинтересованным сообществом, возможно и поддерживать проект в OpenSource.

4. Попробовать интеграцию с Oracle GoldenGate на уровне доставки изменений.

5. Возможно, сделать обратную реплику (дополнительную, не ODS) Replica -> GT.m, для сервисных процессов повышения качества данных.

6. Развивать оперативную отчетность поверх ODS.



Резюме



В статье мы рассказали о нашем детище – Profile Loader и о том, как NoSQL данные можно анализировать в SQL СУБД. Данное решение возможно не совсем правильное и элегантное, но оно прекрасно работает и выполняет возложенные на него обязательства.



Если вы решитесь реплицировать свою NoSQL БД в «реляционку» для удобной аналитики, в первую очередь оцените объемы изменений, модель данных и возможности тех технологий, которые все это будут обеспечивать.



Желаем успехов в ваших начинаниях!

Всегда готовы ответить на ваши вопросы.



P.S. Также выражаем благодарность коллегам, участвовавшим и активно помогавшим в проекте: Шевелеву Дмитрию, Чебанову Николаю, Бубону Роману, Быстрову Денису, Бейспекову Кайсару, Люфко Андрею, Кудюрову Павлу, Воробьёву Сергею, Лысых Сергею, Кулешову Денису, Никитчик Елене, Мушкет Ольге, Чечёткиной Юлии, Пасынкову Юрию и коллегам из CAV Systems и FIS.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306954/

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

[Перевод] Это данные, тупица, и почему администраторы баз данных важны как никогда?

Пятница, 29 Июля 2016 г. 13:06 (ссылка)

«Специализированные базы данных, облачные технологии и DevOps не упраздняют роль администраторов, а наоборот – расширяют их функции. Возможно, дело уже не только в таблицах. Но роль администратора БД до сих пор важна, даже если у этой профессии нет названия». Син Галагер


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



Все эти функции админов старой закалки ещё кое-где встречаются, особенно на крупных предприятиях, где гигантские кластеры баз данных по-прежнему правят дата-центрами. Но виртуализация, облачные хранилища данных, микросервисы, DevOps-подход к разработке и запуску приложений и ряд других факторов существенно изменили то, как организации хранят свои данные и управляют ими. Многие традиционные роли администратора БД представляются спорными в том счастливом новом мире, который обещает нам новое поколение баз данных.



NoSQL базы данных не требуют предопределённой схемы данных, а многие репликации встроены по умолчанию. Подготовку новых серверов к работе можно свести к нажатию нескольких переключателей (радио-баттонов) и выставлению галочек на веб-странице. Команды разработчиков просто выбирают точку в облачном хранилище, таком как Amazon Web Services Simple Storage Service (S3), и идут отдыхать (roll). И даже разработчики реляционных БД, таких как Oracle, Microsoft и IBM, подталкивают клиентов к data-as-a-service (DaaS) моделям, кардинально упрощающим доступность и управление оборудованием.



Вы могли подумать, что от этого работа админов БД становится легче. Отнюдь.



«Я думаю, что их задачи [админов БД] стали значительно более сложными, — сказал Крис Лалонд, вице-президент и генеральный менеджер по работе с данными компании Rackspace. — Пока у нас не будет определённо большей автоматизации и технологической оснастки (инструментария), многие новые технологии будут менее зрелыми и их нужно будет холить и лелеять (они требуют больше ухода и кормления). Я хочу сказать, что многие из традиционных задач админов БД всё ещё существуют или должны существовать».



На самом деле все эти великолепные новые технологии подчёркивают профессионала в области данных, будь то администратор БД, архитектор данных, data engineer или даже, в некоторых случаях, data scientist. «Сегодня данные ещё более важны, — сказал Кенни Горман, ветеран БД и соучредитель Eventador (сервис для передачи данных в режиме реального времени). — Компании привыкли полагаться на базы данных, чтобы быть «на подъёме» (to be sound), работать гладко и давать хорошую отчётность. Но сегодня данные и вправду делают вас более конкурентоспособным, и существует больше разных профессий, связанных с данными, и больше технологий, их использующих. И профессионал по БД — в самом центре».



На шаг вперёд...



Нереляционные платформы пообещали снизить нагрузку на администраторов БД. В некотором роде они, действительно, сделали это. Рави Мэюрем, старший вице-президент Couchbase Inc. по продуктам и разработкам, сравнил сдвиг в обязанностях АБД с изменением вождения автомобиля (на протяжении многих лет): давным-давно «для того, чтобы водить машину, вы должны были по существу быть инженером; и когда что-то шло не так, вам нужно было сворачивать с дороги и лезть под капот. Теперь вещи сами заботятся о себе, но я бессилен их исправить».



Такие базы данных как MongoDB и CouchBase, хоть они и не реляционные, поддерживают SQL запросы. У них есть и другие аспекты, вызывающие благосклонность опытных админов БД. Но они также предоставляют «возможности динамического развёртывания, которых нет у реляционных систем, — утверждает Мэюрем. — А добавление новых структур данных обычно требует изменения схемы и влечёт к простою».



Данные как некая Услуга были отданы «на откуп компаний, — считает Мэюрем. — Большинство компаний не держат в облаке критически важную информацию».


В то время как большая реляционная система управления базами данных требует понимания всего аппаратного и программного обеспечения, «следующее поколение АБД будет вовлечено в это намного меньше, — объясняет Мэюрем. — К админу БД будет предъявляться, например, такое требование: всеобъемлюще разбираться в базах данных, но не только», чтобы сосредоточиться на таких задачах как планирование мощностей. АБД будущего должен будет знать, когда следует снабдить бо

https://habrahabr.ru/post/306692/

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

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

Четверг, 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)КомментироватьВ цитатник или сообщество

Следующие 30  »

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

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

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