Опыт миграции из собственного датацентра в облако AWS

Публикация № 860772

Администрирование - Производительность и оптимизация (HighLoad)

AWS базы данных миграция

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

Компания glassdoor.com является вторым по трафику сайтом в США для соискателей работы. SLA установлен на уровне 99.99% без возможности проводить обслуживание серверов и приложений в оффлайн режиме. Объем баз данных, которые должны быть мигрированы в облако - порядка 40Тб. В среднем сервера баз данных выполняют 2 млрд. запросов в день.

 

Ситуация до миграции

Для обеспечения высокой доступности (HADR) используется стандартная технология SQL Server Failover Cluster Instance.

 

 

Существующие особенности, которые надо было учесть при миграции:

  1. Для работы кластера требуется дорогостоящее сетевое хранилище данных (SAN), подключенное оптическими каналами ко всем нодам кластера.

  2. Физически имеется только одна активная копия данных, поэтому при обнаружении повреждений в страницах баз данных требуется восстановление этих страниц из бэкапов.

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

  4. Клиентские приложения написаны на java и работают под управлением Linux. Используется устаревшая версия jdbc-драйвера, которая официально поддерживает только SQL2008, хотя сами базы данных были переведены на SQL2016.

  5. Лицензии на SQL2016 уже были оплачены.

 

Какие вопросы надо было решить при миграции

  1. AWS не поддерживает общее хранилище данных для Windows. Использование  SQL Server Failover Cluster Instance невозможно.

  2. AWS не поддерживает свободный переход IP-адресов между серверами. Windows не сможет сама переместить клиентский адрес доступа на новую ноду при переключении между нодами.

  3. Требуется повысить уровень отказоустойчивости при авариях.

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

  5. Использовать свои лицензии на SQL Server.

Лицензирование

Политика Microsoft в части лицензирования баз данных в облаке довольно сложная.

Я бы выделил три возможных варианта для AWS:

  1. Для компаний с большим бюджетом дополнительные соглашения с Microsoft позволяют запускать виртуальные машины с SQL Server в облаке без особых ограничений. Вы можете запустить новую Windows VM, установить SQL и использовать без каких дополнительных манипуляций.

  2. AWS предоставляет возможность запустить Windows VM с предустановленным SQL Server. При этом оплата производиться по фактическому использованию. К примеру один сервер с 512 Gb RAM и 64 CPU обойдется примерно в $23000/месяц.

  3. Использовать собственные лицензии SQL Server в облаке AWS.

 

Для нас был приемлем только третий вариант:

  • SQL Server должен запускаться на выделенном физическом сервере. Звучит глупо.. облако.. физический сервер, но AWS поддерживает такую возможность.

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

  • AWS не позволит использовать публичные образы Windows для запуска VM на выделенном сервере. Потребуется создать собственный образ Windows VM собственными силами с помощью Hyper-V или VMWare, а затем экспортировать этот образ в AWS. Образ должен содержать собственную лицензию Windows и активироваться собственными KMS.

  • AWS не поддерживает автоматическое восстановление при аварии для таких виртуальных машин. Если физический сервер умирает вы должны перевести виртуальные машины на новый сервер самостоятельно.

При построении образа потребуется установить соответствующие драйверы для работы в AWS - драйвер хранилища и сетевой драйвер.

 

Выбор HADR архитектуры

Учитывая ограничения AWS на общее сетевое хранилище, было решено использовать SQL Server AlwaysOn.

Основные достоинства:

  1. Каждая нода кластера содержит собственную физическую копию данных. При повреждении страниц баз данных на одной ноде они могут восстановлены с других нод.

  2. Процесс фейловера занимает всего несколько секунд. В отличие от SQL FCI, нет необходимости завершать основной процесс базы данных и запускать его на новом сервере. Фейловер в SQL FCI обычно требовал 5 минут из-за агрессивности клиентских приложений.

  3. Возможность перенести нагрузку резервного копирования на другие ноды.

Недостатки:

  1. Двойной коммит - все синхронные ноды должны зафиксировать коммит одновременно с мастер нодой. В результате, производительность UPDATE\DELETE\INSERT операций в AlwaysOn ниже, чем в SQL FCI.

  2. Восстановление AlwaysOn ноды с нуля требует значительно большего времени, чем восстановление ноды в SQL FCI, т.е. необходимо восстановить все базы данных.

 

