Наверх ▲

Addressing Vendor Weaknesses in User-Space

Роберт Трит (Robert Treat) Роберт Трит (Robert Treat) Возглавляет группу по работе с базами данных в компании OmniTI.

Robert Treat: Я выступал здесь в прошлом году, и вот я опять здесь, перед вами. Мы поговорим с вами о преодолении недостатков у поставщиков. При этом под вендорами я имею в виду и поставщиков, и производителей программных продуктов. Сейчас поговорим о тех проблемах, с которыми мы сталкиваемся. 

Кто я такой, чем я занимаюсь? Я работаю на компанию OMNTI.

Я думаю, что мы известны, в основном, широкомасштабными вещами. Мы занимаемся данными терабайтных масштабов, высокими транзакциями. 

 

Но основной аспект – мы имеем дело с аспектами, критичными для выполнения миссий.

 

С точки зрения баз данных – инструменты, с которыми мы работаем. В основном, больше всего мы работаем с Postgres. Также мы делаем MySQL, Oracle, мы работали с SQL. Мы обладаем широким кругом знаний по разным направлениям. Иначе вы бы этого не увидели. 

 

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

Мы начнем с определения проблемы, которую нам приходится решать. Мы называем ее проблемой "расдувания" (англ. Bloat). В основном она касается баз данных. То, что там хранится, как правило, имеет критическое значение для производительности. 

Чем больший размер требуется для хранения данных, тем больше это сказывается на времени и объемах хранилища. Речь идет о том, сколько данных вы храните, сколько затрат по продукту баз данных. Если вы переходите от одной базы данных к другой (даже с тем же объемом данных), вы зачастую получаете разные размеры на диске, когда речь идет о разных проектах, потому что каждая база данных предполагает свои затраты. 

Р используется программой, "Раздувшиеся" данные используются базой, но для хранения они не нужны. Такая проблема есть в каждой базе данных. 

Можно сказать, что если вы разрабатываете базу данных, то, наверное, вы попытаетесь минимизировать затраты. Это верно. Соответственно, есть вопрос: почему возникает проблема "раздувания"?

Основная причина "раздувания" в том, что архитектура MVCC так настроена. Мы с вами еще поговорим об MVCC. Но основная идея заключается в том, что вы создаете систему, в которой возможна высокая конкурентность при чтении записи. Вот, собственно говоря, краткий обзор MVCC и ее целей. 

Для этого необязательно использовать Postgres. Можно применять и Oracle, и MySQL (в значительной мере). Представители "старой школы" говорят, что реализовывали разные версии MVCC, но не у всех одни и те же варианты. Postgres – это стандартная концепция, вполне нормальная в мире баз данных.

  

Это не просто старые проекты баз данных, которые используют MVCC. Если посмотреть на CouchDB, то они также внедряли архитектуру, основанную на MVCC, и у них та же проблема. 

 

Когда речь идет о "раздувании", то это не просто аспект того, что я реализовал MVCC – значит, у меня может быть проблема с "раздуванием". MongoDB может использоваться у вас в системе, когда вы обновляете данные, перезаписываете существующие данные. Даже в ходе обычного порядка действий некоторые обновления приводят к "раздуванию". Именно в результате этого дисковое пространство используется не только для хранения. 

Есть различные продукты. Будь то традиционная база данных или какие-то новые – разделенная, другая архитектура, MySQL-система, индексирование (у них свои данные, они должны управлять данными) – можно судить о том, насколько это зрелый продукт, по тому, как он работает с "раздуванием".

Первоначально из MongoDB брали данные и загружали в новый Mongo. В результате сокращалось дисковое пространство. Это не самое хорошее решение для чего бы то ни было, но это приходится делать. Команда MongoDB может это исправить, и продукт в результате этой ситуации улучшится.

Можно посмотреть на разные базы данных и сказать, есть ли у них проблема "раздувания" и как она решается. Если взять Lucen и Access, то там многое надо исправлять (многие с этим сталкивались). Или можно взять что-то такое, типа Hadoop или HDFS – здесь, насколько я понимаю, новое решение SQL. Есть файлы, которые передвигаешь внутрь, вовне, иногда собираются небольшие файлы, кладутся в один более крупный файл – и повышается производительность. Соответственно, в таких проектах дела с "раздуваниет" обстоят несколько лучше, но этим должна заниматься база данных. 

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

