Просто поразительно. Я пришел прочитать статью по ссылке из телеги и украсть пару идей для нашей документации. Прошелся по ссылкам, не нашел команд (а мне хотелось посмотреть, как это сделано у вас), подсветил проблему, которой уже года четыре как минимум. В результате получил порцию токсичности от тебя на ровном месте. В общем, так себе опыт.
Дима, я действительно хочу подсветить проблему. Просто вспомни, что произошло с конверсией сайта документации PostgresPro, когда они завершили перевод PostgreSQL - им никакой СЕО не нужен после этого. Ну и став первыми с русской документацией вы автоматически становитесь стандартом и определяете терминологическую базу во всей русскоговорящей среде. Да, кстати, если будете делать, я рекомендую посмотреть на пример SQLite с их railroad диаграммами синтаксиса.
Подскажите, а когда у вас появится для ADB список SQL команд? Пока есть только ссылка на документацию VMware в загадочном разделе «список команд SQL, не поддерживаемых в ADB».
И все же, какого ресурса вам не хватает (ЦПУ, диск, память)?
Количество сегментов обычно увеличивают, если недостаточно утилизирован ЦПУ. В вашем же случае (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 может для ряда фамилий убрать окончания или увидеть в них стоп-слова
А вы сравнивали скорость чтения из АОС таблиц с BRIN индексом против Parquet файлов с bloom фильтрами (через FDW)?
Просто поразительно. Я пришел прочитать статью по ссылке из телеги и украсть пару идей для нашей документации. Прошелся по ссылкам, не нашел команд (а мне хотелось посмотреть, как это сделано у вас), подсветил проблему, которой уже года четыре как минимум. В результате получил порцию токсичности от тебя на ровном месте. В общем, так себе опыт.
Дима, я действительно хочу подсветить проблему. Просто вспомни, что произошло с конверсией сайта документации PostgresPro, когда они завершили перевод PostgreSQL - им никакой СЕО не нужен после этого. Ну и став первыми с русской документацией вы автоматически становитесь стандартом и определяете терминологическую базу во всей русскоговорящей среде. Да, кстати, если будете делать, я рекомендую посмотреть на пример SQLite с их railroad диаграммами синтаксиса.
P.S. Будь менее токсичным, пожалуйста.
Подскажите, а когда у вас появится для ADB список SQL команд? Пока есть только ссылка на документацию VMware в загадочном разделе «список команд SQL, не поддерживаемых в ADB».
А проводилось сравнение по скорости и компрессии между плагином 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 может для ряда фамилий убрать окончания или увидеть в них стоп-слова