Невозможность перемещения IP адреса между нодами средствами Windows также накладывает ограничения на целевую архитектуру:

  1. Каждая нода, вовлеченная в процесс фейловера, должна находится в отдельной подсети. В этом случае Windows Failover Cluster позволит установить выделенный IP-адрес для каждой ноды и его перемещение в процессе фейловера не потребуется.

  2. Каждая нода должна иметь только один сетевой интерфейс для каждой подсети. Если требуется два интерфейса - расположите их в разных подсетях. Это позволит избежать проблемы, когда Windows Failover Cluster пытается активировать клиентский IP адрес на ошибочном сетевом интерфейсе.

 

Принимая во внимание рекомендации по расположению серверов баз данных в разных зонах получаем следующую архитектуру:

Две синхронные реплики в регионе us-east-1. Одна асинхронная реплика в us-west-2. Синхронные реплики позволяют защититься от аварий на уровне одного датацентра (на самом деле не так уж и редки). Асинхронная реплика страхует на случай аварии на уровне региона - но это уже на случай серьезного катаклизма, при котором автоматическое восстановление работы сайта невозможно - потребуется ручной перевод трафика в другой регион.

 

Выбор типа виртуальной машины

При всем многообразии типов VM в AWS, только три могут использоваться для баз данных эффективно.

  1. I3 - наибольший инстанс имеет 512 Gb RAM и 64 CPU. Дополнительно имеется 16Tb локальных быстродействующих SSD, которые могут быть использованы для tempdb и buffer pool extension.
    После ряда болезненных экспериментов мы пришли к выводу, что этот тип для нас не подходит. Вроде как там используется устаревший гипервизор, который тратит слишком много ресурсов на поддержку VM. Например, под большой нагрузкой утилизация CPU на физическом сервер была в 2 раза больше, чем внутри виртуальной машины.

  2. X1E - один из самых новых типов. Наибольший инстанс имеет 4096 Gb RAM и 128 CPU. Работает просто отлично, но цена…

  3. R4 - наибольший инстанс имеет 512 Gb RAM и 64 CPU. Приемлемая цена и хорошая производительность. Используется новая версия гипервизора с малыми издержками на виртуализацию.

 

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

Тип инстанса

Максимальная пропускная способность хранилища (MB/s, 128 KB I/O)

Максимум IOPS (16 KB I/O)

i3.8xlarge

875

32,500

i3.16xlarge

1,750

65,000

r4.8xlarge

875

37,500

r4.16xlarge

1,750

75,000

x1e.16xlarge

875

40,000

x1e.32xlarge

1,750

80,000

 

Конфигурация хранилища

AWS Elastic Block Storage позволяет выбрать из нескольких видов хранилища, каждый из который имеет свои лимиты и особенности.

 

Solid-State Drives (SSD)

Hard disk Drives (HDD)

Volume Type

General Purpose SSD (gp2)*

Provisioned IOPS SSD (io1)

Throughput Optimized HDD (st1)

Cold HDD (sc1)

Max. IOPS**/Volume

10,000

(when volumes size is > 3333Gb)

32,000

500

250

Max. Throughput/Volume

160 MiB/s

500 MiB/s***

500 MiB/s

(40 MB/s per TiB)

250 MiB/s

Use case

Database files

Database files

Database backups

<not being used>

 

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

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

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

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

К примеру наша конфигурация для r4.16xlarge сервера:

  1. Операционная система - C:\ - 300Gb. Тип тома - gp2. Стоимость в месяц $27.

  2. Базы данных с логами, tempdb - X:\ - 34Tb - десять томов gp2, каждый 3400Gb, объединенных в RAID0 средствами Windows Storage Spaces. Стоимость в месяц $3400.
    Как вышли на эту конфигурацию:

    1. Инстанс этого типа имеет лимит в 1750MB/s и 75000 IOPS.

    2. Один том gp2 имеет лимит в 160MB/s и до 10000 IOPS.

    3. Чтобы избежать проседания производительности размер каждого тома должен быть не менее 3333 Gb.

    4. Десять томов gp2, объединенных в RAID0 позволяют максимально утилизировать доступный лимит для инстанса и обеспечить максимальную пропускную способность.

