Рубрика «sql» - 85

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

Обеспечение масштабируемости в SQL Database

Одним из наиболее значимых преимуществ размещения баз данных в среде SQL Database являются встроенные функции обеспечения масштабируемости. При необходимости можно добавить дополнительные базы данных. Два компонента SQL Database обеспечивают масштабируемость за счет постоянного отслеживания рабочей нагрузки на каждом из узлов. Первый компонент — Engine Throttling (регулировщик нагрузки на ядро), который защищает сервер от перегрузки. Второй компонент — Load Balancer (балансировщик нагрузки), который следит за тем, чтобы сервер не работал постоянно в режиме повышенной производительности. Читать полностью »

Интерес к технологиям Big Data постоянно растет, а сам термин приобретает все большую популярность, многие люди хотят поговорить об этом, обсудить перспективы и возможности в этой области. Однако немногие конкретизируют — какие компании представлены на этом рынке, не описывают решения этих компаний, а также не рассказывают про методы, лежащие в основе решений Big Data. Область информационных технологий, относящихся к хранению и обработке данных, претерпела существенные изменения к настоящему моменту и представляет собой стремительно растущий рынок, а значит лакомый кусок для многих всемирно известных и небольших, только начинающих, компаний в этой сфере. У типичной крупной компании имеется несколько десятков оперативных баз данных, хранящих данные об оперативной деятельности компании (о сделках, запасах, остатках и т.п.), которые необходимы аналитикам для бизнес-анализа. Так как сложные, непредвиденные запросы могут привести к непредсказуемой нагрузке на оперативные базы данных, то запросы аналитиков к таким базам данных стараются ограничить. Кроме того, аналитикам необходимы исторические данные, а также данные из нескольких источников. Для того чтобы обеспечить аналитикам доступ к данным, компании создают и поддерживают так называемые хранилища данных, представляющие собой информационные корпоративные базы данных, предназначенные для подготовки отчетов, анализа бизнес-процессов и поддержки системы принятия решений. Хранилища данных служат также источником для оценки эффективности маркетинговых кампаний, прогнозированию, поиску новых возможных рынков и аудиторий для продажи, всевозможному анализу предыдущих периодов деятельности компаний. Как правило, хранилище данных – это предметно-ориентированная БД, строящаяся на временной основе, т.е. все изменения данных отслеживаются и регистрируются по времени, что позволяет проследить динамику событий. Также хранилища данных хранят долговременные данные — это означает, что они никогда не удаляются и не переписываются – вносятся только новые данные, это необходимо для изучения динамики изменения данных во времени. И последнее, хранилища данных, в большинстве случае, консолидированы с несколькими источниками, т.е. данные попадают в хранилище данных из нескольких источников, причем, прежде чем попасть в хранилище данных, эти данные проходят проверку на непротиворечивость и достоверность.
Читать полностью »

Первая часть — вводная.
Вторая часть — быстрый старт.

Третья часть — тонкости и особенности.

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

Windows Azure предлагает как NoSQL хранилища, так и SQL-реляционные хранилища. NoSQL хранилища – это, например, Windows Azure Tables (ключзначение) или BLOB-объекты (двоичные данные такие, как фото, видео, документы и т.п.). К реляционным хранилищам относится SQL Database (ранее SQL Azure).
Обзор архитектуры и обеспечения высокой доступности в SQL Database (SQL Azure)
Читать полностью »

Я думаю, что в процессе изучения той или иной СУБД каждый из вас не раз изобретал велосипеды для решения своих задач, не зная о существовании той или иной функции или приема, которые бы могли в разы ускорить выполнение запросов и уменьшить объем кода. В данной статье я хочу поделиться с вами своим опытом работы с очень «добрым» и «отзывчивым» MySQL, часто позволяющему программисту делать вещи, которые другие СУБД переварить бы не смогли. Материал будет полезен скорее тем, кто только решил углубиться в чудесный мир запросов, но возможно и опытные программисты найдут тут что-то интересное.
Читать полностью »

Бизнес анализ в социальной сети Одноклассники

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

• архитектуру систем;
• основные компоненты систем и алгоритмы;
• нетривиальные проблемы и способы их решенияЧитать полностью »

Картинка Лупа. Исследование изменений в базе данных по средствам контрольных суммИсследование состояния базы данных очень значительно помогает при исследовательском тестировании. А сам тестировщик может найти такой баг, который может удивить самых матерых программистов.

Очень значительной частью приложения, над которым я работаю – является База Данных под управлением SQL Server и Oracle. За 10 лет существования самого приложения, количество таблиц выросло до 210 только в стандартной поставке, каждый пчих пользователя обложен триггерами, написано множество хранимых процедур и функций.

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

Часть 1 — здесь.

В этой части будут затронуты непростые вопросы использования SQLite через работу с его программным интерфейсом (API).

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

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

Небольшая вводная.

Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка и ответов поскольку информации очень много и так хоть немного проще ее структурировать.

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

Недостаточно писать код хорошо читаемым: он также должен быстро выполняться.

Существует три базовых правила для написания такого T-SQL кода, который будет работать хорошо. Они кумулятивные – выполнение всех этих правил окажет положительное влияние на код. Пропуск или изменение любого из них – скорее всего приведет к отрицательному влиянию на производительность вашего кода.

  • Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
  • Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
  • Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.

Существует несколько типичных ошибок, которые люди допускают в своем коде на T-SQL – не совершайте их.
Читать полностью »


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