Но последние вещи по работе MVCC написал Брюс Момджиан (Bruce Momjian). Он, конечно, говорил бы о своей работе лучше и подробнее. Надеюсь, мне удастся рассказать вам то, что стоит знать, когда речь идет о "раздувании" в Postgres.

Основная идея в архитектуре MVCC в Postgres – то, что она поддерживает счетчики глобальных транзакций. Когда транзакция начинается, фактически там есть виртуальные ID транзакции, получаются реальные ID транзакции. Postgres "знает" место каждого подключения и сроки транзакций. Главным образом он отслеживает, какая транзакция сгенерировала те данные, которые он хранит на диске и в таблицах. Если эти данные нужно обновить, то он отслеживает, какая транзакция их удаляет. 

Использование таких счетчиков позволяет Postgres, с одной стороны, оставлять данные на диске, с другой стороны, следить за транзакциями, которые происходят в системе, и определять, что сколько места занимает на диске. То есть, есть возможность записывать новые строки с будущими счетчиками транзакций. Все существующие транзакции их еще не "видят", хотя они уже записаны на диски. По мере того как транзакции переходят по системе, трансгресс становится видимым для всех.

Основная цель: транзакция, читающая старую строку, не должна блокировать транзакцию от записи новой строки.

Представьте, что у меня есть строка в базе данных user_id x42. Эти данные записываются на диск, ставится маркер «транзакция № 32», например. Это и есть вставка. 

Что делает старый трансгресс? Он удаляет строку в транзакции 42. Если у транзакции 35 длинный лог, тогда Postgres может «посмотреть» на данные на диске и сказать: «Если вы посмотрите, что данные там живые, потому что № 35, и люди только после 38-ми поймут, что эти данные были удалены». Это работает достаточно хорошо для таких целей. 

На самом деле, те же самые идеи подходят для обновления данных. Здесь у нас пользователь X69, в сценарии обновления данные перезаписываются первоначально на 43, затем удаляются на 46-м, и по мере того как появляются новые данные, формируется блок, например, № 43. Вот вам и обновление. 

Что происходит потом? Вы берете эти версии на диске (старые, которые никто не видит) со своей маркировкой, потому что обновляется счетчик транзакций. Он по-прежнему остается на диске. 

В конечном счете появляется «мертвая строка», и никто эту строку на диске не увидит. Но старая строка по-прежнему остается там, с диска она не удалена. Все остальные посмотрят и увидят только новую строку, которая видима. Это компромисс, который был сделан разработчиками Postgres. Они оставляют старую строку на диске, а люди смотрят на новую строку.

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

Ведется огромное количество споров относительно того, как это делать. Если посмотреть на Oracle или ODB, они не используют MVCC. Они предпочитают делать построчную очистку по данным, не откладывая это на более поздний момент. Хотя SQL при таком раскладе вряд ли будет работать быстрее. Но не могу поспорить в случае с Oracle. 

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

Назову два основных способа, которыми решается проблема "раздувания". Первый. Здесь очищаются только N-строки. Берутся страницы в Postgres. При подчистке, если видна старая строка на этой странице, а в системе ее уже никому не видно, ставится маркировка. Следующая транзакция может заново перечитать это пространство. 

Что здесь еще интересного? Работа ведется только с обновлениями, если можно что-то отметить и переписать данные. Это работает достаточно хорошо, но только с обновлениями. 

Другой вариант пригодится вам, если вы будете работать с Postgres. Наверняка многие слышали про Vacuum. Это неблокирующая пакетная очистка, которая существует уже примерно 10 лет. Ее идея была предложена впервые еще в 1983-м году, первоначально это называлось Vacuum. Запускаете команду Vacuum, и она проделывает эту работу в фоновом режиме.

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

Что важно в процессе Vacuum? Тут возникают проблемы с восстановлением пространства. Если вы сделаете очень много удалений, и физически это окажется близко к концу файла на диске, то Vacuum не сможет восстановить это пространство. Но он может сделать это по остальным данным. Здесь начинают возникать проблемы.