Такого же эффекта можно добиться с помощью четырех io1 томов 20000 IOPS в каждом. Размер при этом не имеет значения. Но такая конфигурация обойдется значительно дороже при меньшей емкости. Например, 4 тома по 3000 Gb обойдутся в $6700 в месяц.

  1. Бэкапы - S:\ - 4Tb - один том st1. Стоимость в месяц $180 (в два раза дешевле gp2, при хорошей производительности для бэкапов).

 

Бэкапы баз данных

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

  1. Бэкап базы данных выполняется на главной ноде на “локальный” диск S:\. Диск является EBS томом, поэтому беспокоится за его сохранность не стоит - том можно переключить на другой сервер даже если виртуальная машина полностью потеряна. Локальный том хранит бэкапы за последние 7 дней.

  2. По субботам полный бэкап загружается в AWS S3 на долговременное хранение. Для файлов изначально устанавливается тип хранилища “нечастый доступ”, а по истечение 45 дней файлы автоматически выгружаются в AWS Glacier. В итоге долговременное хранилище большого объема файлов выходит относительно дешево.

 

Клиентские приложения

В процессе работы над проектом мы осознали, что используемый jdbc-драйвер не сможет эффективно работать в новой конфигурации, т.к. он не поддерживает клиентские точки доступа с несколькими IP-адресами (multi-subnet cluster). Кстати, платформа 1С также не поддерживает такую конфигурацию в чистом виде - мне не удалось заставить сервер 1С стабильно подключаться к AlwaysOn кластеру с несколькими IP-адресами. Хотя, с определенными оговорками, есть вариант как это решить.

Суть проблемы в том, что для используемого доменного имени DNS сервер возвращает два (или больше) IP адреса вместо одного. Но только один адрес, принадлежащий мастер ноде, является активным.

Для решения проблемы нужно всего лишь добавить параметр “MultiSubnetFailover=True” в строку соединения. Но не всегда есть возможность сделать это.

Варианты решения, если поменять строку соединения невозможно:

  1. Windows Failover Cluster имеет параметр, который позволяет обновлять IP адрес в DNS и регистрировать только один адрес, который активен в данный момент. Минусы:

    1. в процесс фейловера вовлечен дополнительный участник (DNS сервер).

    2. DNS кэш на клиентских серверах обновляется не так часто.

    3. Дополнительные сложности возникнут если клиенты на Linux.

В результате сложно ожидать восстановления нормальный работы приложений быстрее чем через 5-10 минут после фейловера.

  1. Использовать один из сервисов AWS - Network Load Balancer

    1. NLB корректно определяет активную ноду и меняет DNS запись.

    2. Нормально работает в Linux.

    3. Проблема с DNS кэшем все равно присутствует.

Время на восстановление также 5-10 минут.

  1. Использовать решения типа HAProxy

    1. С точки зрения клиента IP адрес не меняется.

    2. Время восстановления после фейловера может приблизится к 30-60 секундам.

    3. Для построения реальной отказоустойчивости на уровне HAProxy требуется построение довольно сложной архитектуры. Один из вариантов: два HAProxy + AWS Network Load Balancer. В этом случае сбой на одном HAProxy не приведет к полной потере доступа к базе данных.

 

Непосредственная миграция

Одним из условий проекта была возможность быстрого возврата в локальный датацентр при проблемах в AWS, поэтому было решено использовать AlwaysOn как средство миграции баз данных. Хотя технически это можно назвать обычным процессом фейловера между нодами, расположенными в разных датацентрах.

 

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

