У микроинвертороов (Эмфейз к примеру) есть еще одно преймущество, они позволяют DC преобразовать сразу в AC, что убирает много много проблем с кабелем и повышенным напряжением И в Штатах например в затапливоемой зоне ты по идее даже разрешение не получишь на их установку ,если не использовать подобные инверторы НО экономически наверное да, не сильно выгодно
Как все это вижу я.
Запускается это не как скрипт на sql servere а как bush\shell\… скрипт в котором
1. выполняется экспорт из Postgress
как -то так
psql -U… -h 127.0.0.1 -d some_datababse -f /some/path/my_script_name.sql
2. выполняется импорт в sql
/opt/mssql-tools/bin/bcp -S destination -d DBname -U userName -P…
3. очищаете каталог
Прямо открытие, что постгресс позволяет выполнять команды операционной системы из своей оболочки и ничего типа xp_cmdshell для этого не надо
С друго стороны. Можно было присоединить любой диск и выполнить все эти команды без линкед сервера. Т.е не понятна необходимость именно его. Все остальное отлично
Как бы bcp это отдельная утилита, которая может запускаться вне оболочки любой базы данных
Делают эти тесты производители железа
А табличка, ну это самый известный в мире database benchmarks. Подробней можно почитать здесь: www.tpc.org/information/about/abouttpc.asp
Лишний раз убеждаюсь, что Вы постгреса не знаете от слова совсем. Я работал на обеих базах: 5+ лет на МС и 7+ на постгресе, на двух проектах: BI и ETL — в обоих проектах при переходе на постгрес скорость вырастала на порядок.
У меня на гораздо более сложном многоэтажном запросе с несколькими JOIN и агрегатами и базе в несколько гиг постгрес был в 20 раз быстрее на базе БЕЗ ИНДЕКСОВ, чем МС с индексами, включая кластерный, с индексированный VIEW WITH SCHEMABINDING, который как ты знаешь в МС работает гораздо быстрее обычного JOIN-а таблиц и т.п.
К сожалению, с Join'ами на больших таблицах все не так радужно… И мегаспецы с sql.ru так же бессильны. Это лично мой пример, и моя попытка получить помощь www.sql.ru/forum/1199125/has-join
SELECT row_number() over (order by ol_number) rnk,
ol_number
,sum(ol_quantity) AS sum_qty
,sum(ol_amount) AS sum_amount
,avg(ol_quantity) AS avg_qty
,avg(ol_amount) AS avg_amount
,count(*) AS count_order
FROM order_line
GROUP BY ol_number
ORDER BY ol_number;
Жду время выполнения этого запроса.
Последняя версия, на которой я это тестировал была
PostgreSQL 9.6.0 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit
И результат был мягко говоря не радостный.
Как по мне — типичная задача BI на не самых больших данных
Спасибо за серию статей.
На самом деле проделана огромная работа
Я не уверен, что мог бы себе позволить вырезать из жизни такой кусок, для написания подобной статьи.
Так держать!
ЭТо бы было крайне любопытно.
Как раз сейчас идет обсуждение подобного теста на sql.ru (http://www.sql.ru/forum/1222372/agregaciya-dannyh-100-mln-strok)
А я недавно проводил тестирование на по такой методологии: https://db.in.tum.de/research/projects/CHbenCHmark/?lang=en
На таких платформах:
HANA
Oracle 12.x
DB2-10.5(blue)
Memsql
Posgresql (9.6 betta)
SQL Server 2016
Данных было чуть поменьше, чем у вас…
Но запросов побольше (22)
SQL server был лучшим в этом сравнении… все 22 запроса выполнились за час более 50 раз.
Второй, кстати была HANA
К примеру, Posgresql не успел выполнить все эти запросы за час дважды.
Сами данные, если кому интересно можно найти здесь:
Жалко… Тем более что инженерам HANA вы такой доступ предоставили :(
Сколько нод вы использовали для GreenPlum и для Exasol?
Присоеденяюсь с к просьбе Обесличивания баз данных… По идее это только номера счетов
У микроинвертороов (Эмфейз к примеру) есть еще одно преймущество, они позволяют DC преобразовать сразу в AC, что убирает много много проблем с кабелем и повышенным напряжением
И в Штатах например в затапливоемой зоне ты по идее даже разрешение не получишь на их установку ,если не использовать подобные инверторы
НО экономически наверное да, не сильно выгодно
Запускается это не как скрипт на sql servere а как bush\shell\… скрипт в котором
1. выполняется экспорт из Postgress
как -то так
psql -U… -h 127.0.0.1 -d some_datababse -f /some/path/my_script_name.sql
2. выполняется импорт в sql
/opt/mssql-tools/bin/bcp -S destination -d DBname -U userName -P…
3. очищаете каталог
С друго стороны. Можно было присоединить любой диск и выполнить все эти команды без линкед сервера. Т.е не понятна необходимость именно его. Все остальное отлично
Как бы bcp это отдельная утилита, которая может запускаться вне оболочки любой базы данных
А табличка, ну это самый известный в мире database benchmarks. Подробней можно почитать здесь:
www.tpc.org/information/about/abouttpc.asp
И что такое TOP-500?
А мужики то оказывается не в курсе…
Позвольте, а где же здесь Постгресс??
www.tpc.org/tpch/results/tpch_advanced_sort.asp?PRINTVER=false&FLTCOL1=ALL&ADDFILTERROW=&filterRowCount=1&SRTCOL1=h_sponsor&SRTDIR1=ASC&ADDSORTROW=&sortRowCount=1&DISPRES=100+PERCENT&include_withdrawn_results=none&include_historic_results=no
Наверное мешки таскать — не языком чесать?
К сожалению, с Join'ами на больших таблицах все не так радужно… И мегаспецы с sql.ru так же бессильны. Это лично мой пример, и моя попытка получить помощь
www.sql.ru/forum/1199125/has-join
Но я ожидал такой ответ :)
что бы не быть голословным можешь выкачать этот набор данных:
northcentr.blob.core.windows.net/tpcc/order_line.txt
(8,6GB)
Это CSV с разделителем tab
Загрузить в PostgreSQL
Прооптимизированный, куда же без этого :)
и выполнить запрос:
Жду время выполнения этого запроса.
Последняя версия, на которой я это тестировал была
И результат был мягко говоря не радостный.
Как по мне — типичная задача BI на не самых больших данных
На самом деле проделана огромная работа
Я не уверен, что мог бы себе позволить вырезать из жизни такой кусок, для написания подобной статьи.
Так держать!
--415,563 MB
--425,536 MB
проверял, работает на этой:
Microsoft SQL Server vNext (CTP1) — 14.0.1.246 (X64)
Nov 1 2016 23:24:39
Copyright © Microsoft Corporation
on Linux (CentOS Linux 7 (Core))
https://msdn.microsoft.com/en-us/library/mt790580.aspx
Есть шансы на данные?
Как раз сейчас идет обсуждение подобного теста на sql.ru (http://www.sql.ru/forum/1222372/agregaciya-dannyh-100-mln-strok)
А я недавно проводил тестирование на по такой методологии: https://db.in.tum.de/research/projects/CHbenCHmark/?lang=en
На таких платформах:
HANA
Oracle 12.x
DB2-10.5(blue)
Memsql
Posgresql (9.6 betta)
SQL Server 2016
Данных было чуть поменьше, чем у вас…
Но запросов побольше (22)
SQL server был лучшим в этом сравнении… все 22 запроса выполнились за час более 50 раз.
Второй, кстати была HANA
К примеру, Posgresql не успел выполнить все эти запросы за час дважды.
Сами данные, если кому интересно можно найти здесь:
https://northcentr.blob.core.windows.net/tpcc/customer.txt 9g
https://northcentr.blob.core.windows.net/tpcc/district.txt 1m
https://northcentr.blob.core.windows.net/tpcc/history.txt 1g
https://northcentr.blob.core.windows.net/tpcc/item.txt 8m
https://northcentr.blob.core.windows.net/tpcc/nation.txt 10kb
https://northcentr.blob.core.windows.net/tpcc/order_line.txt 9g
https://northcentr.blob.core.windows.net/tpcc/orders.txt 1g
https://northcentr.blob.core.windows.net/tpcc/region.txt .5m
https://northcentr.blob.core.windows.net/tpcc/stock.txt 14g
https://northcentr.blob.core.windows.net/tpcc/supplier.txt 2mb
https://northcentr.blob.core.windows.net/tpcc/warehouse.txt 40kb
Сколько нод вы использовали для GreenPlum и для Exasol?
Присоеденяюсь с к просьбе Обесличивания баз данных… По идее это только номера счетов
Я тогда обязуюсь протестирвать Azure Datawarehouse и SQL Server (таблицы в inmemory)