Рубрика «Администрирование баз данных» - 41

в 20:40, , рубрики: cassandra, hdfs, mongodb, riak, Администрирование баз данных, кластер, математика, потеря данных, Серверное администрирование, хранение данных, хранилища данных

В этой статье используется MathJax для рендеринга математических формул. Нужно включить JavaScript, чтобы MathJax заработал.

Многие распределённые системы хранения (в том числе Cassandra, Riak, HDFS, MongoDB, Kafka, …) используют репликацию для сохранности данных. Их обычно разворачивают в конфигурации «просто пачка дисков» (Just a bunch of disks, JBOD) — вот так, без всякого RAID для обработки сбоев. Если один из дисков в ноде отказывает, то данные этого диска просто теряются. Чтобы предотвратить безвозвратную потерю данных, СУБД хранит копию (реплику) данных где-то на дисках в другой ноде.

Самым распространённым фактором репликации является 3 — это значит, что база данных хранит три копии каждого фрагмента данных на разных дисках, подключенных к трём разным компьютерам. Объяснение этому примерно такое: диски выходят из строя редко. Если диск вышел из строя, то есть время заменить его, и в это время у вас ещё две копии, с которых можно восстановить данные на новый диск. Риск выхода из строя второго диска, пока вы восстанавливаете первый, достаточно низок, а вероятность смерти всех трёх дисков одновременно настолько мала, что более вероятно погибнуть от попадания астероида.
Читать полностью »

в 11:15, , рубрики: nosql, sql, Администрирование баз данных, базы данных, Блог компании RUVDS.com

Все мы знаем, что в мире технологий баз данных существует два основных направления: SQL и NoSQL, реляционные и нереляционные базы данных. Различия между ними заключаются в том, как они спроектированы, какие типы данных поддерживают, как хранят информацию.

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

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

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

SQL или NoSQL — вот в чём вопрос - 1

Какую технологию выбрать? Ответ на этот вопрос зависит от особенностей проекта, о котором идёт речь.
Читать полностью »

в 14:52, , рубрики: devops, docker, intersystems cache, Администрирование баз данных, Блог компании InterSystems

В этой статье я хочу рассказать про то как можно получить свой образ Docker с InterSystems Caché/Ensemble.
Читать полностью »

в 9:03, , рубрики: devops, postgresql, sql, Администрирование баз данных, базы данных, книга, книга на гитхабе, книга на русском, масштабирование, настройка, хранение данных, хранилища данных

Работа с PostgreSQL: настройка и масштабирование. 5-е издание - 1
Добрый день, хаброжители. Прошло много времени с выпуска 4 версии книги по PostgreSQL — успела выйти версия 9.5 и 9.6 этой замечательной базы данных. Материалов по практическому использованию этой БД также накопилось немало, поэтому я решил выпустить обновление по книге. Итак, встречайте:«Работа с PostgreSQL: настройка и масштабирование», 5-е издание.

Читать полностью »

в 12:55, , рубрики: Ansible, devops, haproxy, keepalived, linux, patroni, postgresql, Администрирование баз данных, системное администрирование

Привет!

Встала передо мной недавно задача: настроить максимально надежный кластер серверов PostgreSQL версии 9.6.

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

Планируя кластер я проштудировал много статей, как из основной документации к PostgreSQL, так и различных howto, в том числе с Хабра, и пробовал настроить стандартный кластер с RepMgr, эксперементировал с pgpool.
В целом оно заработало, но у меня периодически всплывали проблемы с переключениями, требовалось ручное вмешательство для восстановления после аварий, и т.д.
В общем я решил поискать еще варианты.
В итоге где-то (уже не вспомню точно где) нашел ссылку на прекрасный проект Zalando Patroni, и все заверте…

Читать полностью »

в 7:07, , рубрики: BRMS, Администрирование баз данных, база данных, Блог компании КРОК, инфраструктура, репозитории правил, метки: ,

Репозитории правил для бизнеса и соответствующих блоков кода, которые встраиваются в продакшн - 1

Вкратце напомню: BRMS, или Business Rule Management System, — это «тяжёлые» системы для крупных и очень крупных компаний, которые содержат все те вещи, которые часто меняются в ИТ. Например, в банке в BRMS лежат чаще всего правила оценки по кредиту и параметры вкладов, в сотовом операторе — тарифы и нюансы вычисления всех списаний, в страховой компании — коэффициенты страхования, поправочные коэффициенты, параметры новых продуктов.

Разница между «вобьём руками» и «вобьём через BRMS» примерно такая: парни из одной страховой компании, где мы внедряли BRMS, оказались одними из немногих по итогам прошлого года, кто показал возможность работать очень гибко и быстро. Обычно внедрение коэффициента со всеми проверками занимает в среднем 2 недели. Здесь же это делается максимум за 2 дня, минимум — за считанные часы. У них есть данные статистики, на которые крайне быстро можно реагировать и перепроверять разные показатели сотни и тысячи раз. В страховании это означает возможность очень детально подстраиваться под текущую ситуацию (регион, банки) и получать куда больше прибыли.

