Вендор рекомендует XFS или ext4. Наверно, можно попробовать ZFS, то надо много тестировать перед выводом в прод, оффициально такая конфигурация не поддерживаются. Ещё потом возможны проблемы с поддержкой (она у нас есть для ГП).
2) Абсолютно согласен, однако больше данных не влезло в HANA, она падала с OOM при выполнении запросов N1-N3 :) А так как тестирование должно быть равнозначным на всех БД, пришлось довольствоваться малым.
Про не-in-memory — отчасти согласен, GP и Impala — не in-memory-решения, о чём и упомянул в статье. memSQL и HANA — классические in-memory, memSQL, например, при запуске загружает с диска вообще всё в память и работает только с ней. C Exasol и Clickhouse уже зависит от точки зрения :)
Про VoltDB — изначально рассматривали, однако это не совсем SQL-совместимая БД, с этим скорее всего будут сложности — нам нужна прозрачная интеграция с SAP BO. Кроме того, она и не позиционируется как аналитическая (выросла из H-Store, что есть OLTP-решение).
Про число запусков тестовых запросов: везде бралось первое выполнение запроса, при этом экспериментально выяснили, что первое и второе выполнения по времени значительно отличаются только у Exasol — второй раз он отрабатывает значительно быстрее за счёт построенных при первом запуске индексов (впрочем даже время первого выполнения в Exasol всегда значительно меньше, чем второго всех остальных баз). Пример:
Запрос 1-ый 2-ой
T1 1.8 0.1
T2 4.2 0.1
Правильней, конечно же, было выполнить каждый запрос 5-10 раз, отбросить лучшее и худшее и взять среднее от оставшегося, однако тогда тестирование бы затянулось. Кроме того, так как мы рассчитываем на этой базе выполнять в том числе и ad-hoc запросы пользователей, время первого выполнения нам интересней.
Про затраты: да, несмотря на 7-ми кратное преимущество в скорости, можно добиться преимущества покупкой большего числа серверов за те же деньги. Однако нужно помнить, что:
— большее число серверов влечёт за собой бОльшие накладные расходы в кластере;
— возрастает сложность поддержки и администрирования;
— ЦОД не резиновый и тд и тп.
Да и помимо скорости есть и другие параметры, надо оценивать всё в сумме.
Про MemSQL — блин, как вовремя они подсуетились :( Новая версия (5.5, релиз 03.10.2016) обещает "...a new hash table design which combined with Bloom filters delivers up to 3x-5x performance improvements for hash joins".
Сейчас стенды уже разобрали, протестировать не сможем.
1) Нет, узнал о проекте от Вас :) Почитал кратко — проект интересный. Однако, пока настораживают:
— ограниченная поддержка timestamp и decimal
— необходимость наличия Импалы
Что радует, изначально заложена правильная дистрибюция таблиц по интервалу поля/полей.
2) Есть, но рассказать, увы, не смогу. Могу только сказать, что примерно затраты пропорциональны результатам теста производительности в статье :)
Vertica не является в полном смысле in-memory DB. Подозреваем, что она, как и Greenplum, при достаточном объёме памяти в кластере умеет держать все или почти все данные в памяти, но предпочтение при выборе кандидатов отдавалось именно тем, кто позиционирует себя как in-memory.
Исключительно ради экономии времени и никак не ради пиара, вот тут я вкратце описывал архитектуру Greenplum.
Большое спасибо за вывод в opensource, будем тестировать в наших реалиях :) Правда, очень нужен стабильный ODBC-драйвер…
Для ETL используется SAS DI, подробней про нашу интеграцию SAS с GP можно прочитать тут.
Для BI используется SAP BO.
SQL Server мы не используем, не могу судить о производительности.
Да, аутентификация в версии 2.0 работает ок, правда, в дальнейшем хотелось бы увидеть интеграцию с AD. В InfluxDB пока пугает отсутствие функций для обработки данных в метриках.
Спасибо! Рад, что вам понравилось :)
Нет, не пробовали, но были мысли об обратной интеграции — отсылать метрики diamond'ом в zabbix. Навскидку то, о чем говорите вы, вполне реально — можно попробовать забирать данные zabbix напрямую из её БД (повторюсь, это лишь мысли вслух, надо покопаться).
Мы тоже не используем готовое решение. В тех приложениях, где возможна отсылка большого числа алертов, используем очень похожий процесс, только реализован он на SAS Base (исторически так сложилось, что на SAS написана большая часть DWH-инфраструктуры).
Logstash отдельно немного пробовали, разбирали логи Greenplum. Опыт был очень интересный, всё что хотели — получилось, однако дальше разбора не пошли — оказалось намного проще создавать в Greenplum внешние таблицы, смотрящие на файлы логов, и уже их анализировать и визуализировать.
Про не-in-memory — отчасти согласен, GP и Impala — не in-memory-решения, о чём и упомянул в статье. memSQL и HANA — классические in-memory, memSQL, например, при запуске загружает с диска вообще всё в память и работает только с ней. C Exasol и Clickhouse уже зависит от точки зрения :)
Про VoltDB — изначально рассматривали, однако это не совсем SQL-совместимая БД, с этим скорее всего будут сложности — нам нужна прозрачная интеграция с SAP BO. Кроме того, она и не позиционируется как аналитическая (выросла из H-Store, что есть OLTP-решение).
Про число запусков тестовых запросов: везде бралось первое выполнение запроса, при этом экспериментально выяснили, что первое и второе выполнения по времени значительно отличаются только у Exasol — второй раз он отрабатывает значительно быстрее за счёт построенных при первом запуске индексов (впрочем даже время первого выполнения в Exasol всегда значительно меньше, чем второго всех остальных баз). Пример:
Запрос 1-ый 2-ой
T1 1.8 0.1
T2 4.2 0.1
Правильней, конечно же, было выполнить каждый запрос 5-10 раз, отбросить лучшее и худшее и взять среднее от оставшегося, однако тогда тестирование бы затянулось. Кроме того, так как мы рассчитываем на этой базе выполнять в том числе и ad-hoc запросы пользователей, время первого выполнения нам интересней.
Но он у нас есть и используется для других задач, да.
— большее число серверов влечёт за собой бОльшие накладные расходы в кластере;
— возрастает сложность поддержки и администрирования;
— ЦОД не резиновый и тд и тп.
Да и помимо скорости есть и другие параметры, надо оценивать всё в сумме.
Про MemSQL — блин, как вовремя они подсуетились :( Новая версия (5.5, релиз 03.10.2016) обещает "...a new hash table design which combined with Bloom filters delivers up to 3x-5x performance improvements for hash joins".
Сейчас стенды уже разобрали, протестировать не сможем.
— ограниченная поддержка timestamp и decimal
— необходимость наличия Импалы
Что радует, изначально заложена правильная дистрибюция таблиц по интервалу поля/полей.
2) Есть, но рассказать, увы, не смогу. Могу только сказать, что примерно затраты пропорциональны результатам теста производительности в статье :)
Большое спасибо за вывод в opensource, будем тестировать в наших реалиях :) Правда, очень нужен стабильный ODBC-драйвер…
Для BI используется SAP BO.
SQL Server мы не используем, не могу судить о производительности.
Нет, не пробовали, но были мысли об обратной интеграции — отсылать метрики diamond'ом в zabbix. Навскидку то, о чем говорите вы, вполне реально — можно попробовать забирать данные zabbix напрямую из её БД (повторюсь, это лишь мысли вслух, надо покопаться).