К сожалению, эта ветка появляется первой на запрос, как установить установить columnstore postgresql, однако ничего полезного не написано.

Ветку в GitHub любой школьник может нагуглить за 5 секунд, но что с ней делать неясно. К тому же всё только на английском.

Собственно два конкретных вопроса для тех, кто в теме:
1. Там первым делом ссылаются на другой проект citus: https://github.com/citusdata/citus
Значит ли это, что проект cstore_fdw подлежит закрытию и надо сразу смотреть на citus?

2. В обоих проекта нет скомпилированных пакетов. На тему установки только ссылки для docker да linux. С которыми пока работать не приходилось.
Значит ли это, что для Postgresql под Windows недоступен columnstore? Поясните пожалуйста.

3. Вроде как в MariaDB (продвинутый MySQL) уже есть встроенный columnstore.
Кто-то им пользовался? Есть ли там реализация под Windows?
Сейчас выбираю бесплатный sql-server для несложной БД, однако в ней будет сотни миллионов строк,
поверх которых надо строит аналитические отчеты. Пробовали использовать MS OLAP.
Пробовали как OLAP, так и TABULAR. Но Enterprise sql server ужасно дорогой.
При этом если запилить руками запросы прямо к columnstore базе без использования OLAP,
то работают они также быстро, как и TABULAR (собственно это и есть columnstore база).
И порою быстрее, что старый OLAP, но при этом оперативки требуется гораздо меньше.
Только сам Tabluar в пике съедает 80 ГБт оперативки, а он работает только в оперативке.
Поэтому этот вариант как бы слишком дорогой.
К тому же неудобно пользоваться сводными таблицами EXCEL, когда в фильтрах миллионы строк.

Поэтому есть идея сделать Postgresql или MariaDB columnstore + процедуры, которые выдают сгруппированный и отфильтрованный набор данных, который уже поставлять в сводные таблицы EXCEL.

Ролг Хупин,
по Вашей ссылке ничего путного нет, только старые сообщения в среднем 10 летней давности.
С тех пор MS SQL очень сильно продвинулся, например.
Но сейчас интересует columnstore под windows для Postgre и MariaDB.
Есть ли такое и сравнимы ли они по производительности с MS SQL,
чтобы на 500 млн строк, которые в памяти, запросы заботали в среднем 1 секунду, как в MS SQL?

У MS SQL Server цена теперь зависит от ядер, а не от процессоров, как было давным-давно.
Поэтому на сервак с 44 ядрами (это все ядра, которые видны в диспетчере задач), покупка лицензий коллегам обошлась более 25 млн руб.
Так что вопрос не праздный. Не все на Газпром работают.

Так же предлагали посмотреть на ClickHouse от Яндекса, но опять же это только Linux. Плюс проект молодой и специфичный под Яндекс-Метрику. Толком нельзя делать update/delete (пишут, что вроде как появились, но они асинхронны).
SQL-не особо стандартный.
В общем для людей привыкших к стандартным СУБД под винду - не очень подойдут.
Да и такая ультра-скорость пока не требуется (говорят, что она в 100 000 раз быстрее обычной row-based СУБД).
А вот чтобы загрузка данных и SQL-запросы были как в обычную базу данных - очень бы хотелось.

Установил себе MariaDB под Windows, и columnstore таблиц тоже не нашел.
Читаем тут: https://mariadb.com/kb/en/installing-mariadb-columnstore-5/
Похоже, что оно включено только в MariaDB Enterprise Server, который тоже платный: https://mariadb.com/pricing/

На MariaDB Community Server 10.5 тоже можно поставить самостоятельно, но только под Linux:

https://mariadb.com/docs/features/mariadb-columnstore/

MariaDB ColumnStore is available on select platforms:
CentOS 7 (x86_64)
CentOS 8 (x86_64)
Debian 9 (x86_64)
Debian 10 (x86_64)
Debian 11 (x86_64)
Red Hat Enterprise Linux 7 (x86_64)
Red Hat Enterprise Linux 8 (x86_64)
SUSE Linux Enterprise Server 12 (x86_64)
SUSE Linux Enterprise Server 15 (x86_64)
Ubuntu 18.04 LTS (x86_64)
Ubuntu 20.04 LTS (x86_64)

Похоже, под винду бесплатно только в MS Sql Server Express,
но там только по 10 ГБт на каждую базу, и ограничения по памяти.
Для 20-30 млн строк пробовал - работает прекрасно.
Для небольших проектов самое оно.

Есть мысли? Или только на Linux переходить на старость лет?

PS: MS Sql Server Developer Edition не предлагать, так как нужен только легальный софт.

Доброй ночи, потратил весь рабочий день (плюс коллег) на то, чтобы установить на виртуалку Ubuntu, Posgresql, Citus.
Сделал linked server из MS SQL Server через ODBC, попытался вставить данные из SQL Server в Posgresql в колоночную таблицу. И фиг вам...