Такие подходы к проблеме "раздувания" хороши. Они работают. 90 % проблем они позволят решить. В большинстве случаев, если вы работаете на версии 9.0 или 9.5, вам это подойдет. По мере увеличения масштаба вы поймете, что проблема с "раздуванием" будет вставать все острее, и этого уже будет недостаточно. 

Вот одна из проблем в случае со средством HOT. Она заключается в том, что здесь мы имеем дело только с обновлениями. Если вы проделываете, например, много вставок (вставляете данные), и непонятно, ограничения это, уникальные ключи или другие нарушения, то когда эта строка записывается на диск, там будет условие ошибки. Postgres запишет, что строка недействительна. Эту строку никто не будет видеть, но она по-прежнему остается на диске, ее надо будет очищать с помощью Vacuum, HOT и других средств. HOT, конечно, работает не во всех сценариях.

Есть еще одна проблема, когда вы меняете индексные данные. В этом случае возникает больше проблем, потому что это достаточно распространенная ситуация с обновлением данных. Что я имею в виду? Например, представьте себе таблицу, где у вас колонка со штампом времени и индекс, временной штамп. Вы ее отсканируете. Индексная таблица – единственная, в которой это хорошо получается. Возможно, есть и другие таблицы, где вы обновляете всю колонку с временными штампами. Postgres должен записать, что у вас есть информация в индексе, и перенести точку. На самом деле, он может сделать это в HOT, это нормально. Есть Vacuum – можно его использовать.

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

В подобных случаях Vacuum просмотрит все это: «Эта задача будет выполняться час. Я не могу маркировать это пространство так, будто его можно использовать». 

Что здесь еще важно? Vacuum требует ввода-вывода и может работать только с определенной скоростью. Возникает проблема с вводом-выводом. Чем медленнее работает вся система, тем медленнее работает Vacuum. Если это сделать в фоновом режиме, то можно обрабатывать и большие транзакции. Но будет тратиться много времени. В результате мы видим: при работе с Vacuum получается ситуация высокой точки (англ. High Water Mark).

Если происходит большое количество обновлений или удалений, то можно столкнуться с серьезной проблемой. Трудно совершенствовать этот процесс. Обрабатывая большие объемы данных, важно, чтобы не было блокировки. Поэтому многое выполняется на ходу. Но если мониторить систему, видно, что появляется "раздувание". 

Postgres позволяет нам решить эти задачи – VACUUM FULL и CLUSTER. Это хорошо работает, поскольку восстанавливается место в таблицах. После запуска все сокращается до необходимых размеров. 

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

Кроме того, это требует большого числа вводов-выводов. Это даже больше, чем обычный Vacuum. Необходимо большое рабочее пространство, чтобы все это осуществить. Поэтому нам часто звонят и говорят, что это занимает очень много времени. Проблема в том, что необходимо использовать Vacuum, чтобы действительно все это почистить. Но нет необходимого пространства. Это еще одна проблема, с которой можно столкнуться. Даже если ты выполняешь, это требует много времени. Собственно, если проблема становится слишком серьезной, ты используешь полный Vacuum.

Учитывая наличие проблем, мы уделили этому серьезное внимание. Каковы критерии того, что у нас проблемы с "раздуванием"? 

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

В нашем сообществе мы разработали два инструмента, чтобы проверить, какое количество "раздуваний" у нас есть и есть ли проблемы. Первый называется check_postgres. Это плагин. Он может мониторить одновременно 30-40 вещей, в частности, "раздувание". 

Как это работает? Плагин проверяет типы данных в строке, оценивает необходимые величины этих строк и потом сравнивает их с физическим размером на диске. Можно установить критический размер в 10 % или 15 %, и будет даваться соответствующее предупреждение. Это работает довольно хорошо. 

Наша группа не только консультирует, но и сама занимается этим. Иногда из-за проблемы "раздувания" приходится вставать в 2 часа ночи. Конечно, проверять систему рано утром не так приятно, поэтому мы создали еще один инструмент под названием bloat report. Он проверяет все таблицы и дает вам отчет, где говорится, например: «Мы считаем, таблица должна быть такой величины, надо сделать то-то и то-то, чтобы устранить проблему». Этот инструмент дает нам возможность посмотреть, "раздута" ли наша таблица и насколько серьезна эта проблема.

