Нужна помощь в выборе лучшего механизма хранения MariaDB для нашего варианта использования и ограничений серверного оборудования.
я работаю в небольшой компании, и нам нужно хранилище данных.
Наша производственная база данных содержит около 50 ГБ данных (растет ~10 ГБ в год, в настоящее время), наш сервер немного перегружен, и мы думаем, что можем перенести некоторые исторические данные в хранилище данных. (около половины из этих 50 ГБ можно переместить), чтобы снова обеспечить бесперебойную работу.
Конечно, в хранилище данных будут храниться все данные ETL, а не только исторические данные. Таким образом, мы также можем получать эти дорогостоящие отчеты и данные информационных панелей из хранилища данных, а не с производственного сервера.
Я намереваюсь передать данные в DW и хранить их по схеме «снежинка», а затем я планирую создать несколько киосков данных для отчетности и бизнес-аналитики. Эти витрины данных будут создаваться с использованием звездообразных схем, чтобы сделать запросы проще, (быстрее?).
Мы склонны использовать для этого MariaDB, что подводит меня к моему основному вопросу: какой механизм хранения лучше всего подходит для нашего случая, innoDB или ColumnStore. И насколько это решение повлияет на размеры сервера, на котором он будет работать.
Из того, что я прочитал до сих пор, я предполагаю, что ColumnStore может быть быстрее и лучше подходить для нашего варианта использования, но для этого также потребуется лучшее оборудование. Сейчас мы не можем позволить себе более одного сервера с 4 ядрами ЦП и 32 ГБ ОЗУ (на наш бизнес серьезно повлияла глобальная пандемия. Мы встаем на ноги, но еще не все).
Итак, учитывая приведенные выше характеристики сервера и вариант использования, вы все равно рекомендуете использовать ColumnStore вместо innoDB? Мы даже открыты для решений, отличных от MariaDB.
Движок :InnoDB. Период. (Конечно, 1% случаев использования лучше с чем-то другим, но ваш, похоже, не указывает на необходимость другого движка.)
Snowflake :Ужасно, особенно если нужно искать по "диапазону". Пожалуйста, предоставьте схему (предпочтительно черезSHOW CREATE TABLE); Я буду более конкретным. (Тогда я могу согласиться, что Снежинка хороша, но я сомневаюсь в этом.)
Звездная схема --Хорошо. Нормализация общих строк :хороша. Нормализация «непрерывных» значений (даты, целые числа, числа с плавающей запятой ):плохая. Но цель состоит в том, чтобы сэкономить место на диске и, следовательно, ускорить некоторые запросы.
10 ГБ/год --что в среднем звучит как «несколько» строк в секунду. Тяжелый, но не сильно тяжелый. То есть обработка ETL не звучит так, как будто вам нужна помощь.
Хранилище данных--http://mysql.rjweb.org/doc.php/datawarehouse
Удаление старых данных --Это одно из немногих применений PARTITIONing.http://mysql.rjweb.org/doc.php/partitionmaint
Разбиение на отдельные таблицы, которые хранятся в сети --, может быть хлопотным, но с очень небольшой пользой.
Дорогостоящие отчеты --> Сводные таблицыhttp://mysql.rjweb.org/doc.php/summarytablesСводные таблицы намного меньше, чем таблица фактов; допустима даже денормализация.
Columnstore --Одним из больших плюсов является значительное сжатие, которое он обеспечивает. Но я не считаю ваши 50 ГБ очень большими. Еще одним преимуществом CS является автоматическая «индексация» каждого столбца. Однако только один столбец может использоваться для эффективности поиска на двух -уровнях.
4 ядра --достаточно для InnoDB; больше ядер было бы полезно для CS.
32 ГБ ОЗУ --Всего 50 ГБ данных и 10 ГБ в год --Если все, что вы делаете, это смотрите на данные за последний год, 32 ГБ более чем достаточно. Если вы часто сканируете все 50 ГБ, то будет много операций ввода-вывода. Если вы реализуете сводные таблицы, то 32 ГБ будет излишним для большинства действий. (Сводные таблицы могут иметь размер менее 10 ГБ и возвращаться к началу данных; следовательно, очень кэшируемый.)
32 ГБ + CS --Ваши 50 ГБ станут примерно 5 ГБ. (Но я не знаю, будет ли 32 излишним.)
Сравнение жесткого диска и жесткого диска.SSD --SSD заметно быстрее.
Практический результат (и бюджет)--Упомянутые выше методы могут обеспечить бесперебойную работу InnoDB на 32 ГБ в течение нескольких лет.