Комментарии 19
Код можно обернуть тегом
<source lang="язык">
В итоге, немного покопавшись в интернете, необходимого фришного ПО для тестирования не нашлось.JMeter. То что не реализуется стандартными средствами, всегда можно реализовать самому. В любом случае быстрее, чем писать всё с нуля и отлаживать еще инструмент.
> Заполнение таблицы было сделано через процедуру (время на заполнение 100 млн записей составило 7 часов)
Если действия выполнялись в той же последовательности, что и описаны (создание таблицы, создание индексов, заполнение таблицы), то советую сначала занести данные, а потом создавать индексы. Так общее время может существенно сократиться. Если ещё и сделать все эти операции в одной транзакции, можно ещё немного ускорить дело.
Если действия выполнялись в той же последовательности, что и описаны (создание таблицы, создание индексов, заполнение таблицы), то советую сначала занести данные, а потом создавать индексы. Так общее время может существенно сократиться. Если ещё и сделать все эти операции в одной транзакции, можно ещё немного ускорить дело.
После нескольких попыток с разными объемами, как раз пришел к такому выводу. Время заполнения 7 часов это как раз с пересозднием индексов после заливки данных.
Если не секрет, какая была конфигурация тестовой машины и значение параметра checkpoint_segments?
А зачем нужна функция?
Я для тестирования на ноуте заливаю 10 млн записей за несколько минут вот таким образом. Про создание индексов после заливки вам уже написали. Btree использует оптимизацию в этом случае, для лучшей оптимизации увеличьте maintenance_work_mem, скажем до 256MB. Ну и в лог надо глянуть, вдруг там варнинг про checkpoint_segments идет, как вам smagen написал. На самом деле, вам нужно привести полный postgresql.conf, конечно, чтобы мы не гадали. Кстати, опыт тестирования показывает, что случайные данные часто не имеют ничего общего с реальными, так что вам нужно дописать софтину, чтобы она могла проигрывать реальные запросы на реальных данных.
Я для тестирования на ноуте заливаю 10 млн записей за несколько минут вот таким образом. Про создание индексов после заливки вам уже написали. Btree использует оптимизацию в этом случае, для лучшей оптимизации увеличьте maintenance_work_mem, скажем до 256MB. Ну и в лог надо глянуть, вдруг там варнинг про checkpoint_segments идет, как вам smagen написал. На самом деле, вам нужно привести полный postgresql.conf, конечно, чтобы мы не гадали. Кстати, опыт тестирования показывает, что случайные данные часто не имеют ничего общего с реальными, так что вам нужно дописать софтину, чтобы она могла проигрывать реальные запросы на реальных данных.
create table qq as select point( p.lat, p.long) as p
from (
select (0.5-random())*180 as lat, random()*360 as long
from generate_series(1,10000000)
) as p;
'
Кстати, опыт тестирования показывает, что случайные данные часто не имеют ничего общего с реальными
Абсолютно согласен, мало того даже верные данные ничего не дадут, если не будет полноценной рабочей нагрузки — например, насколько будет дегрейд при различных инсертах, больших сортировках и хэш/мердж джойнах, нестед лупсах
postgresql.conf не изменялся после установки, пример тут www.2shared.com/file/zJdnf6lH/postgresql.html
На счет запроса для заполнения таблицы — спасибо, учту на будущее!
На счет запроса для заполнения таблицы — спасибо, учту на будущее!
Расширил набор типов — date, string_line, text.
Можно организовывать тестирование как SELECT'ы, так и INSERT'ы. Сегодня попробовал многопоточное заполнение базы, тоже интересные результаты. Результаты опубликую завтра.
Можно организовывать тестирование как SELECT'ы, так и INSERT'ы. Сегодня попробовал многопоточное заполнение базы, тоже интересные результаты. Результаты опубликую завтра.
В статье нет заключения. К какому выводу относительно первого поставленного вопроса (oracle vs postgresql) пришел автор?
И где файл конфигурации postgres? Без него результаты тестов непонятны.
PS: Выбор субд во многих случаях определяется наличием специалистов или возможностью их привлечь/вырастить. Oracle в этом последнем случае более предпочтителен, т.к. у него есть явная стратегия повышения квалификации (курсы, система сертификации и т.д.).
И где файл конфигурации postgres? Без него результаты тестов непонятны.
PS: Выбор субд во многих случаях определяется наличием специалистов или возможностью их привлечь/вырастить. Oracle в этом последнем случае более предпочтителен, т.к. у него есть явная стратегия повышения квалификации (курсы, система сертификации и т.д.).
Наверно многие видели презентации по ораклу и mssql, типа на «нашем движке работают такие-то большие банки», «объемы баз десятки-сотник террабайт...» и т.д., и сразу думаешь — «Вот это круто!!!». Но это все платные, причем не дешевые СУБД, а как на счет бесплатных движков?
И я давно хотел протестировать постгрес при работе с большими массивами информации (в будущем еще можно и mysql тоже протестировать). Почему постгрес? Потому что он бесплатен и при разработке постгреса принимали участие разработчики из оракла (если я ничего не путаю), и другие субъективные причины. Ответ на вопрос «Что круче? Оракл/MSSQL или Постгрес на таком-то объеме данных?» я для себя получил (причем не просто выдержки из переписки на форумах, а действительно результаты тестов). По сути, на таких объемах обе базы адекватны в работе. Выбор СУБД уже должен приниматься из других соображений (создание или перенос функционала на сторону СУБД, «железные» ресурсы, «финансовые» ресурсы, опять же наличием специалистов, или же просто политические).
И я давно хотел протестировать постгрес при работе с большими массивами информации (в будущем еще можно и mysql тоже протестировать). Почему постгрес? Потому что он бесплатен и при разработке постгреса принимали участие разработчики из оракла (если я ничего не путаю), и другие субъективные причины. Ответ на вопрос «Что круче? Оракл/MSSQL или Постгрес на таком-то объеме данных?» я для себя получил (причем не просто выдержки из переписки на форумах, а действительно результаты тестов). По сути, на таких объемах обе базы адекватны в работе. Выбор СУБД уже должен приниматься из других соображений (создание или перенос функционала на сторону СУБД, «железные» ресурсы, «финансовые» ресурсы, опять же наличием специалистов, или же просто политические).
Вот как раз специалистов по постгресу довольно много в России, да и выучить достаточно легко — отправить на sql.ru, например :) Я и Федя Сигаев, а недавно появился Саша Коротков (надеюсь, что не бросит), в состоянии решать практически любые задачи на постгресе. Можно спросить Мишу Тюрина из avito.ru насчет производительности постгреса, это реальные 24x7 сервис.
МТС, я угадал?
Я как-то написал на перле скрипт, который форкает детей, каждый из которых напрягает базу запросами и отправляет тайминги родителю, который их агрегирует и выдает на stdout каждые сколько-то запросов. Для тестирования задается пропорции insert:delete:select:vacuum, чтобы как-то моделировать ситуацию. Софтину писал для себя, как-то работает, кто-бы генерализовал ее, цены не было бы :)
Хм, пара замечаний.
Для заливки данных почитайте про COPY и pg_restore, как вариант шапку из результата pg_dump'a — можно значительно ускорить загрузку отключив несколько параметров, не создавая индексов, много данных в одной транзакции (множественный инсерт порядка тысячи записей или банальный COPY) Ну и несколько коннектов… Но это для многоядерных машинок.
Ну и практика показывает что результаты тестов имееют очень мало схожего с реальной нагрузкой. Например у вас может быть идеальный отклик пока все (или хотябы индекс) помещается в шарной памяти, но затем единственный запрос SELECT * FROM толстая_таблица вытесняет все из буффера и просаживает io ниже плинтуса.
Или все хорошо и великолепно но затем «идеальный индекс» распухает до невозможных размеров перестает помещаться в память и привет. Причем разница измерения показателей (например транзакций в секунду) может быть на несколько порядков ( я не шучу вместо 10 тысяч вставок в секунду довольно резко проседаем до нескольких десятков вставок). При этом постгрес достаточно сильно оптимизирован. Поэтому все может быть очень хорошо даже с запасом, но по определенному закону у кастомера набор данных будет как раз тем единственным который максимально деградирует БД.
Так что тестируйте, тестируйте, тестируйте… но Еще больше анализируйте, и анализируйте.
Я например вообще склонен отказаться от оценок прямых результатов, в сторону оценок влияния нагрузки на систему. Например не время отклика на запрос, а утилизация системы при таком то числе запросов.
Ну и повторюсь любые тесты это синтетика. А никакая синтетика так не нагнет сервер как единственный кривой запрос кастомера. :)
Для заливки данных почитайте про COPY и pg_restore, как вариант шапку из результата pg_dump'a — можно значительно ускорить загрузку отключив несколько параметров, не создавая индексов, много данных в одной транзакции (множественный инсерт порядка тысячи записей или банальный COPY) Ну и несколько коннектов… Но это для многоядерных машинок.
Ну и практика показывает что результаты тестов имееют очень мало схожего с реальной нагрузкой. Например у вас может быть идеальный отклик пока все (или хотябы индекс) помещается в шарной памяти, но затем единственный запрос SELECT * FROM толстая_таблица вытесняет все из буффера и просаживает io ниже плинтуса.
Или все хорошо и великолепно но затем «идеальный индекс» распухает до невозможных размеров перестает помещаться в память и привет. Причем разница измерения показателей (например транзакций в секунду) может быть на несколько порядков ( я не шучу вместо 10 тысяч вставок в секунду довольно резко проседаем до нескольких десятков вставок). При этом постгрес достаточно сильно оптимизирован. Поэтому все может быть очень хорошо даже с запасом, но по определенному закону у кастомера набор данных будет как раз тем единственным который максимально деградирует БД.
Так что тестируйте, тестируйте, тестируйте… но Еще больше анализируйте, и анализируйте.
Я например вообще склонен отказаться от оценок прямых результатов, в сторону оценок влияния нагрузки на систему. Например не время отклика на запрос, а утилизация системы при таком то числе запросов.
Ну и повторюсь любые тесты это синтетика. А никакая синтетика так не нагнет сервер как единственный кривой запрос кастомера. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Создание тестера для нагрузочного тестирования PostgreSQL