Благодаря отчетам, мы понимаем, что надо очистить нашу систему. Это позволяет прогнозировать, что может случиться. Можно предупредить ситуацию с "раздуваением". Используются предупредительные механизмы. Мы можем сказать клиенту: «Через месяц у вас возникнет проблема с "раздуванием"».

Мы решили разработать какие-то инструменты, которые помогут клиентам за этот период что-то сделать, чтобы решить проблему "раздувания". Собственно, у клиента проблемы могут возникать из-за того, что они что-то неправильно реализовали 10 лет назад. Накапливаются проблемы, ненужные данные, которые всегда надо подчищать. 

Мы разрабатывали этот инструмент почти год, проводили большое количество изменений. Первый, второй, третий релиз. Когда он вышел, работал довольно хорошо. Здесь было много работы. 

Что мы решили для себя? Есть решение? На самом деле, решения нет. Мы решили: «Давайте построим что-то для пользователей в порядке дополнения к нашим основным релизам». Может быть, это будет прототипом для дальнейших разработок. Что-то мы делаем, и у нас хорошие намерения относительно пользователей. 

Самый важный вопрос – сделать решение, которое было бы доступно для пользователей. Идея такая. Когда обновляется ряд, данные переписываются на новое место. Данные всегда записываются на новое место на диске. 

Мы подумали: мы можем избежать этого, если будем использовать Vacuum. 

Нужно запустить Vacuum и перемаркировать все строки в таблице, а потом перенести это в начало страницы. 

 

В результате мы можем обновить эту строку, затем еще раз обработать это Vacuum’ом, чтобы восстановить это пространство после окончания файла. 

 

Это была интересная идея, можно реализовать ее вручную и посмотреть, как это работает. Если мы увидим, что это работает, можно прописать скрипт. Это будет делаться автоматически. 

 

Мы пообщались с людьми, которые работают с Postgres, посмотрели, как это лучше сделать, чтобы решить проблему "раздувания". Написанный нами инструмент работает. Мы видели, что там тоже есть сложности. Во-первых, очистка занимает большое количество времени. Постоянные итерации, использование Vacuum тоже занимает время. Также мы увидели, что это увеличивает "раздувание" в случае с индексами. Когда обновляется данная таблица, индекс увеличивается. 

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

Мы решили, что это не лучшее наше решение. Мы нашли программу – pg_reorg. 

 

К сожалению, это малоизвестный инструмент, но при пользовании Postgres придется изучить его рано или поздно.

Что он делает? Создает замену Vacuum/Cluster.

Это инструмент командной строки. 

 

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

Этот инструмент разработан NTT. Это крупная телекоммуникационная компания, которая находится в Японии. Они занимаются Postgres очень долго. Это известная компания, я встречался с ее разработчиками. Впечатления хорошие. 

Сам инструмент имеет лицензию BSD и код на "Си". С этим кодом мы постоянно работаем, вполне нормально к этому относимся и знаем, как там что устроено. 

Не буду вдаваться в подробности. Принцип работы следующий. Создается лог-таблица для изменения, в изначальную таблицу вводятся соответствующие изменения, которые отслеживаются. Дальше создается новая таблица на основе выбора-запуска (англ. select-start) из старой таблицы. Создается совершенно новая таблица, но туда выводятся только видимые строки. Эта страница индексируется, берется лог этих изменений – то, что удалялось, заменялось и так далее. Модифицируются каталоги системы, и затем старая таблица устраняется, остается только новая.

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

Это вызывает озабоченность. Я видел, как это работает в рабочей среде. Устраняются некоторые ошибки, но при этом каталоги легко меняются – это не очень хорошо. 

С другой стороны, не так много других вариантов, поэтому мы изучаем возможности этого инструмента. Мы смотрим на исходный код, тестируем эту систему, этот инструмент, команды SQL. Можно оценить, как работает этот инструмент, полностью понять, чего этот инструмент способен достичь. Если он хорошо работает, то можно сказать: «Давайте этот инструмент в тестовый режим введем и посмотрим, каковы будут результаты». 

Первоначальное тестирование было очень простое. Создали какие-то таблицы, SQL. Для этих таблиц было сэмулировано искусственное "расдувание", после этого их "пропустили" через инструмент. Нужно было посмотреть, остались ли в силе эти данные. Оказалось, что после применения этого инструмента у нас остались данные хорошего качества. Результаты получились хорошие. 

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