Мы используем BRMS для оценки стоимости ИТ-проекта — она рассчитывается на основе правил вроде «работают сетевики либо программисты» и десятков переменных вроде стоимости часа специалиста.Читать полностью »

в 12:19, , рубрики: zabbix, Администрирование баз данных, Блог компании AT Consulting

Была поставлена задача: реализовать мониторинг БД Oracle средствами Zabbix, а именно — отслеживать параметры табличных пространств на определенном инстансе. Раз задача поставлена, значит делаем. Как известно, Zabbix предоставляет возможность через предопределенный тип данных осуществлять запросы к базам данным и получать результат запроса. На официальном сайте разработчиков Zabbix есть очень хорошая документация по настройке ODBC-мониторинга.

image


У нас сервер Zabbix 3.0.4 под управлением Centos 7. Ранее ODBC мониторинг не был настроен, а следовательно, нужно открывать инструкции и начинать установку и настройку.
Читать полностью »

в 10:01, , рубрики: Cloud Spanner, Google Spanner, NewSQL, nosql, sql, TrueTime API, Администрирование баз данных, Облачные вычисления, СУБД, хранилища данных, метки: ,

Google запустила бета-версию Cloud Spanner — СУБД поколения NewSQL - 1

Google открыла для всех бета-версию сервиса Cloud Spanner, глобально распределённой высокомасштабируемой мультиверсионной NewSQL БД с поддержкой распределённых транзакций.

Несколько лет Google использовала этот сервис исключительно для внутренних нужд. На нём работают ключевые системы Google, в том числе AdWords и Google Play. Spanner — эволюционное развитие NoSQL-предшественника Google Bigtable. Сам же c Spanner относят к семейству NewSQL-решений, то есть оно сочетает в себе преимущества реляционных и нереляционных СУБД. Это ACID-транзакции и SQL-синтаксис традиционных СУБД без ущерба для горизонтального масштабирования и высокой доступности, присущих NoSQL.

Исходя из опыта работы системы внутри компании, Google предлагает клиентам аптайм 99,9999% (шесть девяток, то есть максимум 31,5 секунды простоя в год), клиентские библиотеки с поддержкой Java, Go, Python, Node.js и др.
Читать полностью »

в 6:56, , рубрики: fault, gitlab, incident, postgresql, Администрирование баз данных, Блог компании centos-admin.ru, Серверное администрирование, системное администрирование

sudo rm -rf, или Хроника инцидента с базой данных GitLab.com от 2017-01-31 - 1

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

Аркадий и Борис Стругацкие

31 января 2017 года произошло важное для мира OpenSource событие: один из админов GitLab.com, пытаясь починить репликацию, перепутал консоли и удалил основную базу PostgreSQL, в результате чего было потеряно большое количество пользовательских данных и сам сервис ушел в офлайн. При этом все 5 различных способов бэкапа/репликации оказались нерабочими. Восстановились же с LVM-снимка, случайно сделанного за 6 часов до удаления базы. It, как говорится, happens. Но надо отдать должное команде проекта: они нашли в себе силы отнестись ко всему с юмором, не потеряли голову и проявили удивительную открытость, написав обо всем в твиттере и выложив в общий доступ, по сути, внутренний документ, в котором команда в реальном времени вела описание разворачивающихся событий.

Во время его чтения буквально ощущаешь себя на месте бедного YP, который в 11 часов вечера после тяжелого трудового дня и безрезультатной борьбы с Постгресом, устало щурясь, вбивает в консоль боевого сервера роковое sudo rm -rf и жмет Enter. Через секунду он понимает, что натворил, отменяет удаление, но уже поздно — базы больше нет...

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

Читать полностью »

в 11:30, , рубрики: data, SaaS, Администрирование баз данных, бд, Блог компании Inoventica Services, дата-инженер, инструментарий, инструменты, обработка данных, перевод, разработка, Сетевые технологии, СУБД, хранение данных, хранилища данных

image

Я присоединился к команде Facebook в 2011 году в качестве инженера бизнес-аналитика. К моменту, когда я покинул команду в 2013 году я уже был дата-инженером.

Меня не продвигали или назначали на эту новую позицию. Фактически, Facebook пришла к выводу, что выполняемая нами работа является классической бизнес-аналитикой. Роль, которую в итоге мы для себя создали, была полностью новой дисциплиной, а я и моя команда находились на острие этой трансформации. Мы разрабатывали новые подходы, способы решения задач и инструменты. При этом, чаще всего, мы игнорировали традиционные методы. Мы были пионерами. Мы были дата-инженерами!

Дата-инжиниринг?

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

Но в отличие от ученых, работающих с данными и вдохновленными более зрелым прародителем сферы — программированием — дата-инженеры создают собственные инструменты, инфраструктуру, фреймворки и сервисы. На самом деле, мы намного ближе к программированию, чем к науке о данных.
Читать полностью »

1...1020...404142...5060...64
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js