Затем веб-сайт переводится в оффлайн режим, производится фейловер базы данных в AWS и AlwaysOn переключается обратно в асинхронный режим. В этом время, трафик переключается на приложения в AWS, которые уже подключены в новой мастер ноде.
Суммарное время даунтайма - 6 минут!

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. grumagargler 620 30.07.18 00:09 Сейчас в теме
Подскажите пожалуйста, в статье описаны особенности и сложности перехода, но непонятно зачем вы это делали?
2. Aleksey.Bochkov 3285 30.07.18 02:55 Сейчас в теме
(1) Задача была перевести все приложения в облако, для того, чтобы ускорить развитие бизнеса в конечном счете. В своем датацентре требуется минимум пара недель для получения нового сервера, в облаке же это вопрос пары минут.
JohnyDeath; +1 Ответить
3. mad375 30.07.18 05:15 Сейчас в теме
Было очень интересно, спасибо
4. ihtiking 01.08.18 12:45 Сейчас в теме
Дороговато выходит.... После перехода Вы почувствовали изменения к лучшему с точки зрения бизнеса или с точки зрения ИТ ?
5. Aleksey.Bochkov 3285 03.09.18 23:05 Сейчас в теме
(4) По словам CTO, в долговременной перспективе расходы на инфраструктуру после перехода в AWS ожидаются на 10-20% меньше расходов на собственный датацентр.
Изменения к лучшему заметили практически на всех уровнях:
- цикл разработки новой функциональности ускорился
- стало легче реагировать на скачки трафика (сервера приложений масштабируются горизонтально в течение пары минут)
- проще устранять проблемы
- и, как бы странно это ни звучало, сайт работает существенно быстрее в AWS.
6. kiruha 382 15.10.18 11:05 Сейчас в теме
glassdoor.com из США обратился во франч 1С в России для перевода дата центра ?
7. Aleksey.Bochkov 3285 15.10.18 20:14 Сейчас в теме
(6) я работаю в этой компании. Живу в Сан Франциско.
AQR84; Krio2; kiruha; +3 Ответить
Оставьте свое сообщение

См. также

Простое обнаружение проблем производительности в PostgreSQL

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Hans-J&#252;rgen Sch&#246;nig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    1155    w.r.    4       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Статья Программист Нет файла v8::Запросы Бесплатно (free) Производительность и оптимизация (HighLoad)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    3683    Evil Beaver    13       

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    4105    a.doroshkevich    15       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

Оптимизатор запросов. Вторая часть

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    3395    darkdan77    59       

Улучшаем производительность 1С. Рекомендации

Статья Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    4662    Kaval88    26       

​​​​​​​CorelDRAW Graphics Suite 2019 Промо

CorelDRAW – пакет профессиональных инструментов для редактирования фотографий, разработки дизайна, создания макетов страниц и векторных иллюстраций

Атака сервера кнопонажималкой

Статья Программист Нет файла Бесплатно (free) Нагрузочное тестирование

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    2913    nixel    16       

Мониторим производительность с помощью 1С RAS

Статья Системный администратор Программист Нет файла v8 1cv8.cf Бесплатно (free) Инструментарий разработчика Производительность и оптимизация (HighLoad)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    5585    ivanov660    12       

Программы для исполнения 54-ФЗ Промо

С 01.02.2017 контрольно-кассовая техника должна отправлять электронные версии чеков оператору фискальных данных - правила установлены в 54-ФЗ ст.2 п.2. Инфостарт предлагает подборку программ, связанных с применением 54-ФЗ, ККТ и электронных чеков.

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Статья Системный администратор Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    3945    EugeneSemyonov    11       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Набор скриптов для знакомства с SQL Server

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование СУБД

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

30.09.2019    15524    YPermitin    14       

Мониторинг высоконагруженной системы

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    5944    Repich    5       

Сдача регламентированной отчетности из программ 1С Промо

Сдача регламентированной отчетности из программ "1С" во все контролирующие органы без выгрузок и загрузок в другие программы. Для групп компаний действуют специальные предложения.

от 1500 руб.

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    11378    Sloth    11       

Базовый курс по обмену данными в системе 1С:Предприятие. Онлайн-интенсив с 12 по 28 мая 2020 г. Промо

Данный онлайн-курс предусматривает изучение механизмов платформы “1С:Предприятие”, обеспечивающих обмен данными между различными прикладными 1С-решениями и взаимодействие с другими информационными системами. Курс предназначен для тех, кто уже имеет определенные навыки конфигурирования и программирования в системе “1С:Предприятие”.

5500 рублей

Руководство по SQL: Как лучше писать запросы (Часть 2)

Статья Системный администратор Программист Нет файла СУБД Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    5196    w.r.    1       

Анализ производительности APDEX

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    6017    144    YPermitin    7       