ERROR: UPDATE and CTID scans not supported for ColumnarScan

Попытался вставить одну строку через insert into () values(). Так же ошибка.
Далее вернулся в сам PGAdmin (без MS SQL), одна строка вставляется.
Ну думаю, может просто ODBC для Posgresql не работает.

Иду опять в PGAdmin и пишу элементарнейший запрос:
update tableaaaa set prnum = 1

И тоже получаю такую же ошибку?!?!

Далее читаю весь интернет на тему этой ошибки и натыкаюсь на японском сайте на ссылку:
https://docs.citusdata.com/en/v10.2/admin_guide/table_management.html#limitations

Limitations:
Future versions of Citus will incrementally lift the current limitations:
Append-only (no UPDATE/DELETE support)

Это просто шедеврально! Или я чего-то не понимаю в этой жизни, или людям нравится только вставлять записи, а при необходимости обновить или удалить запись - всегда целиком пересоздают таблицу. Это вообще КАК?

И главное, на этом форуме за три года никто об этом не написал. Неужели никто кроме меня не пробовал эти колоночные таблицы в Posgresql + Citus. Или я что-то не так сделал?

Забегая вперед, чтобы не тратить еще день на танцы с бубном (и не дублировать ветки форума). В MariaDB такие же "чудеса техники"?

Мало того, даже для вставки данных Columnstore таблица в PostGreSQL не может понадобиться в реальном проекте, так как вставлять сюда можно только большими кусками, например складывать люда старые логи (благо изменять их не требуется). Даже просто в качестве таблицы логов такой фуфломицин от postgessql не подойдет. Читаем по той же ссылке:

Citus converts rows to columnar storage in “stripes” during insertion. Each stripe holds one transaction’s worth of data, or 150000 rows, whichever is less.

То есть если вставлять обычные свежи логи, то каждая запись будет как бы в отдельном файле (сегменте), поэтому будет не сжатие данных, а их раздувание. Чтобы потом сжать данные (дефграгментировать) надо ПЕРЕСОЗДАВАТЬ таблицу (с остановкой всех сервисов, возможно, на длительное время, чтобы никто не вставил данные в старую копию таблицы):

BEGIN;
CREATE TABLE foo_compacted (LIKE foo) USING columnar;
INSERT INTO foo_compacted SELECT * FROM foo;
DROP TABLE foo;
ALTER TABLE foo_compacted RENAME TO foo;
COMMIT;

Мало того эти старые логи потом невозможно чистить, так как операции DELETE пока тоже не предусмотрено.
Надо опять пересоздавать таблицу, либо заранее делать партиции. Чтобы удалять целиком партициями.

Уж насколько это всё прозрачно в MS SQL - просто нет слов. Он сам делит данные на куски по миллиону, создает словари и сжимает каждый кусок. Новые строки сначала кладет в кучу, и когда их наберется много - только тогда их сжимает. Удаление и вставка не приветствуются, однако работают они так же прозрачно, как в обычной таблице. Просто старая запись по помечается на удаление (номер строки добавляются в список удаленных строк), а новая строка (при обновлении) вставляется в конец. И есть команда для переиндексирования таблицы.

alter index CCSI_Table1 on dbo.Table1 REBUILD
или
alter index ALL on dbo.Table1 REBUILD

Да, таблица блокируется (так как DDL) - все ждут разблокировки, но по крайней мере не требуется заботиться о том, чтобы никто не вставил записи в старую копию таблицы. К тому же реально это пережимать не требуется. Раз в полгода-год подойдет.

Кстати, экспериментировал с бесплатным MS SQL Express на стареньком компе. База на 500 млн строк (10 гб таблица фактов и еще столько же справочники*) запрос работает 30 секунд на SSD, но при этом данные каждый раз считываются с диска, так как в памяти разрешено менее 1 ГБ. На полноценном сервер нужные колонки первый раз считываются в память и далее запрос работает за 0 секунд.

*Справочники плохо сжимаются, так как там зачастую разные текстовые поля.
*Ограничение в 10 ГБ можно официально обойти создав на одном сервере несколько баз данных, например, справочники отдельно, таблица фактов отдельно (или разбить её на партиции по годам - будет еще быстрее).
*Или как не очень честное решение - сделать большую базу на Developer Edition и подменить файлы на заранее созданную базу в Express Edition.

В общем мы пока в поисках - у кого есть реальный опыт использования для OLAP SQL-запросов бесплатной СУБД со всеми стандартными возможностями SQL, включая update/delete (синхронный, а не асинхронный, как в ClickHouse). Желательно и с оконными функциями. Они возможно понадобятся, чтобы посчитать входящий остаток (сумма по строкам в той же группировке, но за предыдущие даты).