Мы рекомендуем вам посмотреть всю вашу систему, проверить, какие ее части можно оптимизировать. Мы выбрали для себя соответствующие части, запустили pg_reorg – и все. 

Все продолжало работать. После этого мы применили наш инструмент к более широкой системе, и все работало. 

 

Тем не менее, даже такой инструмент надо использовать избирательно. Всегда надо применять его осторожно.

Посмотрим, каков размер системы, в которой мы это применяли. База данных – 540 гигабайт. Не пиковая нагрузка, мы не сошли с ума. В пиковой нагрузке мы не применяли этот инструмент. Там было где-то 2 тысячи транзакций в секунду в непиковое время. Выбор данных, запись данных и так далее. Так или иначе – 2 тысячи транзакций в секунду. Самая крупная таблица (pre-reorg) – 127 гигабайт. В этой базе были и очень крупные, и очень маленькие таблицы. 

Статистика - это первый результат применения. Мы создали список таблиц, наиболее проблемных в этом отношении. 6 часов заняла полная перестройка системы. Мы впервые работали по такой схеме. Мы все время перепроверяли, нормально все у нас функционирует или ненормально. Восстановили 52 гигабайта пространства на диске – примерно 10 %. При этом у нас не было сбоев.

 

Приведу график, который показывает, как все выглядело до применения reorg. Там, где идет перепись таблиц, мы видим пики. Поднимается – падает. Результат хороший. 

Только убедившись, что это работает нормально, мы начали применять это на других системах. 

Вот как "раздувание" таблиц устраняется в одной системе. Мы смотрим, как это развивалось с течением времени. 

Это работает хорошо.

Мы начали проверять работу кода NTT и решили, что, допустим, мы им доверяем, но при этом надо перепроверять. Начали тестировать в тестовой среде, проводили испытания в рабочей среде. 

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

Мы видим, что некие заказы не выполняются. Хорошо, что система дает такие предупреждения. Но я плохо реагирую, когда вижу предупреждения (причем предупреждение, которое я раньше никогда не видел, а Postgres я использую 10 лет). У нас тысячи заказов в секунду, и мы видим, что система может выйти из строя.

Начали разбираться и увидели, в чем была проблема. 

 

Есть такая таблица – три колонки. Теперь смотрим на трансгресс внутри. Что здесь интересно? Что-то может пойти не так. Информация зависит от положения в колонке, а не от названия колонки. Соответственно, я вижу ошибку в колонке "2", а не в колонке "b". 

Можно опустить колонку "a". Потом pg_reorg воссоздает таблицу, он воссоздает ее только с "b" и "c". Это означает, что теперь колонки перемещены. Нумерация другая. У нас остается по умолчанию 2112 на колонке "c", которая теперь колонка "2". Это не очень хорошая колонка для умолчания. Вот основная проблема, которую мы видим у нас в продакшне. 

Я хочу отметить, что все это относится именно к pg_reorg. Здесь у нас системные каталоги. Мы, по сути, говорим: «Спасибо за гарантии, за безопасность, но мы их будем игнорировать и поступать по-своему». Поэтому в этом сценарии все может получиться не так. Система, может быть, полностью не "упадет", но заказы будут пропускаться, и пользователи будут недовольны. В результате у нас ушло определенное время на то, чтобы со всем этим разобраться. 

Что мы сделали в итоге? Эта система достаточно быстро работает в Postgres. 

Есть альтернативный вариант решения – это хакинг системного каталога, там все можно решить достаточно просто. 

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

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

Postgres смотрит и говорит: «Именно поэтому мы вам и говорили, что не нужно использовать каталоги». Мы предложили им патч (это, собственно, был не наш патч). Они решили эту проблему следующим образом – все это запустить в pg_org. Но в результате все были довольны. Есть инструмент, который работает. Он работает лучше, чем раньше.

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

Тут, конечно, многое предстоит сделать. Я думаю, что многое справедливо. Может быть, не все сталкиваются с такими проблемами. Если вы начинаете пользоваться Postgres, у вас 100 транзакций в секунду. Это может быть не так страшно. Проблема возникает не всегда. 

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

