Nano Hash - криптовалюты, майнинг, программирование

написать масштабирование postgresql

У меня есть очень ориентированное на запись приложение, которое использует postgres hstore. мой типичный рабочий процесс - это SELECT, за которым следует несколько UPDATE или INSERT (в основном первые). Обычно это происходит при выполнении около 500 «задач» в секунду.

поэтому мой единственный экземпляр postgres просто не справляется. я вижу, что сервер postgres привязан к процессору, а процессы postgres все время UPDATEing. Дисковый ввод-вывод выглядит нормально, и у меня много свободной памяти (44 ГБ из 48). я пытался настроить в соответствии с вики-страницей postgres и pg_tune, но мне просто нужно немного больше производительности .

мои таблицы следуют следующему дизайну:

   Column   |           Type           |                              Modifiers                              | Storage  | Stats target | Description
------------+--------------------------+---------------------------------------------------------------------+----------+--------------+-------------
 id         | integer                  | not null default nextval('table_id_seq'::regclass) | plain    |              |
 created_at | timestamp with time zone | not null                                                            | plain    |              |
 updated_at | timestamp with time zone | not null                                                            | plain    |              |
 context    | hstore                   | default hstore((ARRAY[]::character varying[])::text[])              | extended |              |
 data       | hstore                   | default hstore((ARRAY[]::character varying[])::text[])              | extended |              |

и почти все мои UPDATE относятся к типу:

UPDATE <table> updated_at=<date> WHERE id=<id>

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

что бы вы порекомендовали для моего (довольно упрощенного) рабочего процесса?

(и да, я пробовал монго, однако я скучаю по схемам запросов SQL)

postgresql scaling hstore postgresql-9.2
28.02.2013

  • Я думаю, что postgres-r еще не закончен — определенно не готов к производству. Итак, у вас остается postgres-xc. Другими вариантами могут быть Bucardo или PL/proxy (что в основном представляет собой ручное сегментирование через PL/pgSQL). 28.02.2013
  • Попробуйте задать вопрос в списке pgsql-performance, вы получите более подробные подсказки для вашего конкретного случая. . Но вы также должны предоставить более подробную информацию, а не простое «просто не могу справиться». 28.02.2013
  • Подробности пожалуйста. EXPLAIN (BUFFERS, ANALYZE) релевантных запросов и покажите типичный пакет с SELECT и последующими обновлениями. В общем, постарайтесь сократить круговые обходы, старайтесь делать больше в БД и делать меньше крупных транзакций. 28.02.2013
  • В дополнение к вопросам Крейга, пожалуйста, добавьте сведения об оборудовании. Сколько процессоров? Какой тип? Сколько ядер? Hyper Threading? Это особенно важно при рассмотрении вопросов параллелизма и производительности процессора. 30.04.2013

Ответы:


1

Во-первых, я думаю, вам нужно быть более конкретным. Настройка производительности очень ориентирована на факты, и без большого количества деталей (объяснение планов и т. д.), информации о вашем оборудовании и т. д. мы не можем сказать вам, что делать. Кроме того, что-то вроде Postgres-XC добавляет много сложности, хотя и помогает с производительностью записи. Я думаю, что это поможет в вашем случае, но вы действительно хотите сначала оптимизировать то, что у вас есть (и, возможно, нанять кого-то, чтобы оптимизировать это для вас).

Однако в вашем посте есть несколько предупреждающих знаков (это еще одна причина, по которой я думаю, что нанять профессионала может быть хорошей идеей). Не зная больше, я не могу сказать вам, является ли Postgres-XC правильным решением или нет. Что я могу вам сказать, так это то, что у вас будет крутая кривая обучения, внедряющая его.

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

  1. i see that the postgres server is cpu bound and the postgres processes are UPDATEing all the time. Скорее всего, это вызвано слишком большим количеством конфликтов за семафоры и разделяемую память. Вы, вероятно, обнаружите, что если вы уменьшите максимальное количество подключений, вы будете обрабатывать больше в секунду. Пул соединений может помочь.

  2. Все ваши интересные данные находятся в расширенном хранилище. Это означает дополнительный произвольный дисковый ввод-вывод при хранении и извлечении. Если вы не выполняете много последовательных сканирований таблиц, вы должны позволить PostgreSQL решить, что делать с TOAST.

  3. Я называю вздором ваше утверждение о том, что большинство утверждений похожи на UPDATE <table> updated_at=<date> WHERE id=<id>, поскольку, вероятно, очень мало причин записывать строку как обновленную, когда вы не обновляете данные. Вероятно, здесь происходит что-то еще. Я предполагаю, что у вас есть много запросов, обновляющих материал в расширенном хранилище. Это может не иметь большого значения с точки зрения производительности, поскольку вы не привязаны к вводу-выводу, но это связано с накладными расходами как с ЦП, так и с дисковым вводом-выводом.

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

02.05.2013
Новые материалы
Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..