Онлайн-курс "Подготовка к экзамену 1С:Эксперт и 1С:Профессионал по технологическим вопросам" с 7 по 24 апреля 2020 г. Промо

На курсе вы получите практические навыки решения задач производительности 1С, в том числе характерных для высоконагруженных информационных систем (более 1000 пользователей). Подготовка к экзамену – только одна из составляющих курса. 70% слушателей приходят за знаниями, которые позволят расти и зарабатывать, делать сложные задачи на крупных проектах.

16450 рублей

Руководство по SQL: Как лучше писать запросы (Часть 1)

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    6434    w.r.    0       

Использование Union вместо OR

Статья Системный администратор Программист Нет файла MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    2545    w.r.    35       

Голосование за доклады на INFOSTART MEETUP Kazan - до 25 февраля. Промо

Выбирайте и голосуйте за самые интересные доклады! Лучшие из лучших попадут в окончательную программу казанского митапа. Оставить свой голос можно до 25 февраля 2020 года.

Тюнинг производительности запросов в PostgreSQL

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Brady Holt "Performance Tuning Queries in PostgreSQL ". Оригинал доступен по ссылке https://www.geekytidbits.com/performance-tuning-postgres/

31.07.2019    4895    w.r.    5       

Неочевидные проблемы производительности: важность системного подхода при анализе

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    6269    Филин    12       

INFOSTART MEETUP Kazan. 13 марта 2020 г. Промо

Инфостарт продолжает путешествие по России. Следующая остановка - Казань. Тема мероприятия - управление и технологии автоматизации учета на платформе "1С: Предприятие". Ждем всех: докладчиков и участников! Стоимость участия - 5 500 рублей. Цена действительна до 30.01.2020

5 500

Ловля блокировок на связке "Microsoft SQL server - 1С"

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    6202    fhqhelp    0       

Настройка параметров PostgreSQL для оптимизации производительности

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tuning PostgreSQL Database Parameters to Optimize Performance". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/31/tuning-postgresql-database-parameters-to-optimize-performance/

08.07.2019    4909    w.r.    13       

Управление ИТ-проектами. Модуль 2: продвинутый онлайн-курс по классическим методам управления проектами. Вебинары проходят с 12 марта по 11 июня 2020 года. Промо

Продвинутый онлайн-курс по классическому управлению ИТ-проектами позволит слушателям освоить инструменты из PMBoK® и 1С:Технологии корпоративного внедрения и научиться их применять для проектов любого масштаба. Курс включает в себя 12 вебинаров и 12 видеолекции, разбор кейсов и рекомендации экспертов по проектам слушателей. Ведущая курса - Мария Темчина.

от 13000 рублей

Сравнительное тестирование работы PostgreSQL с большими страницами Linux

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Представляю вашему вниманию перевод статьи Ibrar Ahmed "Benchmark PostgreSQL With Linux HugePages". Оригинал расположен по ссылке https://www.percona.com/blog/2018/12/20/benchmark-postgresql-with-linux-hugepages/

05.07.2019    3063    w.r.    6       

Настройка параметров ядра Linux для оптимизации PostgreSQL

Статья Системный администратор Программист Нет файла Linux Бесплатно (free) Производительность и оптимизация (HighLoad)

Предлагаю вашему вниманию перевод статьи Ibrar Ahmed "Tune Linux Kernel Parameters For PostgreSQL Optimization". Оригинал доступен по ссылке https://www.percona.com/blog/2018/08/29/tune-linux-kernel-parameters-for-postgresql-optimization/

05.07.2019    3723    w.r.    1       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    8128    igordynets    119       

Сравнительное тестирование PostgreSQL на FreeBSD, CentOS, Ubuntu Debian и openSUSE

Статья Системный администратор Программист Нет файла PostgreSQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная статья является переводом оригинальной статьи Martin Kov&#225;&#269;ik "PostgreSQL benchmark on FreeBSD, CentOS, Ubuntu Debian and openSUSE" https://redbyte.eu/en/blog/postgresql-benchmark-freebsd-centos-ubuntu-debian-opensuse/ В ней рассматриваются тесты СУБД PostgreSQL 10.1 в приближенных к реальным условиям средах на различных unix-системах

30.06.2019    4561    w.r.    2