Я надеюсь, что это все-таки произойдет, но до тех пор pg_reorg – прекрасный инструмент, лучший вариант из всех, которые есть для трудных ситуаций. Но всякий раз нудно смотреть. В данном случае мы ждем, чтобы поставщик, производитель Postgres все-таки исправил эту проблему. Мы пока будем искать обходные пути, чтобы выходить из ситуации по мере возможности. Будьте осторожны.

Это все. Теперь я мог бы ответить на ваши вопросы.

Вопросы и ответы

Вопрос из зала: Спасибо за интересное выступление. Я хотел бы вернуться к вопросу решения NoSQL, которое вы упоминали. Но я не совсем уверен, что все, что вы говорили, относится к этому. Вы говорили в блоке проблем MVCC, который, по-моему, не существует в решениях NoSQL. Вы также упоминали "раздувание" на HTFS как проблему небольших файлов. 

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

Robert Treat: Вопрос в том, можно ли здесь использовать NoSQL-решения. MVCC используется очень часто, и при этом возникали огромные проблемы с "раздуванием" данных. Что касаетсяMongoDB, то они не используют MVCC. Тем не менее, у них те же самые проблемы. 

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

Но для меня это немасштабируемые решения, которые вряд ли будут полезными при более высоком уровне активности. Не все они представляют "раздувание" так же, как Postgres. Couch, Mongo и другие – у них возникают свои проблемы. Если представить себе "раздувание" в более общем плане, когда не эффективно использовать ресурсы, то проблемы будут отличаться. Но все-таки что-то здесь есть.

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

Robert Treat: Хороший вопрос. В этом случае мы возвращаемся к пределам оперативной памяти. Если там 3 мегабайта оперативной памяти, то можно и больше, если больше таблиц. Но если они совсем маленькие, то о них и беспокоиться не стоит. 

Я бы сказал, что в нашем случае мы очень агрессивно мониторим "раздувание", чтобы не генерировались отчеты при "раздувании". Но основная моя идея заключается в том, что если можно получить 10 % повышения производительности или на 10 % увеличить возможности моей системы просто за счет онлайн-операции, то я бы, наверное, это сделал. Более того, я бы делал это каждый день, чтобы заработать такой бонус. Если, конечно, я знаю, что инструмент работает.

Вопрос из зала: Почему вы не назвали свою презентацию «Раздувание в PostgreSQL»?

Robert Treat: Начальник дал мне заголовок и сказал: «Напиши что-нибудь на эту тему и обязательно скажи там про "раздувание"». Поэтому получилась такая презентация. Я надеюсь, что эти идеи применимы, когда вы будете разрабатывать собственные инструменты и решать возникающие проблемы.

Вопрос из зала: Вы можете дать рекомендации по поводу того, как свести к минимуму необходимость использования Vacuum для таблиц при написании запросов в логике приложений? Может быть, что-то более агрессивное?

Robert Treat: Я бы рассказал, что, например, делаем мы. Мы меняем умолчания в Postgres и делаем их более агрессивными. 20 % "раздувания" для мониторинга, например. Мы пытаемся эту планку опустить до 10 % и иногда даже до 5 %. Так что, корректируя параметры Vacuum, можно повысить агрессивность. Еще можно, например, понять, какая у вас рабочая нагрузка вызывает "раздувание", какие инструменты здесь пригодятся.

Очень простой пример. Можно взять пакетное удаление данных или разделение секций, или операции без секционирования. Вообще говоря, Postgres очень сильно зависит от приложений. В идеале, конечно, возможны варианты, когда Postgres автоматически подчищает вашу систему. Рано или поздно это будет, но пока проблема находится здесь. Если есть какие-то хорошие решения, то надо их использовать. 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Денис Бирюков

Денис Бирюков

Ведущий инженер программист в компании "Каванга".

Доклад об особенностях хранения данных пользователей баннерной системы.

Михаил Волович

Михаил Волович

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

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

Алексей Рыбак

Алексей Рыбак

Ex-глава разработки Badoo.

Алексей Рыбак (Badoo) перечисляет общедоступные инструменты и сервисы, созданные специалистами Badoo, а также рассказывает о принципах их работы и примерах применения.