SQL Server для PostgreSQL - проблемы миграции и проектирования - PullRequest
Новая
       28

SQL Server для PostgreSQL - проблемы миграции и проектирования

1 голос
/ 26 октября 2009

В настоящее время мигрирует с SQL Server на PostgreSQL и пытается улучшить пару ключевых областей:

У меня есть таблица статей: 

CREATE TABLE [dbo].[Articles](
    [server_ref] [int] NOT NULL,
    [article_ref] [int] NOT NULL,
    [article_title] [varchar](400) NOT NULL,
    [category_ref] [int] NOT NULL,
    [size] [bigint] NOT NULL
)

Данные (текстовые файлы с разделителями-запятыми) ежедневно выгружаются на сервер импорта ~ 500 (из ~ 1000) серверов ежедневно.

Импорт:

  • Индексы в таблице статей отключены.
  • Для каждого сброшенного текстового файла
    • Данные скопированы во временную таблицу.
    • Временная таблица обновлена.
    • Старые данные для сервера удаляются из таблицы «Статьи».
    • Данные временной таблицы копируются в таблицу статей.
    • Временная таблица отброшена.

После завершения этого процесса для всех серверов создаются индексы и новая база данных копируется на веб-сервер.

Я довольно доволен этим процессом, но всегда есть возможности для совершенствования, так как я стремлюсь к системе реального времени (хаха!). Что я делаю правильно? Таблица Статей содержит ~ 500 миллионов записей и, как ожидается, будет расти. Поиск по этой таблице в порядке, но может быть лучше. то есть SELECT * FROM Articles WHERE server_ref=33 AND article_title LIKE '%criteria%' было удовлетворительным, но я хочу улучшить скорость поиска. Очевидно, что «как» моя проблема здесь. Предложения? SELECT * FROM Articles WHERE article_title LIKE '%criteria%' ужасно.

Секционирование - это особенность SQL Server Enterprise, но $$$, которая является одной из многих интересных перспектив PostgreSQL. Какое снижение производительности произойдет для процесса импорта (удаление данных, вставка данных) и построения индексов? Вырастет ли база данных на огромную сумму?

База данных в настоящее время составляет 200 ГБ и будет расти. Копирование этого по сети не идеально, но это работает. Я вкладываю мысли в изменение структуры оборудования системы. Мысленный процесс наличия сервера импорта и веб-сервера таков, что сервер импорта может выполнять грязную работу (без индексов), в то время как веб-сервер (с индексами) может представлять отчеты. Возможно, сокращение системы до одного сервера поможет пропустить копирование через сетевой этап. Этот один сервер будет иметь две версии базы данных: одну с индексами для доставки отчетов, а другую без импорта новых данных. Базы данных будут меняться ежедневно. Мысли?

Это фантастическая система, и, поверьте или нет, есть какое-то средство для моего безумия, которое сильно встряхнуло.

ОБНОВЛЕНИЕ: Я не ищу помощи по реляционным базам данных, но надеюсь обмениваться идеями с экспертами хранилищ данных.

1 Ответ

1 голос
/ 27 октября 2009

Я не эксперт по хранилищу данных, но несколько советов.

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

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

  1. создать новую таблицу для хранения данных.
  2. используйте COPY для массовой загрузки данных в таблицу.
  3. создайте все необходимые индексы и выполните любую необходимую обработку.
  4. В транзакции удалите старый раздел, переименуйте новую таблицу и добавьте ее как раздел.

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

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

Чтобы ускорить поиск текста, используйте полнотекстовый индекс GIN, если ограничения допустимы (поиск возможен только на границах слов). Или индекс триграмм (предоставляется модулем расширения pg_trgm ), если вам нужно искать произвольные подстроки.

...