И все же, какого ресурса вам не хватает (ЦПУ, диск, память)?
Количество сегментов обычно увеличивают, если недостаточно утилизирован ЦПУ. В вашем же случае (ETL и пользователи), вряд ли вы недостаточно его утилизируете. Вообще единственная причина, почему на одном хосте более одного сегмента в GP - это отсутствие хорошо работающего параллельного сканирования в рамках одного сегмента. В PG для этого поднимаются фоновые процессы, GP использует пул соединений от координатора к сегменту. Если научить GP хорошо утилизировать ЦПУ при сканировании, получится уйти от кучи сегментов на хосте. Но повторюсь, недостаточная утилизация - явно не ваш случай.
Поэтому и вопрос - что вам мешает настроить ресурсные группы и разложить ETL и пользователям по разным коробкам? Там же куча возможностей для этого, вплоть до резервирования конкретных ядер ЦПУ под конкретную группу. Вместо этого два кластер - почему?
А за какие ресурсы идет конкуренция, что приходится делать два кластера и экспортировать из ETL в пользовательский кластер? На первый взгляд, если это ЦПУ, то есть ресурсные группы. Если диск, то вы можете разносить схемы сырых данных и витрин по разным табличным пространствам на разные диски. Память тоже делится через менеджер памяти (настраивается через те же ресурсные группы). Нехватка соединений решается пулером.
Я просто сильно удивился фразе «что на GreenPlum считалось часами, мы могли уже считать на потоке с помощью Flink, еще и в режиме near-realtime». У меня возникло подозрение, что причина была именно заливке данных через координатор, которая крайне медленно работает и сильно утилизирует ресурсы кластера. Я правильно понимаю, что вы добавили Flink и свертку данных на нем, чтобы координатор не захлебывался (меньше льем)? И так вам было сделать проще, чем научить сегменты забирать данные из Кафки?
А вы из Flink льете в S3 и оттуда забираете через CH и GP? Или одной рукой льете в S3 для CH, а второй вставляете в GP? Если второе, то в GP у вас вставка через координатор, или вы написали свой коннектор под GP для вставки через сегменты?
Без S3 Select (при том желательно с поддержкой SIMD/SSE для фильтрации) вы не построите эффективное разделение слоя хранения (S3) и слоя вычислителей (Greenplum). И все данные будете лить через PXF и фильтровать их узлами Greenplum, что неэффективно.
Там помимо фамилии есть имя и отчество. А в реальном продукте ещё и куча других параметров. Но если предложите методику испытаний для оценки качества поиска, я прогоню. И, кстати, буду благодарен за такой алгоритм.
Рассматривался, пока не увидел алгоритм русского Метафона. Я его посмотрел и он показался мне вполне логичным в плане нивелирования ошибок, плюс его тестировали в бою. А транслитерация и последующая обработка фонетическими алгоритмами показалась мне чересчур сложной и потенциально дающей больше ошибок. Но я не тестировал.
Чтобы просто разрезать на лексемы без модификаций — это более простой аналог регуляризация по пробелам. А russian может для ряда фамилий убрать окончания или увидеть в них стоп-слова
Автор не потерял в качестве, информация из первых рук. Во всех выборках возвращалось менее 10 результатов при лимите в 10.
Кстати, то количество строк для разных выборок, которе вы написали, не имеет отношения к результатам. Это количество строчек в выводе плана explain (analyze, buffers) — можете сами посчитать))
Отлично, время создания индекса уменьшилось на 40%, размер почти такой же (разница в 1 Мб — думаю, тут случайный фактор как расщеплялись странички при создании индекса), скорость поиска аналогичная.
Я вначале тоже думал транслитерировать имена в индекс и дальше использовать того же Дейча-Мокотоффа или двойной Метафон. Но нашёл на хабре ту забавную реализацию русского Метафона и был приятно удивлён ее селективностью. Так что дополнительный оверхед не городил. А вот у вас интересный опыт был, может расскажете в статье и с подробностями?)
А проводилось сравнение по скорости и компрессии между плагином dd boost и встроенными zstd/gzip в gpbackup? Можете рассказать про результаты?
На самом деле исправление было сразу портировано во все стабильные версии pg. Вот, например, коммит для 9.6.
И все же, какого ресурса вам не хватает (ЦПУ, диск, память)?
Количество сегментов обычно увеличивают, если недостаточно утилизирован ЦПУ. В вашем же случае (ETL и пользователи), вряд ли вы недостаточно его утилизируете. Вообще единственная причина, почему на одном хосте более одного сегмента в GP - это отсутствие хорошо работающего параллельного сканирования в рамках одного сегмента. В PG для этого поднимаются фоновые процессы, GP использует пул соединений от координатора к сегменту. Если научить GP хорошо утилизировать ЦПУ при сканировании, получится уйти от кучи сегментов на хосте. Но повторюсь, недостаточная утилизация - явно не ваш случай.
Поэтому и вопрос - что вам мешает настроить ресурсные группы и разложить ETL и пользователям по разным коробкам? Там же куча возможностей для этого, вплоть до резервирования конкретных ядер ЦПУ под конкретную группу. Вместо этого два кластер - почему?
А за какие ресурсы идет конкуренция, что приходится делать два кластера и экспортировать из ETL в пользовательский кластер? На первый взгляд, если это ЦПУ, то есть ресурсные группы. Если диск, то вы можете разносить схемы сырых данных и витрин по разным табличным пространствам на разные диски. Память тоже делится через менеджер памяти (настраивается через те же ресурсные группы). Нехватка соединений решается пулером.
Я просто сильно удивился фразе «что на GreenPlum считалось часами, мы могли уже считать на потоке с помощью Flink, еще и в режиме near-realtime». У меня возникло подозрение, что причина была именно заливке данных через координатор, которая крайне медленно работает и сильно утилизирует ресурсы кластера. Я правильно понимаю, что вы добавили Flink и свертку данных на нем, чтобы координатор не захлебывался (меньше льем)? И так вам было сделать проще, чем научить сегменты забирать данные из Кафки?
А вы из Flink льете в S3 и оттуда забираете через CH и GP? Или одной рукой льете в S3 для CH, а второй вставляете в GP? Если второе, то в GP у вас вставка через координатор, или вы написали свой коннектор под GP для вставки через сегменты?
Без S3 Select (при том желательно с поддержкой SIMD/SSE для фильтрации) вы не построите эффективное разделение слоя хранения (S3) и слоя вычислителей (Greenplum). И все данные будете лить через PXF и фильтровать их узлами Greenplum, что неэффективно.
А реализация S3-совместимого хранилища в облаке КРОК поддерживает S3 Select? И, если не секрет, какое вы используете решение для хранения в S3?
Замечу, что всех описанных в статье страданий можно было избежать, просто посмотрев битую страницу через расширение pageinspect (https://www.postgresql.org/docs/current/pageinspect.html)
Рассматривался, пока не увидел алгоритм русского Метафона. Я его посмотрел и он показался мне вполне логичным в плане нивелирования ошибок, плюс его тестировали в бою. А транслитерация и последующая обработка фонетическими алгоритмами показалась мне чересчур сложной и потенциально дающей больше ошибок. Но я не тестировал.
Чтобы просто разрезать на лексемы без модификаций — это более простой аналог регуляризация по пробелам. А russian может для ряда фамилий убрать окончания или увидеть в них стоп-слова
Автор не потерял в качестве, информация из первых рук. Во всех выборках возвращалось менее 10 результатов при лимите в 10.
Кстати, то количество строк для разных выборок, которе вы написали, не имеет отношения к результатам. Это количество строчек в выводе плана explain (analyze, buffers) — можете сами посчитать))