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

Уже не одна правильная статья написана про необходимость и преимущества хранения исходных кодов схем базы данных в системах контроля версий (типа CVS, SVN, TFS и др.), а также ведения deploy – скриптов.
Не стану повторяться, но разберем один специфических аспектов этого процесса.

Не секрет, что нормально поставленный процесс разработки состоит из собственно разработки(Dev), внутреннего тестирования(QA), приёмочного тестирования конечными пользователями (UAT) и, непосредственно, «Production». Детали жизненного цикла могут отличаться в индивидуальных случаях, но это не существенно для темы статьи.

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

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

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

Часть 3. Vertica. Simply Fast

Simply Fast — этот вертиковский слоган возник не на пустом месте. Она, действительно, очень быстрая. Быстрая даже с “коробочными” настройками, что показали наши тесты во время выбора решения. В процессе миграции инфраструктуры мы хорошо изучили, как сделать Вертику еще быстрее и получать от нее максимальную производительность. Но обо всем по порядку.
Читать полностью »

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

Джон Грэхем-Камминг (John Graham-Cumming) сегодня жаловался в своём блоге, что компьютерная система, с которой он работал, не приняла его фамилию из-за недопустимых символов. Конечно, там нет недопустимых символов, потому что любой способ, как человек представляет себя, — по определению — является подходящим идентификатором. Джон выразил сильную досаду насчёт данной ситуации, и он имеет полное право, потому что имя — суть нашей индивидуальности, практически по определению.
Читать полностью »

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

Бэкапы больших баз данных (от сотен гагабайт и выше) достаточно бесполезное занятие по одной простой причине: восстановление из бэкапа может занять дни. Если база данных используется постоянно для ведения бизнеса и в нее непрерывным потоком грузятся данные — это неприемлимо. Несколько лучше обстоит дело в случае инкрементального бэкапа на резервную систему, которую можно включить прямо поверх бэкапа. Однако, такой способ подходит не для всех баз данных, а только на тех, которые не меняют однажды записанные на диск файлы. Например, для MySQL этот способ плохо подходит, все таблицы лежат или в едином tablespace (InnoDB), или в отдельных файлах (MyISAM). Для Вертики — это возможный вариант, так как данные записываются в безличных файлах, которые не меняются после записи, а только удаляются. Однако, в случае кластерных систем необходимо обеспечивать идентичную топологию основной и резервной систем. Также могут возникнуть проблемы с целостностью данных в случае сбоя основной системы.

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

Что же делать?Читать полностью »

Этой статьей я открываю серию материалов про инфраструктуру для аналитики вообще и экзотическую для России базу данных Vertica в частности. Статьи описывают опыт серии проектов в моей компании LifeStreet и не претендуют на полноту. Однако, где это представляется возможным, я буду пытаться давать общие обзоры. Прежде чем начать разговор собственно о Вертике, я хочу рассказать немного о том, как мы к ней пришли. Начнем с истории развития аналитической инфраструктуры в нашей компании.

Часть 1. Немного истории, теории и практики

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

Первая версия “инфраструктуры” была сделана “на коленке” за два дня в далеком 2006 году, когда в компании было 4 человека разработчиков, и примерно столько же людей из бизнеса. Читать полностью »

Мой друг Роберт Ходжес на днях опубликовал статью про репликацию из OLTP в OLAP базу данных (а именно, из MySQL в Vertica), которую его компания построила на своем продукте Tungsten. Самое интересное, это преобразование данных, которое происходит в процессе репликации. Подход достаточно общий, и может быть использован и для других систем.

Обычный подход к репликации — это синхронный или асинхронный перенос бинарного лога с одной базы данных (мастер) на другие (слейвы). В бинарном логе строго последовательно записываются все операции, которые модифицируют данные. Если его «проиграть» на другой системе с той же начальной точки, то должно получиться точно такое же состояние данных, как и на исходной. «Проигрывание» происходит по одной операции или по одной транзакции, то есть очень маленькими кусочками.

Этот подход плохо работает с OLAP-специфичными, и особенно, колонко-ориентированными базами данных, которые хранят данные физически не по строкам, а по колонкам. Такие базы данных оптимизированы на запись, чтение и сортировку больших массивов данных, что типично для аналитических задач, но не на маленькие операции на единичных записях, потому что любая операция затрагивает много колонок, которые физически хранятся в разных файлах (а иногда и разных дисках). Хуже всего обстоит дело с изменением данных. Конечно, все базы данных поддерживают стандарт SQL и оператор UPDATE, но на физическом уровне он, как правило, транслируется в то, что обновляемая запись помечается как удаленная, а вместо нее вставляется измененная копия. Потом, когда-нибудь, «сборщик мусора» перетрясет таблицу и удаленные записи удалятся навсегда. Помимо плохой эффективности, отсюда следует, что частые удаления и обновления приводят к «засорению» базы данных, что снижает ее производительность в том числе и на чтение.

Роберт предложил, как мне кажется, новый, хотя и естественный подход к решению проблемы репликации данных для таких случаев. Бинарный лог преобразуется в последовательность частично упорядоченных множеств операций типа DELETE/INSERT для каждой таблицы, причем, так слово «множество» подразумевает, что «одинаковые» в некотором смысле операции достаточно сделать один раз. Поясню чуть подробнее.
Читать полностью »

Приветствую.

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

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

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

В силу частых и неупорядоченных изменений базы данных, большим числом пользователей, часто возникает вопросы о истории изменений. Речь не идет о тотально логирование всех изменений, которые происходят с базой в течение дня. Интерес представляют собой снимки структуры БД каждый день после окончания рабочего дня. С помощью SQL Server Management Studio можно сгенерировать скрипты, но поштучно или все сразу. Полную свободу действий можно получить использовав набор библиотек от SQL Server Management Studio в вашем .NET приложение. Описание программы генерации скриптов: таблиц, представлений, процедур далее.
Читать полностью »

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

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

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

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

  • Для целей тестирования
  • Для совместной разработки
  • Для каких-то программных алгоритмов, оперирующих этими данными

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js