Рубрика «базы данных» - 53

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

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

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

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

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

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

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

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

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

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

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

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

Вступление

Год назад потребовалось написать БД в рамках курсовой работы. Особого труда это не вызвало. Выбрал тему, начертил ER-диаграмму, определился с полями таблиц и начал написание. Язык долго не выбирал, на тот момент начинал работать на Java в Eclipse. Выбрал СУБД, мой выбор пал на Firebird. Добавил таблиц через IBExpert и был всем доволен, как только написал UI для пары таблиц понял что можно создавать остальные с помощью копипаста. Код получился ужасный(ООП? не не слышал, так можно это было охарактеризовать), но на тот момент меня все радовало. Прошел год и по воле случая пришлось пересматривать свой код. Это было нечто страшное с непонятной структурой.

Перед собой решил поставить несколько целей:
— простое добавление таблиц
— применить, наконец, ООП
— применить шаблоны проектирования(для обучения)

Также сейчас непонятно почему людям в институте сложно писать простые БД (или лень), в любом случае, хочу показать простоту написания БД и познакомить со своим видением приложения (на мой взгляд очень простым).
Читать полностью »

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

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

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

Денормализация данных лучше, чем делать вычитание таблиц

Здравствуйте господа.

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

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

imageВот уже второй год как мы используем в нашем продукте JBoss Teiid. Накоплен опыт, сделаны и учтены многие ошибки. Сожалений в сделаном выборе нет. Появилось желание поделиться собранной информацией, надеюсь кому-то пригодится.

В двух словах JBoss Teiid – федеративная база данных [2]. Ну или так – это объединяющая реляционная надстройка над многочисленными источниками данных. С точки зрения пользователя такая база выглядит как единая схема, в которой таблицы, представления, и процедуры являются объектами внешних данных. Можно еще сказать что внешние данные транслируются в единую виртуальную базу.

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

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

Большинство реляционных баз данных, за исключением MS Access, состоят из двух отдельных компонентов: «back-end», где хранятся данные и «front-end» — пользовательский интерфейс для взаимодействия с данными. Этот тип конструкции достаточно умный, так как он распараллеливает двухуровневую модель программирования, которая отделяет слой данных от пользовательского интерфейса и позволяет сконцентрировать рынок ПО непосредственно на улучшении своих продуктов. Эта модель открывает двери для третьих сторон, которые создают свои приложения для взаимодействия с различными базами данных.

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

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

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

Давно хотел перевести, но сейчас как раз подходящее время в связи со сменой лицензии у OpenStreetMap.

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

Большая часть потенциальной ценности данных, в частности их ценность для всего общества, реализовывается за счёт использования без организационных преград. Как это происходит (юридически)? Многие сайты дают узкое разрешение на использование данных с помощью условий предоставления услуг. Активно обмен специальными данными происходит среди исследователей. И всё чаще открытые данные освобождаются посредством распространения на публичных условиях (например, лицензий CC или передачи в общественное достояние CC0) для преодоления ограничений авторского права, которые в противном случае способны ограничить распространение или повторное использование данных.

Многие организации, учреждения и правительства используют инструменты CC для данных.

Лицензии CC используются для баз данных следующими организациями (подробнее):
Australia Federal Government, Australia Queensland State Government, ChEMBL, DBpedia, Finnish Libraries, Freebase, Geocommons, Google, Greece Government, Italian Government, MusicBrainz, Mydosis Portal, New Zealand Government, Open Directory Project (dmoz), OpenStreetMap, Powerhouse Museum, Spain (Basque) Government — Open Data Euskadi, Stack Overflow, Uniprot, United Kingdom Government.

Инструмент CC0 используется для баз данных следующими организациями (подробнее):
The British Library, CERN Library, Cologne-based Libraries, Digg, Dryad, Europeana, FigShare, Flickr, Genomes Unzipped, German National Library, German Wikipedia, GlaxoSmithKline (GSK), National Library of Spain, Italian Piemonte Regional Government, MichiganView, Netherlands Government, Open Library, OpenEI, OpenJurist.org, Personal Genome Project, Polar Information Commons, Proteome Commons Tranche Network, Public.resource.org, Safecast, Sage Bionetworks — Sage Commons, Spanish National Library, Smithsonian Cooper-Hewitt Museum, SimpleGeo, Swedish National Library, Talis Connected Commons, University of Florida Library, University of Michigan Library, WisconsinView, Université de Montréal Biodiversity Centre, Mercy Corps, Open Clip Art Library.

Часто задаваемые вопросы о данных

Могут ли базы данных быть выпущенные по лицензиям CC?

Да, лицензии CC могут быть использованы для любых защищенных авторским правом произведений, включая защищённые авторским правом на базу данных. Лицензия CC может быть применена к любому или всем копирайт-аспектам базы данных и её содержимого.Читать полностью »


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